
Атата
11.05.2018
06:27:00

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

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

Kirill
11.05.2018
06:55:24

Google

Kirill
11.05.2018
06:59:35

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

Michal
11.05.2018
07:07:02


Александр
11.05.2018
07:12:27


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?

Kirill
11.05.2018
07:38:10

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

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

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

Ivan
11.05.2018
08:13:25

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

Ivan
11.05.2018
08:20:26

LeiDruid
11.05.2018
08:22:18
никак
Хочу найти хороший рецепт
INSERT INTO x SELECT FROM y - плохой
в моих условиях производительность порядка 11к/сек
При том, что, очевидно, ничего не мешает делать больше
Пробую с дампами

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

Kirill
11.05.2018
08:26:43

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
Но вариант с 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

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
на удаленном сервере.

LeiDruid
11.05.2018
09:29:09

Michal
11.05.2018
09:31:10
В рамках эксперимента: а что если попробовать перелить данные в обычный 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

Stas
11.05.2018
09:46:43

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
на 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?

prll
11.05.2018
10:17:14

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

prll
11.05.2018
10:19:08

Stas
11.05.2018
10:19:20

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

Stas
11.05.2018
11:08:42
так что это баг =)
а вот с 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

Alex
11.05.2018
12:00:42