Комментарии 11
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
А сама Кассандра себя позиционирует как key-value? Имхо если просто запрашивать по ключу то любая база справится отлично, даже MySQL.
Зачем только это все нужно если можно просто выкатить редис.
Зачем только это все нужно если можно просто выкатить редис.
Потому что нужен объем данных, который куда больше ОЗУ. Redis хорошо справляется там, где размер БД сильно меньше или сопоставим с размером ОЗУ. А когда надо условно хранить 100Тб в 3-х географически разнесенных ДЦ, тут и выходят на сцену
Самое забавное, что нет ). Они база данных временных рядов (tabular или wide columns) БД - может, немного "гибридного дизайна" - но выбор в качестве kvstore и впрямь, странный.
Для временных рядов Cassandra вряд ли хороший вариант. Для этого есть специализированные решения https://en.wikipedia.org/wiki/Time_series_database
При выборе БД, надо смотреть какие из трех букв CAP-теоремы реализует БД и какие задачи необходимо решать в рамках приложения. Кассандра - это одна из немногих БД, которая может реализовать нужные вам буквы в зависимости от необходимости в той или иной части приложения. Например, если вам необходимо быстро прочитать, но не факт, что очень актуальные данные - вы это можете сделать с определенной целостностью, если вам надо точно записать в рамках текущего DC или в целом всего распределенного кластера - пожалуйста тоже можете, указав другой уровень целостности.
Позиционировать себя любая БД может как угодно, а вот на сколько хорошо она выполняет все задачи - это уже дискуссионный вопрос. Поинт этого абзаца в том, что задачи KV - решаются этими БД хорошо, а вот сложные выборки по множеству полей и т.д. уже не так хорошо, хотя они заявлены в документации.
Конкретно MySQL/MariaDB/etc не умеет из коробки в гео-распределенные кластеры. Руками можно конечно сделать с определенными допущениями, но решить таким образом можно узкий круг задач (репликация для бэкапа, для чтения возможно устаревших данных и т.д.). Но MySQL или любой другой RDBMS имеет другие плюсы.
используем три независимых кольца, по одному на дата-центр
У вас три отдельных кластера или внутри одного кластера вы разбили token range на 3 кольца? Типа 8 тачек 1 кольцо? Вы "руками" расчитывали token range, а не использовали num_tokens или как?
Как вы repair выполняете? С помощью cassandra-reaper или через nodetool? Инкрементальный или full? Пару дней для full repair не так уж и много, как по мне.
Какую версию cassandra вообще используете? Пробовали уже 5, хотите прод на 5 обновлять?
Про бэкап тоже расскажите, по подробнее :) Где снепшоты храните и тд и тп
8 тачек - 1 кольцо, всего 24. рэнджи руками выставляли, все верно. используем reaper с фуллом, до инкрементального пока не доросли:) сейчас 4.0.1, апаем до 4.1.9, потом будем трогать 5ю. бэкап - отдельная боль, связанная с объемами и RTO/RPO. думаю, об этом будет отдельная статья
Ну, с учетом того, что cassandra - ниочень-то key-value database, а скорее wide columns\tabular database - претензий должно быть не мало...
Дорого ли обошлась вам Scylla? Если возможно, упомяните хотя бы порядок.
Наш опыт с Cassandra и ScyllaDB: какие есть ограничения у этих key-value-БД и почему стоит присмотреться к альтернативам