Дороха выходит пока

перезапустил с новыми настройками (max_block_size=1000, max_insert_block_size=1000, max_threads=1) - новая ошибка ↑ Progress: 441.17 million rows, 40.93 GB (6.91 million rows/s., 640.83 MB/s.) ████████████████████████████████████████▎ 64Received exception from server (version 18.10.3): Code: 241. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Memory limit (for query) exceeded: would use 46.58 GiB (attempt to allocate chunk of 67108864 bytes), maximum: 46.57 GiB: (while reading column error): (while reading from part /var/lib/clickhouse/data/default/object_events_mt12/20180508_20180512_4650_4662_1/ from mark 240 with max_rows_to_read = 1000). 0 rows in set. Elapsed: 64.081 sec. Processed 441.17 million rows, 40.93 GB (6.88 million rows/s., 638.74 MB/s.)

Kirill, спасибо, вот структура CREATE MATERIALIZED VIEW status_mv12 TO status_amt12 AS SELECT created_at_d as created_at_d, group_id as group_id, user_id as user_id, master_object_id as master_object_id, argMaxState(object_id, event_ms_ts) AS last_object_id, argMaxState(object_complete, event_ms_ts) AS object_complete, argMaxState(object_complete_success, event_ms_ts) AS object_complete_success, argMaxState(completed_at_dt, event_ms_ts) AS last_complete_dt, argMaxState(error, event_ms_ts) AS last_error, argMaxState(report, event_ms_ts) AS last_report FROM status_amt12_null GROUP BY created_at_d, group_id, user_id, master_object_id у меня почему то возникает ощущение что настройки не применяются, например, я вижу что процентики бегут примерно с одинаковой скоростью независимо от настроек (визуальное ощущение, но я могу ошибаться)

Я так понимаю падает на POPULATE? Можно попробовать сделать populate "ручками". Проверьте кстати применились ли настройки ( select * from syatem.settings where changed=1 ) для того пользователя которым создаёте mv, особенно max bytes before external group by.

max_bytes_before_external_group_by выставите, например, в 30GB, вы же там группируете и max_block_size в 8192 и попробуйте не все разом писать, движок еще в фоне все помержит

Я так понимаю падает на POPULATE? Можно попробовать сделать populate "ручками". Проверьте кстати применились ли настройки ( select * from syatem.settings where changed=1 ) для того пользователя которым создаёте mv, особенно max bytes before external group by.

max_bytes_before_external_group_by стоит в 20 ГБ сейчас

ОК, тогда пишите в несколько запросов, например по дням, и посмотрите хватит ли памяти и сколько он будет есть ее при мержах

Привет! Подскажите, а можно как-то запросом посмотреть все имеющиеся словари?

select * from system.dictionaries

Табикс пытается подключиться к местному localhost и обламывается. А надо подключаться к адресу впс

перезапустил с новыми настройками (max_block_size=1000, max_insert_block_size=1000, max_threads=1) - новая ошибка ↑ Progress: 441.17 million rows, 40.93 GB (6.91 million rows/s., 640.83 MB/s.) ████████████████████████████████████████▎ 64Received exception from server (version 18.10.3): Code: 241. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Memory limit (for query) exceeded: would use 46.58 GiB (attempt to allocate chunk of 67108864 bytes), maximum: 46.57 GiB: (while reading column error): (while reading from part /var/lib/clickhouse/data/default/object_events_mt12/20180508_20180512_4650_4662_1/ from mark 240 with max_rows_to_read = 1000). 0 rows in set. Elapsed: 64.081 sec. Processed 441.17 million rows, 40.93 GB (6.88 million rows/s., 638.74 MB/s.)

Ребят вопрос - а cli client поддерживает автодополнение?

В следующей версии должно появиться.

Круто было б!

а, который грузится через clickhouse-client? если формат tsv, то можно cat-sed магию накрутить

Подскажите кто сталкивался, пытаюсь добавить файл с макросами macros.xml в основном конфинге прописал <macros incl="macros">macros.xml</macros> Сам файл лежит в /etc/clickhouse-server/conf.d права на месте, внутри <?xml version="1.0"?> <yandex> <macros replace="replace"> <shard>01</shard> <replica>01</replica> </macros> </yandex> При создании реплицируемой таблицы ошибка Code: 62, e.displayText() = DB::Exception: No macro shard in config, e.what() = DB::Exception CH рестартовал, эффекта ноль.

