@clickhouse_ru

Страница 523 из 723
Атата
11.05.2018
06:27:00
Kirill
11.05.2018
06:27:11
Но, оно работает только если вставлять полностью идентичные блоки данных, что, иногда, тоже тот еще квест

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

Google
Kirill
11.05.2018
07:00:07
Спасибо!

Michal
11.05.2018
07:07:02
Добрый день. проследил этап развития функции 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.

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

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

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

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

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

Oleksandr
11.05.2018
07:57:30
я также не пойму, почему проскакивают дубликаты по ключу (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'

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

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

LeiDruid
11.05.2018
08:07:03
Товарищи, а select to outfile format native умеет сразу пожатое писать ?

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

или нет ?

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

Andrew
11.05.2018
08:10:43
Кажется что в большинстве случаев лучше делать склейку на уровне приложения.

Oleksandr
11.05.2018
08:11:21
просто если очень много данных, то мержить в памяти и тянуть по сети не всегда хорошо

Ivan
11.05.2018
08:13:25
Товарищи, а select to outfile format native умеет сразу пожатое писать ?
я дополнительно паковал такие файлы zip'ом, раз в 10 сжимает

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

LeiDruid
11.05.2018
08:22:18
никак

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

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

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

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

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

Ivan
11.05.2018
08:24:42
может действительно тогда прям партиции детачить, архивировать и переливать в новое место, а там разворачивать

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

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

Oleksandr
11.05.2018
08:42:09
я не уверен, что DISTINCT на миллиардах данных будет быстро работать

Michal
11.05.2018
08:44:50
Товарищи, а select to outfile format native умеет сразу пожатое писать ?
Если по HTTP тянуть с compress=1 то будете получать сжатый стрим на выходе. Можно его сразу писать в файл без распаковки.

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

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

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

Stas
11.05.2018
08:59:40
господа, 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.

Michal
11.05.2018
09:03:01
ODBC

Stas
11.05.2018
09:04:26
ODBC
да именно он

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

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

Stas
11.05.2018
09:12:14
unicod версия не работает - падает, а вот ansi худо-бедно завелась

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

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

Michal
11.05.2018
09:28:52
на удаленном сервере.

Michal
11.05.2018
09:31:10
нагрузка еле-еле, там R10 из 8 SSD
Тогда странно, по идее должно летать. Может какой-нибудь кворум при инсертах включен?

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

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

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

Michal
11.05.2018
09:45:33
сам себе отвечу, документация не актуальна: что бы сходить на удаленный сервер нужно 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/

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

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

Michal
11.05.2018
09:47:55
Наверное действительно может быть не очень понятно.

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

Michal
11.05.2018
09:49:14
А зачем вы NULL суммируете?

Stas
11.05.2018
09:50:01
А зачем вы NULL суммируете?
если там есть null - он в качестве результата должен дать null это стандартное поведение же

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

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

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

Michal
11.05.2018
10:18:32
если там есть 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.)

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

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

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

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

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

Stas
11.05.2018
11:05:12
в екселе не завелся?
Нет ли рецепта как линк завести?

Michal
11.05.2018
11:07:34
и что мне это дает?)
Даёт то что NULL ничего не дает :)

Stas
11.05.2018
11:08:42
Даёт то что 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?

Alex
11.05.2018
11:34:38
Подскажите, пожалуйста, как можно ускорить мёрж с таким паттерном: 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

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

Kirill
11.05.2018
11:39:47
уж очень долго происходит
Можно уменьшить максимальный размер куска и он не будет большие мержить, но, зачем оно вам надо?

Alex
11.05.2018
11:51:07
Я тут вижу, что _несколько_ партов мёржится

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

Wolf
11.05.2018
11:53:48
Очень медленный хдд ?

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

Kirill
11.05.2018
11:56:00
max_bytes_to_merge_at_max_space_in_pool ?
Да, это оно, по умолчанию размер куска 150 GB. Пока куски меньше он будет пытаться их мержить

Alex
11.05.2018
12:00:42
Очень медленный хдд ?
SSD, 24 ядра (включая HT)

Страница 523 из 723