HighLoad.org – блог о высоких нагрузках
HighLoad.org > DIGG: рост производительности 4000% благодаря сортировке в PHP, а не в MySQL

DIGG: рост производительности 4000% благодаря сортировке в PHP, а не в MySQL
2010-03-25 07:00 my_fess  
James Turner взял очень содержательное интервью у Joe Stump (технический директор SimpleGeo и ведущий разрработчик архитектуры Digg), в котором Joe, как обычно, дал несколько инсайдерских комментариев о своем опыте использования Cassandra и MySQL. Так как Digg начинал с использованием MySQL-ориентированной архитектуры и недавно на полной скорости начал переходить на Cassandra, то его наблюдения, выученные уроки и мотивы для перехода особенно ценны.
Здесь приведены некоторые ключевые моменты, которые для вас будут полезны:
  1. Предварительные вычисления при записи делают чтение более быстрым. Это довольно старый прием как стратегия масштабирования, но полезно посмотреть, как SimpleGeo применяет это для решения своей задачи нахождения записей с конкретным географическим регионом. С использованием Cassandra они построили два кластера: один для индексов и другой для записей. В кластере с записями, как вы могли себе представить, используется простой поиск по данным. На кластере с индексами тщательно построен индекс для любого сценария поиска. Индексы вычисляются при записи, поэтому чтение очень быстрое. Это очень правильно, так как чтение доминирует. Запросы, основанные на времени, тоже превычисляются. Joe упомянул несколько специальных алгоритмов для распределения данных, которые должны быть объединены по географическому признаку, но не конкретизировал.
  2. Поставить ограничения на действия пользователя. Система получается более простой, если открытые завершенные запросы не разрешены. Пользователям разрешено выполнять четко определенные операции, завершающиеся сильно оптимизированными поисками. Им не нужно существование общих данных, они хотят хорошо обслуживать геоданные.
  3. Реляционная цепочка утилит не работает для риалтайма. Цепочка инструментов реляционной базы данных не подходит. Это не работает для большой масштабируемости и для риалтаймового окружения. Построение масштабируемых систем на реляционной базе данных требует построения шардинга, балансировки нагрузки, решардинга, и других уровней, так спрашивается, для чего все эти мучения? Cassandra делает все это за вас прямо из коробки. Отрубите сервер и Cassandra сама автоматически сделает переделку мапирования и перестроение маршрутов.
  4. Практика масштабирования приводит нас от реляционных баз данных к нереляционным базам данных. Для масштабирования Digg они использовали несколько методов, очень похожих на те, что использовались в eBay. Нет JOIN-ов, нет ограничений по внешним ключам (для правильного масштабирования), поиск только по первичному ключу, ограничен диапазон запросов и JOIN-ы выполняются в оперативной памяти. Во время реализации возможности комментирования рост производительности в 4000% был достигнут использованием сортировки в PHP вместо MySQL. Все эти усилия былти необходимы для того, чтобы сделать реляционную базу данных масштабируемой так же, как нереляционная база данных. Почему бы тогда с самого начала не использовать нереляционную базу данных?
  5. Брать на вооружение и расширять существующие продукты вместо того, чтобы создавать свой собственый. Cassandra позволила SimpleGeo создать необходимые политики партиционирования данных для лучшего распределения данных. Это означает, что подогнаную базу данных не нужно было создавать, существующая база данных может быть расширена для того, чтобы работать необычайно мощно, сохраняя при этом преимущества хорошо поддерживаемой высокофункциональной базы данных. Этот урок уже также выучили Justin.tv и это будет становиться все более важной стратегией с возрастанием сложности.
  6. Масштабирование подразумевает под собой специализацию. Для масшатбирования часто требуется построить сильно подогнаное, специфичное для данной проблемы решение.
  7. MySQL работает хорошо для некоторого набора проблем. Обычно — для относительно статичного множества данных, относительно небольшого объема запросов и относительно высоких требований к времени отклика.

Автор статьи: Todd Hoff Дата: 23 марта 2010 Оригинал статьи


комментарии [0]  | комментировать

  © 2010-2018 HIGHLOAD