если подключать EBS storage и делать Autoscaling Group на AWS EKS и поставить в кластер https://github.com/aws/aws-node-termination-handler
чтобы spot instances нормально гасили кликхаус и поднимали новую ноду
то проблем с корраптом данных не будет
но ситуация когда у вас все spot instances в ASG погашены, а новые недоступны
случается
и для production это применять нельзя

Партицирование точно ТОЛЬКО по месяцам?
может там какой нибудь
PARTITION BY date, clientID ?

попробуйте почитать про то как работает MergeTree движок

то что вы хотите работать не будет в принципе для OLAP паттерна нагрузки
в MySQL это работает потому что вставка идет "одной записью"
в MySQL это работает на самом деле ужастно медленно (o(log N) обращений к диску при вставке) и спасает только дисковый кеш innodb buffer pool

ReplacingMergeTree + SELECT FINAL ... или какой нибудь SELECT argMax() без final, это вполне нормальный вариант

ReplacingMergeTree не создает новые строки, только удаляет  старые (фильтрует при объединении в background merge) если есть более новая версия с таким же значением ключа стортировки, но большим значением столбца который как version в параметрах ReplacingMergeTree

Спасибо за совет, почитаю

можно ставить два, один будет использоваться для записи с недорогой тачкой, а второй для кверинга на спотах

вы хотите два EC2 instance один on-demand второй Spot?
ну в любом случае вам надо самому полить тогда момент когда Spot будет удаляться, чтобы корректно clickhouse стопануть

это да

Привет!
Как правильно выставить clickhouse по http в интернет для доступа из браузера?
Доступ только на чтение. SQL запросы не представляют ценности.
Предполагается, что будут тысячи зарегистрированных в clickhouse пользователей с настроенными квотами, row-based security правилами и прочими ограничениями. Ротация паролей.

Заранее спасибо!

мы ставили простейший нгикс с прокси на порты кх

спасибо
я к тому, что нет ли в такой схеме каких-то известных, но не очевидных, уязвимостей?
плюс я не очень понимаю, что в такой схеме с коннектами к БД, они ведь ограничены

Привет. Подскажите кто и как добавляет новые колонки в таблицах с последующим заполнением историческими данными? Искал лучшие практики, но ничего не нашел толком.

Объясню подробнее ситуацию. Есть одна колонка, в которой хранится огромный JSON с разными данными, который хорошо сжат. По мере необходимости, когда определенные данные становятся часто используемыми, чтобы не выполнять JSONExtract каждый раз, потому что он работает долго, из этих данных делается отдельная колонка, у которой DEFAULT значение это JSONExtract нужных данных.
Так вот, если просто добавить так колонку, то исторические данные, которые уже раньше присутствовали в этом JSON-е по сути не запишутся физически на диск, и запросы все так же будут отрабатывать долго. Для решения этой проблемы я выполняю OPTIMIZE FINAL, но по мере роста таблицы, этот оптимайз выполняется все дольше и дольше. Второй вариант, это делать INSERT INTO new_table SELECT * FROM source_table, так данные тоже физически запишутся, но выполняется все так же очень долго, плюс надо иметь всегда места в два раза больше чем занимают таблица.

Из доков кликхауса, читал что в бекграунде кликхаус вроде как должен заполнять такие колонки данными сам в бекграунде. Для эксперимента я сделал такую колонку, и ничего не оптимайзил. За неделю ничего так и не поменялось.

Подскажите кто и как поступает в таких ситуациях.

Добрый день.
У нас есть таблица и на эту таблицу есть вьюха. Хотим эту вьюху отдать клиенту. Но чтобы он не видел основную таблицу. Для этого создали пользователя и добавили GRANT SELECT на эту вьюху. Этого недостаточно, КХ просит разрешить SELECT к основной таблице.

+ проблема в том, что когда добавляешь GRANT SELECT таблица становится видна для SHOW TABLES , а нам бы хотелось хотябы ее скрыть из этого списка. REVOKE на SHOW TABLES не дают эффекта, пользователь видит их обе.(вью и таблицу)
Как можно выйти из этого положения?

это снова я. обновились, память все равно выедается. все таблички служебные посмотрел, непонятно на что уходит память. как понять сколько уходит на кэш для запросов?

Подскажите, пожалуйста, где подвох?

SELECT dictGetString('app_name', 'id', toUInt64(123))


Received exception from server (version 20.8.13):
Code: 53. DB::Exception: Received from localhost:9000. DB::Exception: Third argument of function dictGetString must be (UInt64).

SELECT dictGetString('app_name', 'id', toUInt64(123))


Received exception from server (version 20.8.13):
Code: 53. DB::Exception: Received from localhost:9000. DB::Exception: Third argument of function dictGetString must be (UInt64).

как вы создавали словарь?

Подключением xml.

сам код

если ключ UInt64, то лучше использовать layout flat если ключей меньше 500к или hashed