Вредные советы ClickHouse
Vložit
- čas přidán 2. 10. 2023
- Напоминаем, что вредные советы не стоит воспринимать, как руководство к действию.
Подробнее о сервисе: cloud.yandex.ru/services/mana....
Документация: cloud.yandex.ru/docs/managed-.... - Věda a technologie
Спасибо за видео! Классная подача!
Здравствуйте, Владимир! Рады, что вам понравилось 💙
Спасибо, было очень полезно!
Отличные советы, замечательное объяснение. Спасибо за проделанную работу!
великолепная подача материала.
Рады стараться для вас 💙
означает ли сказанное в первой части видео, что кластеры yandec cloud не надежны и для рабочей среды аналитики обязательны репликации?
Здравствуйте, Сергей! Сервисы управления данными Yandex Cloud соответствуют официально заявленным SLA. Подробнее об этом вы можете прочитать в нашей Справке: clck.ru/36Sib8
Механизмы репликации ClickHouse позволяют распределить нагрузку, повысить отказоустойчивость. Об этом мы детальнее рассказали в документации: clck.ru/36Sioj
Использование репликации не является обязательным, но значительно улучшает пользовательский опыт при работе с этой базой данных.
Я это знаю, но ваши высказывания в начале видео формируют достаточно явное впечатление, что ваш кластер без репликации не обеспечивает приемлемой для прода надежности, а если менее 32Гб то еще и нестабилен и подается это безотносительно сценариев использования. То есть, не было бы вопросов, если бы звучало, что речь о сценариях с высокой (какой) нагрузкой на вставку данных и/или высоких требованиях к доступности (недопустимости простоев свыше х секунд). Так как речь про OLAP систему, то это далеко не все сценарии. Фактически же любой, кто посмотрит это видео задаст вопрос: то есть кластер Яндекса с х ядрами и 16Гб без репликации не надежен и надо искать другое решение? Как минимум разворачивать СУБД на своем сервере?
@@pltvsrg Вы какой-то душный и слишком придираетесь.
Доступность на облаках, в и тч на яндексе довольно высокая.
Нужна ли именно вам репликация - вам нужно самим исходить из собственных нужд. Можно жить и на одном хосте без проблем. Должен быть баланс между доступностью, затратами и потенциальными рисками, даже если шанс их небольшой.
Кому-то и для OLAP требуется сверхдоступность, не говоря о высокой нагрузке. У кого-то данных немного и активность невысокая, и в случае чего один инсерт потерять не страшно, а у кого-то наоборот, пару ГБ данных ежечасно приходят и сразу в какой-то мониторинг или анализ, при этом потеря даже одной записи критична -тут требования соответственно уже другие.
"То есть, не было бы вопросов, если бы звучало..." ну как по мне, это подразумевается вполне. На этот ролик вряд ли попадут домохозяйки, этот ролик увидят именно те, кто в курсе, зачем репликация нужна и шардирование, а особенно в аналитических СУБД. Это само собой разумеющееся.
"Как минимум разворачивать СУБД на своем сервере?" А чем развернутое на вашем сервере будет надежнее?
"ваш кластер без репликации не обеспечивает приемлемой для прода надежности, а если менее 32Гб то еще и нестабилен"
Тут кстати нюанс, что это справедливо и в том случае, если вы запустите это на своем сервере. Это требования именно кликхауса.
Если вы читали слайд на 5:10, то вы обратите внимание на то, что clickhouse можно использовать даже и при 2ГБ памяти, но для этого требуется тюнинг. А 32 рекомендуется разработчиками кликхауса именно при дефолтных настройках, если вы ничего не тюните сами.
Тут на самом деле разработчики и яндекс сильно перестраховываются, ( впрочем, это не редкость ), по опыту, с дефолтом спокойно работается и на 8. Но почему такая рекомендация - в видео тоже все объяснили, кстати говоря, там все логично объясняется.
Я бы советовал вам самому опробовать и потестить. Рекомендации рекомендациями, но реальный юзкейс у вас может сильно отличаться от рекомендаций ( и 32 будет даже овер много ), и это касается не только кликхауса.
не согласен до конца с 4 вредным советом.
Можно указать все поля таблицы в ORDER BY ключе (хоть их 100 будет), но чтоб не засорять память большими файлами индексов, можно определить еще и PRIMARY KEY, который может быть ТОЛЬКО префиксом ORDER BY ключа. Таким образом таблицу можно отсортировать по всем 100 полям, а в индексе будут храниться 2-3 поля, определенные в PRIMARY KEY.
Такое может быть полезно для кейсов, когда данные дедуплицируются по большому набору полей (в движке ReplcaingMergeTree, например) или для более эффективного сжатия.
Здравствуйте, Кирилл! На видео пример с использованием только ORDER BY, при таком варианте ключ индексирования будет определяться всеми используемыми в нём колонками. В случае использования PRIMARY KEY и ORDER BY одновременно, ключ индексирования будет определяться уже только значением PRIMARY KEY, дополнительные колонки в ORDER BY не будут входить в индекс.
Прикольная абвгдейка😂
Советы из разряда
- У меня зачесался затылок и поэтому я решил отрубить себе голову - не делайте так!
Блин, ну вы серьезно? В Клике есть много более "интересных", не явных граблей, на которые можно наступить в процессе эксплуатации
Поделитесь?
расскажите, какие знаете вы? мне надо)
Аналогичное впечатление. У меня несколько проектов прекрасно живут на 4 ядрах в 16Гб без репликации и дают пользователям их аналитические срезы за пару секунд несколько графиков, и без глупостей с индексами исключения.
Их много. Для начала правильные сортировки и первичные ключи, правильные партиции. Следующие мощные инструменты - это агригационные движки и проекции. Далее эффективное использование словарей... Грубо говоря даже вопрос памяти не решается в лоб, так как потребности в ней сильно зависят от ваших запросов и количества ядер, потому что Клик умеет в паралеллизм даже на одном сервере. Более того, он создан для жизни именно на широком сервере. И реплики могут решить проблеммы по пропускной способности на вставку, но могут и добавить проблем на выборку.@@hsv000
@@pltvsrg Я бы мог понять про бессмысленность шардирования в каких-то случаях.
Но жить без репликации это печально (имхо экономия того не стоит).
Надеюсь у вас хотя бы есть бэкапы и вы тестировали восстановление данных с них.
"говорить за аналитику" это что-то на украинском.. В русском есть ПРО. Говорят про, а не за. "Я стою за Васей. Васи нет, я за него". А говорят - про.
Ну вы и душнила….
тебе делать не)(уй чи шо?
Согласен, как будто стало модным так говорить. Но это, видимо, какой-то южный акцент… Есть же слова в песне «я вам не скажу за всю Одессу. Вся Одесса очень велика». Это в целом норм… А вот еще много встречается «умеет в (что-то)». Умеет в аналитику, клик не умеет в джойны. Это уже больше похоже на англ, наверное. Неужели нельзя по-русски говорить «есть возможности для анализа», «у клика есть сложности с джойнами…