doc

doc/reference_en.html

@@ -6332,6 +6332,25 @@ The dictionary config file has the following format:
 			</clickhouse>
 			<!- - If the address is similar to localhost, the request is made without network interaction. For fault tolerance, you can create a Distributed table on localhost and enter it. - ->
 			-->
+
+			<!-- or the source is a executable. If layout.complex_key_cache - list of needed keys will be written in STDIN of program -->
+			<executable>
+				<!-- Path on the local file system or name located in one of env PATH dirs. -->
+				<path>cat /opt/dictionaries/os.tsv</path>
+				<!-- Which format to use for reading/writing stream. -->
+				<format>TabSeparated</format>
+			</executable>
+
+			<!-- or the source is a http server. If layout.complex_key_cache - list of needed keys will be sent as POST  -->
+			<http>
+				<!-- Host. -->
+				<host>::1</host>
+				<port>80</port>
+				<path>/os.tsv</path>
+				<!-- Which format to use for reading answer and making POST. -->
+				<format>TabSeparated</format>
+			</http>
+
 		</source>
 
 		<!-- Update interval for fully loaded dictionaries. 0 - never update. -->
@@ -6397,7 +6416,7 @@ This is the most effective method. It works if all keys are smaller than 500,000
 This method is slightly less effective than the first one. The dictionary is also loaded to RAM in its entirety, and can contain any number of items with any identifiers. In practice, it makes sense to use up to tens of millions of items, while there is enough RAM.
 All types of sources are supported. When updating, data (from a file or from a table) is read in its entirety.
 
-3. %%cache%% - This is the least effective method. It is appropriate if the dictionary doesn't fit in RAM. It is a cache of a fixed number of cells, where frequently-used data can be located. MySQL and ClickHouse sources are supported, but file sources are not supported. When searching a dictionary, the cache is searched first. For each data block, all keys not found in the cache (or expired keys) are collected in a package, which is sent to the source with the query %%SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...)%%. The received data is then written to the cache.
+3. %%cache%% - This is the least effective method. It is appropriate if the dictionary doesn't fit in RAM. It is a cache of a fixed number of cells, where frequently-used data can be located. MySQL, ClickHouse, executable, http sources are supported, but file sources are not supported. When searching a dictionary, the cache is searched first. For each data block, all keys not found in the cache (or expired keys) are collected in a package, which is sent to the source with the query %%SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...)%%. The received data is then written to the cache.
 
 We recommend using the flat method when possible, or hashed. The speed of the dictionaries is impeccable with this type of memory storage.
 

doc/reference_ru.html

@@ -6463,6 +6463,25 @@ regions_names_*.txt: TabSeparated (без заголовка), столбцы:
             <!- - Если адрес похож на localhost, то запрос будет идти без сетевого взаимодействия.
                   Для отказоустойчивости, вы можете создать Distributed таблицу на localhost и прописать её. - ->
             -->
+
+            <!-- или источник - исполняемый файл. Если layout.cache - список нужных ключей будет записан в поток STDIN программы -->
+            <executable>
+                <!-- Путь или имя программы (если директория есть в переменной окружения PATH) и параметры -->
+                <path>cat /opt/dictionaries/os.tsv</path>
+                <!-- С помощью какого формата понимать вывод и формировать список ключей. -->
+                <format>TabSeparated</format>
+            </executable>
+
+            <!-- или источник - http сервер. Если layout.cache - список нужных ключей будет послан как POST запрос -->
+            <http>
+                <!-- Host. -->
+                <host>::1</host>
+                <port>80</port>
+                <path>/os.tsv</path>
+                <!-- С помощью какого формата понимать ответ и формировать список ключей. -->
+                <format>TabSeparated</format>
+            </http>
+
         </source>
 
         <!-- Периодичность обновления для полностью загружаемых словарей. 0 - никогда не обновлять. -->
@@ -6537,7 +6556,7 @@ regions_names_*.txt: TabSeparated (без заголовка), столбцы:
 Слегка менее эффективный способ. Словарь тоже загружается в оперативку целиком, и может содержать произвольное количество элементов с произвольными идентификаторами. На практике, имеет смысл использовать до десятков миллионов элементов, пока хватает оперативки.
 Поддерживаются все виды источников. При обновлении, данные (из файла, из таблицы) читаются целиком.
 
-3. %%cache%% - наименее эффективный способ. Подходит, если словарь не помещается в оперативку. Представляет собой кэш из фиксированного количества ячеек, в которых могут быть расположены часто используемые данные. Поддерживается источник MySQL и ClickHouse; источник-файл не поддерживается. При поиске в словаре, сначала просматривается кэш. На каждый блок данных, все не найденные в кэше ключи (или устаревшие ключи) собираются в пачку, и с этой пачкой делается запрос к источнику вида %%SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...)%%. Затем полученные данные записываются в кэш.
+3. %%cache%% - наименее эффективный способ. Подходит, если словарь не помещается в оперативку. Представляет собой кэш из фиксированного количества ячеек, в которых могут быть расположены часто используемые данные. Поддерживается источники MySQL, ClickHouse, executable, http; источник-файл не поддерживается. При поиске в словаре, сначала просматривается кэш. На каждый блок данных, все не найденные в кэше ключи (или устаревшие ключи) собираются в пачку, и с этой пачкой делается запрос к источнику вида %%SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...)%%. Затем полученные данные записываются в кэш.
 
 4. %%range_hashed%%