11238
Обсуждаем ClickHouse
Ну да, лучше добавить как новые шарды и потом переносить данные по партициям для шардированных таблиц
Читать полностью…
возможно все сломается, потому что приложение не готово что те таблицы станут шардироваными, все не просто, я видел как после шардирования запросы на инициаторе начинали кушать в 5 раз больше памяти и работали в 10 раз дольше.
или например replacing + final, надо шардировать чтобы записи с одинаковым ключом попали на один шард, т.е. надо все переинсерчивать
Есть еще идея добавить новые ноды в текущие шарды, после того как данные на них синхронизируются, сделать их отдельными шардами и на шардированных таблицах дропнуть лишние партиции, ну и на старых шардах так же дропнуть не нужные партиции. И тогда не нужно будет переносить партиции
Читать полностью…
Это как то на стороне клика ограничивается или сервере нужно делать?
Читать полностью…
Добрый вечер!
Поделитесь опытом, если кто делал такое.
Есть кликхаус кластер состоящий из 3 шардов, кластер весит 100 ТБ из них 50 ТБ это шардированные таблицы, а остальные 50 ТБ это таблицы не шардированные и они имеют одинаковый набор данных на всех нодах этих 3 шардов. Нужно к текущему кластеру добавить еще две шарды. Как правильно их добавить? чтобы не было высокой нагрузки на кипера и данные быстро среплицировались, тут скорее вопрос про 50 ТБ данных, которые будут иметь одинаковый набор данных на всех нодах кластера. Шардированные таблицы инженера скорее всего будут переносить по партициям.
Знаю только вариант с добавлением новых шардов и созданием на них реплицированных таблиц, но смущает большой объем данных передаваемый по сети
min логично ставить
https://kb.altinity.com/altinity-kb-queries-and-syntax/ttl/ttl-group-by-examples/
но для toStartOfDay не принципиально
А вы уверены что это причина??, а не следствие??. И причина в другом
Читать полностью…
причина была в том что на данных одной из таблиц не попадает в индекс: количество символов в поле UserID в another_table1 гораздо меньше чем в another_table2
Читать полностью…
SELECT uuid
FROM system.tables
WHERE database = 'test' AND name = 'table_for_mv';
вот такой запрос говорит о том что у таблицы постоянно меняется uuid (раз в минуту), что логично, ведь КХ пересоздает таблицу по сути, только без данных
2025.10.09 14:34:04.181433 [ 570077 ] {e347b012-53b9-4ef3-8ce4-3f71509dcbfb} <Debug> DDLWorker(test): Executed query: /* ddl_entry=query-0000000696 */ CREATE OR REPLACE TABLE test.`.tmp.inner_id.9c7165d5-6d16-4952-858b-0c65953c34a2` UUID '43d700e8-5996-4033-b23a-a49010d1dbd4' (`sum` Int32, date Date) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}') PRIMARY KEY date ORDER BY date SETTINGS index_granularity = 8192
2025.10.09 14:34:04.181479 [ 570077 ] {} <Trace> DDLWorker(test): Checking task query-0000000697
2025.10.09 14:34:04.223182 [ 570077 ] {} <Debug> DDLWorker(test): Processing task query-0000000697 (query: EXCHANGE TABLES test.`.tmp.inner_id.9c7165d5-6d16-4952-858b-0c65953c34a2` AND test.table_for_mv, backup restore: false)
вот нашел лог
да, мигает переодически и потом удаляется
Читать полностью…
а есть ключевое слово как найти такую инфу в логе?
Читать полностью…
так тут все в порядке, надо смотреть в логе сколько строк select сложил в .tmp.inner_id.9c7165d5-6d16-4952-858b-0c65953c34a2
Читать полностью…
{replica_node1=1} -- shard2/replicas/replica_node2
Читать полностью…
да, спасибо, поправил скрипты которые убирают sensitive info из логов
Читать полностью…
Возможно я неправильно понял вас, но я имею в виду: в текущий шардированный кластер из 3 шардов и по 3 ноды в каждой шарде, добавить еще 6 новых нод, на 2 из 3 шардов, они среплицируют все данные и станут репликами 2 из 3 шардов. После полной синхронизации из 6 новых нод сделать 2 новые шарды, там будут 50 ТБ обычных реплицированных таблиц и 50 ТБ шардированных, на шардированных подропать не нужные партиции как на новых так и на старых шардах.
Хотя наверно такой вариант непрокатит, в пути кипера же указывается номер шарды и он скорее всего может сломаться
server-configuration-parameters , не merge_tree, merge_tree уже убрали
Читать полностью…
https://clickhouse.com/docs/operations/server-configuration-parameters/settings#max_replicated_sends_network_bandwidth_for_server
https://clickhouse.com/docs/operations/server-configuration-parameters/settings#max_replicated_fetches_network_bandwidth_for_server
поставьте sends в 2гбита
так а в чем проблема скопировать 50ТБ по сети? сеть 10гбит? боитесь что диск будет нагружен? Можно зарезать поток, например сделать 2 гбита
Читать полностью…
а если для another_table2 написать limit 3000 , то быстро работает?
Читать полностью…
Привет, а подскажите как работает ttl
https://clickhouse.com/docs/guides/developer/ttl#implementing-a-rollup
Вот по доке, в этом примере что поставится вместо timestamp, там выберется any? min?
Насколько ок самому воткнуть
Читать полностью…
SET timestamp = toStartOfDay(any(timestamp))
SELECT
UserID
FROM
test.hits
WHERE
UserID IN (
SELECT UserID
FROM another_table1
);
такое впечатление что сам запрос не исполняется и не вставляет данные в таблицу, хотя сам запрос в RVM верный и если его выполнить руками - он работает
Читать полностью…
в смысле создается _tmp.UUID - подозреваю что туда должно скинуть данные которые получились после выборки
потом удаляется, а вот данные не остаются нигде при этом
да, поправил еще раз, там все ок с репликами и серверами, они все реплицируют как положено на обычной базе
Читать полностью…
обновил свое сообщение
так же нашел в логах такое
2025.10.09 14:18:06.195049 [ 570077 ] {bc53d16b-e778-4ce3-a567-9777ded91920} <Debug> executeQuery: (from 0.0.0.0:0, user: ) (comment: refresh of test.mv_from_raw_source_local_to_table) /* ddl_entry=query-0000000558 */ DROP TABLE IF EXISTS test.`.tmp.inner_id.9c7165d5-6d16-4952-858b-0c65953c34a2` (stage: Complete)
т.е RMV выполняется, вот правда данные не сохраняет, почему-то
брр, ниче не понимаю shard2 - replica_node1
в макросах было replica_node2 shard2