Это фича реплицируемых таблиц

Значит изменяет )

Но, оно работает только если вставлять полностью идентичные блоки данных, что, иногда, тоже тот еще квест

Это фича реплицируемых таблиц

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

Добрый день. проследил этап развития функции CityHash вижу что у гугла есть приемник FarmHash https://opensource.googleblog.com/2014/03/introducing-farmhash.html и новый HighwayHash https://opensource.googleblog.com/2016/03/new-algorithms-may-lower-cost-of-secure.html

CityHash в ClickHouse немного особенный - он старой версии

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

Да, есть insert_quorum тут кое что написано https://blog.clickhouse.ninja/posts/distributed-tables-sharding-and-replication/

Спасибо!

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

Насколько я знаю - это так только в случае Replicated*MergeTree, и если блоки данных идентичны.

Добрый день. проследил этап развития функции CityHash вижу что у гугла есть приемник FarmHash https://opensource.googleblog.com/2014/03/introducing-farmhash.html и новый HighwayHash https://opensource.googleblog.com/2016/03/new-algorithms-may-lower-cost-of-secure.html

В КХ есть несколько незадокументированных функций хэшировавния: :) select * from system.functions where name like '%Hash%'; SELECT * FROM system.functions WHERE name LIKE '%Hash%' ┌─name─────────────────┬─is_aggregate─┐ │ sumburConsistentHash │ 0 │ │ intHash64 │ 0 │ │ jumpConsistentHash │ 0 │ │ farmHash64 │ 0 │ │ sipHash64 │ 0 │ │ sipHash128 │ 0 │ │ cityHash64 │ 0 │ │ intHash32 │ 0 │ │ metroHash64 │ 0 │ │ yandexConsistentHash │ 0 │ │ URLHash │ 0 │ └──────────────────────┴──────────────┘ 11 rows in set. Elapsed: 0.002 sec.Между прочим metroHash64 и farmHash64.

Насколько я знаю - это так только в случае Replicated*MergeTree, и если блоки данных идентичны.

Возможно :) Я точно не могу сказать, но вроде бы да, только для Replicated таблиц.

В КХ есть несколько незадокументированных функций хэшировавния: :) select * from system.functions where name like '%Hash%'; SELECT * FROM system.functions WHERE name LIKE '%Hash%' ┌─name─────────────────┬─is_aggregate─┐ │ sumburConsistentHash │ 0 │ │ intHash64 │ 0 │ │ jumpConsistentHash │ 0 │ │ farmHash64 │ 0 │ │ sipHash64 │ 0 │ │ sipHash128 │ 0 │ │ cityHash64 │ 0 │ │ intHash32 │ 0 │ │ metroHash64 │ 0 │ │ yandexConsistentHash │ 0 │ │ URLHash │ 0 │ └──────────────────────┴──────────────┘ 11 rows in set. Elapsed: 0.002 sec.Между прочим metroHash64 и farmHash64.

Они кстати недавно появились судя по всему

Они кстати недавно появились судя по всему

Довольно давно на самом деле. В принципе непонятно почему не задокументированы: https://github.com/yandex/ClickHouse/commit/f1bc75980774cee7b2877c98bb052db1138c24c2 https://github.com/yandex/ClickHouse/commit/58408dc8a3f4bfe295bd77010715b9e7b73864cd

Там недавно появились несколько функций для консистентного хеширования (*ConsistentHash). Я так понимаю - чтобы использовать как ключ шардирования, чтобы перешардирование было менее болезненным.

Перешардирование это insert into new select from old? А оно сможет понять что данные, которые остаются локальными, не надо никуда пересылать?

Или нужно будет руками из локальных таблиц переливать по where?

Перешардирование это insert into new select from old? А оно сможет понять что данные, которые остаются локальными, не надо никуда пересылать?

Нет - это https://clickhouse.yandex/docs/en/utils/clickhouse-copier/

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

