Если я правильно понимаю, то проблемы полезут из других движков и из зоокипера, но там num_layers может поможет (не проверял).

Буфер живет в памяти и при отключении питания ваши данные тютю. Со всеми вытекающими.

Ну, скажем, приложенько на пхп так едва ли сможет (готовить пачку). Не все ж могут себе купить чего-нибудь.

Мы из приложеньки на пхп бахаем через эту штуку, которая нам батчует всё - https://github.com/badoo/lsd

Опять наткнулся на 2017.08.01 20:16:24.814536 [ 189 ] <Error> HTTPHandler: Code: 252, e.displayText() = DB::Exception: Too much parts. Merges are processing significantly slower than inserts., e.what() = DB::Exception, Stack trace:

background_pool_size увеличил до безобразия - не помогло

сервера ничего не делают, процессоры простиавают и инсерты просели в 5 раз

и что с этим делать непонятно

интересно что это на кластере из 3 машин, 3 шарды по 2 реплики

на одной машине когда поставил background_pool_size = 8 этого хватило чтобы мержи успевали

На скрине видно как после 8:08 где-то процессинг из Кафки стал рваным (лаг перестал снижатьс быстро) и в это же время КХ сервера начали курить

Непорядок какой-то

Ну, скажем, приложенько на пхп так едва ли сможет (готовить пачку). Не все ж могут себе купить чего-нибудь.

приложение -> очередь -> наблюдатель очереди

Ну, скажем, приложенько на пхп так едва ли сможет (готовить пачку). Не все ж могут себе купить чего-нибудь.

У нас php успешно пишет в файлы TSV по 10 сек, и потом типа cron грузит в CH... уже год как и не напрягает...

@garikanet что если на этапе загрузки в CH стало понятно, что с данными что-то не так? Не правильный тип поля, например. Как решаете? впрочем это касается не только php

@garikanet что если на этапе загрузки в CH стало понятно, что с данными что-то не так? Не правильный тип поля, например. Как решаете? впрочем это касается не только php

У нас несколько ETL, в самом простом виде пишем в tsv заливаем, без особой проверки - данные не критичные и их потеря допустима. Другой etl - читает protobuf данные, потом преобразует в RowBinary У них всех есть очередь в простом варианте две папки - "ожидают" и "обработанные" - перемещение из одной в другую после успешной загрузки, если происходит ошибка то руками можно поправить и перезалить. Использование формата типа protobuf - решает проблему формата полей и структуры данных, позволяет версионность.

@garikanet что если на этапе загрузки в CH стало понятно, что с данными что-то не так? Не правильный тип поля, например. Как решаете? впрочем это касается не только php

Вариант 1. Удаление таблицы и заливка данных заново Вариант 2. Deattach "битых" данных и заливка их заново

У нас несколько ETL, в самом простом виде пишем в tsv заливаем, без особой проверки - данные не критичные и их потеря допустима. Другой etl - читает protobuf данные, потом преобразует в RowBinary У них всех есть очередь в простом варианте две папки - "ожидают" и "обработанные" - перемещение из одной в другую после успешной загрузки, если происходит ошибка то руками можно поправить и перезалить. Использование формата типа protobuf - решает проблему формата полей и структуры данных, позволяет версионность.

Вопрос скорее был в том, что делать когда данные УЖЕ в CH

Позвольте повторить свои вопросы, потому как без ответов я застопорился совсем

1 по кластеру. SELECT * FROM system.clusters ┌─cluster─┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name──┬─host_address─┬─port─┬─is_local─┬─user────┬─default_database─┐ │ metrics │ 1 │ 1 │ 1 │ 10.1.1.251 │ 10.1.1.251 │ 9000 │ 1 │ default │ │ │ metrics │ 1 │ 1 │ 2 │ 10.1.1.86 │ 10.1.1.86 │ 9000 │ 1 │ default │ │ │ metrics │ 2 │ 1 │ 1 │ 10.1.1.251 │ 10.1.1.251 │ 9000 │ 1 │ default │ │ │ metrics │ 2 │ 1 │ 2 │ 10.1.1.145 │ 10.1.1.145 │ 9000 │ 1 │ default │ │ │ metrics │ 3 │ 1 │ 1 │ 10.1.1.86 │ 10.1.1.86 │ 9000 │ 0 │ default │ │ │ metrics │ 3 │ 1 │ 2 │ 10.1.1.145 │ 10.1.1.145 │ 9000 │ 0 │ default │ │ └─────────┴───────────┴──────────────┴─────────────┴────────────┴──────────────┴──────┴──────────┴─────────┴──────────────────┘ 6 rows in set. Elapsed: 0.050 sec. Тут вроде все ок, 3 шарды по 2 реплики

