Было бы здорово, если бы сервис наподобие кафки был бы встроен в кликхаус. Например, в виде отдельного типа таблицы

А это не то? https://clickhouse.yandex/docs/ru/table_engines/kafka/

Наверное, потому что кафка выполняет похожую работу, что буфер-таблицы - мержит входящие данны в бОльшие пачки данных и скармливает их кликхаусу. Отличие, наверное, в том, что кликхаус сам вытягивает данные из кафки, когда готов это делать (pull модель), а из буфер-таблицы данные могут прилететь в mergetree в произвольный момент, который может оказаться не таким удобным для кликхауса (push-модель). Еще одно отличие, что данные из буфер-таблицы видны в запросах сразу же, а данные в кафке не видны до тех пор пока кликхаус их не заберет.

Спасибо за подробный ответ

Наверное, потому что кафка выполняет похожую работу, что буфер-таблицы - мержит входящие данны в бОльшие пачки данных и скармливает их кликхаусу. Отличие, наверное, в том, что кликхаус сам вытягивает данные из кафки, когда готов это делать (pull модель), а из буфер-таблицы данные могут прилететь в mergetree в произвольный момент, который может оказаться не таким удобным для кликхауса (push-модель). Еще одно отличие, что данные из буфер-таблицы видны в запросах сразу же, а данные в кафке не видны до тех пор пока кликхаус их не заберет.

А какие объемы вы впихаваете, если не секрет? И как оно впихивается?

А это не то? https://clickhouse.yandex/docs/ru/table_engines/kafka/

вроде не то - для этого требуется жирная кафка. А хотелось бы обойтись только кликхаусом

А какие объемы вы впихаваете, если не секрет? И как оно впихивается?

впихивали до 300к строчек по ~45 колонок в секунду на один сервер. Каждая строчка содержит данные по рекламному запросу. В основном инты и короткие строки. В сутки прилетало до 25 миллиардов событий на сервер. Когда начинало прилетать больше строчек в секунду, начинались тормоза. Поэтому мы добавляли новую шарду в кластер.

А что за железо?)

впихивали до 300к строчек по ~45 колонок в секунду на один сервер. Каждая строчка содержит данные по рекламному запросу. В основном инты и короткие строки. В сутки прилетало до 25 миллиардов событий на сервер. Когда начинало прилетать больше строчек в секунду, начинались тормоза. Поэтому мы добавляли новую шарду в кластер.

1 сервер это одна железка с ух и какой на борту?

1 сервер - это один инстанс в google compute engine с 32 ядрами, 104 гигами памяти и динамически расширяемым persistent hdd диском. Максимальный размер данных на одном сервере был в районе 40Тб

Есть ли какие-то рекомендации или опыт, с базами с таблицами в совокупном размере посколько ТБ может оперировать один сервер с Clickhouse? 36ТБ, 54ТБ, 72ТБ - может кто-то работает с таким в проде?

Если только хранить то в целом без разницы

Есть ли какие-то рекомендации или опыт, с базами с таблицами в совокупном размере посколько ТБ может оперировать один сервер с Clickhouse? 36ТБ, 54ТБ, 72ТБ - может кто-то работает с таким в проде?

Мы нормально работали с 40тб на сервер - см. выше

Мы нормально работали с 40тб на сервер - см. выше

А сейчас тоже работаете? Прошедшее время звучит пугающе)

Не знаю. Я там уже не работаю )

Все вопросы к объему зависят от вставок и ваших запросов

Все вопросы к объему зависят от вставок и ваших запросов

И типа железа, это понятно. У нас xeon gold - ы и RAM от 128, так что интересуют чисто потенциальные ограничения CH. Типа "не может сразу искать по таблицам больше 20ТБ"

Зная как он хранит данные то надо только смотреть чтобы не упереться в ограничения файлухи

Зная как он хранит данные то надо только смотреть чтобы не упереться в ограничения файлухи

XFS с точки зрения минимального оверхеда на всякие inodes я думаю предпочтительна?

Зная как он хранит данные то надо только смотреть чтобы не упереться в ограничения файлухи

