сейчас 1 миллиард тестовых данных, отрабатывает примерно за 10 сек.
Планируются данных около триллиона

я сейчас выполнил запрос как у вас на 2млрд записей - 1.5 секунды

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

у вас заметно лучше

а ну у вас получается еще и таблица не распределнная судая по коду

с условиями по координатам у меня тоже быстро, тут проблем нет.
Тормозит такое, так как полный фуллскан:
SELECT COUNT(*) FROM log WHERE uuid='4c7210c1-45fa-4eac-aef5-7bf1c180bd07'

count() по пользователю - 1сек

у меня только пользователи интовые

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

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

h3 может помочь

min(created_date) AS min_created_date,

Так и получится, если поле учавствет в сортировке

у меня данные шардируются по пользователю, так как шарда 3шт, то видимо самый пессимистичный сценарий - это 333 секунды)
а запросы к базе по id пользователя будут стандартные? если да, то может имеет смысл посмотреть в сторону MatView?

Немного сузил проблему по Cannot convert column log_type because it is non constant in source stream but must be constant in result.

Не получается сделать SELECT-ы с указанием констант только для движка Merge.

SELECT
   time_local,
   response_code,
   'a' AS log_type
FROM test_merge
LIMIT 1

Received exception from server (version 19.17.4):
Code: 171. DB::Exception: Received from  DB::Exception: Cannot convert column log_type because it is non constant in source stream but must be constant in result.


SELECT
   time_local,
   response_code,
   'a' AS log_type
FROM test_distributed_v1
LIMIT 1

┌──────────time_local─┬─response_code─┬─log_type─┐
│ 2019-10-31 07:00:05 │           200 │ a        │
└─────────────────────┴───────────────┴──────────┘

Merge таблица создана как:
CREATE TABLE default.test_merge ON CLUSTER logs AS default.test_distributed_v1
ENGINE = Merge(default, '^test_distributed_v');

Похоже на баг? Или я что-то не так делаю.....

> а запросы к базе по id пользователя будут стандартные? если да, то может имеет смысл посмотреть в сторону MatView?

да, периодически нужно делать такие запросы.

А MaterializedView решает эту проблему?
Я думал это что то типа сохраненного запроса, как в mysql view

MatView материализует данные при инсертах, это обычный view просто сохраняет запрос, а матвью физических их запишет в таблицу в нужном вам виде

ок, буду читать разбираться, пока не понял 🙂
Спасибо

Спасибо

тип атрибута LowCardinality(String) для hashed словаря можно указывать? если да - имеет ли смысл?

Доброго утра. Я наткнулся на проблему, что date_time_input_format = 'best_effort' почему-то не помогает распарсить валидный iso8601 2019-12-12T10:32:32+01:00. Кто-то решал подобную проблему?

SELECT toDateTime('2019-12-12T10:32:32+01:00')
Code: 6. DB::Exception: Received from localhost:9000. DB::Exception: Cannot parse string '2019-12-12T10:32:32+01:00' as DateTime: syntax error at position 19 (parsed just '2019-12-12T10:32:32').

если убрать +01:00, то работает