Comments 16
Что-то прям не доверяю я фразе про то, что C* - одна из самых популярных колоночных СУБД. Вещь очень нишевая и применяется сегодня редко, потому что хоть и писать в нее легко, но читать из нее и сделать правильную схему - это рокет сайнс. С появлением Clickhouse, а до этого с Vertica, кажется, что C* вообще нафиг никому не надо сегодня...
А код из "Простой пример работы с Cassandra" - это прямо живой антипаттерн.
rows = session.execute("SELECT * FROM users")
for row in rows:
print(row.id, row.name, row.email)Вот это сделает "кря" на реальной БД как пить дать в C*. А все потому, что C* только притворяется СУБД с поддержкой SQL, а по факту это просто Redis с кучей скрытого в тени под типа CQL.
С появлением Clickhouse, а до этого с Vertica, кажется, что C* вообще нафиг никому не надо сегодня...
Только одна ОЛАП а другая ОЛТП
Ничего не сделает кря. Спокойно выполнится запрос. Не очень эффективно конечно и будут проблемы, если одна из нод лежит в кластере, но выполнится. Хоть там петабайт в таблице данных.
На redis это мало похоже хотя бы потому, что оно скейлится действительно и отказоустойчиво в отличии от. Сравнивать с CH и Vertica тоже некорректно, ибо принципиально разные базы для совершенно разных нагрузок и объемов данных.
А популярность касандры сложно оспаривать. Повсюду она в применении. Читать из нее и сделать нормальную схему ничего сложного не представляет. У нее очень простые правила хранения данных и того, как выполняются запросы. Намного проще, чем в реляционных базах. Все предсказуемо и понятно. От того, не каждый тип запросов можно вообще реализовать на ней.
Не знаю не знаю. По таймауту свалится, насколько я помню без сужения через partition key, cluster key и т.п.
Не свалится. Это не реляционная база. Постранично запрашивайте сколько влезет и все будет ок.
Я не специалист в С*, сразу оговорюсь.
Но, давайте честно говорить, что C* - это KV-store. Если с ней работать не как с KVS - будет больно. Особенно больно будет операциям записи, которые после commit log-а начнут пытаться партиционироваться и столкнутся лбом с операциями чтения.
В общем, мы использовали успешно C* только как KVS, причем со связкой через Kafka. Для всего, что связано с "запросами", которые C* пытается исполнять, делая вид, что умеет SQL, все это перестает работать быстро и прогнозируемо.
Если вытаскивать данные по ключу, без сканирования непонятных объемов данных - не вопрос, C* можно.
Ну и куча антипаттернов. TTL есть, но использовать для реализации очереди - антипаттерн. Уж по мне, проще на связке Kafka + RocksDB, без плясок с этими чудесными кольцами C*.
Вот уж операциям записи вообще не больно будет. Будет больно как раз таки чтению, оно самое проблемное в касандре. При жирных партициях и частых обновлениях будет полно тамбстоунов, которые при чтении придется пропускать. Записи же вообще пофиг. В коммит лог и memtable записал и забыл.
Оно все же больше, чем просто KV хранилище. Именно за счет кластерных ключей и алгоритмов распределения данных. Не говоря уже о материализованных представлениях, вторичных индексах, транзакциях, CDC и прочих плюшках. За счет всего этого поверх нее можно сделать очень многое, если не требуется строгая консистентность между таблицами. Хоть основной OLTP сторандж, хоть OLAP, хоть data lake.
Антипаттернов полно в любой базе, это вообще ниразу не недостаток касандры. Очереди делаются вполне себе, если в дополнению к TTL правильную стратегию компакшена выбрать. А так, всему свой инструмент. Кафка тажа.
Ну Kafka, Redis не притворяется что они кто-то другой, "типа SQL", например, а C* притворяется, что она типа СУБД и все будет по лайту, а на самом деле не будет. Вот и вся моя претензия.
Не знаю, откуда вы взяли, что притворяется. Просто взяли простой знакомый язык запросов и назвали его специально CQL, чтобы люди не думали, что это как постгре SQL какой-нить.
Kafka, redis точно так же можно сказать притворяются. Их точно так же пытаются натянуть как сову на глобус с подачи компаний, стоящих за их разработкой. Ничего плохого в этом нет, просто надо понимать, что к чему. Касандра тут ничем не выделяется. По факту, это СУБД. Просто NoSQL с широкими колонками и прочими особенностям. Все как у всех.
Пост конечно глупый совершенно. Во-первых, касандра не колоночная база данных и никаким местом с Clickhouse и Vertica их сравнивать и противопоставлять нельзя, ибо OLTP против OLAP получается. Из касандры OLAP делается только через Apache Spark ему подобные. Во-вторых, пример запросов действительно совершенно некорректный. Делать выборки без primary key это антипаттерн и заставит ходить за данным по всем нодам в кластере. Ну и касандра никак вообще не оптимизирована, можно сказать, для работы на высокопроизводительном оборудовании. Она его не способная утилизировать в принципе. Сцилла да, касандра нет от слова совсем.
К уже написанному выше добавлю некоторые простейшие выводы, которые сделал, когда выбрал и заиспользовал Cassandra для проекта:
- в неё можно очень много и быстро писать (логи, телематика, вычисления и т.д.)
- выбирать только если скоростью чтения можно пренебречь
- сложные запросы - это не сюда, просто делать выборку данных, обрабатывать в другом месте
- достаточно удобно "лепить" структуру хранения данных (лучше это сделать заранее и убедиться, что Cassandra подходит под неё и потом не будет мучительно больно перестраивать структуру хранения под неё)
Для информативности было бы здорово раскрыть в статье не только преимущества колоночных БД, но и недостатки.
Блин запарили column family приравнивать к column oriented.
После таких статей многие архитекторы на собесах на полном серьезе спрашивают рассказать о колоночных БД и тут же приводят кассандру в кач-ве одного из примеров.
Кому нужна Cassandra? Пара слов о преимуществах колоночных баз данных