@clickhouse_ru

Страница 430 из 723
 
Гаврилов
21.02.2018
17:10:38
но например из 10 строк в секунду может быть 7-8 дублей

 
Артемий
21.02.2018
17:11:52
https://clickhouse.yandex/docs/ru/table_engines/collapsingmergetree.html

 
См. внизу "Существует несколько способов получения полностью "схлопнутых" данных из таблицы типа CollapsingMergeTree"

 
Гаврилов
21.02.2018
17:12:48
не это перебор )

Google
 
Гаврилов
21.02.2018
17:13:09
поидее мы кликхаус вообще вместо традиционных кубов вставляем

 
тоесть заказчик привыкший к кубам, которые по 10 часов расчитываются ночью

 
а какие машинки вы используете и для какого количества запросов в секунду?

 
нам надо будет гдето 5к запросов в секунду нагрузочное тестирование пройти

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

 
пара 16ти ядерных машин такое вывезут?

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

 
Артемий
21.02.2018
17:23:22
пара 16ти ядерных машин такое вывезут?
Зависит от того, что конкретно требуется и какой длины записи. Длина записи 10кб * 1млн при импорте будет выполняться очень быстро, с 10-30% нагрузкой 3-5 ядер

 
Гаврилов
21.02.2018
17:24:00
я про вывод результата пользователю, а не про запись

 
Артемий
21.02.2018
17:24:12
>Зависит от того, что конкретно требуется

 
Гаврилов
21.02.2018
17:25:13
основная масса короткие запросы, которые сейчас на 4х2.4 ггц выполняются по 100-200 ms

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

 
Артемий
21.02.2018
17:29:20
посчитать количество после кучи фильтров в основном
Оперативка будет иметь значение

Google
 
Артемий
21.02.2018
17:29:36
Желательно, чтобы все блоки, попадаемые в фильтр помещались в память

 
Гаврилов
21.02.2018
17:29:37
примерно в 4 раза больше объема данных

 
оперативки будет

 
где-то 3-4 гб данных будет

 
и 16 гб оперативки на машину

 
ну 3-4 всмысле уже в кликхаусе после сжатия

 
в постгресе это почти 20

 
ну и 95% запросов будут идти к данным последнего месяца

 
которых врятли больше миллиона будет

 
тоесть получается горячих данных 500 мб

 
Атата
21.02.2018
17:33:39
тоесть получается горячих данных 500 мб
Зачем вам кх, в таком случае?)

 
Гаврилов
21.02.2018
17:33:47
постгрес умирает)

 
постгрес запросы по 5 секунд делает этиже

 
на этомже сервере

 
Kirill
21.02.2018
17:34:25
напишите, мне, плиз, кто-нибудь в личку, кому его можно порепортить
Можно сразу сюда писать и маякнуть, например: @milovidov_an @ztlpn @orantius

 
∀
21.02.2018
17:34:48
я на рассылку письмо кинула уже

 
Alexander
21.02.2018
17:34:56
Подскажет кто еще по инсерту из файла курлом?

 
curl -d "@test.json" -X POST 'http://HOST:PORT/?query=INSERT INTO db.table FORMAT JSONEachRow'

 
Pavel
21.02.2018
17:35:20
Привет, подскажите, пожалуйста, как данные кликхауса перенести с одной машины на другую. Я могу просто остановить сервак и сделать scp /var/lib/clickhouse?

 
Alexander
21.02.2018
17:35:22
получаем ошибку Code: 62, e.displayText() = DB::Exception: Syntax error: failed at position 8 (line 2, col 1): {"date":"2018-02-21","aff_id":"b0a8a25f-5d66-44f3-9169-bb7426dc15f7"}{"date":"2018-02-21","aff_id":"d692a059-2b9a-4c56-87e3-f201a0836125"}. Unrecognized token, e.what() = DB::Exception

Google
 
