Телеграмм чат группы clickhouse

лимит действует после сортировки

14:48пожаловаться #1

DT

Всем привет!

Есть такая таблица ~ (148kk+ rows)

CREATE TABLE test_table (
  `_id` String,
  `title` String,
  `p1` Int64,
  INDEX title_ngram_index title TYPE ngrambf_v1(3, 10240, 1, 0) GRANULARITY 1
) ENGINE = ReplacingMergeTree() PARTITION BY substring(_id, 1, 1)
ORDER BY
  (_id) SETTINGS index_granularity = 8192


Делаю из нее выборку 

WITH
    2 AS distance,
    ['Bost'] AS pattern,
    multiSearchFirstPositionCaseInsensitive(title, pattern) AS mSearchPosCaseInsensitive,
    ngramSearchCaseInsensitive(title, pattern[1]) AS ngSearchCaseInsensitive
SELECT
    title,
    mSearchPosCaseInsensitive,
    ngSearchCaseInsensitive
FROM test_table
WHERE multiFuzzyMatchAny(title, distance, pattern)
limit 25

запрос читает 700к строк

но как только появляется order by, то сразу количество строк становится равным размеру таблицы
в какую сторону копать?

если эта сортировка всегда есть и так важна можно ее пихнуть в начало ORDER BY

14:49пожаловаться #2

D

вопрос в том что если сам запрос без сортировки выдает 700к строк, то почему после этого для сортировки он перечитывает всю таблицу?

14:50пожаловаться #3

SC

потому что без сортировки он просто останавливается при достижении лимита

14:51пожаловаться #4

DT

вопрос в том что если сам запрос без сортировки выдает 700к строк, то почему после этого для сортировки он перечитывает всю таблицу?

потому что взять какие попало 700к и взять оттуда 25 можно
А если тебе нужно отсортировать, то взять какие попало не получится

14:51пожаловаться #5

D

ну там не какие попало) которые удовлетворяют условию WHERE multiFuzzyMatchAny(title, distance, pattern)

окей тогда вот такой пример:

select 
*
from (
WITH
    2 AS distance,
    ['Bost'] AS pattern,
    multiSearchFirstPositionCaseInsensitive(title, pattern) AS mSearchPosCaseInsensitive,
    ngramSearchCaseInsensitive(title, pattern[1]) AS ngSearchCaseInsensitive
SELECT
    title,
    mSearchPosCaseInsensitive,
    ngSearchCaseInsensitive
FROM test_table
WHERE multiFuzzyMatchAny(title, distance, pattern)
)
order by …

14:55пожаловаться #6

D

ааа понял
вы про то говорите что с лимитом он просто в разнобой накидал первые попавшиеся и остановил дальнейшее чтение

14:56пожаловаться #7

SC

да

14:56пожаловаться #8

D

на что обратить внимание чтобы сократить объем читаемых данных?

14:59пожаловаться #9

DT

речь идет о ORDER BY таблицы

14:59пожаловаться #10

DT

Переслано от Dmitry Titov

если эта сортировка всегда есть и так важна можно ее пихнуть в начало ORDER BY

14:59пожаловаться #11

D

а если это динамическая сортировка?
подобие оценки релативности данных elasticsearch сделанный через коленку с помощью multiSearchFirstPositionCaseInsensitive и ngramSearchCaseInsensitive

15:01пожаловаться #12

DT

а если это динамическая сортировка?
подобие оценки релативности данных elasticsearch сделанный через коленку с помощью multiSearchFirstPositionCaseInsensitive и ngramSearchCaseInsensitive

тогда только страдать

15:02пожаловаться #13

D

понял спасибо 👌

15:02пожаловаться #14

SC

можно ещё предагрегировать через MaterializedView если есть возможность

15:02пожаловаться #15

DT

На самом деле люди делали через дополнительную табилцу подобие реверс индекса, но то налюбителя

15:03пожаловаться #16

D

про это вкурсе, но когда у тебя pattern меняется каждую секунду, а записей более 300кк то это не вариант 🙁
данные в temp таблицу будут заливаться дольше, чем перестроить юзеру запрос

15:04пожаловаться #17

DT

про это вкурсе, но когда у тебя pattern меняется каждую секунду, а записей более 300кк то это не вариант 🙁
данные в temp таблицу будут заливаться дольше, чем перестроить юзеру запрос

ну для реверс индекса это не важно, кмк

15:05пожаловаться #18

D

а есть где-то более подробная дока по скип индексам, чем https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-data_skipping-indexes ?
потому что хотябы для ngrambf_v1(3, 10240, 1, 0) не могу найти описание его параметров

15:11пожаловаться #19

DT

а есть где-то более подробная дока по скип индексам, чем https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-data_skipping-indexes ?
потому что хотябы для ngrambf_v1(3, 10240, 1, 0) не могу найти описание его параметров

Обычно они делают только хуже. поэтому ими не часто пользуются