Pull to refresh

Comments 19

Спасибо за статью, жаль ее не было, когда я так в ней нуждался :)

Как раз недавно делал аналитику и БД была Cassandra
Вкратце — задача была хранить логи действий пользователей в системе и потом на основе этих данных выводить статистику

Так вот
1) действительно столкнулся с проблемой каунтеров (но без них тяжеловато было бы вести подсчет)

2) данные действительно очень денормализуются, вместо 1 коассической реляционной таблицы получилось 12 «кассандровских»
Правда потом уменьшилось до 4, так как часть работы по аггрегации данных вынеслась в логику приложения

В остальном пока все отлично, вставка действительно очень быстрая, выборка при правильно аггрегированных данных тоже работает хорошо
Ещё кассандра хороша, как движок для хорошего параллельного hash-merge join'а =)
Подтверждаю, со многим столкнулся. И в моем случае postgresql показал лучшие результаты по скорости выборки. И вместо mysql+C* просто перешел на postgres.
Ну тут вы уж загнули. если задачу можно решить с помощью реляционных БД, то её нужно решить с помощью реляционных БД.
Я вообще не вижу смысла в инструментах типа C*, если ваш набор данных может обработать одна машина.
Дело в том, что задача — накопление данных скажем по датчикам, чтото типа timeseries (что как раз хорошо ложится в идею К). Можно решить реляционными БД? Конечно, но хотелось использовать чтото заточенное под накопление данных. После сравнительных тестов мускль, К (4 ноды в кластере) и простой постгрес. Победил постгрес по всем показателям.
Для накопления данных неплохи всякие решения типа rrd, influx, carbon/whisper, если data flow понятен на этапе проектирования
Да, но rrd/carbon не подходил — выборки не только по time индексу, в К держал двойную-тройную копию данных под разные запросы. influxdb на тот момент был еще слишком молод.
influxdb не подходит по тем же причинам (кастомные индексы насколько я знаю должны появится в 0.9).
pg справился хорошо — одна большая таблица и несколько индексов.
так ведь о том и речь. C* не заточена под абстрактное «накопление данных», она заточена под задачи, в которых вам 100% не хватит одной машины (с PG, не с PG, не важно). просто если рано или поздно PG начнёт захлёбываться, и вам придётся выписывать кульбиты с шардингом и репликациями (и множеством сопутствующих проблем), C* позволит линейно и безотказно расширяться с помощью лишь одной команды в консоли.
В ближайшие пару-тройку лет сможем расширятся вертиально. Память и диск сейчас достаточно дешевые. Потом будем думать.
Если речь заходит об аналитике на больших данных, map-reduce и всё такое, то надо смотреть в сторону HBase. Это хранилище спроектированно именно для этих целей. Кассандра больше подходит для географически распределенных систем, с повышенной доступностью.
Вопрос по п.5.
Почему update и insert — это одно и то же? Afaik в C* это разные вещи.
Отличается только тем, что Insert не работает с каунтерами, в остальном — одно и тоже
И да — по факту и Insert, и Update это Upsert :)
По поводу для чего придумали CQL.
Подход мне тоже не очень нравится — там внутри неочевидная магия делается, которую чтобы понять надо знать как физически хранятся данные.
Однако программировать через альтернативный Thrift API — это застрелиться, достаточно тяжело, т.ч. SQL-like язык нужен и полезен.
Был ещё кроме голого thrift'а довольно удобный hector
Sign up to leave a comment.

Articles