Гаврилов
21.02.2018
17:35:34
формат не подходит

 
Alexander
21.02.2018
17:35:54
формат не подходит
в файле: {"date":"2018-02-21","aff_id":"b0a8a25f-5d66-44f3-9169-bb7426dc15f7"} {"date":"2018-02-21","aff_id":"d692a059-2b9a-4c56-87e3-f201a0836125"}

 
Гаврилов
21.02.2018
17:36:02
а в базе

 
Alexander
21.02.2018
17:36:15
DESCRIBE TABLE clicks_test ┌─name───┬─type───┬─default_type─┬─default_expression─┐ │ aff_id │ String │ │ │ │ date │ Date │ │ │ └────────┴────────┴──────────────┴────────────────────┘

 
Kirill
21.02.2018
17:36:16
Привет, подскажите, пожалуйста, как данные кликхауса перенести с одной машины на другую. Я могу просто остановить сервак и сделать scp /var/lib/clickhouse?
Да, можно папку с данными просто синкнуть

 
Гаврилов
21.02.2018
17:37:01
может на сервере другой формат даты стоит?

 
Alexander
21.02.2018
17:37:40
может на сервере другой формат даты стоит?
а как проверить формат?

 
Гаврилов
21.02.2018
17:37:54
вставь эти данные руками в таблиц

 
∀
21.02.2018
17:38:11
ну так Date это число

 
Гаврилов
21.02.2018
17:38:16
и сделай экспорт в JSONEachRow

 
∀
21.02.2018
17:38:25
в днях с начала unixtime а ты туда строку кладешь

 
Гаврилов
21.02.2018
17:38:30
увидишь в чем разница между тем, что у тебя есть

 
и тем, что база от тебя ждет

 
я через tsv кидаю дату тоже в таком формате

 
и он нормально понимает

 
Alexander
21.02.2018
17:41:50
такое же :) SELECT * FROM clicks_test FORMAT JSONEachRow {"date":"2018-02-21","aff_id":"b0a8a25f-5d66-44f3-9169-bb7426dc15f7"}

 
Гаврилов
21.02.2018
17:43:10
магия какаето)

 
Alexander
21.02.2018
17:43:13
та да.

 
причем при инсерте вручную было интересно еще

 
Гаврилов
21.02.2018
17:43:32
NSERT INTO db.table

Google
 
Гаврилов
21.02.2018
17:43:42
DESCRIBE TABLE clicks_test

 
вставляешь в одну

 
а тип другой скидываешь

 
Alexander
21.02.2018
17:43:57
insert into clicks_test (date, aff_id) values ("2018-02-21", "b0a8a25f-5d66-44f3-9169-bb7426dc15f7"); INSERT INTO clicks_test (date, aff_id) VALUES Exception on client: Code: 36. DB::Exception: Element of set in IN or VALUES is not a constant expression: 2018-02-21

 
а это вставилось: insert into clicks_test (date, aff_id) values ('2018-02-21', 'b0a8a25f-5d66-44f3-9169-bb7426dc15f7');

 
values с двойными кавычками не проходит, а с одинарными проходит

 
то я заменил название чтобы тут не светить. Вставляю туда же

 
Kirill
21.02.2018
17:45:49
Так и есть, как в PostgreSQL, в двойных он считает что это какой-то филд

 
Гаврилов
21.02.2018
17:46:09
но json формат то с двойными кавычками

 
Alexander
21.02.2018
17:46:18
ну да. как в доке делаем

 
попробуем csv значит

 
Kirill
21.02.2018
17:47:19
но json формат то с двойными кавычками
нужно явно формат указать INSERT INTO table FORMAT JSONEachRow...

 
Alexander
21.02.2018
17:48:20
мы так и делаем INSERT INTO clicks_test FORMAT JSONEachRow

 
Kirill
21.02.2018
17:48:46
в днях с начала unixtime а ты туда строку кладешь
если по http слать или в клиенте дату написать то они будут преобразованы и нормально запишуться

 
∀
21.02.2018
17:49:24
мы так и делаем INSERT INTO clicks_test FORMAT JSONEachRow
какая версия ch?

 
у вас же работает инсерт с таким форматом?

 
Alexander
21.02.2018
17:49:58
ClickHouse server version 1.1.54336

 
curl может что-то ломает?

 
∀
21.02.2018
17:57:37
в 1.1.54342 теряются первые 8 символов на инсертах JSONEachRow

 
Alexander
21.02.2018
18:02:54
из консоли вставляет :) insert into clicks_test format JSONEachRow {"date":"2018-02-21","aff_id":"b0a8a25f-5d66-44f3-9169-bb7426dc15f7"}

Google
 