Доброго дня, если я делаю условие сравнения datetime и date, то 1 кейс работает >= select * from table where event_time >=toDate('2018-01-01') 2 запрос не отраатывает <= select * from table where event_time <=toDate('2018-01-01') ни одной строки не возвращается кто мне ответит почему?

спасиб, думалось я что-то не то делаю

<macros>conf.d/macros.xml</macros> + reboot сервера

в v1.1.54390 кажется исправили

Есть способ приведение к типу DateTime строки у которой формат не соответсвует "YYYY-MM-DD hh:mm:ss" ?

Функция parseDateTimeBestEffort

А в insert никакого вычисления нет? А insert проходит в null таблицу если не создавать MV? report и error насколько большими по размеру могут быть?

в INSERT вычисления нет, report и error строки, могут быть в пределах килобайта, но вы правы - инсерт в нулл таблицу не проходит по причине нехватки памяти, это может быть из-за ORDER BY? Просто у events_mt12 уже в PK created_at_d, думал, бесплатно сортировка будет INSERT INTO status_amt12_null SELECT event_ms_ts, created_at_d, completed_at_dt, group_id, user_id, master_object_id, object_id, object_complete, object_complete_success, error, report FROM events_mt12 ORDER BY created_at_d ASC

Сортировка не бесплатна, но ее тоже можно вытеснить на диск max_bytes_before_external_sort

вставка без сортировки в NULL таблицу прошла, запустил вставку без сортировки в MV, все стало очень медленно, посмотрим как пройдет, потом буду пробовать этот ключик. Спасибо

Так и знал что вы от нас что-то скрываете :) В том запросе который раньше показывали не было ORDER BY, и вообще ничего в нем не указывало что он может отвалиться по памяти при включенной группировке на диске. :) Про медленно - да, INSERT ... SELECT не быстр. Тут как раз настройки размеров блоков могут помогать.

сорри, я не скопировал INSERT в чатик, надо было сразу это сделать. Вопрос в догонку (наверное, очевидный, но все-таки) - настройки, которые я делаю с помощью SET, только на эту сессию? Все остальные сессии будут использовать конфиг? Например, у меня будет сессия которая будет вставлять данные бОльшими кусками маленькие объемы (типа 1000 записей в секунду) и параллельно я запущу миграцию меньшими кусками и с бОльшими настройками памяти на сессию. Правильно я понимаю, что все должно работать и медленный инсерт не должен тормозить маленькие частые инсерты?

вычесть даты, получить длину для range, сочинить массив дат, потом array join

Добрый вечер, в документации источника внешнего словаря по http: https://clickhouse.yandex/docs/ru/query_language/dicts/external_dicts_dict_sources/#dicts-external_dicts_dict_sources-http написано, что «Если тип размещения словаря cache и complex_key_cache, то ClickHouse запрашивает необходимые ключи, отправляя запрос методом POST» Можете пожалуйста разъяснить этот момент поподробнее, сейчас сделал внешний словарь на http сервер, и при его использовании на сервер приходит пустой POST запрос. <yandex> <dictionary> <name>ext_test</name> <source> <http> <url>http://localhost/dict.php</url> <format>TabSeparated</format> </http> </source> <layout> <cache> <size_in_cells>10000</size_in_cells> </cache> </layout> <structure> <id> <name>ip</name> </id> <attribute> <name>city_id</name> <type>UInt64</type> <null_value>0</null_value> </attribute> </structure> <lifetime>3600</lifetime> </dictionary> </yandex> select toUInt64(ip),dictGetUInt64('ext_test','city_id',toUInt64(ip)) city_id FROM test.test where hour = 426517 LIMIT 10

да, настройки в SET влияют только на сессию. Инсерты не дешевы (в плане диска и процессора) поэтому во время больших инсертов всё может немного замедляться.

Возможно дело в http сервере и в том что он не понимает Transfer-Encoding: chunked

а как узнать, прошли бакграунд мержи в AggregatedMT или нет?

А зачем это знать? В таблице system.parts смотреть сколько партов. Но до конца оно может никогда не смержится, не обязан.

Может в MV строк столько же сколько в оригинальной таблице?

Тогда вам этот MV не нужен. Вот если строк будет раз в 1000 меньше.