Это надо постараться :) Тот же ext3, ЕМНИП, позволит хранить 32К объектов в одной директории. На таком числе партов CH будет поганенько сканить :)

XFS с точки зрения минимального оверхеда на всякие inodes я думаю предпочтительна?

Яндекс рекомендует всё-таки ext4

В свое время отказался от xfs как только доросла ext4, c xfs только хорошие воспоминания, но ее там надо было как то отдельно ставить, а екст4 из коробки хорошо работает

У меня как-то во время тестов и заполнения очереди distributed таблицы закончились иноды на ext4, так что грызут сомнения

подскажите, пожалуйста, а можно ли для ReplacingMergeTree сделать так, чтобы оставалась старая версия, а не новая? -ver не работает.

Отбой XFS, не хочу повторять опыт Cloudflare =) "Another disk failure highlighted a problem with the filesystem we used. Initially we used XFS, but it started to lock up during replication from 2 peers at the same time, thus breaking replication of segments before it completed. This issue has manifested itself with a lot of I/O activity with little disk usage increase as broken parts were deleted, so we gradually migrated to ext4 that didn’t have the same issue."

И типа железа, это понятно. У нас xeon gold - ы и RAM от 128, так что интересуют чисто потенциальные ограничения CH. Типа "не может сразу искать по таблицам больше 20ТБ"

знаю следующие ограничения: 1) Скорость сканирования данных ограничена скоростью чтения сжатых данных с диска, если эти данные отсутствуют в файловом кэше операционной системы ("холодные" данные). Например, у persistent hdd в google cloud'е максимальная скорость чтения - 180мб/с на инстанс. Если сканировать колонку с хорошим уровнем сжатия (например, поставить фильтр на дату, которая сжимается в 1000 раз), то кликхаус сможет в теории сканировать эту колонку с диска со скоростью 180мб/с*1000=180гб/с или 180 / 4 = 45 миллиардов строк в секунду (одно поле DateTime занимает 4 байта) . Если же сканировать плохо сжимаемую колонку (например, IP юзера, которая сжимается в лучшем случае в полтора раза), то скорость сканирования айпишек с диска будет ограничена 180*1.5=270мб/с или 270/4 = 67.5 миллионов строк в секунду (если айпишки хранить в UInt32). Если бы они читались из файлового кэша ("теплые" данные, которые либо были недавно записаны, либо недавно считаны), то скорость была бы ограничена скоростью чтения из памяти, т.к. в районе 10гб/с или 2.5 миллиарда строк в секунду, т.е. почти в 40 раз быстрее. 2) Вроде индексы всех таблиц должны помещаться в оперативную память. В теории возможна ситауция, когда для очень больших таблиц не хватит оперативной памяти для индексов. У нас такого никогда не было.

https://github.com/yandex/clickhouse-jdbc

java.lang.NoClassDefFoundError: Could not initialize class ru.yandex.clickhouse.ClickHouseDriver

знаю следующие ограничения: 1) Скорость сканирования данных ограничена скоростью чтения сжатых данных с диска, если эти данные отсутствуют в файловом кэше операционной системы ("холодные" данные). Например, у persistent hdd в google cloud'е максимальная скорость чтения - 180мб/с на инстанс. Если сканировать колонку с хорошим уровнем сжатия (например, поставить фильтр на дату, которая сжимается в 1000 раз), то кликхаус сможет в теории сканировать эту колонку с диска со скоростью 180мб/с*1000=180гб/с или 180 / 4 = 45 миллиардов строк в секунду (одно поле DateTime занимает 4 байта) . Если же сканировать плохо сжимаемую колонку (например, IP юзера, которая сжимается в лучшем случае в полтора раза), то скорость сканирования айпишек с диска будет ограничена 180*1.5=270мб/с или 270/4 = 67.5 миллионов строк в секунду (если айпишки хранить в UInt32). Если бы они читались из файлового кэша ("теплые" данные, которые либо были недавно записаны, либо недавно считаны), то скорость была бы ограничена скоростью чтения из памяти, т.к. в районе 10гб/с или 2.5 миллиарда строк в секунду, т.е. почти в 40 раз быстрее. 2) Вроде индексы всех таблиц должны помещаться в оперативную память. В теории возможна ситауция, когда для очень больших таблиц не хватит оперативной памяти для индексов. У нас такого никогда не было.

