у нас типа такого

таблица типа data (rid UInt32, kid UInt32, deleted UInt8, dataa, datab,datac, еще 20 параметров, ver DateTime DEFAULT now())
это данные для некой сущности с определенным rid
когда надо получить что то про эти данные, выбираем

select kid, argMax(dataa, ver), argMax(datab, ver)
from data
where rid=XXX
group by kid
having argMax(deleted,ver)=0

соответственно в вашем случае я бы задал еще какую то сортировку и шагал limit 20, 500

но у нас в таких таблицах лежит не супер много данных, прямо сейчас - 2 066 507 206 записей неравномерно разложенные по 2 711rid

Подскажите плз. Есть таблица (a Date, b Value). Как в кликхаусе правильно выбрать строку вида (a Date, b Value, c Value) где с - значение в той же таблице, но из строки в которой a Date меньше, допустим, на 30 минут?

Народ, подскажите нубу, начинающему познавать clickhouse.


Делаю поиск по координатам (geospatial)

Структура таблицы:

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'

Направьте пожалуйста, как такое можно оптимизировать?
Возможно для этого как то подойдут "Индексы пропуска данных"?
В документации как то не подробно описано, пока не разобрался толком в них.

Всем привет!
Столкнулись со следующей ошибкой после обновления на 19.17.4.11:
Code: 171, e.displayText() = DB::Exception: Cannot convert column log_type because it is non constant in source stream but must be constant in result (version 19.17.4.11 (official build))

SELECT делаем в VIEW, в которой log_type - это поле (задано как 'somestr' AS log_type). В SELECT тоже просто как одно из полей указываем

Коллеги, привет. Хотелось бы избежать join при запросе. Пока проблемы нет. Еще Проектируем структуру.
Есть большой лог с инфой об активности пользователей, часть данных будет заноситься сразу в clickhouse, а другая часть (там длительная обработка до суток) должна потом дополнить тот же лог. Пока в голове две отдельные таблицы с оперативной и неоперативной инфой, а затем join при select, но хотелось бы этого избежать.

может быть можно использовать словари? или сущностей прям оч много?

может скажу глупость, но можете попробовать создать одну таблицу в которую будете записывать записи а потом обновлять (дополнять) их когда остальная часть информации будет приходить. тогда можно будет избежать джоина

Не много

ну или да, как вариант - одна таблица для уже готовых строк (к которым приехали все данные), вторая - временный буфер на период ожидания, туда пишем не полные данные и дропаем партиции по мере подвоза досчитанной статистики и переноса данных в постоянное хранилище

если укладывается в механику словарей, то совсем отлично, они крутые

при записи добавить еще поле geohash, и по нему делать фильтрацию предварительную :)

redis вроде похожий подход использует

ну это наверно получится шило на мыло 🙂

Читать нужно сразу все, там где пока нет данных - не страшно

а как искать по столбцу, который не учавствует в primary key, как uuid например в моей ситуации?
Или это не решаемая задачи и об этом можно забыть?

чтобы читать все - наверно можно сделать union all или таблицу с движком мердж https://clickhouse.yandex/docs/ru/operations/table_engines/merge/

а какие у вас объемы, и что для вас «тормозит»?