Спам

нет, там идея в том что бы вернуть distinct - но после order by
тоесть например уникальные ивенты, и к каждому ивенту дату первого хита

/voteforban

/stat@combot

Тогда вам нужен не DISTINCT, а LIMIT N BY

например
SELECT * FROM events ORDER BY action_at ASC LIMIT 1 BY (hit_code)

Поймали ограничение по памяти при вставке

DB::Exception: Memory limit (for query) exceeded: would use 27.94 GiB (attempt to allocate chunk of 131072 bytes), maximum: 27.94 GiB.

Делаем

INSERT INTO table SELECT field1, ...fieldN FROM table2 WHERE action_date = '2017-08-01' ORDER BY action_at

При этом вставка без сортировки отрабатывает отлично, собственно как и сам запрос
SELECT COUNT() FROM (SELECT field1, ...fieldN FROM WHERE action_date = '2017-08-01' table2 ORDER BY action_at)

настройки

┌─name───────────────────────────────┬─value───────┬─changed─┐
│ max_bytes_before_external_group_by │ 20000000000 │ 1 │
│ max_bytes_before_external_sort │ 20000000000 │ 1 │
└────────────────────────────────────┴─────────────┴─────────┘

max_insert_block_size/max_threads крутили, не помогает

Что можно покрутить ещё ?

Просто оставлю это здесь: https://db-engines.com/en/ranking

"В перспективный стартап ищем SQLite DBA"

это ощущение от рейтинга )

неее, от рейтинга нужен DBA на MS Access

На подобии этого
https://clickhouse.yandex/docs/ru/query_language/queries.html#id8
есть внешняя сортировка
max_bytes_before_external_sort

у нас оно выставлено, с самим запросом работает (хотя он и так в пямять влазит), а на INSERT оно не влияет

Возможно нужно создать issue чтобы влияло, или можно было повлиять

Я на такое наталкивался, пришлось отказаться от прямой вставки. Можно попробовать выгрузить данные в отсортированом виде на диск, а потом с диска их вставить через clickhouse-client

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

К сожалению при
INSERT INTO table SELECT * FROM table2
данные видны до окончания выполнения запроса, что иногда не очень удобно. Нет ли ручки которую можно покрутить чтоб исправить такое поведение ?

Привет, кто нибудь хранит в кликхаусе деревья и каким шаблоном, таблицей связей?

Не поддерживает ли формат (col1, col2, col3) IN ( (1,2,3) ) wildcard, типа (1, 2, *)?

наверно можно так IN (SELECT id FROM ids)

не так понял вопрос, только так col in () AND col2 IN() ...

Попробуйте ещё несколько уменьшить пороги на внешнюю сортировку и агрегацию. Например, в два раза.

Может кто подскажет как на 3 серверах сделать распределенную таблицу с репликацией?
Сделал 3 шарды и 2 реплики
создал таблицы на нодах так
1 » shard 1 replica 1, shard 2 replica 1
2 » shard 2 replica 1, shard 1 replica 2
1 » shard 2 replica 2, shard 3 replica 2
Поверх этого сделал Распределенную таблицу с rand() в качестве ключа шардирования
Как теперь проверить что все поднялось каак мне надо?

В целом нет. Есть некоторые ухищрения, но на них рассчитывать не стоит.

Обычно деревья (регионы, товарные категории) хранятся отдельно и подключаются в виде иерархического словаря.

Не поддерживает.

Посмотрите на тесты в репозитории, там есть пример перекрёстной репликации

спсб

у меня явно что-то не поднялось :) SELECT * FROM system.clusters

SELECT *
FROM system.clusters

Ok.

0 rows in set. Elapsed: 0.001 sec.

https://github.com/yandex/ClickHouse/blob/c90ea346ce9ef51886875b8f3f99c24c6c19c2e0/dbms/tests/integration/test_cross_replication/test.py

спсб, буду разбираться.
вопрос по распределенной таблице
1. Читать можно с любого сервера рандомно или только с того где таблицу распределенную создали?
2. Писать рандомно в низлежащие таблицы? А как оно перешардироваться будет или если в качестве ключа rand() то ляжет как положили?

а что он должен делать?

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

ищем в эллипсе, примерно соответствущему этому кругу в декартовых координатах.
pointInEllipses()

1. Читать нужно из таблицы с движком Distributed. При этом можно создать такую таблицу на каждом сервере (так, чтобы структура кластера совпадала)
2. Писать можно как в Distributed таблицу (тогда нужно указать выражение для шардирования), так и отдельно на каждый шард. Подробнее написано в документации: https://clickhouse.yandex/docs/ru/table_engines/distributed.html

А создавать распределенную таблицу только на одном сервере и читать только с него

или можно на каждом по распределенной таблице создать и читать со всех параллельно?

можно на каждом

круто

спсб

не могу понять почему в кластерах пусто

cat /etc/clickhouse-server/remote_servers.xml
<yandex>
<remote_servers>
<metrics>
<shard>
<!— Optional. Wheight for writing. Default is 1. —>
<weight>1</weight>
<!— Optional. Write to only 1 replic?. By default, false - write to all replics. —>
<internal_replication>true</internal_replication>
<replica>
<host>10.1.1.251</host>
<port>9000</port>
</replica>
<replica>
<host>10.1.1.86</host>
<port>9000</port>
</replica>
</shard>

SELECT count(*)
FROM Measures_Distributed

Received exception from server:
Code: 170. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Requested cluster 'metrics' not found.

0 rows in set. Elapsed: 0.020 sec.

:)

SELECT *
FROM system.clusters

Ok.

0 rows in set. Elapsed: 0.001 sec.

:)

сервер рестартовал

Переместите файл remote_servers.xml в
/etc/clickhouse-server/conf.d/

понял, видимо пропустил в документации

ура спсб

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.004 sec.

Спасибо!

Подскажите, есть 2 сервера конфигурация 2 шарда и 2 реплики - хочу чтобы чтение было с обоих серверов. В таком конфиге ведь чтение не обязательно будет идти с обоих серверов, как задать и возможно ли чтобы чтение было с двух серверов по возможности ?
<yandex>
<remote_servers>
<graphite>
<shard>
<replica>
<host>node1</host>
<port>9000</port>
</replica>
<replica>
<host>node2</host>
<port>9000</port>
</replica>
</shard>
<shard>
<replica>
<host>node1</host>
<port>9000</port>
</replica>
<replica>
<host>node2</host>
<port>9000</port>
</replica>
</shard>
</graphite>
</remote_servers>
</yandex>

Если читаете из Distributed таблицы, то должно читаться со всех серверов.

А у меня такой вопрос. Вот есть движок ReplacingMergeTree, а есть ли для него Replicated эквивалент? Для всего семейства движков MergeTree кроме Replacing нашёл упоминание в доке

Есть такой движок

ReplicatedReplacingMergeTree?

так точно

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

вроде как есть параметр load_balancing и in_order - не очень понятно как правильно прописать их

Всем привет, используем таблицу ReplicatedReplacingMergeTree для схлопывания строк, и вот интересно, может ли она схлопывать записи с одинаковыми версиями? На практике видим, что не схлопывает, так и задумано? Или это будет меняться?

а как из одинаковой версии понять, какую запись оставить, а какую выкинуть?

Наверно по этому и не нужно вставлять одинковые версии. В доке https://clickhouse.yandex/docs/ru/table_engines/replacingmergetree.html#replacingmergetree описано что можно использовать DateTime

ну, да, вопрос-то был про одинаковые версии :)

Да, испольузем dateTime - но в одну секунду может быть две записи

а как в таком конфиге задатать верные макросы ? делал кто-нибудь ?

а миллисекунды?

DateTime - unix timestamp

нет миллисекунд у КХ :(

я имел в виду "записывать ms отдельно"

А куда сюда http://joxi.ru/zANGZyRilwRdZr записывать отдельно? Я бы попробовал заменить DateTime на UInt64 и переводить дату вставки в дату в милисекундах

Если только использовать UInt в качестве версии где оно равно timestamp*1000

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

все, группировать по уникальности только?

UInt64 может такое хранить https://clickhouse.yandex/docs/ru/data_types/int_uint.html#uint
Т.е. можно конечно попробовать timestamp*1000 + что-то ещё зависящее от времени или версии строки

Подозреваю это не юзер-кейс ReplaceMergeTree и CH вообще

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

Нет такого поля

Только если на уровне приложение его генерировать и там же проверять уникальность. Сам CH никак не умеется автоинкреемнтить. Так же не отслеживается уникальность строк по какому-либо полю. Исключение - движки семейства MergeTree - ReplaceMergeTree, CollapsingMergeTree и т.п. Но они не делают в прямом смысле то, что ожидается от уникального поля

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

Схлопывает же с одинаковыми версиями. Оставляет последнюю запись (видимо из кусочка с большим номером)

Я ловил что не схлопывает только в случае когда в КХ заинсертили всего один раз. Тогда у него всего один чанк, он ничего ни с чем не мерджит, соотвественно и схлопывания одинаковых ключей не происходит

Т.е. в одном INSERT были одинаковые значения PKEY?

да

красиво, спасибо за информацию!

Если я правильно понимаю, то нужно указать параметр load_balancing = in_order (в настройках пользователя или через SET) и тогда реплики будут выбираться в порядке перечисления в конфигурационном файле

В разных. Просто два раза сделал один и тот запрос и одни и те же данные (в том числе версия тоже)

можно выполнить optimize table xxx partition 201708 final;

со своим месяцем

и положить кластер)

