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

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

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

лучше жмется

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

понял

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

IEEE 754

спсб

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

Привет! Хочу в 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 скорее всего будут работать очень медленно

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

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

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

Где тут 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, и удалить старую таблицу."

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

Всем привет. Я правильно понимаю, что нет возможности добавить новый столбец в таблицу и одновременно добавить его в первичный ключ? В документации написано только про удаление и изменение: "Отсутствует возможность удалять столбцы, входящие в первичный ключ или ключ для сэмплирования (в общем, входящие в выражение ENGINE). Изменение типа у столбцов, входящих в первичный ключ возможно только в том случае, если это изменение не приводит к изменению данных (например, разрешено добавление значения в Enum или изменение типа с DateTime на UInt32)." То есть любое изменение первичного ключа требует создания новой таблицы: "Если возможностей запроса ALTER не хватает для нужного изменения таблицы, вы можете создать новую таблицу, скопировать туда данные с помощью запроса INSERT SELECT, затем поменять таблицы местами с помощью запроса RENAME, и удалить старую таблицу."

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

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

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

Спасибо!

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

Конфиги на вид кажутся нормальными. То, что расходятся цифры для 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 машинках и посмотрю

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

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

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

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

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

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

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

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

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

А в колонке 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 серверов

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

Причины 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).

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

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

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

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

Подскажите, товарищи: в какой-то момент 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)

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

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.)

ERROR: S client not available

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

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

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

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

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

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

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

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

а уже 3.4.10 есть?

а уже 3.4.10 есть?

ага

30 March, 2017: release 3.4.10 available

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

Понятно, спасибо. Сомневаюсь, чтобы у кого-то 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).

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