Спасибо. Из рекомендаций RedHat почитал, что у ext4 ограничение на размер файловой системы - 50ТБ. Отсюда и будем отталкиваться.

Это для Jmetr

Спасибо. Из рекомендаций RedHat почитал, что у ext4 ограничение на размер файловой системы - 50ТБ. Отсюда и будем отталкиваться.

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

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

в общем имеем два стула - динамические иноды в xfs и возможные просадки по io до отвала реплик из-за отставания, и статические в ext4 которые при недостаточном выделении закончатся и тоже может всё сломаться. Но ext4 предсказуемее выглядит, реально. Благодарю за помощь в обсуждении.

с инодами довольно редкая проблема так как заранее знаешь что их мало по дефолту

еще вопрос. Nullable с JOIN-ами работать умеет?

У меня как-то во время тестов и заполнения очереди distributed таблицы закончились иноды на ext4, так что грызут сомнения

В вашей таблице либо тысячи колонок, либо вы вставляли туда данные по одной строчке и увеличили лимит на максимальное количество кусков с 300 до десятков тысяч. Иначе не совсем понятно, как могут закончиться иноды. Для кликхауса легко посчитать максимальное количество файлов на таблицу - умножаем количество колонок на 2 (для каждой колонки создается два файла - с данными, индексом), потом на 300 (максимальное количество кусков в одной партиции, если вы его не меняли), потом на количество партиций. Например, если партиционирование помесячное и у вас есть данные за год, то нужно умножать на 12. Обычно в старых партициях куски "схлопываются", поэтому их количеством можно пренебречь. Пример: максимальное количество файлов для таблицы с 50 колонками равно 50*2*300*partitions_count = 30000*partitions_count, т.е. по 30к на партицию. Обычно это количество намного меньше, т.к. кликхаус старается минимизировать количество кусков путем их слияния. Большое количество файлов обычно говорит либо о неправильной вставке данных (много мелких вставок) либо о неправильном партиционировании (слишком много партиций).

В вашей таблице либо тысячи колонок, либо вы вставляли туда данные по одной строчке и увеличили лимит на максимальное количество кусков с 300 до десятков тысяч. Иначе не совсем понятно, как могут закончиться иноды. Для кликхауса легко посчитать максимальное количество файлов на таблицу - умножаем количество колонок на 2 (для каждой колонки создается два файла - с данными, индексом), потом на 300 (максимальное количество кусков в одной партиции, если вы его не меняли), потом на количество партиций. Например, если партиционирование помесячное и у вас есть данные за год, то нужно умножать на 12. Обычно в старых партициях куски "схлопываются", поэтому их количеством можно пренебречь. Пример: максимальное количество файлов для таблицы с 50 колонками равно 50*2*300*partitions_count = 30000*partitions_count, т.е. по 30к на партицию. Обычно это количество намного меньше, т.к. кликхаус старается минимизировать количество кусков путем их слияния. Большое количество файлов обычно говорит либо о неправильной вставке данных (много мелких вставок) либо о неправильном партиционировании (слишком много партиций).

+1

java.lang.NoClassDefFoundError: Could not initialize class ru.yandex.clickhouse.ClickHouseDriver

Скачал maven mvn install:install-file -DgroupId=ru.yandex.clickhouse -DartifactId=clickhouse-jdbc -Dversion=0.1.39 -Dpackaging=jar -Dfile=clickhouse-jdbc-0.1.39.jar -DgeneratePom=true (BUILD SUCCESS)

А что дальше? как класс инициализировать?))

А что дальше? как класс инициализировать?))

а ты чего вообще делаешь-то?

Jmetr настроить

Нужен jdbc driver class

Нужен jdbc driver class

Uncaught Exception java.lang.NoClassDefFoundError: Could not initialize class ru .yandex.clickhouse.ClickHouseDriver. See log file for details.