replacing схлопывает версии только при мерже кусков. если есть 2 одинаковых куска, то и в select запросе данные бедут дублироваться. при мерже, если версия совпадет, выберется строка с последней версией.

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

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

Привет!
Есть задача:
Хранить в clickhouse как оперативные данные (на серверах с SSD), так и архивные (серваки с HDD). Как это правильно реализовать? Как-то использовать Distributed-движок?

Скажите это нормально?

Запросы к 3 локальным таблицам
1 rows in set. Elapsed: 0.381 sec. Processed 3.26 billion rows, 6.51 GB (8.53 billion rows/s., 17.07 GB/s.)
1 rows in set. Elapsed: 0.372 sec. Processed 2.99 billion rows, 5.99 GB (8.05 billion rows/s., 16.11 GB/s.)
1 rows in set. Elapsed: 0.513 sec. Processed 4.18 billion rows, 8.35 GB (8.14 billion rows/s., 16.28 GB/s.)

3.26+2.99+4.18=10.43

Запрос к распределенной
1 rows in set. Elapsed: 1.176 sec. Processed 11.60 billion rows, 23.20 GB (9.86 billion rows/s., 19.73 GB/s.)

10.43 != 11.60

+ Еще один вопрос.

backgroung threads поставил в 16 в настройках потому как сластер начал отваливаться с too many parts
смотрю в system.merges 0-2 записи, в parts 5000 или 7000 и растет а процессор не загружен
почему КХ не мержит в 16 потков в срочном порядке?

Я, конечно, не знаю, что такое батчи. Можете ткнуть в меня ссылкой. Но таки получается, что если я буду делать живую аналитику на тыкдоме, то приложенько, которое будет у меня вызывать 20к вставок в секунду, просто положит сервер и всё. А обещалось как раз быстро вставлять.
Таки а где ж оптимизатор умный, который будет там складывать, скажем в буфер, а потом вносить данные?

батчи=пачками по 20000 в вашем случае
и да есть Buffer в КХ, но лучше делать самому подготовку пачки на стороне приложения по краиней мере документация Buffer не рекомендует почему-то

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

Чот яндекс опять наврал.

Мне кажется надо Buffer.

Тут упомянули ещё какие-то внешние решения, которые собирают батчи, но желания не возникло пробовать. В целом буффер именно для этого.

Вставлял ~500к в секунду.

Помимо того, что вставлять в буфер, ещё удобно вставлять чанками через http

Получается так сказать два буфера , там уже за 3млн переваливает легко.

Это на буфере и простом mergetree

ну так буфер ж не рекомендован. А я б не стал использовать то, что не рекомендовано производителем.

Хотя... Я вообще не знаю, зачем писать о чём-то в доке, если есть предупреждение "не использовать"

Я точно не помню, но там вроде были описаны кейсы когда он не рекомендуется.

Если буферов 16, то порядок не сохраняется. Но по идее в mergetree он же восстановится?

Если я правильно понимаю, то проблемы полезут из других движков и из зоокипера, но там 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

У нас несколько ETL, в самом простом виде пишем в tsv заливаем, без особой проверки - данные не критичные и их потеря допустима.

Другой etl - читает protobuf данные, потом преобразует в RowBinary

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

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

Вопрос скорее был в том, что делать когда данные УЖЕ в 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 ?

сам 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;

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

сами 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

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

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.

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

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

На всех

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-я совсем не должна была создаться, так как IF NOT EXISTS, и имя совпадает с первой.

Согласен

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

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

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

можно наверное в разних БД создавать

но это изврат наверное какой-то

и распределенную не натянуть

Точно не уверен, что возможно. Попытаюсь уточнить. В любом случае, создавать надо 1 таблицу, а параметры реплики\шарда указывать в подствновке {shard} и {replica}, иначе что-то странное будет.

Спсб

Добавлю 4 сервер тогда и пока сделаю 2*2
Но очень хочется читать сразу с 4 а не с 2 как тут получится

https://github.com/yandex/ClickHouse/tree/master/dbms/tests/integration/test_cross_replication

Все таки с разными бд, я думал это изврат

а бд указали в распределенной как '' и оно заработало?
Спсб

Да, у меня так срабатывало

Уря-уря

ушел все дропать

да, действительно, судя по тесту, я был неправ :)

!!! Спсб

Alex a вы случаем не знаете что с too many parts делать?

батчи до 1M увеличивать?

Все таки немног втранно что КХ ничего не делает при этом (при том что parts мержить надо)

Помнится была какая-то настроечка которую советовали увеличить в таких случаях.

background threads pool?

Поставил аж 64 - нифига

может магическое число 8192 увеличить

Только что ответил внутри, из-за чего может быть ошибка Too much parts. Скопирую сюда:

Может быть несколько причин, почему такое происходит:

1. Данные не успевают мержатся, но всё-таки мержатся. Это будет видно по наличию большого количества одновременных мержей.
Запрос SELECT * FROM system.merges,
метрика ClickHouse.Metrics.Merge в Графите.
В этом случае может помочь увеличение размера пачки.

2. Данные не мержатся из-за того, что превышено некоторое ограничение. В последней версии ограничение на суммарный размер кусков, которые можно мержить - 100 GB. На практике мы убедились, что это плохо - если за месяц больше 10 ТБ данных, то это приводит к тому, что есть несколько сотен кусков, которые не мержатся. Скоро увеличим по-умолчанию, а пока можно увеличить вручную - я скажу, как.
Чтобы проверить - нужно посмотреть на размеры кусков: SELECT * FROM system.parts WHERE active

3. Данные не мержатся из-за бага. Суть в том, что среди реплик выбирается одна реплика-лидер, и именно она решает, какие мержи нужно делать. Раньше было много проблем - например, реплика-лидер могла отставать и не видеть куски для мержей. Или одна реплика могла уступить лидерство, а другая долго не брать его, из-за того, что это требует захвата некоторых блокировок. Все эти проблемы мы исправили и больше не наблюдали :) Но похожие вещи всё-равно могут быть.
Чтобы проверить - надо посмотреть на число одновременных мержей, так же, как написано выше. Если мержей нет - значит подозрение на такую проблему.

Сейчас есть проблема, что при объёме данных больше 10 ТБ в месяц, куски плохо мержатся, из-за выставленных настроек по-умолчанию. Если это ваш случай, то можно прописать в config.xml в секции merge_tree, max_bytes_to_merge_at_max_space_in_pool побольше (по-умолчанию - 100 ГБ, можно увеличить до 500 ГБ, например).

max_bytes_to_merge_at_max_space_in_pool

У меня похлже случай что merges пустая

и сервер простаивает

по крайней мере я много раз делал селект и в 50% случаях ничего не возвращалось

увеличу до 500000000000

ubuntu@pprod-spm-ch-3:~$ cat /etc/clickhouse-server/conf.d/remote_servers.xml
<remote_servers>
<metrics>
<shard>
<!— Optional. Wheight for writing. Default is 1. —>
<weight>1</weight>
<!— Optional. Write to only 1 replic?. By default, false - write to all replics. —>
<internal_replication>true</internal_replication>
<replica>
<default_database>shard_1</default_database>
<host>10.1.1.251</host>
<port>9000</port>
</replica>
<replica>
<default_database>shard_1</default_database>
<host>10.1.1.86</host>
<port>9000</port>
</replica>
</shard>

2017.08.02 11:48:11.231828 [ 35 ] <Error> HTTPHandler: Code: 170, e.displayText() = DB::Exception: Requested cluster 'metrics' not found, e.what() = DB::Exception, Stack trace:

Это после рестарта

я болван, пофиксил

Пересоздал как в рецепте на питоне с одтельными бд дла каждой шарды

все равно count пляшет
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;
30670267
40000954
30670267
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;
30670267
35331001
36669049
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;
30670267
45999736
26000314
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;
30670267
40000954
41339002
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;
30670267
30670267
36669049
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;
31003969
46332908
41672704

Что касается мержей то вот
SELECT count(*)
FROM system.parts

┌─count()─┐
│ 4117 │
└─────────┘

1 rows in set. Elapsed: 0.014 sec. Processed 4.12 thousand rows, 805.87 KB (293.92 thousand rows/s., 57.53 MB/s.)

:) select count(*) from system.merges;

SELECT count(*)
FROM system.merges

┌─count()─┐
│ 0 │
└─────────┘

1 rows in set. Elapsed: 0.001 sec.

