Вредные советы ClickHouse

Советы из разряда
- У меня зачесался затылок и поэтому я решил отрубить себе голову - не делайте так!

Блин, ну вы серьезно? В Клике есть много более "интересных", не явных граблей, на которые можно наступить в процессе эксплуатации

"говорить за аналитику" это что-то на украинском.. В русском есть ПРО. Говорят про, а не за. "Я стою за Васей. Васи нет, я за него". А говорят - про.

Спасибо. Для начинающих будет полезно.
Вот еще несколько вредных советов:
9. Если думаете какую версию клика поставить, ставьте версию 21.1. И смотрите логи)
10. Если вы устроились на новую работу и там старая версия клика (например 21.1), то смело делайте апдейт до последней. Рестартуйте сервер и следите за тем что происходит вокруг)
11. Обновляйте версию сервера на кластере по одному с задержкой, чтобы посмотреть как клик работает с разными версиями))
12. Если у вас таблица с несколькими терабайтами данных, смело делайте update table set field = 1 и ждите)
13. При проектировании таблицы создайте поля с кодеком None, заливайте побольше данных и периодически выполняйте df -h
14. Добавьте на таблицу TTL timestamp + interval of week и подождите недельку))
15. При запросах смело используйте джойны, правые таблицы должны быть побольше (пол миллиарда записей например)
16. Подключите клик к бекэнду вашего нагруженного сайта и смело делайте запросы с выборкой по id)
17. Удалите что-нибудь в зукипере, наконец)
18. На одной машине лучше разместить несколько кликхаусов по разным портам. Так же лучше репликацию сделать, что шард и реплики были разные на одной ноде)
19. В телеграм чате кликхауса, если задаете вопросы то задавайте их, пожалуйста, в виде картинок. Особенно интересуют скриншоты со стекрейсами ошибок)
20. Используйте кликхаус всегда и везде куда у вас дотянутся руки)

означает ли сказанное в первой части видео, что кластеры yandec cloud не надежны и для рабочей среды аналитики обязательны репликации?

Прикольная абвгдейка😂

Отличные советы, замечательное объяснение. Спасибо за проделанную работу!

не согласен до конца с 4 вредным советом.

Можно указать все поля таблицы в ORDER BY ключе (хоть их 100 будет), но чтоб не засорять память большими файлами индексов, можно определить еще и PRIMARY KEY, который может быть ТОЛЬКО префиксом ORDER BY ключа. Таким образом таблицу можно отсортировать по всем 100 полям, а в индексе будут храниться 2-3 поля, определенные в PRIMARY KEY.

Такое может быть полезно для кейсов, когда данные дедуплицируются по большому набору полей (в движке ReplcaingMergeTree, например) или для более эффективного сжатия.

Спасибо, было очень полезно!

великолепная подача материала.

Спасибо за видео! Классная подача!