∀
21.02.2018
18:04:53
ну мне не из консоли нужно, правда)

 
Alexander
21.02.2018
18:05:27
в общем, из консоли работает, курлом удаленно - нет

 
∀
21.02.2018
18:06:42
даже если в клиент лить данные через пайп — не вставляет

 
Гаврилов
21.02.2018
18:15:59
а какихто мажорных обнов не планируется?

 
papa
21.02.2018
18:49:32
а какихто мажорных обнов не планируется?
конечно планируется, у нас тут динамически развивающийся продукт.

 
Alexey
21.02.2018
20:40:16
Вопрос к разработчикам. Поймали серьёзную деградацию на работе с промежуточными состояниями аггрегатных функций. Под условия WHERE нет подходящих строк, но попытка обращения к колонке с состоянием деградирует запрос в 10-20 раз. Полечилось заменой на PREWHERE. Вопрос - это баг/фича? Подробности в gist: https://gist.github.com/alex-krash/035d32a87fd94be2483055e60ba3a383
Скорее всего это связано с тем, что состояния агрегатных функций становятся "толстыми" значениями, и index_granularity = 8192 для такого случая уже много. Ведь при чтении из таблицы придётся прочитать и десериализовать (восстановить состояния в оперативке) как минимум такое количество строк. Но даже с учётом этого соображения, наблюдаемая скорость гораздо меньше ожидаемой. Попробуйте запустить тяжёлый запрос в цикле с помощью clickhouse-benchmark, и в соседнем терминале посмотреть на sudo perf top.

 
в схеме сервера: прореживать до час все что старше одного месяца, он сам это не делает? почему в исходно все данные?
Прореживание делается во время фоновых мержей. Если партиционирование по месяцам (по-умолчанию), то для старых месяцев, мержи никогда или почти никогда не делаются, и прореживание не производится. Специально для этого случая есть запрос OPTIMIZE ... FINAL PARTITION ... Его можно запускать вручную для прореживания старых данных.

 
так, похоже с iptrie все ок, а вот другой hash словарь теперь поломался ?
А что именно? Для примера, у нас была несовместимость - пустота (из CSV или TSV) не читается в качестве Float числа.

 
Такой вопрос Есть какой нибудь менее костыльный вариант проверить наличие значения в Array(Enum8(....)), чем то, что ниже? SELECT ... WHERE has(arrayMap(x -> toUInt8(x), arrColumn), 4)
arrayExists(x -> toUInt8(x) = 4, arrColumn)

 
К вопросу выше добавлю — можно ли найти индекс максимального в массиве?
Есть несколько неудобных способов это сделать. WITH [11, 22, 33, 25] AS arr SELECT arrayReduce('argMax', arrayEnumerate(arr), arr) WITH [11, 22, 33, 25] AS arr SELECT arrayFirstIndex(x -> x = arrayReduce('max', arr), arr) WITH [11, 22, 33, 25] AS arr SELECT arrayReverseSort((idx, val) -> val, arrayEnumerate(arr), arr)[1]

 
Всем привет. Подскажите, плиз, нам нужно выполнять по запросу порядка 2к запросов типа insert into table select col1,col2,sum(col4) from table where ... group by col1,col2 Если начинаем подряд слать 2к штук, то взлетает количество кусков, и начинает идти дым. Как это можно оптимизировать? Понимаю, что в КХ слать батчем, но тут практически нереально объединить эти 2к запросов в один большой. Если мы их отправим через ; эти чем-то поможет? т.е. будет одна отправка в КХ, а не несколько.
Можно сначала сделать много мелких INSERT-ов в таблицу типа StripeLog (или TinyLog или Log), а потом уже из неё INSERT SELECT в MergeTree. Простые таблицы StripeLog/TinyLog/Log как раз подходят для временных данных.

 
Artem
21.02.2018
20:54:17
arrayExists(x -> toUInt8(x) = 4, arrColumn)
Как ни странно, такой запрос выполняется в два раза дольше (+25-30 секунд)

 
arrayExists(x -> toUInt8(x) = 4, arrColumn)
Хотя нет, прошу прощенья, пропустил toUInt8(x) в запросе

 
Ваш вариант действительно быстрее

 
Спасибо!

 
Alexey
21.02.2018
20:59:41
Мы просто вставляем как раз в ReplicatedMergeTree через Buffer-таблицу, интересно было узнать, что с этой схемой не так, кроме exactly-once и сохранения порядка
Из-за отсутствия exactly once, в данных иногда будут дубликаты, а из-за буферизации изредка будут потери... А в остальном всё нормально - Buffer работает как ожидается.

 
напишите, мне, плиз, кто-нибудь в личку, кому его можно порепортить
Можно мне в личку, но лучше всего на clickhouse-feedback@yandex-team.ru - так письмо смогут прочитать все разработчики.

 
можно же вручную вызвать optimize
Система рассчитана на то, что запрос OPTIMIZE не требуется делать самому. Есть редкие исключения типа GraphiteMergeTree, о котором я писал чуть выше. Есть некоторая целесообразность - можно выполнить OPTIMIZE, если в таблицу не постоянно пишутся новые данные, а вы закончили в неё писать, и надо добиться максимальной производительности SELECT-ов. Количество кусков имеет значение для коротких запросов (а для долго выполняющихся не сильно важно, из какого числа кусков читать).

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

 
Отключил прореживние на тестовом сервере, создал таблицу с грануляцией в 32768 строк, скопировал данные из таблицы с грануляцией в 8192 строк, БД усохла на диске с 91Г до 48Г, но часть данных потерялась: SELECT count(*) FROM graphite32 ┌─────count()─┐ │ 13901899118 │ └─────────────┘ 1 rows in set. Elapsed: 2.896 sec. Processed 13.90 billion rows, 27.80 GB (4.80 billion rows/s., 9.60 GB/s.) :) select count(*) from graphite; SELECT count(*) FROM graphite ┌─────count()─┐ │ 13903321793 │ └─────────────┘ 1 rows in set. Elapsed: 2.100 sec. Processed 13.90 billion rows, 27.81 GB (6.62 billion rows/s., 13.24 GB/s.) :)
Даже без прореживания, GraphiteMergeTree удаляет дубликаты, аналогично ReplacingMergeTree.

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