docs/en/sql-reference/statements/create/dictionary/lifetime.md
import CloudDetails from '@site/docs/sql-reference/statements/create/dictionary/_snippet_dictionary_in_cloud.md';
ClickHouse periodically updates dictionaries based on the LIFETIME tag (defined in seconds).
LIFETIME is the update interval for fully downloaded dictionaries and the invalidation interval for cached dictionaries.
During updates, the old version of a dictionary can still be queried. Dictionary updates do not block queries, apart from when they load for first use. If an error occurs during an update, the error is written to the server log, and queries can continue using the old version of the dictionary. If a dictionary update is successful, the old version of the dictionary is replaced atomically.
Example of settings:
<CloudDetails /><dictionary>
...
<lifetime>300</lifetime>
...
</dictionary>
or
CREATE DICTIONARY (...)
...
LIFETIME(300)
...
Setting <lifetime>0</lifetime> (LIFETIME(0)) prevents dictionaries from updating.
You can set a time interval for updates, and ClickHouse will choose a uniformly random time within this range. This is necessary in order to distribute the load on the dictionary source when updating on a large number of servers.
Example of settings:
<dictionary>
...
<lifetime>
<min>300</min>
<max>360</max>
</lifetime>
...
</dictionary>
or
LIFETIME(MIN 300 MAX 360)
If <min>0</min> and <max>0</max>, ClickHouse does not reload the dictionary by timeout.
In this case, ClickHouse can reload the dictionary earlier if the dictionary configuration file was changed or the SYSTEM RELOAD DICTIONARY command was executed.
When updating the dictionaries, the ClickHouse server applies different logic depending on the type of source:
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:
<invalidate_query> field in the settings for the source.Example of settings:
<dictionary>
...
<odbc>
...
<invalidate_query>SELECT update_time FROM dictionary_source where id = 1</invalidate_query>
</odbc>
...
</dictionary>
or
...
SOURCE(ODBC(... invalidate_query 'SELECT update_time FROM dictionary_source where id = 1'))
...
For Cache, ComplexKeyCache, SSDCache, and SSDComplexKeyCache dictionaries both synchronous and asynchronous updates are supported.
It is also possible for Flat, Hashed, HashedArray, ComplexKeyHashed dictionaries to only request data that was changed after the previous update. If update_field is specified as part of the dictionary source configuration, value of the previous update time in seconds will be added to the data request. Depends on source type (Executable, HTTP, MySQL, PostgreSQL, ClickHouse, or ODBC) different logic will be applied to update_field before request data from an external source.
update_field will be added as a query parameter with the last update time as the parameter value.update_field will be added as an executable script argument with the last update time as the argument value.WHERE, where update_field is compared as greater or equal with the last update time.
WHERE-condition is checked at the highest level of the SQL-Query. Alternatively, the condition can be checked in any other WHERE-clause within the query using the {condition}-keyword. Example:
...
SOURCE(CLICKHOUSE(...
update_field 'added_time'
QUERY '
SELECT my_arr.1 AS x, my_arr.2 AS y, creation_time
FROM (
SELECT arrayZip(x_arr, y_arr) AS my_arr, creation_time
FROM dictionary_source
WHERE {condition}
)'
))
...
If update_field option is set, additional option update_lag can be set. Value of update_lag option is subtracted from previous update time before request updated data.
Example of settings:
<dictionary>
...
<clickhouse>
...
<update_field>added_time</update_field>
<update_lag>15</update_lag>
</clickhouse>
...
</dictionary>
or
...
SOURCE(CLICKHOUSE(... update_field 'added_time' update_lag 15))
...