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

Рет қаралды 7,146

Yandex Cloud

Күн бұрын

Пікірлер: 25

@vladimireliseev7602 4 ай бұрын

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

@YandexCloudPlatform 4 ай бұрын

Здравствуйте, Владимир! Рады, что вам понравилось 💙

@mikurrey416 8 ай бұрын

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

@MrZnakos 8 ай бұрын

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

@pltvsrg Жыл бұрын

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

@YandexCloudPlatform Жыл бұрын

Здравствуйте, Сергей! Сервисы управления данными Yandex Cloud соответствуют официально заявленным SLA. Подробнее об этом вы можете прочитать в нашей Справке: clck.ru/36Sib8 Механизмы репликации ClickHouse позволяют распределить нагрузку, повысить отказоустойчивость. Об этом мы детальнее рассказали в документации: clck.ru/36Sioj Использование репликации не является обязательным, но значительно улучшает пользовательский опыт при работе с этой базой данных.

@pltvsrg Жыл бұрын

Я это знаю, но ваши высказывания в начале видео формируют достаточно явное впечатление, что ваш кластер без репликации не обеспечивает приемлемой для прода надежности, а если менее 32Гб то еще и нестабилен и подается это безотносительно сценариев использования. То есть, не было бы вопросов, если бы звучало, что речь о сценариях с высокой (какой) нагрузкой на вставку данных и/или высоких требованиях к доступности (недопустимости простоев свыше х секунд). Так как речь про OLAP систему, то это далеко не все сценарии. Фактически же любой, кто посмотрит это видео задаст вопрос: то есть кластер Яндекса с х ядрами и 16Гб без репликации не надежен и надо искать другое решение? Как минимум разворачивать СУБД на своем сервере?

@CatWorldson Жыл бұрын

@@pltvsrg Вы какой-то душный и слишком придираетесь. Доступность на облаках, в и тч на яндексе довольно высокая. Нужна ли именно вам репликация - вам нужно самим исходить из собственных нужд. Можно жить и на одном хосте без проблем. Должен быть баланс между доступностью, затратами и потенциальными рисками, даже если шанс их небольшой. Кому-то и для OLAP требуется сверхдоступность, не говоря о высокой нагрузке. У кого-то данных немного и активность невысокая, и в случае чего один инсерт потерять не страшно, а у кого-то наоборот, пару ГБ данных ежечасно приходят и сразу в какой-то мониторинг или анализ, при этом потеря даже одной записи критична -тут требования соответственно уже другие. "То есть, не было бы вопросов, если бы звучало..." ну как по мне, это подразумевается вполне. На этот ролик вряд ли попадут домохозяйки, этот ролик увидят именно те, кто в курсе, зачем репликация нужна и шардирование, а особенно в аналитических СУБД. Это само собой разумеющееся. "Как минимум разворачивать СУБД на своем сервере?" А чем развернутое на вашем сервере будет надежнее? "ваш кластер без репликации не обеспечивает приемлемой для прода надежности, а если менее 32Гб то еще и нестабилен" Тут кстати нюанс, что это справедливо и в том случае, если вы запустите это на своем сервере. Это требования именно кликхауса. Если вы читали слайд на 5:10, то вы обратите внимание на то, что clickhouse можно использовать даже и при 2ГБ памяти, но для этого требуется тюнинг. А 32 рекомендуется разработчиками кликхауса именно при дефолтных настройках, если вы ничего не тюните сами. Тут на самом деле разработчики и яндекс сильно перестраховываются, ( впрочем, это не редкость ), по опыту, с дефолтом спокойно работается и на 8. Но почему такая рекомендация - в видео тоже все объяснили, кстати говоря, там все логично объясняется. Я бы советовал вам самому опробовать и потестить. Рекомендации рекомендациями, но реальный юзкейс у вас может сильно отличаться от рекомендаций ( и 32 будет даже овер много ), и это касается не только кликхауса.

@KirillMankov 8 ай бұрын

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

@YandexCloudPlatform 8 ай бұрын

Здравствуйте, Кирилл! На видео пример с использованием только ORDER BY, при таком варианте ключ индексирования будет определяться всеми используемыми в нём колонками. В случае использования PRIMARY KEY и ORDER BY одновременно, ключ индексирования будет определяться уже только значением PRIMARY KEY, дополнительные колонки в ORDER BY не будут входить в индекс.

@Евгений-х8с3г 6 ай бұрын

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

@YandexCloudPlatform 6 ай бұрын

Рады стараться для вас 💙

@vrfrost Жыл бұрын

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

@igor_im Жыл бұрын

Поделитесь?

@hsv000 Жыл бұрын

расскажите, какие знаете вы? мне надо)

@pltvsrg Жыл бұрын

Аналогичное впечатление. У меня несколько проектов прекрасно живут на 4 ядрах в 16Гб без репликации и дают пользователям их аналитические срезы за пару секунд несколько графиков, и без глупостей с индексами исключения.

@pltvsrg Жыл бұрын

Их много. Для начала правильные сортировки и первичные ключи, правильные партиции. Следующие мощные инструменты - это агригационные движки и проекции. Далее эффективное использование словарей... Грубо говоря даже вопрос памяти не решается в лоб, так как потребности в ней сильно зависят от ваших запросов и количества ядер, потому что Клик умеет в паралеллизм даже на одном сервере. Более того, он создан для жизни именно на широком сервере. И реплики могут решить проблеммы по пропускной способности на вставку, но могут и добавить проблем на выборку.@@hsv000

@vrfrost Жыл бұрын

@@pltvsrg Я бы мог понять про бессмысленность шардирования в каких-то случаях. Но жить без репликации это печально (имхо экономия того не стоит). Надеюсь у вас хотя бы есть бэкапы и вы тестировали восстановление данных с них.

@ДавидСтяжнев 10 ай бұрын

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

@nobody_nowhere_ Жыл бұрын

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

@MrPavel0 Жыл бұрын

Ну вы и душнила….

@goodnews6523 Жыл бұрын

тебе делать не)(уй чи шо?

@elcolex777 Жыл бұрын

Согласен, как будто стало модным так говорить. Но это, видимо, какой-то южный акцент… Есть же слова в песне «я вам не скажу за всю Одессу. Вся Одесса очень велика». Это в целом норм… А вот еще много встречается «умеет в (что-то)». Умеет в аналитику, клик не умеет в джойны. Это уже больше похоже на англ, наверное. Неужели нельзя по-русски говорить «есть возможности для анализа», «у клика есть сложности с джойнами…