Всем привет, ребята нужен совет - есть условная табличка на 30

Question

Всем привет, ребята нужен совет - есть условная табличка на 30

полей и 1 млрд записей
- подразумевается активный поиск по 15 полям

какие есть варианты чтоб поиск по этим полям занимал менее 1-2 секунды (делать все 15 полей индексируемыми ?) и сколько под такой объем данных нужно ram ?

#backend #clickhouse #database #devops #programming #russian

0

27.05.2021

14 ответов

8 просмотров

Стас Автор вопроса

Otta Alluba
в CH нет возможности просто взять и навесить индек...

я это и сделал... 1 млрд записей, поиск по не индексному полю 73 секунды в среднем

0

27.05.2021

Otta Alluba

Стас
я это и сделал... 1 млрд записей, поиск по не инде...

если у вас запрсоы WHERE x = y, то я бы потестил еще другие базы, касандра там и тд ) Там хоть классик индексов можно действительон навесить. Есть правда возможносчть и все эти поля в 1 ключ засунуть в CH, но скорей всего будет ерунда. Ну либо копии, если данные хорошо жмутся.

0

27.05.2021

Yuran

Какого рода данные? В любом случае зачастую ClickHouse сжимает данные в несколько раз, но сильно зависит от сортировки и прочего. Для более-менее простых типов данных (например, Date, UInt16 и т.д.) на среднем 24-ядерном (12 физических ядер) Xeon скорость полного сканирования может быть порядка 4-6 млрд записей в секунду. То есть для простых типов полный скан может быть весьма быстрым, если выбирать только нужные колонки, или засовывать условие в PREWHERE для предварительной фильтрации блоков целиком, если результатов ожидается немного. По крайней мере на ClickHouse, как по мне, индексировать все колонки совершенно бессмысленно, он для этого не предназначен: индексирование обычно предполагает размещение данных в другом порядке, чем в исходной таблице, а если индексированы все колонки, то никакого единого порядка данных не будет, и неясно, что здесь ClickHouse тогда может предложить как колоночная база.

0

27.05.2021

Стас Автор вопроса

Yuran
Какого рода данные? В любом случае зачастую ClickH...

большая часть данных именно String

0

27.05.2021

Yuran

Стас
большая часть данных именно String

Насколько они уникальные? Если различных значений, скажем, несколько миллионов или меньше, можете попробовать LowCardinality(String)

0

27.05.2021

Стас Автор вопроса

Yuran
Насколько они уникальные? Если различных значений,...

например это могут быть ссылки какие то длинной от 20 символов до 120 можно было бы как то к md5 их привести, но нужен поиск и по частичному совпадению

0

27.05.2021

Yuran

Стас
например это могут быть ссылки какие то длинной от...

Можно вынести какую-то часть URL в отдельную колонку с LowCardinality, и ускорять поиск по ней таким образом

0

27.05.2021

Yuran

Стас
например это могут быть ссылки какие то длинной от...

А искать нужно всегда только по одной колонке, или фильтрация нужна по любым комбинациям? Есть ли какие-то фиксированные аргументы, например диапазон дат или что-нибудь такое, что может помочь снизить диапазон просматриваемых данных? Первичный ключ Вам всё равно нужно выбрать и он ускоряет выборку очень существенно

0

27.05.2021

Стас Автор вопроса

Yuran
А искать нужно всегда только по одной колонке, или...

в том то и дело, что поиск может быть как по 1 колонке так и по 15 как с диапазоном так и без и вот в случае без диапазона дат и поиск по одной текстовой колонке, занимает секунд 70

0

27.05.2021

Yuran

Стас
в том то и дело, что поиск может быть как по 1 кол...

Ну, в целом, ничего удивительного 🙂

0

27.05.2021

Akim

Посмотрите в сторону материализованных представлений. А в общем, как уже заметили выше, это хорошо подобраная индексация и партиционирование, но оно не всегда решит вопрос времени выполнения, если есть большое сканирование данных, например всякое match, like, - здесь приходит на помощь MATERIALIZED VIEW.

0

27.05.2021

Стас Автор вопроса

Akim
Посмотрите в сторону материализованных представлен...

спасибо, читаю про MATERIALIZED VIEW, возможно это поможет, я попробую

0

27.05.2021

Akim

Стас
спасибо, читаю про MATERIALIZED VIEW, возможно это...

Вот для примера, приблизительно похожие данные по своей сущности в "сырой" таблице. Наша задача - строить по ним метрики, на основе нескольких полей с фильтрацией WHERE ... like .., match ..., там есть и индексируемые поля и неиндексируемые. Для каждого такого потенциально тяжелого запроса или схожих по типу запросов - создается адаптированный MV. В результате из 45 секунд запроса, получаем менее секунды. Сразу можно заметить, сколько в итоге данных читается из "сырой" таблицы и уже из агрегированного и фильтрованного MV. В общем и целом сама сырая таблица занимает 6.81 billion данных, а один из её MV 508.97 thousand, что упрощает выборку. Сырая таблица в сжатом виде на диске занимает 300GB, MV занимает порядка 1GB из тех же данных, но только с нужными аггрегациями. Т.е. порядка 0.33% от основной таблицы. При создании MV обратите внимание на опцию POPULATE, чтобы наполнить MV уже существующими данными. Длительность создания MV с POPULATE = времени выполнения такого же запроса AS SELECT из сырой таблицы.

0

27.05.2021

Otta Alluba · Accepted Answer

в CH нет возможности просто взять и навесить индексов сколько хочется. Индекс грубо говоря 1 возможен только. и еще рядом 14 копий данных в каждой свой индекс ) Я бы начал с теста, залил примерно данные и посмотрел сколько сек сейчас оно выдает.

184 похожих чатов

Всем привет, ребята нужен совет - есть условная табличка на 30

14 ответов

Похожие вопросы