И кол-во частей растет

SELECT count(*)
FROM system.parts
WHERE active

┌─count()─┐
│ 2638 │
└─────────┘

1 rows in set. Elapsed: 0.011 sec. Processed 2.64 thousand rows, 517.82 KB (245.53 thousand rows/s., 48.19 MB/s.)

Размеры кусков (часть небольшая)

│ 238744 │
│ 150295 │
│ 45537 │
│ 1877 │
│ 3497620 │
│ 45097735 │
│ 100445291 │
│ 25183453 │
│ 24205009 │
│ 8025090 │
│ 2813436 │
│ 2776275 │
│ 640824 │
│ 2951712 │
│ 45963162 │
│ 103841374 │
│ 29787212 │
│ 35136577 │
│ 670064 │
│ 661817 │
│ 694306 │
│ 675514 │
│ 675479 │
│ 1969 │
│ 1659 │
│ 1482 │
│ 1385 │
│ 1635 │
│ 1326 │
│ 1641 │

SELECT bytes
FROM system.parts
WHERE active
ORDER BY bytes DESC
LIMIT 20

┌─────bytes─┐
│ 103841374 │
│ 100445291 │
│ 45963162 │
│ 45097735 │
│ 35136577 │
│ 29787212 │
│ 27960524 │
│ 25183453 │
│ 24205009 │
│ 21057918 │
│ 18070983 │
│ 10042797 │
│ 6931969 │
│ 3497620 │
│ 3056593 │
│ 2951712 │
│ 2716754 │
│ 757982 │
│ 757828 │
│ 748188 │
└───────────┘

Кол-во parts уменьшается, значит мерджы идут

cначала они и вчера шли

Возможно ваши реплики и шарды с разной скоростью обрабатывают данные - потому и отличия в COUNT

а потом через 3-4 часа

когда колво достигло около 20000 все заглохло

Давайте останавлю вставку и проверим через минуту

Значит фоновые мерджи, при ваших настройках, закончились. Это штатное поведение

Коллеги, всем привет. Получается, что нельзя использовать условные операторы https://clickhouse.yandex/docs/ru/functions/conditional_functions.html?highlight=%D1%83%D1%81%D0%BB%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9 с NamedParameterJdbcTemplate

я когда написал в запросе (model_id != 0 ? model_id : cluster_id) AS model_id, у меня возникла бага

org.springframework.dao.InvalidDataAccessApiUsageException: Not allowed to mix named and traditional ? placeholders. You have 2 named parameter(s) and 2 traditional placeholder(s) in statement

штатное поведение когда ничего не вставляет потому как пишет что много частей и при этом процессор ничего не делает (см картинку выше)?

Можно писать if(cond, then, else) и тогда такого не будет

вот после остановки вставки через минуту примерно

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;
197847333
265166333
197847333
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;
257339801
142501192
209820192
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;
197847333
209820192
257339801
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;
257339801
257339801
205673865

а норм

сча напишу

По моему опыту, если писать большими пачками, в один поток - всё нормально мерджиться.
Ждать минуту - мало, поскольку примерный интервал старта меджей - 8-10 минут. При этом все не мерджиться. Т.е. процесс мерджей - дело не 1-2 минут

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

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

Я обычно по iotop смотрю что мерджи идут

Так мержи это второй вопрос

самое главное что count разное возвращает

ubuntu@pprod-spm-ch-3:~$ for i in seq 1 5; do curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
202826595
209820192
143334127
150327724
259506058

SELECT count(*)
FROM default.Measures_Distributed

┌───count()─┐
│ 207007187 │
└───────────┘

1 rows in set. Elapsed: 0.073 sec. Processed 207.01 million rows, 414.01 MB (2.84 billion rows/s., 5.67 GB/s.)

:) select count(*) from default.Measures_Distributed;

SELECT count(*)
FROM default.Measures_Distributed

┌───count()─┐
│ 259839933 │
└───────────┘

1 rows in set. Elapsed: 0.333 sec. Processed 259.84 million rows, 519.68 MB (781.28 million rows/s., 1.56 GB/s.)

:) select count(*) from default.Measures_Distributed;

SELECT count(*)
FROM default.Measures_Distributed

┌───count()─┐
│ 200347465 │
└───────────┘

1 rows in set. Elapsed: 0.374 sec. Processed 200.35 million rows, 400.69 MB (536.11 million rows/s., 1.07 GB/s.)

это как понимать?

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

Vladimir а из локальных таблиц значения стабильные?

сек

В локальных таблицах все стабильно

но по репликам данные не совпадают

и вот такое есть

SELECT *
FROM system.replicas
FORMAT Vertical

Row 1:
──────
database: shard_1
table: Measures
engine: ReplicatedMergeTree
is_leader: 0
is_readonly: 0
is_session_expired: 0
future_parts: 2
parts_to_check: 0
zookeeper_path: /clickhouse/tables/measures/01
replica_name: 1
replica_path: /clickhouse/tables/measures/01/replicas/1
columns_version: 0
queue_size: 6471
inserts_in_queue: 5087
merges_in_queue: 1384
queue_oldest_time: 2017-08-02 12:04:23
inserts_oldest_time: 2017-08-02 12:04:23
merges_oldest_time: 2017-08-02 12:06:45
oldest_part_to_get: 20161013_20161013_3_3_0
oldest_part_to_merge_to: 20160727_20160727_4_103_1
log_max_index: 9997
log_pointer: 9998
last_queue_update: 2017-08-02 12:26:00
absolute_delay: 1343
total_replicas: 2
active_replicas: 2

absolute_delay: 1343 » это в каких единицах?

Почему оно после остановки вставки не догоняет если даже и есть рассинхронизация

Неужели за 10 мин вставки так расколбасило.

absolute_delay: 1554
Увеличивается, хотя я с кластером вообще ничего не делаю сейчас

SELECT count(*)
FROM system.parts AS active

┌─count()─┐
│ 7816 │
└─────────┘

1 rows in set. Elapsed: 0.033 sec. Processed 7.82 thousand rows, 1.54 MB (237.76 thousand rows/s., 46.76 MB/s.)

:) select * from system.merges;

SELECT *
FROM system.merges

Ok.

0 rows in set. Elapsed: 0.001 sec.

:)

Мержей нет

Parts дофига

Приехали...

Vladimir а 7816 кусков за какое время набралось?

то есть в какой момент их было 0?

10 мин

то есть за 10 минут было 7816 инсертов (минимум)?

13 в секунду в среднем

тут нет описание
https://clickhouse.yandex/docs/ru/system_tables/system.replicas.html

По коду либо милисекунды, либо секунды

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

Это плохо, CH становиться плохо при таком кол-ве инсертов

2017-08-02 12:14:04,683 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500005 docs into store
2017-08-02 12:14:04,706 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500003 docs into store
2017-08-02 12:14:04,867 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store
2017-08-02 12:14:06,182 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500007 docs into store
2017-08-02 12:14:07,362 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500003 docs into store
2017-08-02 12:14:07,400 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500006 docs into store
2017-08-02 12:14:08,967 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500000 docs into store
2017-08-02 12:14:10,025 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500012 docs into store
2017-08-02 12:14:12,184 INFO [CHRawDataPullerThread_1] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_1: Inserted 500002 docs into store
2017-08-02 12:14:12,699 INFO [CHRawDataPullerThread_5] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_5: Inserted 500000 docs into store
2017-08-02 12:14:12,709 INFO [CHRawDataPullerThread_0] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_0: Inserted 500004 docs into store
2017-08-02 12:14:13,012 INFO [CHRawDataPullerThread_6] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_6: Inserted 500000 docs into store
2017-08-02 12:14:14,096 INFO [CHRawDataPullerThread_2] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_2: Inserted 500003 docs into store
2017-08-02 12:14:14,915 INFO [CHRawDataPullerThread_4] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_4: Inserted 500013 docs into store
2017-08-02 12:14:15,618 INFO [CHRawDataPullerThread_8] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_8: Inserted 500002 docs into store
2017-08-02 12:14:16,807 INFO [CHRawDataPullerThread_7] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_7: Inserted 500004 docs into store
2017-08-02 12:14:18,303 INFO [CHRawDataPullerThread_3] com.sematext.spm.clickhouse.CHRawDataPuller$Companion$PullerThread:123 - CHRawDataPullerThread_3: Inserted 500011 docs into store

Вот лог встявлятеля

вставляет пачки по 500к

посмотрел по коду, там секунды

вот встявляло

не 10 мин, больше

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

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

тут вопрос что не видно куда упирается КХ

Всё равно нужно через некий батчер группировать данные и делать одни запрос

Упирает в то, что слишком много одновременных вставок. Так делать не советуют, лучше одну большую, чем несколько маленьких

5-6 в секунду не выглядит критическим

ок

увеличу размер батча до 2 млн

Тут люди писали что вливают по 7 милионов строк в секунду - работает

вот и я о том же

где-то затык и надо понять где

