Переключение от MySQL до Cassandra - профессионалы/Недостатки?

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

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

Реляционные функции мне было бы нужно -

• Порядок [SliceRange в API Cassandra кажется satisy этим]
• Группа
• Отношения Manytomany между несколькими таблицами [Cassandra SuperColumns, кажется, преуспевают для одного многим]
• Сфинкс на этом дает мне хорошую полнотекстовую систему, таким образом, это - необходимость также. [На Cassandra проект Lucandra, кажется, удовлетворяет эту потребность]

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

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

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

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

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

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

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

Спасибо.