словаре с источником postgres значения, которые он не смог найти в pg? А то он возвращает defaultValue или null, и также кэширует его
Паттерн "кэш" обычно не делает различия между положительным и отрицательным ответом от бэка при кэшировании... Оно Вам точно именно в таком виде требуется? Кэш сделан для того, чтобы снять нагрузку с бэка. Тут Вы просите эту нагрузку не снимать. Может кэш совсем отключить тогда?
Суть проблемы вчера описывал, посоветовали использовать словарь с layout cache (понравилось, что делает запросы только по факту промаха кэша). Но вот в этот моменте случилась загвоздка. Основная идея уйти от internal join в материализованном представлении, но хочется быть всегда up to date с таблицей postgres, при этом не нагружать обновлениями hashed словарь каждую секунду
я вижу это как в доп обработчике изменяющем мастер данные в постгресе, который при обновлении сбрасывает кэш в КХ ну т.е. Вы кэш этот выделяете в отдельный компонент на схеме своего приложения/системы и работаете с ним...
и вот ещё для раздумий из документации про обновление справочников: For other sources (ODBC, PostgreSQL, ClickHouse, etc), you can set up a query that will update the dictionaries only if they really changed, rather than each time. To do this, follow these steps: The dictionary table must have a field that always changes when the source data is updated. The settings of the source must specify a query that retrieves the changing field. The ClickHouse server interprets the query result as a row, and if this row has changed relative to its previous state, the dictionary is updated. Specify the query in the <invalidate_query> field in the settings for the source.
Спасибо, читал про это, но пока не сообразил как использовать, так как по сути основная задача это триггерится на вставку новой сущности в postgres, а все примеры именно на обновление сущности. Спасибо, попробую лучше подумать в эту сторону
триггериться на вставку нужно извне. т.е. тот, кто вставил в постгрес сделал запрос на инвалидацию (очистку) кэша. про инвалидейт внутри КХ, то я читаю документацию так: если задан запрос на инвалидацию, то перед обновлением справочника будет выполнен запрос инвалидации. Если результат его будет отличаться от предыдущего, то весь кэш инвалидируется и справочник обновится. В противном случае кэш останется. Про обновление, если Вы про update_field, то это про инвалидацию всего кэша. Если эта настройка есть, то делается не сброс кэша и полное чтение, а запрос на изменённые значения и обновление в справочнике только изменённого.
нет. про update_field не так
простите, не совсем получилось разобраться, что не так про update_field... понятно, что его использование потребляет больше памяти и, наверное понятно, что потребляет больше цпу... что не так в том, что при этом обновляется не весь справочник, а только его часть?
на сколько я понимаю обновляется весь справочник, а вот запрашивается не весь
такого нет насколько я могу судить по доке пока для баз данных есть только ENGINE=Replicated(...
Обсуждают сегодня