Скажите, а какие параметры должны быть по времени и по размеру батча? Я просто сейчас тестирую своё приложение и в кх пропадают записи, этого не может быть из-за частой многопоточной вставки ?

и нифига не понятно почему absolute_delay: 2284 растет когда всавки нет

Затык в том, что при каждой вставке делается достаточно много действий с данными. Чтобы CH не помирал от большого кол-ва данных - делайте свой батчер или берите готовый и делайте однопоточную вставку

и почему КХ не мержит ничего хотя есть что и вставка приосановлена

SELECT count(*)
FROM system.parts AS active

┌─count()─┐
│ 7816 │
└─────────┘

1 rows in set. Elapsed: 0.028 sec. Processed 7.82 thousand rows, 1.54 MB (276.94 thousand rows/s., 54.46 MB/s.)

:) select count(*) from system.merges;

SELECT count(*)
FROM system.merges

┌─count()─┐
│ 0 │
└─────────┘

1 rows in set. Elapsed: 0.001 sec.

Нужно больше данных, что значит пропадают? Измените вставку так, чтобы вставлять не чаще раза в секунду в один поток. Размер батча - не меньше 1 000 строк

ну вот должно быть 100 минут

"делайте свой батчер"
Я не очень понимаю
Я ж показываю что батчами встявляется по 500к

Vladimir вроде бы (я могу ошибаться) что в таком случаи советуют брать buffer таблицы и через них качать данные

если нет возможности свой батчер сделать

ну так у вас по рассчетам выходит 10+ вставок в секунду

а вы говорите что одна

значит ваш батчер не батчер

как это?

код показать?

Этот делай - это какая разница между неким последним инсером и текущем временем (сюдя по коду)

Пропадает, значит, что вставляю n, а оказывается в базе n - m. Вставляю Батчами по 2000 штук, в 8 потоков, вставка происходит раз 10 минут, но из-за 8 потоков, вставки могут прилететь одновременно

тогда ок c delay понятно

ну вот так это

ты сказал что за ~10 минут набежало 7000 кусков

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

7000/600

даст количество вставок в секунду

батчер должен быть перед КХ по сути

а не у клиента

альтернативно - попробуйте буферные таблицы взять и поставить их перед Replicated

то есть Distributed -> Buffer -> Replicated

может быть поможет

или как минимум учлушит ситуацию

Тот же совет, сделать вставку однопоточной - например в несколько потоко ставлять в buffer таблицы, а потом за раз INSERT .. SELECT

Подозрительно мелкий размер частей. Как будто мелкими инсертами сыпят в кх.

но там есть особенности

каждая строка это где-то 5-6 int32 и один float 32

Понятно, спасибо. Грустно

Ну я не знаю. Отсюда вроде понятно что батчи не меньше чем bulkSize

val insertCount = insert(dataRow.row)

count += insertCount
i += insertCount

if (count >= bulkSize) {
flushTo(st)
LOG.info("$name: Inserted $count docs into store")
count = 0
i = 0
st = repo.prepareNewBatchStatement()
}

Совсем не понимаю почему в много потоков писать нехорошо?
Ну как рекомендация спасибо, но это ненормально как-то

То есть примерно 14Мб на пачку. Не очень верится что они ужимаются кликхаусом до полутора килобайт.

ну я не знаю как вам доказать

я готов предоставить все что вас убедит

может это поможет решить вопрос

Vladimir ты графитные метрики с него собираешь? Если да, покажи что в ClickHouse.ProfileEvents.InsertQuery

Я вывел такие правила работы со вставкой в CH:
- однопоточная вставка через некий батчер. Несколько источников логов (приложения, клиенты, логи), один вставщик в CH
- размер вставки от 10к, меньше часто не имеет смысла

и они же где-то в табличках в system есть

метрики не собираю

system.events

сейчас в табличке посмотрю

eсть такое

│ InsertedRows │ 435003976 │
│ InsertedBytes │ 28657505480 │

│ DelayedInserts │ 288 │
│ RejectedInserts │ 43 │

│ SelectQuery │ 560 │
│ InsertQuery │ 1300 │

Vladimir curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'"; sleep 60; curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'";

сделай так

разница между ними будет количество инсертов за минуту

сейчас вставку включу

пока оно стартует

не мержит почему пока есть возможность? :)

Мерджит не сразу, стартует примено раз в 8-10 минут. На то они и фоновые мерджи

