AS
так mod -- это хешфункция, где ошибка у альтинити? вы о чем вообще?
технически да, практически это очень плохая хэш функция для получения равномерного распределения на любом входе)
Size: a a a
2020 August 27
DC
технически да, практически это очень плохая хэш функция для получения равномерного распределения на любом входе)
в доке КХ все разжевано, причем на русском
AS
в доке КХ все разжевано, причем на русском
хм.. может моя проблема в том что я английскую смотрю? сейчас сравню
DP
Привет!
Подскажите, пж. Нигде не нашел ответ на свой вопрос: Каких именно grant'ов не хватает user'у?
Пытаюсь создать Distributed table из под пользователя с ограниченными правами. Получаю ошибку:
Подскажите, пж. Нигде не нашел ответ на свой вопрос: Каких именно grant'ов не хватает user'у?
Пытаюсь создать Distributed table из под пользователя с ограниченными правами. Получаю ошибку:
CREATE TABLE db_test123.table_test2_all ON CLUSTER cluster_test AS db_test123.table_test2
ENGINE = Distributed(cluster_test, db_test123, table_test2, rand())
Received exception from server (version 20.4.4):
Code: 497. DB::Exception: Received from fg-clk02:9000. DB::Exception: test_user: Not enough privileges. To execute this query it's necessary to have the grant REMOTE ON *.*.
0 rows in set. Elapsed: 0.003 sec.DC
хм.. может моя проблема в том что я английскую смотрю? сейчас сравню
https://clickhouse.tech/docs/ru/engines/table-engines/special/distributed/
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
DC
Dmitry Pl
Привет!
Подскажите, пж. Нигде не нашел ответ на свой вопрос: Каких именно grant'ов не хватает user'у?
Пытаюсь создать Distributed table из под пользователя с ограниченными правами. Получаю ошибку:
Подскажите, пж. Нигде не нашел ответ на свой вопрос: Каких именно grant'ов не хватает user'у?
Пытаюсь создать Distributed table из под пользователя с ограниченными правами. Получаю ошибку:
CREATE TABLE db_test123.table_test2_all ON CLUSTER cluster_test AS db_test123.table_test2
ENGINE = Distributed(cluster_test, db_test123, table_test2, rand())
Received exception from server (version 20.4.4):
Code: 497. DB::Exception: Received from fg-clk02:9000. DB::Exception: test_user: Not enough privileges. To execute this query it's necessary to have the grant REMOTE ON *.*.
0 rows in set. Elapsed: 0.003 sec.grant REMOTE ON *.*DC
написано же в сообщении
DP
grant REMOTE ON *.*Попробую. Хотелось увидеть точный синтаксис. В доках о REMOTE ON - ничего.
AS
https://clickhouse.tech/docs/ru/engines/table-engines/special/distributed/
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
нашел, спасибо
AK
set max_threads=1,max_block_size=512
>Когда перечислил все столбцы вместо *, то падает по лимиту в 10ГБ
КХ не для вас. У вас 65к строк распакованными со всеми полями (*) не влезают в 10ГБ
>Когда перечислил все столбцы вместо *, то падает по лимиту в 10ГБ
КХ не для вас. У вас 65к строк распакованными со всеми полями (*) не влезают в 10ГБ
Через tabix не проходит set перед select. Так и должно быть? Как проще всего выполнить написанное?
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
AS
https://clickhouse.tech/docs/ru/engines/table-engines/special/distributed/
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
Для выбора шарда, на который отправляется строка данных, вычисляется выражение шардирования, и берётся его остаток от деления на суммарный вес шардов. Строка отправляется на шард, соответствующий полуинтервалу остатков от prev_weights до prev_weights + weight, где prev_weights - сумма весов шардов с меньшим номером, а weight - вес этого шарда. Например, если есть два шарда, и у первого выставлен вес 9, а у второго 10, то строка будет отправляться на первый шард для остатков из диапазона [0, 9), а на второй - для остатков из диапазона [9, 19).
на самом деле, на моих данных распределение должно было быть более менее равномерным, так как у меня там обычный int64 возрастающий монотонно
если выбор шарда определяется в итоге как key mod 2 (2 шарда, веса по умолчанию)
если выбор шарда определяется в итоге как key mod 2 (2 шарда, веса по умолчанию)
F🚜
Господа и дамы, а ни у кого нету под рукой какого-нибудь инструмента для удобного парсинга RowBinary формата?
и отвечая, hexedit. Лучше пока не нашёл
DP
grant REMOTE ON *.*Спасибо. Получилось. =)
DC
Через tabix не проходит set перед select. Так и должно быть? Как проще всего выполнить написанное?
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
можно навесить.
Ваша проблема в том что например 24 потока читают таблицу по 65к строк, отдают в пайплайн, и найдя искомый limit пайплайн останавливается. Но если читать все колонки * -- то у вас max_threads*65k * на все колонки, не влезают в 10ГБ.
выход set max_threads=1,max_block_size=512
что такое tabix -- я хз
Ваша проблема в том что например 24 потока читают таблицу по 65к строк, отдают в пайплайн, и найдя искомый limit пайплайн останавливается. Но если читать все колонки * -- то у вас max_threads*65k * на все колонки, не влезают в 10ГБ.
выход set max_threads=1,max_block_size=512
что такое tabix -- я хз
DC
на самом деле, на моих данных распределение должно было быть более менее равномерным, так как у меня там обычный int64 возрастающий монотонно
если выбор шарда определяется в итоге как key mod 2 (2 шарда, веса по умолчанию)
если выбор шарда определяется в итоге как key mod 2 (2 шарда, веса по умолчанию)
во всех примерах в КХ доке используются хеш функции в ключе шардирования, и в КХ есть consistent функции
YD
Всем привет, подскажите пожалуйста инструмент для аналитики запросов к кликхаус.
Сейчас использую https://grafana.com/grafana/dashboards/2515 но этот дашборд не очень удобный. может есть какие то альтернативы?
Сейчас использую https://grafana.com/grafana/dashboards/2515 но этот дашборд не очень удобный. может есть какие то альтернативы?
l
Всем привет, подскажите пожалуйста инструмент для аналитики запросов к кликхаус.
Сейчас использую https://grafana.com/grafana/dashboards/2515 но этот дашборд не очень удобный. может есть какие то альтернативы?
Сейчас использую https://grafana.com/grafana/dashboards/2515 но этот дашборд не очень удобный. может есть какие то альтернативы?
tabix?
DC
Запрос
select *
from CfLog c
where Timestamp < '2020-07-12 10:00:00'
order by Timestamp desc
limit 1
падает по memory limit
Схема
CREATE TABLE default.CfLog (
...
...
...
) ENGINE = MergeTree() PARTITION BY toYYYYMMDD(Timestamp)
ORDER BY
(Timestamp, RayIdInt) SETTINGS index_granularity = 8192
select *
from CfLog c
where Timestamp < '2020-07-12 10:00:00'
order by Timestamp desc
limit 1
падает по memory limit
Схема
CREATE TABLE default.CfLog (
Timestamp DateTime64(3), RayIdInt Int64, CookieGa String,...
...
...
) ENGINE = MergeTree() PARTITION BY toYYYYMMDD(Timestamp)
ORDER BY
(Timestamp, RayIdInt) SETTINGS index_granularity = 8192
кстати
CREATE TABLE default.CfLog (
ORDER BY (Timestamp, RayIdInt)
это очень странный ORDER BY т.е. там RayIdInt наверное смысла уже нет после DateTime64
CREATE TABLE default.CfLog (
Timestamp DateTime64(3), RayIdInt Int64,ORDER BY (Timestamp, RayIdInt)
это очень странный ORDER BY т.е. там RayIdInt наверное смысла уже нет после DateTime64
D
Через tabix не проходит set перед select. Так и должно быть? Как проще всего выполнить написанное?
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
Ну и, касательно 10ГБ, понимаю, что под OLAP запросы надо для наших запросов в 50-100 раз больше. Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.
попробуйте через
select xxxx from yyy
SETTINGS max_threads=1,max_block_size=512
select xxxx from yyy
SETTINGS max_threads=1,max_block_size=512
AK
попробуйте через
select xxxx from yyy
SETTINGS max_threads=1,max_block_size=512
select xxxx from yyy
SETTINGS max_threads=1,max_block_size=512
Спасибо, отработало