я также не пойму, почему проскакивают дубликаты по ключу (date_time DateTime) ENGINE = ReplacingMergeTree PARTITION BY toYYYYMMDD(date) ORDER BY (date_time, symbol) SETTINGS index_granularity = 8192;" select count(date_time) as c from buckets group by date_time having c > 1 2018-05-11 06:07:00 2 2018-05-11 06:05:00 2 2018-05-11 06:02:00 2 абсолютно идентичные записи select * from buckets where date_time = '2018-05-11 06:07:00'

ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов. я так понимаю это тот случай Обратите внимание, что дедупликация данных производится лишь во время слияний. Слияние происходят в фоне в неизвестный момент времени, на который вы не можете ориентироваться. Некоторая часть данных может так и остаться необработанной. Хотя вы можете вызвать внеочередное слияние с помощью запроса OPTIMIZE, на это не стоит рассчитывать, так как запрос OPTIMIZE приводит к чтению и записи большого объёма данных. автоматом схлопнуть их никак нельзя? не используя периодически запросы optimize

На уровне хранения - нет. А если на уровне выборки, то вероятно это понизило бы эффективность (пришлось бы на любой запрос мержить данные по pk).

Товарищи, а select to outfile format native умеет сразу пожатое писать ?

Что-то мне казалось, что так должно быть по-умолчанию

или нет ?

На уровне хранения - нет. А если на уровне выборки, то вероятно это понизило бы эффективность (пришлось бы на любой запрос мержить данные по pk).

плохо, что приходится делать distinct, лучше бы, когда по pk эксепшн бросало, я бы бизнес логику подкрутил

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

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

Товарищи, а select to outfile format native умеет сразу пожатое писать ?

я дополнительно паковал такие файлы zip'ом, раз в 10 сжимает

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

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

а как сейчас переливаете, INSERT INTO x SELECT FROM y?

никак

Хочу найти хороший рецепт

INSERT INTO x SELECT FROM y - плохой

в моих условиях производительность порядка 11к/сек

При том, что, очевидно, ничего не мешает делать больше

Пробую с дампами

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

ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов. я так понимаю это тот случай Обратите внимание, что дедупликация данных производится лишь во время слияний. Слияние происходят в фоне в неизвестный момент времени, на который вы не можете ориентироваться. Некоторая часть данных может так и остаться необработанной. Хотя вы можете вызвать внеочередное слияние с помощью запроса OPTIMIZE, на это не стоит рассчитывать, так как запрос OPTIMIZE приводит к чтению и записи большого объёма данных. автоматом схлопнуть их никак нельзя? не используя периодически запросы optimize

В Collapsing через FINAL можно дубликаты выкидывать недожидаясь мержа

о, точно. Отличается от MergeTree тем, что позволяет автоматически удалять - "схлопывать" некоторые пары строк при слиянии.

я убирание дубликатов решил через https://clickhouse.yandex/docs/ru/query_language/queries/#limit-n-by

я не уверен, что DISTINCT на миллиардах данных будет быстро работать

Товарищи, а select to outfile format native умеет сразу пожатое писать ?

Если по HTTP тянуть с compress=1 то будете получать сжатый стрим на выходе. Можно его сразу писать в файл без распаковки.

Но вариант с freeze partition / rsync / attach partition скорее всего будет быстрее.

При том, что, очевидно, ничего не мешает делать больше

Обычно диск и мешает. У меня обычно при таких операциях первые пара гб пролетают почти мгновенно (показывает скорость около 1Gb/s), а потом файловые буфферы кончаются и начиается медленный и печальный disk io (и скорость падает до ок 60-70 Mb/s, что вполне объяснимо физическими возможностями диска). А о каких 11к/сек вы пишете? 11 тыс строк? Тут всё зависит от размера этих строк.

Кроме ограничений диска - есть ещё дополнительный оверхед на регистрацию новых фрагментов в зукипере, на рассылку данных на реплики и т.д.

господа, ODBC не пашет, что делать? Cannot process the object "select count() from table where mts = toDateTime('2018-05-03 00:00:00');". The OLE DB provider "MSDASQL" for linked server "CLICKHOUSE_TEST" indicates that either the object has no columns or the current user does not have permissions on that object.

ODBC

ODBC

да именно он

ODBC с полгода назад последний раз пробовал ковырять, там всё было мрачно и нестабильно. С тех пор там кое-что поменялось, но вряд ли всё стало идеально. Лучше всего описать конкретную проблемную последовательность действий, запрос и схему таблицы как issue тут https://github.com/yandex/clickhouse-odbc

