Переход с MySQL на Кассандру - плюсы и минусы? - PullRequest
Новая
       18

Переход с MySQL на Кассандру - плюсы и минусы?

58 голосов
/ 25 февраля 2010

Для некоторой предыстории - этот вопрос касается проекта, работающего на одном маленьком экземпляре EC2, и собирается перейти на средний. Основными компонентами являются Django, MySQL и большое количество пользовательских инструментов анализа, написанных на Python и Java, которые делают тяжелую лифтинг. На той же машине работает Apache.

Модель данных выглядит следующим образом: большое количество данных в реальном времени поступает в потоковом режиме с различных сетевых датчиков, и в идеале я бы хотел использовать метод длинных опросов, а не текущий опрос каждые 15 минут ( ограничение вычислительной статистики и записи в саму базу данных). Как только данные поступают, я сохраняю сырую версию в MySQL, пусть инструменты анализа теряют эти данные и сохраняют статистику в следующих нескольких таблицах. Все это визуализируется с использованием Django.

Реляционные функции, которые мне нужны -

  • Заказ по [SliceRange в API Кассандры, кажется, удовлетворяет этому]
  • Группировка по
  • Многочисленные отношения между несколькими таблицами [Cassandra SuperColumns, кажется, преуспевают для одного ко многим]
  • Сфинкс дает мне хороший текстовый движок, так что это тоже необходимо. [На Кассандре проект Lucandra, кажется, удовлетворяет эту потребность]

Моя основная проблема заключается в том, что чтение данных происходит очень медленно (и записи не так уж горячи). Я не хочу сейчас тратить на это много денег и оборудования, и я бы предпочел что-то, что может легко масштабироваться со временем. Вертикальное масштабирование MySQL не является тривиальным в этом смысле (или дешевым).

По сути, после того, как я много прочитал о NOSQL и поэкспериментировал с такими вещами, как MongoDB, Cassandra и Voldemort, мои вопросы таковы:

  • На среднем экземпляре EC2 получу ли я какие-либо преимущества при чтении / записи, перейдя к чему-то вроде Cassandra ? Эта статья (pdf) определенно предполагает это. В настоящее время я бы сказал, что несколько сотен записей в минуту будет нормой. Для чтения - поскольку данные меняются каждые 5 минут или около того, аннулирование кэша должно происходить довольно быстро. В какой-то момент он также сможет обрабатывать большое количество одновременно работающих пользователей. Производительность приложения в настоящее время снижается на MySQL, выполняющем некоторые объединения на больших таблицах, даже если создаются индексы - на рендеринг чего-то порядка 32 тыс. Строк уходит больше минуты. (Это может быть и артефакт виртуального ввода-вывода EC2). Размер таблиц составляет около 4-5 миллионов строк, таких таблиц около 5.

  • Каждый говорит об использовании Cassandra на нескольких узлах, учитывая теорему CAP и возможную согласованность. Но для проекта, который только начинает расти, имеет смысл развернуть сервер cassandra с одним узлом ? Есть ли какие-то предостережения? Например, может ли он заменить MySQL в качестве бэкэнда для Django? [Это рекомендуется?]

  • Если я сделаю сдвиг, я предполагаю, что мне придется переписать части приложения, чтобы сделать намного больше «администрирования», так как мне пришлось бы делать несколько поисков для извлечения строк.

  • Имеет ли смысл просто использовать MySQL в качестве хранилища значений ключей , а не реляционный движок, и пойти с этим? Таким образом, я мог бы использовать большое количество доступных стабильных API, а также стабильный движок (и переходить по мере необходимости). (Сообщение Бретта Тейлора от Friendfeed об этом - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)

Буду признателен за любые идеи людей, которые сделали смену!

Спасибо.

Ответы [ 3 ]

38 голосов
/ 25 февраля 2010

Cassandra и другие распределенные базы данных, доступные сегодня, не предоставляют поддержку специальных запросов, к которой вы привыкли из sql. Это потому, что вы не можете распределять запросы с производительными соединениями, поэтому вместо этого акцент делается на денормализацию.

Тем не менее, Cassandra 0.6 (бета-версия официально выйдет завтра, но вы можете собрать из ветки 0.6 самостоятельно, если вам не терпится) поддерживает Hadoop map / lower для аналитики, что на самом деле кажется вам подходящим.

Cassandra обеспечивает отличную поддержку для добавления новых узлов безболезненно, даже для начальной группы из одного.

Тем не менее, при нескольких сотнях записей в минуту вы будете хорошо работать с MySQL в течение очень долгого времени. Cassandra намного лучше работает как хранилище ключей / значений (даже лучше, key / columnfamily), но MySQL гораздо лучше, если она является реляционной базой данных. :)

Пока нет поддержки django для Cassandra (или другой базы данных nosql). Они говорят о том, чтобы сделать что-то для следующей версии после 1.2, но, основываясь на разговоре с разработчиками django на pycon, никто пока не уверен, как это будет выглядеть.

19 голосов
/ 06 мая 2011

Если вы разработчик реляционных баз данных (как и я), я бы посоветовал / указал:

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

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

Вот некоторые полезные ресурсы, которые я нашел:

1 голос
/ 11 января 2013

Джанго-Кассандра - ранний бета-режим. Также Django не сделал для баз данных без SQL. Ключ в Django ORM основан на SQL (Django рекомендует использовать PostgreSQL). Если вам нужно использовать ТОЛЬКО no-sql (вы можете смешивать sql и no-sql в одном приложении), вам нужно рискованно использовать ORM no-sql (это значительно медленнее, чем традиционные SQL-формы или прямое использование хранилища No-SQL). Или вам нужно будет полностью переписать Django ORM. Но в этом случае я не могу предположить, зачем тебе Джанго. Может быть, вы можете использовать что-то еще, например, Торнадо?

...