INSERTS=$(curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'" 2>/dev/null); while :; do NEW_INSERTS=$(curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'" 2>/dev/null); DELTA=$((NEW_INSERTS-INSERTS)); echo "${DELTA} inserts/min"; sleep 60; INSERTS=${NEW_INSERTS}; done

Vladimir вот такое вот запусти

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

с некоторой точностью, но все ж

ubuntu@pprod-spm-ch-3:~$ curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'"; sleep 60; curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'";
1365
1430

Vladimir ну вот у тебя что-то не так с батчером

он не батчит их нифига

откуда такой вывод

65 в минуту

много?

а, ты не дельту показал

не, 65 в минуту в целом нормально должно быть

так оно и работало на одной машине

как 3 поставил так и поломалось

Vladimir а без репликации работает?

если просто 3 машины и distributed

не пробовал.
я ж не могу все варианты перебрать

ubuntu@pprod-spm-ch-3:~$ INSERTS=$(curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'" 2>/dev/null); while :; do NEW_INSERTS=$(curl "localhost:8123?query=select+value+from+system.events+where+event='InsertQuery'" 2>/dev/null); DELTA=$((INSERTS-NEW_INSERTS)); echo "${DELTA} inserts/min"; sleep 60; INSERTS=${NEW_INSERTS}; done
0 inserts/min
-60 inserts/min
-67 inserts/min

просто может проблемы с сетью какие-то жестокие?

не может быть

все в одной стойке на AWS

пинги минимальные

почему не может - виртуалки могут оверселится довольно жестко

PING 10.1.1.86 (10.1.1.86) 56(84) bytes of data.
64 bytes from 10.1.1.86: icmp_seq=1 ttl=64 time=0.220 ms
64 bytes from 10.1.1.86: icmp_seq=2 ttl=64 time=0.221 ms
64 bytes from 10.1.1.86: icmp_seq=3 ttl=64 time=0.218 ms

что говорит iperf между хостами?

ну это отлично что 84 байта передаются 0.2мс

а что говорит iperf?

берешь iperf на двух хостах

на одном iperf -s (или iperf3 -s)

на втором клиента в bidirectional mode

и смотришь какая полоса

так

sudo apt install iperf поставил

дальше помедленнее плиз

я не совсем с этим всем на ты

iperf -s

на одном хосте

на другом iperf -c IP_хоста_где_уже_запущен_iperf

^Cubuntu@pprod-spm-ch-3:~$ iperf -c 10.1.1.86
—----------------------------------------------------------
Client connecting to 10.1.1.86, TCP port 5001
TCP window size: 325 KByte (default)
—----------------------------------------------------------
[ 3] local 10.1.1.251 port 44254 connected with 10.1.1.86 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 5.81 GBytes 4.99 Gbits/sec

а если клиент с -R ? чтоб и обратно проверить

-c IP -R

ubuntu@pprod-spm-ch-3:~$ iperf -c 10.1.1.86 -R
—----------------------------------------------------------
Client connecting to 10.1.1.86, TCP port 5001
TCP window size: 325 KByte (default)
—----------------------------------------------------------
[ 3] local 10.1.1.251 port 46066 connected with 10.1.1.86 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 5.82 GBytes 4.99 Gbits/sec

-c ip -d

Vladimir о, еще глупый вопрос - у тебя хостнеймы указаны в КХ же, да?

попробуй по хостнейму клиентом iperf'а

мало ли что

не, у меня там ip

ок, ну ок, теперь про сеть можно пока верить что она работает нормально

^Cubuntu@pprod-spm-ch-3:~$ iperf -c 10.1.1.86 -d
—----------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
—----------------------------------------------------------
—----------------------------------------------------------
Client connecting to 10.1.1.86, TCP port 5001
TCP window size: 1.17 MByte (default)
—----------------------------------------------------------
[ 5] local 10.1.1.251 port 47844 connected with 10.1.1.86 port 5001
[ 4] local 10.1.1.251 port 5001 connected with 10.1.1.86 port 44896
[ ID] Interval Transfer Bandwidth
[ 5] 0.0-10.0 sec 5.81 GBytes 4.99 Gbits/sec
[ 4] 0.0-10.0 sec 5.81 GBytes 4.99 Gbits/sec

а что ради интереса - до ZK все также ок?

5 мин отойду , невтерпеж :D

ZK на тех же 3 машинах
это может не суперправильно но это тест у меня.
ZK пишет в другой диск тоже SSD

сделал батчи по 1.5M

стало писать по 25-30 раз в минуту

-26 inserts/min
-25 inserts/min

Вот это необяснимо, да?
ubuntu@pprod-spm-ch-3:~$ for i in seq 1 5; do curl 'pprod-spm-ch-3:8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
156501169
156501169
227514652
152327963
223507989

да, это выглядит как будто он читает из разного набора реплик

и количество кусков у тебя необъяснимо

при таком количестве инсертов их должно быть меньше намного, а мержей больше

у меня на этой цифре зависло

SELECT count(*)
FROM system.parts AS active

┌─count()─┐
│ 7982 │
└─────────┘

и никуда не двигается

из разного набора реплик да, но они должны сходится

Можно я выложу как создавал и конфиги свои? может заметно будет где ошибка?

Это что значит?
2017.08.02 13:38:46.570499 [ 6589 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/02/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.02 13:38:46.592134 [ 83 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.02 13:38:46.592190 [ 102 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.02 13:38:46.610775 [ 125 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.02 13:38:46.618404 [ 6589 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/01/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.02 13:38:46.626119 [ 6583 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/measures/02/replicas/2, e.what() = DB::Exception, Stack trace:

replica 2 недоступна?

В ZK вроде есть такой путь
[zk: localhost:2181(CONNECTED) 8] ls /clickhouse/tables/measures/02/replicas/2
[is_active, columns, max_processed_insert_time, host, parts, flags, log_pointer, min_unprocessed_insert_time, queue]

Я бы попробовал собрать кластер без шардов, только реплики. А только потом сделать Disturbed

Причем на части данных, для скорости

тоесть 1 шарду в remote server указать и 2 реплики для нее?
писать в любую 1 локальную таблицу?

Я имею в виду, что может быть сначала разобраться с репликацией? Убедиться, что данные доходят до каждой реплики. А потом уже пилить данные на шарды

И разбираться с распределенными запросами

Имеет смысл
Не думал что столько глаблей сразу встречу просто.

В CH репликация и шардирование - это скорее конструктор, чем готовое решение. Такой подход позволяет гибко настроить схему под нужную задачу

Просто 2 реплики синхронизируются быстро

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
67500250
67500250
ubuntu@pprod-spm-ch-3:~$
ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
142048934
142048934
ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
142488667
142490947
ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
142500364
142500364
ubuntu@pprod-spm-ch-3:~$ for i in seq 3 4; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+default.Measures_Distributed;'; done;
142500364
142500364

сейчас верну распределенность

Интересно что количество parts не растет и все успевает мержиться

Попробуйте залить все данные. Может проблема появиться после некого объема данных

давай на ты пожалуйста

ок

сделаю как ты сказал

Вставилось около 300М строк и все было ок. Кол-во parts не превышало 100 мержить успевало

Переделал на Distributed и с первых секунд начались проблемы

Вот создание таблиц

Вот remote_servers.xml

Где-то тут ошибка

Опять же, попробуй более простое распределение данных, например на две половинки

Сложно сказать, я пока не пробовал реплицировать и шардировать на CH. В твоей схеме три шарда, сделай два

Как минимум, почему тут http://joxi.ru/RmzNOePtWVpO8m пусто? Вот что в доке http://joxi.ru/gmvzZ3Pix05Z5m

там выше говориличто если тут пусто то берет БД из remote servers

вот этот пример кидали

https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/test_cross_replication/test.py

А вставляешь ты в распределенную таблицу или приложением в каждый шард?

в распределенную

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+shard_1.measures;'; done;
29669439
61325190

реплика в случае распределенной очень сильно отстает

Я бы даже сказал не отстает а в 2 раза больше результаты показывает одна из реплик

ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+shard_1.measures;'; done;
40169007
81393576

Vladimir ты шлешь напрямую в сервера или в распределенную таблицу?

в распределенную

еще я вижу много такого в логах
но что это и почему не понятно
2017.08.02 15:18:58.384768 [ 4262 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.02 15:18:58.396931 [ 39 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.02 15:18:58.519827 [ 4270 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.02 15:18:58.535047 [ 102 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.02 15:18:58.542597 [ 4262 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/02/measures/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.02 15:18:58.553679 [ 49 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

Сделал кластер без реплик, теперь распределенная таблица возвращает синхрнизированние данные

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;
69892767
70000700
70000700
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;
70500703
70500703
70500703
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;
71491774
71495408
71496055

Что мы имеем:
1. Реплицированная таблица работает и реплики не отстают друг от друга. Проблем с мержем нету system.parts всегда маленькое.
2. Распределенная таблицв работает, все 3 распределенные таблицы (на разных серверах) поверх одних и тех же Merge таблиц возвращают одинаковые данные. Появляется проблема с system.parts. Через 10 мин работы видно такое
SELECT count(*)
FROM system.parts

┌─count()─┐
│ 6150 │
└─────────┘

1 rows in set. Elapsed: 0.021 sec. Processed 6.15 thousand rows, 1.21 MB (290.54 thousand rows/s., 57.03 MB/s.)
3. Распределенная таблица поверх реплицированных как по схеме тут (шарды а разных БД чтобы можно было создать таблицы с одинаковыми именами) https://github.com/yandex/ClickHouse/blob/master/dbms/tests/integration/test_cross_replication/test.py
не работает. Есть и проблема с system.parts как в пункте 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;
197847333
209820192
257339801
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;
257339801
257339801
205673865

Алексей может у Вас есть идеи что в моих руках и голове не так?.

Привет! А можешь поподробнее рассказать про подкладывание в private? Туда можно положить как-то чтобы оно само в libdbms.a дописалось или нужно другой lib*.a делать?

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

А вот еще интересная статистика system.events показывает
│ InsertedRows │ 4711779888 │

А таблицы показывают

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;
3190003655
3190003947
3190004375

Вставку я прекратил 3 мин назад а кол-во строк растет

Где-то очередь на полтора миллиарда строк?

Через 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;
3286834653
3286834653
3286834653

Почему не бъется с InsertedRows и почему вообще после прекращения вставки количество строк росло 2 мин непонятно. Неужели так забуфферизировало.
Я тут всех запарил чувствую, простите, ответов так и не понаходил

Мне наоборот нравится, так как такое потенциально у каждого может легко вылезти. И прежде чем в прод выдавать чтото про такое надо знать. Я тоже хотел вставлять намного чаще чем раз в секунду.

спсб за поддержку, ушел на перекур (не курю :) )

А ты не пробовал через буфер с num_layers=1 ?

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

Я чаще чем раз в секунду вставляю и все норм. 6-7 миллионов строк в минуту получается

Лью в 100 потоков

>Я чаще чем раз в секунду вставляю и все норм. 6-7 миллионов строк в минуту получается
Я тоже чаще в вставлял и вопросов не было. Все началось при репликации + шардирование

>А ты не пробовал через буфер с num_layers=1 ?
не пробовал. тут вопрос не в том как сделать, а почему оно не мержит само интенсивно когда проессоры простаивают

Ну и чехарда с count() при репликации и шардировании, и увеличение кол-ва строк после того как инсерты застопились 2 мин назад. Много непонятного какого-то

Я вот сейчас до перекура поставил пачки по 3млн и ушел. Стабилизировалось все на таких цифрах
ubuntu@pprod-spm-ch-3:~$ for i in seq 3 5; do curl 'pprod-spm-ch-'$i':8123?query=select+count(*)+from+system.parts;'; done;
5701
4866
4734

Меня устраивает впринципе, гдавное что стабилизировалось и перестало отдавать ошибки

Неохота делать 2*2 на 4 серверах. Не могу никак понть почему 3*2 на 3 не работает.
2*2 и серверов больше и читать только с 2 в одном запросе, минусы одни

Кажется что всё проблемы от вставки через Distributed-таблицу. Насколько я помню, кто-то писал что в Яндекс.Метрике используют вставку напрямую в локальные таблицы. И вставка через Distributed не рекомендуется.

А как это согласуется с тем что если Distrinuted поверх нереплицированных таблиц то все более менее ок?

Всем привет, в документации сказано "We do not recommend storing floating-point numbers in tables.", а какие есть альтернативы?

integer

а как быть не целой частью числа?

хранить в отдельных колонках?)

Умножать же. Если 2 знака после запятой - на 100.

3 - на 1000 и тд

спасибо, действительно

извините, не сразу увидел что используется slf4j

А может кто толком объяснить почему int32 пердпочтительнее float 32?

лучше жмется

у float всегда будет шум

понял

IEEE 754

спсб

Привет! Хочу в clickhouse создать табличку типа set, которая содержит информацию об обновлениях в таблицах. Чтобы она содержала 2 столбца: table_name, update_id. То есть чтобы я мог быстро проверить, закачались ли данные в таблицы. Движок SET как я понял, не подойдет, в нем нет возможности проверить вхождение строки в таблицу. Какой движок юзать?

Почему именно set?

Все что мне нужно - это добавлять запись в таблицу и проверять, существует ли данная запись в таблице. Пара table_name+update_id уникальна. Можно даже слить их в один стобец.

А чем обычный поиск с WHERE непоходит?

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

Советую прочитать документацию, всю, её там не так много

Так я читал. LOG, TINYLOG - для временных данных, одноразовой записи. Не подходит. MergeTree нужна колонка DATE. JOIN, MERGE,SET,MEMORY для другого предназначены. Выходит, я не могу создать обычную таблицу =(

Конечно. потому что CH - СУБД, заточенная под аналитику, в ней нет обычных таблиц

И выборки вида "выбрать список пользователей по списку id-ок" в CH скорее всего будут работать очень медленно

Возможно, имеет смысл писать во внешний источник (например, mysql) и подключить его как словарь. Но такое решение может медленно работать.

Где тут
https://clickhouse.yandex/docs/ru/table_engines/tinylog.html
это написано? Пробуйте, экспериментируйте

Всем привет! Кто-то использует лимиты для доступа к КХ? А именно max_memory_usage, max_execution_time, max_concurrent_queries_for_user ?

Всем привет.

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

"Отсутствует возможность удалять столбцы, входящие в первичный ключ или ключ для сэмплирования (в общем, входящие в выражение ENGINE). Изменение типа у столбцов, входящих в первичный ключ возможно только в том случае, если это изменение не приводит к изменению данных (например, разрешено добавление значения в Enum или изменение типа с DateTime на UInt32)."

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

"Если возможностей запроса ALTER не хватает для нужного изменения таблицы, вы можете создать новую таблицу, скопировать туда данные с помощью запроса INSERT SELECT, затем поменять таблицы местами с помощью запроса RENAME, и удалить старую таблицу."

Потребует пересортировки и перезаписи всего существующего на диск КМК поэтому и нету

Да, иначе пришлось бы перестраивать индекс.

Николай а не смотрели вчера мои конфиги? Может у вас есть идею почему 3 шарды с репликацией на 3 серверах у меня так странно себя ведут?

Подскажите, пожалуйста, что можно предпринять - растёт system.replication_queue. При этом CPU на машине - гора, в диск тоже не упирается. background_pool_size выставили в 48

Спасибо!

Конфиги на вид кажутся нормальными. То, что расходятся цифры для Distributed таблицы тоже объяснимо, так как данные сначала пишутся на диск, а потом отдельным потоком передаются на остальные реплики. Вот почему не проходят мержи - пока неясно.

Так подождите

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;
197847333
209820192
257339801
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;
257339801
257339801
205673865

Вот это объяснимо?

Можно попробнее плиз

запись сейчас идет или на какое-то время остановлена?

сейчас все пересобрано на кластер без реплик

и все ок

я писал выше
1. 2 реплики - все ок, не рассинхронизируются
2. 3 шарды все ок
3. 3 шарды по 2 реплики - непонятночто
Такое ощущение что оно путает реплики для разных шард
Но никто ошибку в конфигах не нашел

Сидим ждем Алексей. Ну и сейчас все грохну и соберу 2*2 на 4 машинках и посмотрю

+1. Возможно CH нельзя использовать так, как ты хочешь (баг или фича)

согласен, но должен быть выход.

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

> бралась реплика из локальной машины
я делал 2 распределенные таблици на каждой локальной и сравнивал - все ок, + балансировщик rand опять же, так чт не думаю что в этом дело

на какие бы машины не ходил скакать на 20% результаты не должны наверное.
я грешу на конфигирацию

А в колонке exception из system.replication_queue что-нибудь написано? Также интересуют postpone_reason

SELECT
count(),
type
FROM system.replication_queue
GROUP BY type

┌─count()─┬─type────────┐
│ 180 │ MERGE_PARTS │
│ 4091 │ GET_PART │
└─────────┴─────────────┘

из них с postpone_reason - всего 30

Если кому интересно, то поставил кластер 2*2.
Вставляю пачками по 2М (вроде как больше 1М вставлять не имеет смысла потому как КХ побъет все равно, но все же) около 40М в минуту
Все работает ок. Рассинхронизации нет (совсем маленькая из-за реплик) + system.parts более менее стабилизируются на 5000-10000 тысячах (после большого мержа с 10000 падает на 5000 на всех серверах).
Все хорошо короче.
Чисто ради спортивного интереса непонятно что происходит в слечае 3 серверов

Причины postpone:
Not executing log entry for part 20170730_20170730_851_859_1 because its size (22.21 MiB) is greater than current maximum (4.23 MiB)
Not merging into part 20170730_20170730_775_807_3 because part 20170730_20170730_807_807_0 is not ready yet (log entry for that part is being processed).

А в поле last_exception есть что-нибудь?

интересно, спасибо! попробую разобраться

Подскажите, товарищи: в какой-то момент clickhouse-server, работавший в докере перестал отвечать. Совсем. Удалил все контейнеры, образы. Все равно не отвечает.
docker run -it --rm --link some-clickhouse-server:clickhouse-server yandex/clickhouse-client --host clickhouse-server
ClickHouse client version 1.1.54245.
Connecting to clickhouse-server:9000.
Code: 209. DB::NetException: Timeout exceeded while reading from socket (172.17.0.2:9000)

SELECT *
FROM system.replication_queue
WHERE last_exception != ''

Ok.

0 rows in set. Elapsed: 0.026 sec. Processed 16.43 thousand rows, 3.70 MB (626.63 thousand rows/s., 141.33 MB/s.)

Это на одной реплике так или на обеих? Сеть (dstat) загружена?

сеть не загружена

на обеих репликах одинаковые значения

Тогда select * from system.merges FORMAT Vertical

Всем привет, вопрос можно ли в кластере описывать приоритет реплик? Есть 3 сервера в кластере (конфиг https://pastebin.com/wLYr0VT2 ), таблица ReplicatedReplacingMergeTree шардирована на 3 части по ним, причем на каждом сервере также есть вторая база, которая хранит еще одну реплику другого шарда (перекрестная репликация). При погашении одного сервера находится сервер с репликой погашенного шарда и все ок, но вот при возвращении погашенного сервера в строй его шард не становтся активным. А хотелось бы (чтобы запросы параллельно считались на трех серверах а не на двух).

есть настройка load_balancing: https://clickhouse.yandex/docs/ru/operations/settings/settings.html#load-balancing . возможно, возвращенный шард не выбирается из-за большого числа ошибок

https://github.com/yandex/ClickHouse/issues/127
Сейчас нельзя создавать вьюхи с подзапросами

Может кто в курсе, есть ли в планах фикс этой баги?

Пришел с прогулки, поломалась вставка,через 2 часа куча такого посыпалось
2017.08.03 19:15:38.688909 [ 187 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/01/measures/replicas/2, e.what() = DB::Exception, Stack trace:
2017.08.03 19:15:38.702824 [ 340 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:
2017.08.03 19:15:38.967668 [ 600 ] <Error> InterserverIOHTTPHandler: Code: 221, e.displayText() = DB::Exception: No interserver IO endpoint named DataPartsExchange:/clickhouse/tables/01/measures/replicas/2, e.what() = DB::Exception, Stack trace:

Данные рассинхронизировались
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;
3299260074
3362685583
3381671392

И вот
SELECT
count(),
type
FROM system.replication_queue
GROUP BY type

┌─count()─┬─type────────┐
│ 348 │ MERGE_PARTS │
│ 1679 │ GET_PART │
└─────────┴─────────────┘

2 rows in set. Elapsed: 0.010 sec. Processed 2.03 thousand rows, 803.80 KB (200.41 thousand rows/s., 79.47 MB/s.)

а глупый вопрос - у тебя же zookeeper в качестве zookeeper'а?

никаких странных zetcd?

и версия ЗК - 3.4.10?

Какие отзывы, кстати? Ну, кроме того, что это очень странно)

тут в соседнем канале кто-то жаловался что он не работает адекватно )

@i_cant_use_4_symbol_nick как раз на всякое непредсказуемое поведение под нагрузкой жаловались люди

а уже 3.4.10 есть?

ага

30 March, 2017: release 3.4.10 available

Понятно, спасибо.
Сомневаюсь, чтобы у кого-то zetcd в хайлоаде

>а глупый вопрос - у тебя же zookeeper в качестве zookeeper'а?
он самый. 3.4.9

│ MERGE_PARTS │ Not executing log entry for part 20170210_20170216_12252_12406_4 because another log entry for covering part 20170210_20170216_0_12408_2704 is being processed.

│ MERGE_PARTS │ Not executing log entry for part 20170710_20170726_11915_12259_13 because another log entry for covering part 20170710_20170731_4666_12268_74 is being processed.

│ MERGE_PARTS │ │
│ MERGE_PARTS │ │
│ MERGE_PARTS │ │
│ GET_PART │ Not executing log entry for part 20170106_20170117_12268_12268_0 because another log entry for covering part 20170106_20170117_0_12358_1190 is being processed. │
│ GET_PART │ Not executing log entry for part 20170106_20170117_12270_12270_0 because another log entry for covering part 20170106_20170117_0_12358_1190 is being processed. │
│ MERGE_PARTS │ Not executing log entry for part 20170210_20170216_0_11893_2692 because another log entry for covering part 20170210_20170216_0_11956_2695 is being processed. │
│ MERGE_PARTS │ │
│ MERGE_PARTS │ Not executing log entry for part 20170620_20170630_0_12107_2959 because another log entry for covering part 20170620_20170630_0_12284_2962 is being processed. │
│ MERGE_PARTS │ Not executing log entry for part 20170620_20170630_12214_12224_1 because another log entry for covering part 20170620_20170630_0_12284_2962 is being processed.

Сыплет вот этим
2017.08.03 19:26:01.956741 [ 602 ] <Error> DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Code: 33, e.displayText() = DB::Exception: Cannot read all data, e.what() = DB::Exception, Stack trace:

0. clickhouse-server(StackTrace::StackTrace()+0x16) [0x29b2626]
1. clickhouse-server(DB::Exception::Exception(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)+0x1f) [0x10b079f]
2. clickhouse-server(DB::DataPartsExchange::Fetcher::fetchPartImpl(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool)+0x1cc7) [0x2bb1cb7]
3. clickhouse-server(DB::DataPartsExchange::Fetcher::fetchPart(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int, bool)+0x76) [0x2bb2766]
4. clickhouse-server(DB::StorageReplicatedMergeTree::fetchPart(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool, unsigned long)+0x25a) [0x2a98b1a]
5. clickhouse-server(DB::StorageReplicatedMergeTree::executeLogEntry(DB::ReplicatedMergeTreeLogEntry const&)+0x1bcf) [0x2a9b35f]
6. clickhouse-server() [0x2a9d22d]
7. clickhouse-server(DB::ReplicatedMergeTreeQueue::processEntry(std::function<std::shared_ptr<zkutil::ZooKeeper> ()>, std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&, std::function<bool (std::shared_ptr<DB::ReplicatedMergeTreeLogEntry>&)>)+0x4a) [0x2b263da]
8. clickhouse-server(DB::StorageReplicatedMergeTree::queueTask()+0x150) [0x2a88930]
9. clickhouse-server(DB::BackgroundProcessingPool::threadFunction()+0x3dc) [0x2b74edc]
10. clickhouse-server() [0x36d9f1f]
11. /lib/x86_64-linux-gnu/libpthread.so.0(+0x76ba) [0x7fb04ab606ba]
12. /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7fb04a1813dd]

Вставляли мы вставляли (одна запись в Кафке = 6 записей в КХб тоесть вставляли бодро, по млн в сек). Потом CPU упало и вставлять перестали.

Вот это по 1-2 за пару минут сокращается (такими темпами будет сокращаться до завтра)
SELECT
count(),
type
FROM system.replication_queue
GROUP BY type

┌─count()─┬─type────────┐
│ 347 │ MERGE_PARTS │
│ 1666 │ GET_PART │
└─────────┴─────────────┘

2 rows in set. Elapsed: 0.009 sec. Processed 2.01 thousand rows, 842.50 KB (219.60 thousand rows/s., 91.91 MB/s.)

В ZK куча такого, но ничено с уровнем ERROR
2017-08-03 17:27:57,298 [myid:1] - INFO [ProcessThread(sid:1 cport:-1)::PrepRequestProcessor@596] - Got user-level KeeperException when processing sessionid:0x15da651c5ea0003 type:multi cxid:0x59974cf0 zxid:0x50058052f txntype:-1 reqpath:n/a aborting remaining multi ops. Error Path:/clickhouse/tables/01/measures/blocks/8002449562181767356_7724958680224753627 Error:KeeperErrorCode = NodeExists for /clickhouse/tables/01/measures/blocks/8002449562181767356_7724958680224753627

2017-08-03 19:44:31,096 [myid:1] - INFO [ProcessThread(sid:1 cport:-1)::PrepRequestProcessor@649] - Got user-level KeeperException when processing sessionid:0x15da651c5ea0001 type:setData cxid:0x598ef13a zxid:0x500682323 txntype:-1 reqpath:n/a Error Path:/clickhouse/tables/02/measures/block_numbers/201610/block-0000000702 Error:KeeperErrorCode = NoNode for /clickhouse/tables/02/measures/block_numbers/201610/block-0000000702

На вот такое OPTIMIZE TABLE measures PARTITION 201707 FINAL

Выдает
127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Too much simultaneous queries. Maximum: 100.

Я проде один запрос отправляю :) Он может размножается внутри

Вставку давно отрубил а очередь не двигается на вставку
SELECT *
FROM system.replicas
FORMAT Vertical

Row 1:
──────
database: default
table: measures
engine: ReplicatedMergeTree
is_leader: 0
is_readonly: 0
is_session_expired: 0
future_parts: 0
parts_to_check: 0
zookeeper_path: /clickhouse/tables/01/measures
replica_name: 1
replica_path: /clickhouse/tables/01/measures/replicas/1
columns_version: 0
queue_size: 1995
inserts_in_queue: 1649
merges_in_queue: 346
queue_oldest_time: 2017-08-03 18:49:23
inserts_oldest_time: 2017-08-03 18:49:23
merges_oldest_time: 2017-08-03 18:52:05
oldest_part_to_get: 20170502_20170502_11683_11683_0
oldest_part_to_merge_to: 20170502_20170502_11678_11866_8
log_max_index: 113596
log_pointer: 113597
last_queue_update: 2017-08-03 19:29:24
absolute_delay: 4502
total_replicas: 2
active_replicas: 2

1 rows in set. Elapsed: 0.003 sec.

Это при 2х2?

да

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.145 │ 10.1.1.145 │ 9000 │ 1 │ default │ │
│ metrics │ 2 │ 1 │ 1 │ 10.1.1.86 │ 10.1.1.86 │ 9000 │ 0 │ default │ │
│ metrics │ 2 │ 1 │ 2 │ 10.1.1.94 │ 10.1.1.94 │ 9000 │ 0 │ default │ │
└─────────┴───────────┴──────────────┴─────────────┴────────────┴──────────────┴──────┴──────────┴─────────┴──────────────────┘

4 rows in set. Elapsed: 0.001 sec.

Почему 2 с is_local 1 и 2 с 0? Что это вообще за флаг?

Вот нашел про local https://github.com/yandex/ClickHouse/blob/85f85af033e5251fdab7dafe15e91ef7edd71d89/dbms/src/Interpreters/Cluster.cpp#L37
Мне не поможет :)

Если у шарда стоит is_local=1, то это просто означает, что IP машинки к которой вы сейчас подключились совпадает с одним из IP реплик данного шарда (с поправкой на мое замечание касательно default_database).

Есть вообще у кого работает распределенная реплицированная таблица под постоянной нагрузкой (но вставки не чаще раза в секунду)?
Или это только в теории работает и у ребят из Яндекса?

Может не понял суть вопроса, у нас +- 15krps в кластер 6ти нод в хетзнере - 3реплики 3 шарда - год полет нормальный

Схема - как я описывал в статье на хабре

15krps мало.

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

Господа разработчики КХ пожалуйста сжальтесь надо мной и давате все пофиксим завтра :)
Спокойной ночи всем.

че-т load_balancing не помогает при выборе лидирующей реплики при восстановлении упавшего сервера

За ночь ничего не восстановилось/синхронизировалось.

Буду сносить, ставить перед 4 серверами балансер и писать в локальные таблицы

может это спасет.

У меня 4 шарда по 2 реплики и все ок

пересоздал таблицы с такими же именами и сейчас в логах такое
2017.08.04 07:15:26.221481 [ 3 ] <Trace> Measures_Distributed.Distributed.DirectoryMonitor: Started processing /mnt/local/clickhouse/data/data/default/Measures_Distributed/default@10%2E1%2E1%2E86:9000,default@10%2E1%2E1%2E94:9000/4000.bin
2017.08.04 07:15:26.576287 [ 3 ] <Trace> Measures_Distributed.Distributed.DirectoryMonitor: Finished processing /mnt/local/clickhouse/data/data/default/Measures_Distributed/default@10%2E1%2E1%2E86:9000,default@10%2E1%2E1%2E94:9000/4000.bin
2017.08.04 07:15:26.576309 [ 3 ] <Trace> Measures_Distributed.Distributed.DirectoryMonitor: Started processing /mnt/local/clickhouse/data/data/default/Measures_Distributed/default@10%2E1%2E1%2E86:9000,default@10%2E1%2E1%2E94:9000/4002.bin
2017.08.04 07:15:26.947365 [ 3 ] <Trace> Measures_Distributed.Distributed.DirectoryMonitor: Finished processing /mnt/local/clickhouse/data/data/default/Measures_Distributed/default@10%2E1%2E1%2E86:9000,default@10%2E1%2E1%2E94:9000/4002.bin
2017.08.04 07:15:26.947388 [ 3 ] <Trace> Measures_Distributed.Distributed.DirectoryMonitor: Started processing /mnt/local/clickhouse/data/data/default/Measures_Distributed/default@10%2E1%2E1%2E86:9000,default@10%2E1%2E1%2E94:9000/4004.bin

походу очнулось и начало что-то старое процессить

>У меня 4 шарда по 2 реплики и все ок
У меня первые 2 часа тоже было все ок под большой нагрузкой
А потом пошло все р разнос.
Расскажите подробнее что и сколько пишите

На каждом сервере реплицируемая локальная таблица + поверх нее распределенная таблица. Когда потребуется перезаливка данных (такое иногда бывает, да), пишу в 100 потоков, примерно 6-7 млн в минуту (быстрее не получается, т.к. батчи совершенно разных размеров получаются от 10 строк до 1 000 000 строк), пишутся в основном интовые данные + несколько текстовых колонок. Такая нагрузка продолжается примерно в течение 3-4х часов. В это же время (наливки данных в КХ) происходят регулярные запросы на селекты, примерно по 10-15 запросов в секунду.

При этом все работает, CPU адекватный, IO тоже, сеть практически не кушается за счет gzip.

Было пару кейсов когда КХ жрал просто немеренное кол-во CPU и целая нода виртуализации падала, но это было из-за неверных настроек самой виртуалки.

Даже после таких падений в последствии запуска ноды, данные синхронизировались и никакого рассинхрона нет. Версия сервера 1.1.54246 собранная руками.

Три инстанса ZK поднято для репликации

У меня все очень похоже. 3 зукипера.
4 ноды, пишу 40-50млн в минуту пачками. 2 шарда по 2 реплики
2 часа все писало и было ок
потом что-то слетело, писать перестало и пошло рассинхронизироваться
запись остановил.
за ночь ничего не синхронизировалось.

Вы пишите в распределенную таблицу?

А какими пачками пишите?

Да

пачки по 2млн

где-то 20-25 вставок в мин

Должно быть норм. А PK большой?

3 колонки

дата и 2 интовые

А гранулярность большая?

8192

Или вы не про это?

Не, я имел ввиду разброс значений индекса большой?

опять не понял

Например есть ClientID и их может быть миллион, а может быть 3 )

в индексе есть таймстамп

Я не так выразился ) Не проснулся

Как интовое поле?

или я

да

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/01/measures', '1',date, (account, id, timestamp), 8192);

Мне кажется лучше сделать DateTime, хотя могу ошибаться

но тогда мои запросы медленно пойдут

Почему?

я ж не зря время добавил

Я имею ввиду перевести колонку timestamp в тип DateTime

аа

А не UInt32 )

вы имеете в виду тип поменять?

Да

думаю ничего не изменится

Это чисто предположение

а на чем основанное?

интуиция?

Для КХ мне кажется роднее будет то, что связано как раз таки со временем )

Типа того )

понял

Вам данные нужно сортировать по таймштампу или фильтровать?

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

сортировать и фильтровать

Мне кажется лучше так
ReplicatedMergeTree('/clickhouse/tables/01/measures', '1',date, (account, date ), 8192);

убрать лишнее из ключа

так это не лишнее

Печально. Я бы на вашем месте все таки поигрался со структурой таблиц и по пробовал бы по разному строить запросы

Ребята я ж в ключ id тоже не просто так добавил

а мотому как быстрый скан по ключу и времени нужен

если я уберу то что эт ополучится

составной int ключь + дата ( без времени ) - так пробуйте

да и не должна ХЛ БД парать от нагрузки и так непонятно себя везти

ок допустим без времени сделал
записалось 2 месяца данных надо выбрать 3 часа
сканить все 2 месяца?

https://medium.com/@f1yegor/clickhouse-primary-keys-2cf2a45d7324

Я что то не понимаю или?

Так три часа выбрать можно через тот же prewhere

А потом уже все остальное выкидывать

например по account и timestamp сделать prewhere

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

тоесть вы хотите сказать что выкинув время и оставив только дату в PK я получу такую же скорость запросов?

Думаю да

Я сталкивался с кейсами когда по разному построенный запрос работал тоже по разному

но результат был одинаковый

причем разница была в десятки, а то и сотни раз )

Если вы не использете date - скорость падает в десятки / сотни раз

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

В статье @f1yegor все расписал

Попробовать можно конечно, но согласитесь должно работать и без всего этого и как то стремно брать в прод с таким поведением.
Надо или победить изначальную схему или отказываться. Бог знает на что я еще натолкнусь.

Ну блин ) Любую БД можно сложить, даже ХЛ, если с ней неправильно обращаться )

Тут нужно понять почему это произошло )

Значит используйте Vertica )))