В вашей таблице либо тысячи колонок, либо вы вставляли туда данные по одной строчке и увеличили лимит на максимальное количество кусков с 300 до десятков тысяч. Иначе не совсем понятно, как могут закончиться иноды. Для кликхауса легко посчитать максимальное количество файлов на таблицу - умножаем количество колонок на 2 (для каждой колонки создается два файла - с данными, индексом), потом на 300 (максимальное количество кусков в одной партиции, если вы его не меняли), потом на количество партиций. Например, если партиционирование помесячное и у вас есть данные за год, то нужно умножать на 12. Обычно в старых партициях куски "схлопываются", поэтому их количеством можно пренебречь. Пример: максимальное количество файлов для таблицы с 50 колонками равно 50*2*300*partitions_count = 30000*partitions_count, т.е. по 30к на партицию. Обычно это количество намного меньше, т.к. кликхаус старается минимизировать количество кусков путем их слияния. Большое количество файлов обычно говорит либо о неправильной вставке данных (много мелких вставок) либо о неправильном партиционировании (слишком много партиций).

Там немного сложнее если есть массивы/nested-структуры, но для простых типов всё так + несколько служебных файлов типа чексум/колонок и т.д.

Jmetr настроить

извини, я в pycharm работаю с КХ

Ребята, день добрый! одскажите плиз куда копать (кластер из 5 реплик), хостнеймы проверил, все корректно Code: 159. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Watching query is executing too long (121 sec.) version 1.1.54248.

Ребят, есть вопрос по конфигурации ZooKeeper: в мане предлагается указать все ноды ZooKeeper, а если он будет представлен как сервис по одному адресу, это будет работать? В k8s можно его повесить за сервис, который будет сам балансить запросы на узлы.

работать будет точно, но вот что будет при обрыве соединения, когда нода перепинывается - хз.

Ребят, есть вопрос по конфигурации ZooKeeper: в мане предлагается указать все ноды ZooKeeper, а если он будет представлен как сервис по одному адресу, это будет работать? В k8s можно его повесить за сервис, который будет сам балансить запросы на узлы.

в этом нет смысла

Нет смысла вешать за сервис или указывать все инстансы при наличии балансера перед zookeeper?

нет смысла в балансере

какой смысл перед зукипером поднимать еще одну сущность , просто станет единая точка отказа по сути

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

Потому что в k8s сервис - это нормально. Отсюда и вопрос возник. Под с зукипером и так, по сути, за сервисом висит. Тем более тут сущность достаточно эфемерная, ибо там используется ipvs

А что произойдет, если запустить detach partition и во время выполнения запроса прилетят данные в эту партицию?

И как это реплицируется? Т.е. если я сделал detach партиции на одной реплике и написал в это время данных на другой реплике в эту партицию, то добавленные данные отлетят?

Там лок будет и drop/detach будут ждать выполнения insert

А если сначала detach запущен был, а потом insert? Получается, что insert будет ждать пока detach отработает?

Да

Супер! А с репликацией как дела обстоят? Вот я запустил детач на первой реплике и на второй реплике во время выполнения детача на первой, приехали данные в удаляемую партицию. Они останутся на второй реплике или при получении запроса на detach так же отлетят?

Можно в конце запроса дописывать SETTINGS max_block_size = ваше число.

Так можно менять любые квоты? В конец любого запроса можно вставлять?

Супер! А с репликацией как дела обстоят? Вот я запустил детач на первой реплике и на второй реплике во время выполнения детача на первой, приехали данные в удаляемую партицию. Они останутся на второй реплике или при получении запроса на detach так же отлетят?

у нас реплика ломалась, когда мы пробовали удалять партицию, в которую идет запись, но, возможно, это не актуально больше

у нас реплика ломалась, когда мы пробовали удалять партицию, в которую идет запись, но, возможно, это не актуально больше

А давно это было?

А давно это было?

в январе или феврале

Супер! А с репликацией как дела обстоят? Вот я запустил детач на первой реплике и на второй реплике во время выполнения детача на первой, приехали данные в удаляемую партицию. Они останутся на второй реплике или при получении запроса на detach так же отлетят?

Я, если честно, непомню, надо по коду посмотреть или спросить у @ztlpn он точно знает

у нас реплика ломалась, когда мы пробовали удалять партицию, в которую идет запись, но, возможно, это не актуально больше

