Переключение с MySQL на Cassandra-Плюсы / Минусы?

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

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

реляционные функции, которые мне понадобятся -

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

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

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

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

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

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

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

любые идеи от людей, которые сделали сдвиг будет очень признателен!

спасибо.

58
cassandra django migration mysql nosql

3 ответов

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

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

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

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

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

38

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

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

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

некоторые хорошие ресурсы, которые я нашел включают в себя:

19

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

1