Igor Str правильно говорит, что отфильтровав данные по дате, которая в PK есть, останется не так много строк для обработки, там уже делайте что хотите )

Что значиит сложить?
Я понимаю если бы сторость просела
Но не так же умирать

Вы заставили базу делать очень много лишних действий с таким ключем

Я как то 5 колонок натолкал в пк ) в том числе и таймштамп, потом разобрался с пк и все ок стало

Ок давайте попробую по порядку
1. убираем время из ключа
2. добавляем дату
3. переписываем запрос
можно переписать на этом примере?
SELECT (avg(value)), toInt64(timestamp/60)*60 as granularity FROM Measures_Distributed where account=169 and id=109 and timestamp>1501596000 and timestamp<1501740000 and arrayElement(tags.value,indexOf(tags.name,4))=11724 group by granularity order by granularity

Добавьте в where date=today() - просто дату

и взлетит

Решение у меня - нужно последние 48 часов

event_date>=today()-2 AND timepoint_hour>=now()-(60*60*48)

так
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/01/measures', '1',date, (account, id, date), 8192);

?

Да попробуйте так + еще можно попробовать ID выкинуть - зависит что меньше будет сканится

(account, date, id)

id порядка 2 тысяц
date 5-10

data вперед

У меня сейчас в пк всего три колонки, дата в самом начале стоит, потом все остальное

