Переход от MySQL к Cassandra - за/против?

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

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

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

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

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

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

На средстве EC2, , я получу какие-либо преимущества при чтении/записи, перейдя на что-то вроде Cassandra? Эта статья (pdf) определенно, похоже, предполагает это. В настоящее время я бы сказал, что несколько сотен записей в минуту будут нормой. Для чтения - поскольку данные изменяются каждые 5 минут или около того, кэш-недействительность должна произойти довольно быстро. В какой-то момент он должен иметь возможность обрабатывать большое количество одновременно работающих пользователей. Производительность приложения в настоящее время убивается, когда MySQL выполняет некоторые объединения на больших таблицах, даже если индексы создаются - что-то порядка 32 тыс. Строк занимает больше минуты, чтобы отобразить. (Это может быть артефактом виртуализованного ввода-вывода EC2). Размер таблиц составляет около 4-5 миллионов строк, а их около 5.
Все говорят об использовании Cassandra на нескольких узлах, учитывая теорему CAP и возможную согласованность. Но для проекта, который только начинает расти, имеет смысл для развертывания одного node сервера cassandra? Есть ли какие-либо оговорки? Например, может ли он заменить MySQL в качестве backend для Django? [Это рекомендуется?]
Если я смену, я предполагаю, что мне придется переписать части приложения, чтобы сделать намного больше "административной", так как мне придется делать несколько поисков для извлечения строк.
Будет ли смысл использовать MySQL как хранилище ключевых значений, а не реляционный движок, и пойти с этим? Таким образом, я мог бы использовать большое количество стабильных API-интерфейсов, а также стабильный движок (и по мере необходимости переходить к реляционным). (Сообщение Бретта Тейлора от Friendfeed на этом - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)

Любые идеи людей, сделавших смену, будут очень благодарны!

Спасибо.

Ответ 1

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

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

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

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

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

Ответ 2

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

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

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

Некоторые полезные ресурсы, которые я нашел, включают:

Ответ 3

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