decimal есть вполне себе живой

две реплики с одинаковыми данными могут прососать больше distributed запросов чем одна

* провокационно-еретическое*

А вот круговая репликация, которая здесь всячески осуждается и порицается, сразу же задействует в обработке запросов не половину, а вообще все ноды кластера.
Как бы максимально эффективное использование всего железа :P

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

то есть допустим было 3 железки, 9 нод clickhouse, разбиты как circular
все круто, кластер спокойно переживает падение 2 из 3 серверов,

теперь вопрос, как сюда добавить 4й сервер? ;)

Добрый день, как правильно выбрать ORDER BY, если
количество user_id - сотни тысяч
количество domain для каждого user_id - до 100
Сейчас так:
ORDER BY (user_id, report_date, domain)
Будет ли быстрее поиск, если сделать так:
ORDER BY (user_id, domain, report_date)

В where всегда есть эти три поля.

Добрый день. В клике есть форматирование чисел? Например чтобы десятичным разделителем была запятая, а не точка

@milovidov_an привет, я тут из-за твоего доклада про сборку clickhouse, есть пару вопросов. Если вы вкорячили большую часть musl, почему было не всунуть её всю? Говорил, что fuzzing включаете на час, как это происходит? Отдельная джоба на ci, или сервис, как у гугла, куда закидываете бинарник и потом ждёте от него вестей (по почте?)?

report_date, domain, user_id

от менее кардинальных, до более кардинальных

report_date в начало и еще PARTITION BY toYYYYMM(report_date)
обычно чтобы быстрые range запросы по дате были (дата обычно в каждом запросе есть)

кстати, вопрос
а в чем концептуальная разница между partition by toStartOfMonth(date) и toYYYYMMM(date) - только в хранимом типe данных ?

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

Но везде в примерах дата входит в ордер. Вот из документации
ENGINE MergeTree()
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate)

нет
если дата в партиции это просто значит что сначала будут выбрана партиция
но если нет в ORDER BY то внутри партиции будут просканированы все data parts (system.parts)
и это будет медленно, потому что дата будет отсуствовать в mrk файлах... соответсвенно последовательно будут открываться .bin файлы распаковываться и фильтроваться, это будет ДОЛГО

да, toYYYYYMM это 32bit interger а toStartOfMonth это 64bit integer
mrk файлы будут жирнее

По постановке вопроса - не совсем понял, почему 3 железки, но 9 нод кликхауса.
Вы подразумеваете тройную репликацию? Если так, то это очень суровое требование, которое, наверное, в значительном числе случаев избыточное.

Для 3 железных серверов под круговой репликацией я имел в виду схему:
s - shard, r - replica
[host1]: s1r1, s3r2
[host2]: s2r1, s1r2
[host3]: s3r1, s2r2
Она падения 2 из 3 не переживёт, но (в общем случае) при вылете нескольких НЕсмежных N из M должна остаться работоспособной.

Теперь появился host4, как расширяться?
По сравнению с исходным состоянием целевое состояние теперь:
...
[host4] s4r1, s3r2
[host1] s1r1, s4r2

Дальше если совсем прямолинейно пойти, сперва скопировав данные всех старые партиции (в которые данные уже не поступают) 2й реплики 3го шарда с host1 на host4,
затем выключить host1 (кластер работоспособен)
затем в зукипере 'host' в описании 2й реплики 3го шарда изменить с host1 на host4
добавить s41 на host4
удалить s3r2 с host1, включить host1
добавить s4r2 на host1
как-то так?

На практике я это ещё не проверял, так что может описание добавления новой ноды где-то ошибочно. И да, тут уже кажется было несколько ограничений  и граблей по дороге... В частности не поплохеет ли зукиперу от такой подмены, и сумеет ли он (продолжая получать новые данные от s3r1) нормально восстановить несколько отсутствующих партиций s3r2 на host4

я подразумеваю "circular replication"
она подразумевает что на одной железке крутятся реплики от разных шардов
один шард как минимум на 2х железках крутится

3 железки могут обслуживать 3 шарда кликхауса по 2 репилики в каждом итого 6 clickhouse-server
такая схема переживет отключение 1 сервера из 3

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

соответсвенно надо либо делать коэффициент репликации 3 и 3 ноды ch уже в железку могут не влезть
либо добавлять большее кол-во серверов что в итоге приводит к схеме 1 железка = 1 clickhouse-server

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

Было
host1: s1r1, s3r2, s2r3
host2: s2r1, s1r2, s3r3
host3: s3r1, s2r2, s1r3
+ host4

Надо:
host1: s1r1, s4r2, s3r3
host2: s2r1, s1r2, s4r3
host3: s3r1, s2r2, s1r3
host4: s4r1, s3r2, s2r3

Для этого должны переехать:
s4r2 и s3r3 с host1 на новый host4
s3r3 с host2 на host1

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

если что clickhouse-operator умеет в Circular Pod AntiAffinity
https://github.com/Altinity/clickhouse-operator/blob/master/docs/chi-examples/13-distribution-02-3x3-circular-replication.yaml

Из-за чего может быть, скажем так, лаг данных в КХ? Лагом я называю то, что данные в SELECT "отстают" от тех, которые вставляются сейчас. Причем в моем случае на несколько часов (хотя еще 12 часов назад этот лаг был 15 минут).

Что можно почитать на эту тему? Как форсировать этот лаг, если это возможно?

Вы делаете (успешный) INSERT, но вставленные данные в SELECT становятся доступны с большой задержкой до нескольких часов?
Вставляете в DISTRIBUTED таблицу?