Подскажите, пожалуйста, куда копать.
CH версии 19.15.3.6. (16 Гб RAM)
Есть 2 таблицы, движок MergeTree.
В каждой по 150 колонок, в основном String. В левой 5.5 млн записей. В правой 120 000.
Пытаюсь вставить в левую таблицу записи из правой, которых нет в левой таблицы.
Джоин идет по хеш-ключу - тип поля FixedString(20)
При попытке выполнения запроса ClickHouse выедает 9 Гб и запрос падает (стоит ограничение на запрос)
При этом ClickHouse не освобождает память на сервере.
При повторной попытке выполнить запрос он выедает оставшуюся память, сервер падает и перезагружается.
Вот сам селект.
INSERT INTO db1.order_hash
SELECT r.*
FROM db1.order_hash l
RIGHT JOIN
   (SELECT *
   FROM db2.order_source_hash) r
   ON l.hashKey = r.hashKey            
WHERE 1=1
   AND empty(l.hashKey)

В правом запросе точно 120 тыс возвращается?

И какой размер таблицы правой, все вместе колонок сколько

Для колоночной базы нет хуже запроса с *. Вам точно нужен КХ для такого?

правая таблица возвращает 120 тыс, если выполнить подзапрос. Вот размер правой таблицы (в мб)

У меня вставка идет пачками - при вставке проверяется, что записей с таким хешом ранее не было. Поля нужны все, поэтому и *.

Привет. Есть ли в кх настройка на ограничение количества одновременных запросов для пользователя?

Это я понял. Вопрос - зачем вам для запросов с * нужен КХ? Что вы дальше будете со всеми колонками делать?

Мы парсим разные документы и раскладываем данные по колонкам. Потом строим отчеты для клиентов - там наименования, суммы по каждой позиции и т.п. Все эти данные в итоге хранятся в очищенном виде с правильными типами - не String. В моем случае, который я скинул выше - я пишу в область сырых данных - 'как есть', чтобы в любой момент можно было из сырых данных перезагрузить данные в ядре хранилища

Коллеги, добрый день! Я BI-специалист и мои отвечающие за  DWH коллеги уверяют меня, что в ClickHouse нет настройки последовательного исполнения запросов. Что он может только одновременно, это правда?

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

это размер на диске... попробуйте ваш запрос так - сколько памяти съест?

SELECT r.hashKey
FROM db1.order_hash l
LEFT JOIN 
    (SELECT hashKey
    FROM db2.order_source_hash) r
    ON l.hashKey = r.hashKey            
WHERE 1=1
    AND empty(l.hashKey)

Попробуйте в основной запрос добавить некое партиционирование, например по дате. И пачками переливать данные из сырых в основное

А так во всех базах? Раньше работала с Postgre + MySQL - с такой проблемой не сталкивалась

ну в клиппере и фоксбейз тоже так например =)
а вообще postgre/mysql - oltp базы
можете взять вертику - там есть шелл код как процедуры

Правда. Можете посмотреть в сторону https://github.com/Vertamedia/chproxy

SELECT r.hashKey
FROM db1.order_hash l
LEFT JOIN 
    (SELECT hashKey
    FROM db2.order_source_hash) r
    ON l.hashKey = r.hashKey            
WHERE 1=1
    AND empty(l.hashKey)

стоп... у вас чуть раньше был лефт join, теперь right

Спасибо большое! Надеюсь, нам это поможет.

В пг без внешних инструментов тоже можно делать сколько угодно (до max conn) запросов одновременно.

Ребят, а как можно ограничить количество потоков на скачивание партов с реплик?