tabix.io/doc/Install

этот

tabix.io/doc/Server/Install

возможно или прошлая версия, или что-то еще, уже и реп таких не вижу

не вижу данного текста здесь tabix.io/doc/Install , давно используем, все ок

Точно не скажу, тестировал таки не я.
После внедрения CH, ребята также провели тесты для сравнения, и на сколько я знаю то основные минусы были:

• на конкретном тестируемом примере получалось медленнее чем в CH;
• стоимость превышала аренду серверов для CH.

При наличники, к тому времени, готовых наработок по CH, которые решают наши проблемы, сильно копать в сторону BQ уже не стали.

запущен, но «на все 100» не используем

В таком направлении не думали. Бегло просмотрел сайт, стоящая штука?

На том этапе были проблемы как с «естественными» ключами, так и с «суррогатными», в нашем случае автоинкремент.

Был, например, кейс с таблицей, которая хранит лог неких событий клиента, которые могут потом дополнятся информацией. Записей не предполагалось очень много, был выбран автоинкрементный PK.
Спустя некоторое время, сегмент бизнеса сильно вырос, и мы внезапно уперлись в максимальное значение PK. Таблица к тому времени была довольно большая, и у DBA как раз таки были проблемы с переводом ее на «естественный» ключ.

Правда в достижении лимита PK также сыграл метод обновления записей:
INSERT ON DUPLICATE KEY UPDATE
Попытка INSERT выполняется раньше, чем UPDATE. Потому MySQL увеличивал счетчик автоинкремента, хоть потом и обновлял существующую запись.

Спасибо за комментарий.

В нашем случае небольшая потеря данных не критична. C использованием NullEngine, таки нет с чем сравнить данные в MV.

Еще не использовали MV в продакшин фичах, где можно четко проверить консистентность их работы на долгом временном отрезке. Для локальных потребностей что-то собрать — все было хорошо.

Из последнего, что слышал о MV: поменяли pre-insert на post-insert при вставке в MV.

Спасибо за коммент и вопросы.

По бэкапам: пока только снапшоты, данные которые были добавлены после снапшота можно оперативно долить c тех же источников. Если будет все совсем плохо — всегда есть HDFS. Но честно сказать, кейса с корраптом данных, чтобы их нужно было восстанавливать из снапшота у нас еще не было. Если же даунтайм ClickHouse — консьюмеры kafka просто ждут пока он вернется к жизни.

Пользователя никак не ограничиваем, любые комбинации разрезов и метрик не вызывают проблем с производительностью.

По обновлению данных: я упомянул новую фичу в разделе «Редактирование данных», в самом конце. Пока не использовали, отпугивает слово beta.

Можно. Работы больше о том, что мы попутно хотим выполнить/потестировать некоторые улучшения нашей структуры таблиц.

Спасибо за коммент.

По метрикам использования ресурсов в масштабах системы сказать сложно. В ClickHouse мы храним сильно больше данных, и в более сыром виде. С появлением ClickHouse аппетиты по хранению данных сильно выросли.

Сейчас в ClickHouse храним ~4TB + ведутся работы по увеличению доступного места.

Но, касательно места, как раз на этой неделе выполнял перенос небольшой таблицы из MySQL в ClickHouse.

Занимаемое место в MySQL: 11.3GB
В ClickHouse с аналогичной структурой: 1.12GB
Если навесить дополнительный MATERIALIZED View для сбора агрегатов, по интересующему разрезу и метрикам, с временной засечкой к часу: 19MB