а тут пишет что реплика 1 SELECT * FROM system.replicas FORMAT Vertical zookeeper_path: /clickhouse/tables/measures/01 replica_name: 1 replica_path: /clickhouse/tables/measures/01/replicas/1 columns_version: 0 queue_size: 3 inserts_in_queue: 0 merges_in_queue: 3 queue_oldest_time: 2017-08-02 07:44:40 inserts_oldest_time: 0000-00-00 00:00:00 merges_oldest_time: 2017-08-02 07:44:40 oldest_part_to_get: oldest_part_to_merge_to: 20170210_20170216_42373_54709_5421 log_max_index: 914493 log_pointer: 914494 last_queue_update: 2017-08-02 07:44:40 absolute_delay: 0 total_replicas: 1 active_replicas: 1 Так по 2 реплики или все таки по одной ?

Вопрос номер два: Локальные запросы с 3 машин 1 rows in set. Elapsed: 1.254 sec. Processed 9.56 billion rows, 19.13 GB (7.63 billion rows/s., 15.25 GB/s.) 1 rows in set. Elapsed: 0.833 sec. Processed 7.38 billion rows, 14.75 GB (8.85 billion rows/s., 17.70 GB/s.) 1 rows in set. Elapsed: 0.810 sec. Processed 6.80 billion rows, 13.59 GB (8.39 billion rows/s., 16.79 GB/s.) 9.56+7.38+6.80=23.74 Распределенный запрос 1 rows in set. Elapsed: 2.310 sec. Processed 25.92 billion rows, 51.85 GB (11.22 billion rows/s., 22.44 GB/s.) Почему одно не равно другому?

Вопрос номер три, последнии :) Что же все таки делать с 2017.08.01 20:16:24.814536 [ 189 ] <Error> HTTPHandler: Code: 252, e.displayText() = DB::Exception: Too much parts. Merges are processing significantly slower than inserts., e.what() = DB::Exception, Stack trace: Почему кластер перестает грузить машины и писать начинает очень медленно? Как его заставить мержить используя все ресурсы?

Картинку повторю

2) Он получил данные с 3-х машин, потом результат локально померджил (тоже строки) 3) Вставляйте большими пачками не чаще чем раз в 1-2 секунды

Привет, правильно ли я понимаю, что replacingMergeTree удаляет дубликат по соответствию составного primary ключа? Т.е если у меня составной ПК состоит из него лонгового id и даты, то mergeTree удалит дубликат, при соответствии и айди, и даты одновременно

2) Так count же, как он так помержил что итоговая сумма разная получилась?

3) вставляю пачками по 500000

Увеличить до 1000000?

Уверены что оно одним блоком уходит, а не кучей insert into ?

2) Так count же, как он так помержил что итоговая сумма разная получилась?

сам COUNT правильно посчитан ?

привет! а что за метрика ClickHouse.ProfileEvents.SelectedRanges ?

Уверен что блоком иначе бы оно намного раньше умерло

Count правильно? Не уверен что понял вопрос, извини. Ну сложил я 3 числа вроде правильно. А как КХ их посчитал я не уверен

стопаем запись, делаем SELECT COUNT() FROM distributed и на всех локальных SELECT COUNT() from local складываем числа с локальных и они должны сойтись с распределенной

так это и делал

сейчас повторю

насчет записи

и что получилось ?

вот так начинается

2017-08-01 19:55:00,272 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500001 docs into store 2017-08-01 19:55:00,904 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500003 docs into store 2017-08-01 19:55:01,612 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500003 docs into store 2017-08-01 19:55:02,462 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500001 docs into store 2017-08-01 19:55:04,705 INFO [CHRawDataPullerThread_1] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_1: Inserted 500001 docs into store 2017-08-01 19:55:05,590 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500002 docs into store 2017-08-01 19:55:06,438 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500001 docs into store

вот так потом с затыками 2017-08-01 20:50:31,461 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500004 docs into store 2017-08-01 20:50:31,521 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store 2017-08-01 20:50:53,914 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500006 docs into store 2017-08-01 20:50:53,980 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500002 docs into store 2017-08-01 20:50:54,452 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500003 docs into store

и на картинке выше видно что в это время сервера ничего не делают

вот повторил

1 rows in set. Elapsed: 0.780 sec. Processed 6.86 billion rows, 13.73 GB (8.80 billion rows/s., 17.61 GB/s.) 1 rows in set. Elapsed: 0.851 sec. Processed 7.44 billion rows, 14.89 GB (8.74 billion rows/s., 17.49 GB/s.) 1 rows in set. Elapsed: 1.087 sec. Processed 9.65 billion rows, 19.31 GB (8.88 billion rows/s., 17.77 GB/s.) 6.86+7.44+9.65=23.95 1 rows in set. Elapsed: 2.144 sec. Processed 26.17 billion rows, 52.35 GB (12.21 billion rows/s., 24.42 GB/s.)

могу скриншотов наделать

запросы такие select count(*) from Measures; и select count(*) from Measures_Distributed;

