Comments 9
Простота очень спорное утверждение, на вопросы которые у нас возникали найти решения чаще всего было просто негде, даже по Elassandra проще. Документация написана для своих, банально создать юзера с нужными значениями выходит чтение 12 разных страниц доки, и зачастую даже достаточно криво написанных, особенно в сравнении с Oracle. Описание движков достаточно скудное, и многие вещи программистам часто непонятны вообще.
На мой взгляд кликхаус удобная бд для аналитики, но хранить в нём данные и использовать его как фронт — это мазохизм.
и да, продукт требует некоторого времени разобратся
а программисты один хрен его не понимают и главное не хотят его понимать
Ну так это проблема программистов или их менеджеров. Любой продукт надо понимать, чтобы уметь им пользоваться. ClickHouse — штука с кучей своих особенностей, и именно эти особенности, если правильно ими пользоваться, позволяют быть куда более эффективным, чем Oracle или Vertica. О чем я и другие ребята рассказывают на хайлоадах и других конференциях. Вертику, кстати, тоже надо уметь готовить.
Ну и не забывайте, что ClickHouse — это open source, поэтому документация пока не самая сильная сторона. Но всегда можно посмотреть в код, что и как работает. С Oracle/Vertica это невозможно в принципе. Или спросить в каналах поддержки. Было бы желание.
Подтверждаю, что ClickHouse — крутая аналитическая БД, которая отлично масштабируется как вертикально (переезд на более мощное железо), так и горизонтально (добавление нод в кластер). Конечно, при ее использовании могут возникать некоторые проблемы. Особенно, если не до конца понимать базовых принципов работы этой БД и неправильно спроектировать схему таблиц для хранения данных и отправлять в нее "кривые" запросы, потребляющие все доступные ресурсы (память, disk IO, CPU) в течение длительного времени.
Благодаря ClickHouse появилась такая time series БД, как VictoriaMetrics. Она использует базовые идеи из ClickHouse для достижения максимальной эффективности и производительности — см. подробности в этой статье.
Конечно, при ее использовании могут возникать некоторые проблемы.
Не в обиду будет сказано, но я как разработчик, как менеджер и как архитектор очень пугаюсь, когда слышу/вижу слово "некоторые" (особенно в контексте "некоторые проблемы" или "остались некоторые незакрытые вопросы") и "все" ("подходит для всех задач", "все знают").
Некоторые проблемы могут возникнуть при недостаточном понимании базовых принципов работы ClickHouse. Эти принципы достаточно просты в понимании. Поэтому в большинстве случаев проблем с эксплуатацией ClickHouse не должно возникнуть. Например, мы в свое время удачно переключились с postgresql на ClickHouse для хранения и анализа статистики по крупной рекламной сети с 200 миллиардов просмотров в сутки. В результате удалось сократить на порядок расходы на хранение и анализ этих данных. См. подробности в https://medium.com/faun/victoriametrics-creating-the-best-remote-storage-for-prometheus-5d92d66787ac
1. Не потерять данные. Для больших потоков данных нужно использовать таблицу c engine=Buffer, чтобы insert происходил большими батчами. Но проблема в том что эта таблица хранится в оперативке и гарантий нет, что данные не потеряются перед тем как передут в основную таблицу
2. Не задублировать данные. ReplacingMergeTree гарантируют отсутствие дубликатов только в рамках партиции
Так что если кто-то может покидать материалы, поделится велосипедами как такое решить, было бы круто
Переезжаем на ClickHouse: 3 года спустя