Переход с MySQL на Cassandra - Плюсы / Минусы?
https://stackoverflow.com/questions/2332113
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Немного предыстории - этот вопрос касается проекта, работающего на одном небольшом экземпляре EC2, и собирается перейти на средний.Основными компонентами являются Django, MySQL и большое количество пользовательских инструментов анализа, написанных на python и java, которые выполняют тяжелую работу.На той же машине также работает Apache.
Модель данных выглядит следующим образом - большой объем данных в реальном времени поступает потоком с различных сетевых датчиков, и в идеале я хотел бы установить подход с длительным опросом, а не подход с текущим опросом каждые 15 минут (ограничение вычислительной статистики и записи в саму базу данных).Как только данные поступают, я сохраняю необработанную версию в MySQL, разрешаю инструментам анализа работать с этими данными и сохраняю статистику еще в нескольких таблицах.Все это визуализируется с помощью Django.
Реляционные функции, которые мне понадобились бы -
- Заказать по [SliceRange в API Кассандры, похоже, удовлетворяет этому]
- Сгруппировать по
- Множество связей между несколькими таблицами [Суперколонны Cassandra, похоже, хорошо работают от одного до многих]
- Sphinx в этом дает мне хороший полнотекстовый движок, так что это тоже необходимо. [На Cassandra проект Lucandra, похоже, удовлетворяет эту потребность]
Моя главная проблема заключается в том, что чтение данных происходит чрезвычайно медленно (и запись тоже не такая уж горячая).Я не хочу тратить на это много денег и оборудования прямо сейчас, и я бы предпочел что-то, что можно легко масштабировать со временем.Вертикальное масштабирование MySQL в этом смысле нетривиально (или дешево).
Итак, по сути, после того, как я много прочитал о NOSQL и поэкспериментировал с такими вещами, как MongoDB, Cassandra и Voldemort, мои вопросы таковы,
На экземпляре EC2 среднего размера, получу ли я какие-либо преимущества при чтении / записи, перейдя на что-то вроде Cassandra? Эта статья (pdf) определенно, кажется, наводит на мысль об этом.В настоящее время я бы сказал, что несколько сотен записей в минуту были бы нормой.Для чтения - поскольку данные меняются каждые 5 минут или около того, аннулирование кэша должно происходить довольно быстро.В какой-то момент он также должен быть способен обрабатывать большое количество одновременных пользователей.Производительность приложения в настоящее время снижается при выполнении MySQL некоторых объединений в больших таблицах, даже если созданы индексы - для рендеринга чего-то порядка 32 тысяч строк требуется больше минуты.(Это также может быть артефактом виртуализированного ввода-вывода EC2).Размер таблиц составляет около 4-5 миллионов строк, и таких таблиц насчитывается около 5.
Все говорят об использовании Cassandra на нескольких узлах, учитывая теорему CAP и возможную согласованность.Но для проекта, который только начинает расти, имеет ли это смысл развернуть сервер cassandra с одним узлом?Есть ли какие-то предостережения?Например, может ли он заменить MySQL в качестве серверной части для Django?[Рекомендуется ли это?]
Если я сделаю shift, я предполагаю, что мне придется переписать части приложения, чтобы сделать намного больше "администрирования", поскольку мне пришлось бы выполнять несколько поисковых запросов для извлечения строк.
Имеет ли какой-либо смысл просто использовать MySQL в качестве хранилища ключевых значений вместо реляционного движка, и идти с этим?Таким образом, я мог бы использовать большое количество доступных стабильных API, а также стабильный движок (и переходить на реляционный режим по мере необходимости).(Сообщение Бретта Тейлора из Friendfeed об этом - http://bret.appspot.com/entry/how-friendfeed-uses-mysql)
Мы были бы очень признательны за любую информацию от людей, которые провели смену!
Спасибо.
Решение
Cassandra и другие распределенные базы данных, доступные сегодня, не обеспечивают поддержку одноранговых запросов, к которой вы привыкли в sql.Это связано с тем, что вы не можете эффективно распределять запросы с помощью объединений, поэтому вместо этого акцент делается на денормализации.
Тем не менее, Cassandra 0.6 (бета-версия официально выйдет завтра, но вы можете создать ветку 0.6 самостоятельно, если вам не терпится) поддерживает Hadoop map / reduce для аналитики, что на самом деле кажется подходящим для вас.
Cassandra обеспечивает отличную поддержку для безболезненного добавления новых узлов, даже в начальную группу из одного.
Тем не менее, при скорости в несколько сотен записей в минуту вы будете в порядке с mysql в течение долгого, долгого времени.Cassandra намного лучше справляется с ролью хранилища ключей / значений (еще лучше - key / columnfamily), но MySQL намного лучше справляется с ролью реляционной базы данных.:)
Поддержки django для Cassandra (или другой базы данных nosql) пока нет.Они говорят о том, чтобы сделать что-то для следующей версии после 1.2, но, судя по разговорам с разработчиками django в pycon, никто пока не уверен, как это будет выглядеть.
Другие советы
Если вы разработчик реляционных баз данных (как и я), я бы посоветовал / указал:
- Приобретите некоторый опыт работы с Cassandra, прежде чем приступать к ее использованию в производственной системе...особенно, если эта производственная система имеет жесткие сроки завершения.Может быть, сначала использовать его в качестве серверной части для чего-то неважного.
- Делать простые вещи, которые я считаю само собой разумеющимися в отношении манипулирования данными с помощью движков SQL, оказывается сложнее, чем я ожидал.В частности, индексирование данных и сортировка результирующих наборов нетривиальны.
- Моделирование данных также оказалось сложной задачей.Как разработчик реляционных баз данных, вы приступаете к работе с большим багажом...вы должны быть готовы научиться моделировать данные совсем по-другому.
Сказав все это, я настоятельно рекомендую построить что - то в Кассандре.Если вы похожи на меня, то это бросит вызов вашему пониманию хранения данных и заставит вас переосмыслить подход к реляционной базе данных для всех ситуаций, о котором я даже не подозревал.
Некоторые хорошие ресурсы, которые я нашел, включают:
Django-cassandra - это ранний бета-режим.Также Django не был создан для баз данных без sql.Ключ в Django ORM основан на SQL (Django рекомендует использовать PostgreSQL).Если вам нужно использовать ТОЛЬКО no-sql (вы можете смешивать sql и no-sql в одном приложении), вам нужно рискованно использовать no-sql ORM (это значительно медленнее, чем традиционный SQL orm или прямое использование хранилища No-SQL).Или вам нужно будет полностью переписать django ORM.Но в данном случае я не могу предположить, зачем вам нужен Django.Может быть, вы можете использовать что-то другое, например, Tornado?
