Есть интеграция с mysql или по jdbc где можете подсунуть любую реляционную бд где будете  формировать что нужно и уже анализировать нужные данные в CH

Идеология ... clickhouse должен быть ))))

Финальная табличка:
CREATE TABLE gpslogm (
 unixtime UInt64,
   client_id   UInt64,
   managers_id   Array(UInt64)
 gps_lon Float64
 gps_lan Float64
 gps_time Uint64
 server_date Date
)
ENGINE=MergeTree
PARTITION BY toYYYYMM(server_date)
ORDER BY=(unixtime,managers_id)

CREATE TABLE gpslog AS gpslogm ENGINE = Buffer(default, gpslogm, 16, 2, 10, 1000, 10000, 100000, 1000000)

Вводные данные:
Клиенты (пусть будет 100 000) присылают в течении 2 минут минимум по 1 логу gps координат. (833 в секунду) каждый клиент отбрабатывается в отдельном потоке с отдельным INSERT

Менеджеры (пусть будет 50 000) один раз в 10 минут считывают адресованные им свежии логи клиентов (83 в секунду) по запросу:
SELECT * FROM gpslog WHERE has(managers,1111222233330999) AND unixtime > 10282376867

Администратор один раз в час делает выборку всех точек которые находятся в заданном радиусе в определенном промежутки времени (gps_time).

Данные старше трех месяцев из таблицы удаляются (server_date для партиционирования)

Вопрос:
1. Можно ли использовать таблицу типа Buffer в данном контексте
2. Стоит ли делать партиционироване по дням и изменить запрос SELECT на SELECT * FROM gpslog WHERE has(managers,1111222233330999) AND unixtime > 10282376867 AND server_date > *somedate
4. Что еще необходимо настроить для более быстрой работы (SSD, размер данных не играет определяющею роль)

PARTITION BY toYYYYMM(toDateTime(intDiv(unixtime,1000))
ORDER BY unixtime

в partition нужен unixtime чтобы отсекать партиции при where unixtime >
массив в индексе не нужен, не будет использоваться, только память жрать
ORDER BY unixtime я бы заменил на ORDER BY intDiv(unixtime,1000*60) чтобы сократить размер индекса, но это тестить надо.

SSD не нужеы, если будет рейд из HDD

100 000 клиентов + 50 000 Менеджеров КХ не потянет. Треснет сервер от 150тыс. tcp соединений

они же не одновременные и не на прямую складируют, а через ... а через микросервера на GO

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

да все равно возьмите  clickhouse-bulk или kittenhouse

к остальным будет дефолтный, и когда используете codec, надо писать компрессор тоже, типа CODEC(delta, ZSTD) иначе не будет сжато

текущие параметры в system.columns в show create table

Это понятно, лучше будет. Но на данный момент не более 900 подключений (записей 2-3 строк) в секунду. Buffer разве не справится?

хз, у меня один инсерт в минуту, но сразу 10-20 ГБ

кхкх... RAM??? а какой размер инсерта?? И Buffer можно же ограничить??

а компрессор lz4 есть смысл указывать? Сделал CODEC(T64, LZ4) и сжатые данные показывает даже больше чем когда кодек не применён. Смотрю на колонке Int32

очень странно получилось :)

а сам апп на ГО может буферизовать? тогда не нужен вам буфер будет совсем...

Попробую потестить 900 маленьких инсертов в секунду в Buffer.
UnixNano кстати почти полностью решает вопрос Auto-increment  в моем случае

Финальная табличка:
CREATE TABLE gpslogm (
 unixtime Int64, //UnixNano, exemple: 1594754725906610788
   client_id   Int64,
   managers_id   Array(Int64)
 gps_lon Float64
 gps_lan Float64
 gps_time Int64
)
ENGINE=MergeTree
PARTITION BY toYYYYMM(toDateTime(intDiv(unixtime,1000000000))
ORDER BY unixtime

CREATE TABLE gpslog AS gpslogm ENGINE = Buffer(default, gpslogm, 16, 2, 10, 1000, 10000, 100000, 1000000)

LZ4 default

польза codecа сильно зависит от паттерна данных... у нас было не очень, поэтому осталось дефолт-методом ZSTD(1)