Идеи? И что блин с этими мержами делать, видимо надо Алексея ждать. Сам не разберусь.

запросы такие select count(*) from Measures; и select count(*) from Measures_Distributed;

сами COUNT тоже не сошлись ? Measures_Distributed точно ходит на те сервера на которых руками запрос к локальным таблицам делали ?

Да каунты не сошлись

У меня всего 3 сервера сейчас. Выше я выложил как clusters выглядит.

Выкладывать как таблицы создавал?

Добавил еще 2 распределенные таблицы. Они указывают на те же реплицированные. Вот результаты. Что-то я в замешательстве все больше ubuntu@pprod-spm-ch-3:~$ curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;' 27006115772 ubuntu@pprod-spm-ch-3:~$ curl 'pprod-spm-ch-4:8123?query=select+count(*)+from+default.Measures_Distributed;' 22433347800 ubuntu@pprod-spm-ch-3:~$ curl 'pprod-spm-ch-5:8123?query=select+count(*)+from+default.Measures_Distributed;' 24140419001

Запросы к 3 серверам. ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 25349551940 24191925958 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27062961884 »»»»» УМЕНЬШИЛОСЬ КОЛ-ВО? КАК ТАК? 22478516014 21899703023

Запросы к 3 серверам. ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 25349551940 24191925958 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27062961884 »»»»» УМЕНЬШИЛОСЬ КОЛ-ВО? КАК ТАК? 22478516014 21899703023

у тебя точно нет проблем с репликами? например они дико отстают или еще что-то такое?

for i in {1..3}; do curl 'localhost:8123?query=select+count(*)+from+default.metricstats;'; done 127850185240 127850185240 127850185240

тоже запрос на распределенную таблицу, поверх replicated merge tree

Как проверить что реплтки не отстают?

В system.replicas delay = 0

SELECT absolute_delay FROM system.replicas FORMAT Vertical Row 1: ────── absolute_delay: 0 1 rows in set. Elapsed: 0.001 sec.

а версия КХ какая?

где глянуть (извини не знаю)

ERROR: S client not available

На всех

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

где глянуть (извини не знаю)

select version()

например

и проверь сразу на всех железках

На всех 1.1.54245

это вроде последний stable, да

ну тогда ждем когда @milovidov_an или @the_real_jkee или еще кто из разработчиков (или близких к ним людей) посмотрит

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+version();'; done; 1.1.54245 1.1.54245 1.1.54245

Да жду их. Без кластера все вроде ок было. А тут началось :)

Реально очень похоже что что-то с репликами

потому как числа прыгают но вариантов только 2

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27062961884 25349551940 24191925958 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 22478516014 21899703023 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 25349551940 21899703023 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 22478516014 24191925958 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 22478516014 21899703023 ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done; 27641774875 22478516014 21899703023

Может дело в том что я на каждой машине создавал по 2 таблицы такие? CREATE TABLE IF NOT EXISTS Measures ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags Nested ( name UInt32, value UInt32 ) ) Engine = ReplicatedMergeTree('/clickhouse/tables/measures/02', '2',date, (account, id, timestamp), 8192); CREATE TABLE IF NOT EXISTS Measures ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags Nested ( name UInt32, value UInt32 ) ) Engine = ReplicatedMergeTree('/clickhouse/tables/measures/03', '2',date, (account, id, timestamp), 8192);

ну тоесть они шардами и репликми отличались только

а ты уверен что они у тебя обе созданы? )

кажется что с одним именем нельзя

может не обе

как на 3 сервера раскидать 3 шарда с 2 репликами по другому не придумал

Могу все пересоздать если кто подскажет как

:)

названия таблиц поменяй (ИМХО)

но я боюсь ты дистрибьютед на них так просто не натянешь уже

А как тогда в Распределенной их указать?

CREATE TABLE default.Measures_Distributed ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags.name Array(UInt32), tags.value Array(UInt32)) ENGINE = Distributed(metrics, \'default\', \'Measures\', rand())

Может дело в том что я на каждой машине создавал по 2 таблицы такие? CREATE TABLE IF NOT EXISTS Measures ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags Nested ( name UInt32, value UInt32 ) ) Engine = ReplicatedMergeTree('/clickhouse/tables/measures/02', '2',date, (account, id, timestamp), 8192); CREATE TABLE IF NOT EXISTS Measures ( account UInt32, id UInt32, date Date, timestamp UInt32, value Float32, tags Nested ( name UInt32, value UInt32 ) ) Engine = ReplicatedMergeTree('/clickhouse/tables/measures/03', '2',date, (account, id, timestamp), 8192);

Как-то странно создаются таблицы. По-логике, 2-я совсем не должна была создаться, так как IF NOT EXISTS, и имя совпадает с первой.

Согласен

что-то намудрил

дайте рецепт как на 3 серверах получить 3 шарды с 2 репликами для каждой

Неужели у всех 6 серверов :)