дата это включая день или только месяц?

мне наверное тоже ее логично вначала поставить тк ее вариативность меньше чем у остальных

Дата включя день

Все таки рекомендую вот эту статью почитать https://groups.google.com/forum/#!topic/clickhouse/eUrsP30VtSU. Алексей тут очень подробно рассказывает как работают ПК в КХ

Это даже не статья, а ответ )

Спсб попробую сейчас. Но все таки разобраться в тем что у меня было до этого надо.
Иначе никакой гарантии что с новой схемой оно не помрет через какое-то время

пошел читать, спсб

Это как напихать в мускуль 10 индексов и писать туда тонну данных и не понимать почему скорость вставки данных просела )

Так понимаете было пы понятно если бы скорость просела

меня пугает что оно умерло вовсе

вставлять не дает

мержи не идут

опримизация не помогает

что в тако случае на проде делать?

Просто получается так, что КХ после вставки нужно отсортировать данные по ПК и разложить в нужные партиции

Я даже таблици дропнуть пол часа не мог

засыпало лог ошибками

ок

И из-за того, что там таймштамп и порядка 40 миллионов строк вставляется за минуту, то операция достаточно тяжелая )

я все понимаю, но ложиться без возможности восстановления не должно

Это безусловно так, да )

надеюсь мы поняли друг друга
я возможно неправильно использовал
неправильно сконфигурировал
при всем при этом 1 сервер работал как часы даже с временем в ключе без вопросов неделю
как только сделал кластер все поотваливалось
Так что я пока очень скептически отношусь к дате в ключе
И мне интересно неужели разработчикам КХ не итнересно почему 1 нода работает а 3-4 нет :)

