таблицы:
CREATE TABLE log (
uuid UUID,
timestamp DateTime,
longitude Float64,
latitude Float64
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(timestamp)
ORDER BY (longitude, latitude)
Запрос:
SELECT *
FROM log
WHERE (longitude >= $minLon) AND (longitude <= $maxLon) AND (latitude >= $minLat) AND (latitude <= $maxLat)
AND (greatCircleDistance(longitude, latitude, 35.18694, 47.7442) <= $radius)
ORDER BY timestamp ASC
LIMIT 10
Сначала тормозило если использовать в WHERE только greatCircleDistance, потом догадался, что нужно сделать индекс на longitude, latitude и в WHERE допольнительно по этим полям фильтровать.
Вопросы:
1) Возможно есть какой то более родной способ оптимизировать скорость greatCircleDistance, так что бы не фильтровать по полям longitude, latitude, или и так норм?
2) Мне так же иногда нужно делать выборки по uuid и там получется полный скан и тормозит.
SELECT COUNT(*) FROM log WHERE uuid='4c7210c1-45fa-4eac-aef5-7bf1c180bd07'
Направьте пожалуйста, как такое можно оптимизировать?
Возможно для этого как то подойдут "Индексы пропуска данных"?
В документации как то не подробно описано, пока не разобрался толком в них.
при записи добавить еще поле geohash, и по нему делать фильтрацию предварительную :)
а какие у вас объемы, и что для вас «тормозит»?
сделать вторую таблицу отсортированную по uuid (да положить все данные еще раз) (можно с помощью MV) посмотрите на geoToH3 , уберовские шестиугольники h3 (для первой части)
а что, сильно тормозит? сколько данных может MergeTree вместо Log? можете также попробовать что-то типа колонок с UTM зонами или Slippy Maps (tiles) сделать и по ним дополнительно фильтровать greatCircleDistance кстати недавно в 3 раза ускорили, правда вроде бы еще не в релизе (в changeloge нет) но в мастере https://github.com/ClickHouse/ClickHouse/pull/7307
Обсуждают сегодня