не в курсе
просто с т.зрения парадигмы - параметр - это подстановка в "данные" а не в тело запроса
например в where col = %s  

а из какой то мускульной либы для псевдо-униформенности решили их разрешить как %s

оттуда и ползет на вид одинаковое задание в строках но разный физический смысл
* извините - оффтоп

в памяти словари, там до 1-2 миллионов максимум
для таких словарей как у вас
это не словари в таком случае
но есть такая вещь
https://clickhouse.tech/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-layout/#ssd-cache

А если их держать не в MySQL БД, а в ClickHouse?

вы хорошо понимаете что такое "словарь"?

я правильно понимаю что у вас есть потребность в JOIN по двум здоровущим таблицам (миллионы записей) для выборки?

Мигрируем данные из Террадаты (hive) в КХ, гоняя файлы Apache OCR. Как можно оптимизировать процесс? Использовать движок HDFS?

Да я понимаю что такое словарь.
Думал что в зависимости от сорса словаря меняется занимается место в памяти.

И да мне нужно сделать JOIN по двум очень большим таблицам, одна из них более миллиарда записей имеет, а вторая как я уже и говорил 200-300 миллионов

место в памяти не от источника зависит  а от layout
ssd_cache
оптимальный вариант "для очень больших словарей"
https://clickhouse.tech/docs/en/sql-reference/dictionaries/external-dictionaries/external-dicts-dict-layout/#ssd-cache

но слово SSD означает что работать будет более или менее только на нормальном железе

вообще наличие двух больших таблиц, говорит о том, что что-то спроектировано не так

почему данные из меньшей таблицы который такие большие?
что именно там за данные? почему у них такая кардинальность?

почему нельзя обогатить основную таблицу перед вставкой?
или почему нельзя в момент когда данные появляются в "малой" таблице
обогащать данные из основной таблицы вставляя через INSERT INTO ... SELECT в третью таблицу?

вместо JOIN
я бы конечно посоветовал dictGet ... оно более старое и надежное...

Если в 2-х словах, то в большой таблице аналитические данные о пользователе и его предпочтениях.
В этой таблице хранятся основные данные, поэтому она самая большая.
Есть много разных табличек словарей, для расшифровки тех или иных параметров пользователя, все они кроме 1 не очень большие (до 100к).
А есть одна табличка в которой хранятся email-пользователя.

Вместо JOIN используются только dictGet

в последних версиях есть оптимизация JOIN по словарю на базе dictGet, вручную переписывать JOIN-ы (где правой таблицей идет словарь) на dictGet не надо. Если только  знаете какие-то issue, что что-то не работает или работает не так

в перспективе это может быть даже быстрее обычного dictGet - там надо улучшить  работу со словарями, чтобы можно было забирать сразу несколько колонок по ключу

ок,
получается в момент вставки "в основную таблицу" email уже известен
вы эти email потом как анализируете? по доменам разве что? или как то еще?
почему бы не снизить кардинальность и  не вставлять только домены которые спокойно в LowCardinality(String) уложатся... даже если доменов миллионы

Всё немного сложнее, но в целом я для себя нашел ответ, спасибо

Добрый день, кто-нибудь сталкивался с проблемой.
1. Создаю внешний словарь: CREATE DICTIONARY country ( ...  )
       PRIMARY KEY id
       SOURCE(ODBC(table 'country' connection_string 'DSN=dsnname'))
       LAYOUT(HASHED())
       LIFETIME(MIN 300 MAX 360).
2. Создаю таблицу:
create table countrydict (id UInt64, name_ru String, name String, iso String, iso3 String) Engine = Dictionary(country)
3. Если делаю простой селект из этой таблицы, то всё отлично открывается, но если джойню эту таблицу к другой, то сервер падает с ошибкой:
DB::Exception: external dictionary 'country' not found: Cannot attach table countrydict from metadata file

Версия КХ: version 20.4.6.53

а зачем вы таблицу создаете? она не нужна, у словарь не из xml

у вас и так есть эта таблица : country

Понял. Попробую так. Просто на версии 20.3 все ок

Спасибо)

ну баг есть с Engine = Dictionary в 20.4+