@proller вроде бы занимается темой ODBC, может быть он подскажет что-то.

unicod версия не работает - падает, а вот ansi худо-бедно завелась

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

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

на удаленном сервере.

Обычно диск и мешает. У меня обычно при таких операциях первые пара гб пролетают почти мгновенно (показывает скорость около 1Gb/s), а потом файловые буфферы кончаются и начиается медленный и печальный disk io (и скорость падает до ок 60-70 Mb/s, что вполне объяснимо физическими возможностями диска). А о каких 11к/сек вы пишете? 11 тыс строк? Тут всё зависит от размера этих строк.

нагрузка еле-еле, там R10 из 8 SSD

Но вариант с freeze partition / rsync / attach partition скорее всего будет быстрее.

Этот вариант не изменит порядок индексов

нагрузка еле-еле, там R10 из 8 SSD

Тогда странно, по идее должно летать. Может какой-нибудь кворум при инсертах включен?

В рамках эксперимента: а что если попробовать перелить данные в обычный MergeTree (без репликаций и т.п.) - не будет быстрее?

Если бы было - то потом можно переделать MergeTree в Replicated по инструкции из документации.

сам себе отвечу, документация не актуальна: что бы сходить на удаленный сервер нужно select * FROM remote('HOST', DB.TABLE, 'USER', 'PASS') limit 1

сам себе отвечу, документация не актуальна: что бы сходить на удаленный сервер нужно select * FROM remote('HOST', DB.TABLE, 'USER', 'PASS') limit 1

А о какой неактуальности речь? Вроде бы так и написано: remote('addresses_expr', db.table[, 'user'[, 'password']])https://clickhouse.yandex/docs/ru/table_functions/remote/

А о какой неактуальности речь? Вроде бы так и написано: remote('addresses_expr', db.table[, 'user'[, 'password']])https://clickhouse.yandex/docs/ru/table_functions/remote/

в таком формате -не работает, нужно без array и без лишних запятых

а, ага. Там эти квадратные скобки - просто указывают что эти параметры можно пропустить.

что-то одна боль то ли с remote, то ли в последней версии if/multiif поломали.. имею 3 версии ch, полугодовалой давности, и далее новее, на самой новой запрос не отрабатывает с One or more branch (then, else) columns of function multiIf have illegal or incompatible types. с-супер

Наверное действительно может быть не очень понятно.

конкретно ему не нравится конструкция sum(caseWithoutExpr(mt LIKE 'ONE', counter, NULL)) AS ONE,

А зачем вы NULL суммируете?

А зачем вы NULL суммируете?

если там есть null - он в качестве результата должен дать null это стандартное поведение же

на 1.1.54378 работает, на 1.1.54292 - нет

odbc тоже не завелся, https://github.com/yandex/clickhouse-odbc/issues/25 ну что за...

Поведайте, SSL сертификаты перечитываются при reload, или же надо делать рестарт? И ещё: из документации следует, что при заданном http_port конфигурация openssl игнорируется. Означает ли это, что нет смысла одновременно задавать http_port и https_port?

Поведайте, SSL сертификаты перечитываются при reload, или же надо делать рестарт? И ещё: из документации следует, что при заданном http_port конфигурация openssl игнорируется. Означает ли это, что нет смысла одновременно задавать http_port и https_port?

скорее всего не перечитываются. http_port и https_port можно использовать одновременно указывая разные порты ( (80 и 443 например)

если там есть null - он в качестве результата должен дать null это стандартное поведение же

:) select sum(caseWithoutExpr(number = 999,number, NULL)) from numbers(1000); SELECT sum(caseWithoutExpr(number = 999, number, NULL)) FROM numbers(1000) ┌─sum(caseWithoutExpr(equals(number, 999), number, NULL))─┐ │ 999 │ └─────────────────────────────────────────────────────────┘ 1 rows in set. Elapsed: 0.002 sec. Processed 1.00 thousand rows, 8.00 KB (486.49 thousand rows/s., 3.89 MB/s.)

odbc тоже не завелся, https://github.com/yandex/clickhouse-odbc/issues/25 ну что за...

в екселе не завелся?

в екселе не завелся?

завелся, как линк не заводится

