среда, 24 февраля 2010 г.

Cassandra и Twitter: интервью с Райаном Кингом

Недавно появились слухи о том, что в Twitter планируют использовать Cassandra. И вот блогер, специализирующийся на не-SQL базах данных решил пообщаться с одним из разработчиков Twitter на эту тему. Ниже следует перевод этого интервью. Курсив - мой.

Не могли бы Вы начать с проблемы, которая заставила вас обратиться к не-SQL базам данных?

Райан Кинг: У нас очень много данных. Объем данных постоянно увеличивается и скорость увеличения объемов данных тоже постоянно увеличивается.
В данный момент у нас задействована система из связки MySQL + memcache, но в последнее время она стала неоправданна затратной с точки зрения её поддержки. Нам нужна система, которая могла бы расти в более автоматизированно и быть высоко-доступной (что сие есть).

Я думаю, что вы исследовали много разных решений, какие вы рассматривали, как возможные?
Райан Кинг:
  • Автоматизировать расширения связки с MySQL;

  • Различные базы данных:HBase, Voldemort, MongoDB, MemcacheDB, Redis, Cassandra, HyperTable и, наверное, еще какие-то, о которых я уже забыл.


Как проходило тестирование и оценка всех этих систем?

Райан Кинг: Сначала мы оценивали архитектуру каждого решения. Для этого составили ряд вопросов:
  • Как нам добавлять в систему новые машины?

  • Существуют ли критические точки поломки в системе?

  • Масштабируется ли запись в систему?

  • Насколько велика потребность в администрировании системы?

  • Если она открыта, существует ли полноценное сообщество?

  • Насколько велики будут наши затраты времени и усилия в целом для установки системы и интеграции её с нашей?

  • Используется ли технология, которая нам подходит? (Оценивались относительно готовые решения, которые могли работать на разных принципах. Этот пункт именно и относится к оценке принципа работы, а не самого решения.)

Эти вопросы очень сильно сузили наш выбор. Фактически они исключили из рассмотрения всё кроме Cassandra. Сделав такой выбор, мы стали тестировать функциональность ("можем ли мы сделать нормальную модель данных с этой системой в нашей области?") и работу под нагрузкой. В последнем случае мы концентрировались в основном на записи. В среднесрочном/долгосрочном периоде мы бы хотели работать без кэша данных перед помещением их в Cassandra, но в данный момент у нас уже есть большой memcache-ресурс и опыт в таком масштабировании трафика.

Если подводить итог, какие факторы стали решающими при выборе именно Cassandra?
Райан Кинг:
  • Отсутствие критических точек.

  • Высокая масштабируемость записи (наш трафик очень разнороден во времени).

  • Здоровое и производительное сообщество.


Полностью ли Cassandra заменит существующее решение?
Райан Кинг: Да, со временем. Сейчас мы переносим нашу саму большую (и требующую больше всего усилий для её поддержки) таблицу - таблицу статусов, которая содержит все твиты и ретвиты. После этого мы начнем использовать Cassandra для новых проектов и начнем миграцию других таблиц.

Как вы планируете переносить существующие данные?
Райан Кинг: У нас есть элегантная система динамического контроля функционала на сайте. Обычно мы используем её для постепенного развертывания нового функционала среди всех пользователей. Мы используем эту же систему для постепенной смены инфраструктуры.
Таким образом, для того чтобы перейти на новую базу данных мы:
  1. Пишем код, который может вести запись в Cassandra параллельно с MySQL, но держим его неактивным при помощи упомянутой выше системы.

  2. Медленно включаем запись в Cassandra (это мождно сделать, как "включить эту функцию только для работников" или "включить эту функцию для 1,2% пользователей")

  3. Находим баг:)

  4. Выключаем новый функционал.

  5. Исправляем баг.

  6. Переходим ко второму пункту.

Со временем мы придем к ситуации, когда 100% наших записей дублируются. Тогда мы:
  1. Берем архивную базу из MySQL.

  2. Запускаем импорт в Cassandra. Несколько слов об импорте. Сначала мы пытались использовать интерфейс BinaryMemtable (Этот интерфейс используют, например, в Digg), но он оказался слишком быстрым - его использование перегрузило бы нашу сеть. Мы переключились на использование Thrift (Протокол, разработанный в Facebook) и до сих пор его используем. Весь процесс занимает сейчас около недели. С бесконечной пропускной способностью сети на нашем кластере мы могли бы сделать это примерно за 7 часов.

  3. Когда данные будут импортированы, мы опять включим запись нового трафика Cassandra (параллельно с MySQL). Опять постепенно по группам пользователей и по процентам.

  4. Когда мы будем удовлетворены новой системой (мы используем реальные данные для оценки качества нового хранилища данных) мы постепенно начнем выключать запись в базы данных MySQL.

Философская заметка - наш процесс перехода к новой ключевой инфраструктуре можно описать, как "сначала интегрировать, потом переходить". Мы пытаемся интегрировать новые системы в код как можно раньше, но включить их только для небольшого числа людей. Это позволяет нам параллельно переходить к новому во многих аспектах: в дизайне, разработке, функционировании и т.д.

Скажите о чем-нибудь, о чем я не задал вопрос, а следовало бы.
Райан Кинг: Да я больше ничего и не придумаю.

Большое Вам спасибо!
blog comments powered by Disqus