такого вида:
CREATE DICTIONARY IF NOT EXISTS dict_test (
A String,
B String,
C String
)
PRIMARY KEY A, B
SOURCE(CLICKHOUSE(table 'some_view'))
LAYOUT(COMPLEX_KEY_HASHED())
LIFETIME(1);
Что происходит когда я делаю селект вроде такого?
SELECT * FROM dict_test WHERE A = 'SOME_VALUE_A' AND B = 'SOME_VALUE_B';
Запрос будет идти в память словаря как tuple('SOME_VALUE_A', 'SOME_VALUE_B') по ключу?
А так фуллскан?
SELECT * FROM dict_test WHERE A = 'SOME_VALUE';
Или чтение будет из some_view?
селекты из словаря работают медленно, они больше для дебага. лучше ограничиться dictGet*
lifetime очень маленький каждую секуду будет SELECT A,B,C FROM some_view происходить в отдельную область памяти, а потом атомарный replace SELECT * FROM dict_test это кажется всегда фуллскан по представлению dict_test памяти есть отдельно dictGet для словарей, там никакого fullscan конечно нет... проверять надо через SET send_logs_level='trace'; SELECT * FROM dict_test WHERE A = 'SOME_VALUE_A' AND B = 'SOME_VALUE_B'
Да я понимаю. Я хотел результат аггрегации + несклько джоинов складывать в такой как бы кэш и использовать его при выборках. Спасибо, посмотрю что в трейсах происходит
just fyi на запросы вида SELECT * FROM dict_test WHERE A = 'SOME_VALUE_A' AND B = 'SOME_VALUE_B' идет фуллскан.
ну как бы тут такой момент что это фуллскан по памяти, так что оно достаточно быстро должно быть
да это понятно, но почему-то ожидал немного другого поведения. Пока сойдет, но позже буду думать как такие кэши сделать, что бы за единицу ходить.
ну погодите, у вас есть по факту хешмап в памяти чтобы отфильтровать его надо как минимум пройтись по всем ключам получить атрибуты и сравнить их PRIMARY KEY для словаря, это выражение, которое используется как ключ хешпапа... PRIMARY KEYи т.п. для MergrTree это все остается внутри SOURCE() и словарь про это ничего не знает
Это очень медленный фулскан, потому что там каждая колонка в своей хеш-таблице, и эти хеш-таблицы не предназначены для прохода последовательно, у меня есть тест где в 300 раз запрос медленее к словарю чем к мержтри таблице
Обсуждают сегодня