Comments 13
Доброе время суток!
Есть несколько вопросов если позволите:
Какой у вас стек софта над кассандрой для записи/чтения метрик?
Сколько апдейтов в минуту?
Сколько нод кассандры?
Спасибо
Есть несколько вопросов если позволите:
Какой у вас стек софта над кассандрой для записи/чтения метрик?
Сколько апдейтов в минуту?
Сколько нод кассандры?
Спасибо
- в основном с кассандрой работает golang через gocql
- сейчас в среднем пишется ~75 тысяч метрик в секунду = ~4.5 миллиона в минуту
- сейчас 9 нод
Я бы ещё немного вопросов позадавал, если можно.
Какая у нод конфигурация железа?
Конфигурацию самой кассандры меняли относительно дефолтной в плане оптимизации? (вроде таких как используемый GC, размер хипа...)
Спасибо!
Какая у нод конфигурация железа?
Конфигурацию самой кассандры меняли относительно дефолтной в плане оптимизации? (вроде таких как используемый GC, размер хипа...)
Спасибо!
нода: 4 ядра/32Гб/2x300Gb ssd + 2x3Tb sata
конфиг jvm стандартный кассандровский (они кстати очень тщательно это продумывают, можно тикеты в jira почитать)
Спасибо за ответы. Да, я знаю, что продумывают тщательно, но, я читал джиру ;) Скажем https://issues.apache.org/jira/browse/CASSANDRA-7486
Может оказаться так, что версия кассандры ещё без G1 по-умолчанию, однако уже вполне прилично с ним работает (GC просто для примера, повторюсь).
Ну и, я так понял, что всё очень сильно зависит от use-case, дефолтный конфиг ведь не занимается анализом ваших сценариев, он старается быть приемлемым для всех.
Может оказаться так, что версия кассандры ещё без G1 по-умолчанию, однако уже вполне прилично с ним работает (GC просто для примера, повторюсь).
Ну и, я так понял, что всё очень сильно зависит от use-case, дефолтный конфиг ведь не занимается анализом ваших сценариев, он старается быть приемлемым для всех.
Отличный workaround для решения типичной проблемы, мы это проходили в свое время так же
PS.
>>> sstable достаточно большого размера (60Gb, 160Gb и 180Gb)
b это бит, если же байт, то B :)
PS.
>>> sstable достаточно большого размера (60Gb, 160Gb и 180Gb)
b это бит, если же байт, то B :)
Интересно, почему разработчики cassandra решили именно так находить текущее время (перебирать значения в базе и искать максимальное, если я правильно понял), а не просто взять текущее время системы. Чтобы не завязываться на настройки сервера в случае, если значение в колонке приезжает с клиента?
Значения в базе не перебираются. Для каждой таблицы есть не очень большое количество sstable (файлов с данными), для каждого файла в заголовке есть метадата (в том числе минимальный и максимальный таймстамп записей). С точки зрения ресурсов это вычисление не очень дорогое. Почему реализовано именно так сложно сказать, так как отвязаться от локального времени на сервере все равно не получится в случае если timestamp проставляется кассандрой.
и первый и второй случаи сильно похожи на баги. стоит завести тикеты у них в джире, если вы еще не завели. DateTieredCompactionStrategy правда заменяется сейчас на TimeWindowCompactionStrategy, но все равно возможно пофиксят или по крайней мере не перенесут ошибочный getNow в новый код.
Хороший пост, вот только есть одно но
Спасибо, отличный пост!
Sign up to leave a comment.
Как мы неделю чинили compaction в Cassandra