:) select sum(caseWithoutExpr(number = 999,number, NULL)) from numbers(1000); SELECT sum(caseWithoutExpr(number = 999, number, NULL)) FROM numbers(1000) ┌─sum(caseWithoutExpr(equals(number, 999), number, NULL))─┐ │ 999 │ └─────────────────────────────────────────────────────────┘ 1 rows in set. Elapsed: 0.002 sec. Processed 1.00 thousand rows, 8.00 KB (486.49 thousand rows/s., 3.89 MB/s.)

и что мне это дает?)

Подскажите пожалуйста - у vertica при загрузке данных в случае ошибки есть возможность получить дамп тех данных, которые не были вставлены. В той или иной степени это позволяет на стороне приложения реализовать обработку такой ошибки. Как с этим обстоит дело у ch? Где можно прочитать про обработку ошибок при вставке?

https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/COPY/COPY.htm ABORT ON ERROR есть

ну и если PRIMARY есть https://my.vertica.com/docs/9.1.x/HTML/index.htm#Authoring/SQLReferenceManual/Statements/COPY/CopyRestrictions.htm в общем в вертике также как в CH ... rollback будет на ошибку

вообщем в последней версии сломали следующее: sumIf(counter,mt LIKE 'ONE') AS ONE, sum(caseWithoutExpr(mt LIKE 'TWO', counter, NULL)) AS TWO в старой версии работают оба варианта, в новой - только первый

странности продолжаются, конструкция с IF эквивалетная case - работает

т.е внутри if sum(null) - можно, внутри case - нет

Предупреждение тем, кто использует зоокипер в докере. Недавно его развернули для кластера CH и уже наткнулись на эту бомбу со старыми снапшотами. В докере autopurge не работает https://github.com/31z4/zookeeper-docker/issues/30

в екселе не завелся?

Нет ли рецепта как линк завести?

и что мне это дает?)

Даёт то что NULL ничего не дает :)

Даёт то что NULL ничего не дает :)

c if у меня завелось, а вот с case - нет

так что это баг =)

а вот с ODBC беда конечно =( The OLE DB provider "MSDASQL" for linked server "CLICKHOUSE_TEST" indicates that either the object has no columns or the current user does not have permissions on that object

вообще у кого-то есть clickhouse как linked сервер в MSSQL?

Подскажите, пожалуйста, как можно ускорить мёрж с таким паттерном: Row 19: ─────── database: uds table: uds_events_Local elapsed: 13750.632880844 progress: 0.7630291236322443 num_parts: 10 source_part_names: ['20180509_20180527_303355_307955_5','20180509_20180526_307956_315527_6','20180509_20180530_315528_321002_6','20180509_20180522_321003_321900_4','20180509_20180529_321901_324213_5','20180509_20180526_324214_328493_6','20180510_20180526_328494_330498_5','20180510_20180512_330499_330661_3','20180510_20180515_330662_331074_4','20180510_20180516_331075_331464_4'] result_part_name: 20180509_20180530_303355_331464_7 total_size_bytes_compressed: 48039815216 total_size_marks: 1414178 bytes_read_uncompressed: 2570000180900 rows_read: 8839651328 bytes_written_uncompressed: 2569987431106 rows_written: 8839610427 columns_written: 0 memory_usage: 224661202 thread_number: 48 formatReadableSize(total_size_bytes_compressed): 44.74 GiB formatReadableSize(bytes_read_uncompressed): 2.34 TiB formatReadableSize(bytes_written_uncompressed): 2.34 TiB

уж очень долго происходит

уж очень долго происходит

Можно уменьшить максимальный размер куска и он не будет большие мержить, но, зачем оно вам надо?

Можно уменьшить максимальный размер куска и он не будет большие мержить, но, зачем оно вам надо?

max_bytes_to_merge_at_max_space_in_pool ?

Я тут вижу, что _несколько_ партов мёржится

полагаю, что если, например, будет всего два парта мёржиться, то будет веселее

Очень медленный хдд ?

Сервер на один проц?

max_bytes_to_merge_at_max_space_in_pool ?

Да, это оно, по умолчанию размер куска 150 GB. Пока куски меньше он будет пытаться их мержить

Очень медленный хдд ?

SSD, 24 ядра (включая HT)