У многих тут кластера работают на ура

"Так что я пока очень скептически отношусь к дате в ключе" - зря, это придумали разработчики CH, а им виднее

Это все хорошо но объяснить почему работал 1 а не работают 4 в кластере никто не может

Создайте в google group или на гитхабе CH описание проблемы, думаю тогда разработчики пояснят

Хорошии совет спасибо

интерактивно конечно намного удобнее но видимо не получится

А можно как-то производительность синхронизации реплик увеличить?
А то вот это все время растет
queue_size: 1077
inserts_in_queue: 900
merges_in_queue: 177

сеть и процессор почти не загружены

queue_size: 3228
inserts_in_queue: 2684
merges_in_queue: 544

И все сдохло опять
Сейчас писал не в распределеннют таблицу а в локальные 4 через лоад балансер

А структура таблицы поменялась?

в этом тесте нет
5 мин назад запустил с такой структурой

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/01/measures', '1',date, (date, account, id), 8192);

надо подождать теперь часа 2

в прошлый раз легло где-то через 2-2.5

сейчас вставляю обратно через распределенную таблицу

не поделитесь, как вы хотите выборки по tags делать? Это фулскан будет, т.к. они не могут быть в ключе.

так запрос же есть вверху

филскана нет вроде как

по крайней мере запросы отрабатывают быстро

и кол-во обработанных строк говорит что не фулскан

м, ну имею ввиду если в запросе вообще не будет полей из 1 pkey или если запрос по pk все равно вернет тонну данных

или такого не будет