ну это очень старнное решение удалять партицию в которую идет запись

Так можно менять любые квоты? В конец любого запроса можно вставлять?

Да

ну это очень старнное решение удалять партицию в которую идет запись

я не буду спорить, что это странно, я это делал, чтобы очистить партицию, в которой оказался тестовый мусор

ну это очень старнное решение удалять партицию в которую идет запись

Странное, но я не могу останавливать запись на неопределенное время пока актуальные данные переезжают в другую партициую. Некий костыль для делитов.

на обычном MergeTree всё отрабатывало нормально и так, как ожидается :)

Странное, но я не могу останавливать запись на неопределенное время пока актуальные данные переезжают в другую партициую. Некий костыль для делитов.

ну сделайте просто партиции по дням

на обычном MergeTree всё отрабатывало нормально и так, как ожидается :)

я просто слабо себе представляю как ожидаемо себя должен повести кх в репликации в таком случае

я просто слабо себе представляю как ожидаемо себя должен повести кх в репликации в таком случае

точно также, как и без репликации — держать лок на удаляемую партицию, пока она не удалится

Да

спасибо, интересно, попробую

и сначала догнать репликацию, конечно же

ну то есть не принимать записываемые вами данные ?

выдавать ошибку на запист ?

а если вы пишете во вторую реплику постоянно то лок на вечно пока новая партиция не начнется?

подводных камней мне кажется тут слишком много

выдавать ошибку на запист ?

Я думаю, что сервер должен сначала по журналу репликации догнать данные, а потом серез детач отцепить именно куски

А не все что там есть

Я думаю, что сервер должен сначала по журналу репликации догнать данные, а потом серез детач отцепить именно куски

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

Нет, они должны остаться

ну как они останутся если лок на партицию то , куда он их должен по вашему положить ?

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

При DETACH все куски, вставленные в партицию до выполнения команды, должны задетачиться, а все куски, вставленные после, должны остаться. Если это не так, создавайте issue.

При DETACH все куски, вставленные в партицию до выполнения команды, должны задетачиться, а все куски, вставленные после, должны остаться. Если это не так, создавайте issue.

Тут вопрос как реплика себя поведет, если на одной реплике идет детач, а на другой реплике в эту партицию данные пишутся.

Вот данные которые на другой реплике записались в удаляемую партицию на первой реплике останутся или удалятся?

То же самое. Вставки на всех репликах линейно упорядочены через ZooKeeper и DETACH встраивается в этот порядок.

Друзья, а для кафки есть GUI ?

Друзья, а для кафки есть GUI ?

Есть https://github.com/yahoo/kafka-manager

Вот данные которые на другой реплике записались в удаляемую партицию на первой реплике останутся или удалятся?

То есть если в этом едином порядке записанные данные идут до DETACH, они удалятся, если после - нет.

То есть если в этом едином порядке записанные данные идут до DETACH, они удалятся, если после - нет.

Я сам запутался. Т.е. в ситуации Реплика 1: 12.00 - detach партиции 1 12.01 - завершился detach партиции 1 Реплика 2: 12.00.30 - insert в партицию 1 12.02 - выполнение detach партиции 1 из журнала репликации Данные вставленные в реплику 2 останутся живыми или отлетят? )

Есть https://github.com/yahoo/kafka-manager

Спасибо! Еще продукты https://stackoverflow.com/questions/49276785/monitoring-ui-for-apache-kafka-kafka-manager-vs-kafka-monitor

Я сам запутался. Т.е. в ситуации Реплика 1: 12.00 - detach партиции 1 12.01 - завершился detach партиции 1 Реплика 2: 12.00.30 - insert в партицию 1 12.02 - выполнение detach партиции 1 из журнала репликации Данные вставленные в реплику 2 останутся живыми или отлетят? )

Смотря что понимать под "завершился" - DETACH сначала создаёт запись в логе репликации, а потом в зависимости от настройки replication_alter_partitions_sync будет ещё ждать выполнения этой записи у себя (по дефолту) или на всех репликах.

Вот если insert на второй реплике прошёл после создания записи DETACH в логе, то он не должен удалиться.