привет, а подскажите плз, может кто из сорцов собирает, у меня ругается на config_opt_safety_checks, то что не объявлено
v20.3.12.112-stable
где задается JEMALLOC_OPT_SAFETY_CHECKS? через env?

вам стоит понять простую вещь. ZK in-memory db. На диске хранится только бекап. При старте ZK восстанавливает свое состояние в памяти читая последний снепшот + логи после снепшота.

с jemalloc 5.1 собирается

мне казалось, что эти настройки должны очищать логи и снэпшоты?

autopurge.snapRetainCount=10
autopurge.purgeInteval=1

то есть, удалять логи все равно надо вручную, с помощтю zkCleanup.sh?

Доброго, коллеги! Я так понимаю неяндексовые боты спят? У меня вопрос про индексы, если кто сможет помочь, то я буду благодарен. Вопрос: у меня есть примари ключ, который по умолчанию из секции ордер бай. Есть запросы, которые включают еще пару полей типа инт64 (хэш 63 бита) и короткий инт с двумя значениями. Здешние кулибины предлагают блум фильтер с примари ключем и этими двумя полями и гранулярностьб в 1. Я же пользуясь подходами элементарной логики и интуиции предпологаю, что достаточно добавить на каждое дополнительное поле по индексу типа минмакса и это будет более оптимально с точки зрения использования ресурсов и скорости. Помогите понять ошибаюсь ли я и где?

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

SELECT get_time, value
FROM `table` 
 PREWHERE(source_id, get_time) IN 
( 
SELECT source_id, max(get_time) FROM `table` 
PREWHERE source_id=333415 AND get_time<='2020-06-26 09:00:00' 
 GROUP BY source_id 
UNION ALL 
SELECT source_id, min(get_time) FROM `table` 
PREWHERE source_id=333415 AND get_time>'2020-06-26 09:00:00'
 GROUP BY source_id 
)

к такой таблице условно (колонок больше конечно)

CREATE TABLE `table` ( 
  `source_id` UInt32,
  `get_time` DateTime ,
  `value` Float64
)  ENGINE = MergeTree()
PARTITION BY toYYYYMM(get_time)
ORDER BY (source_id,get_time)

т.е. доставание строк до и после некоторого произвольного момента времени
когда запросы одиночные - всё нормально, но стоит дать скажем 100rps (да я понимаю, что это натягивание совы на глобус наверное, но может как-то можно подкрутить)
начинает жрать проц, iops мало при этом жрёт, LA зашкаливает и всё раком становится
4.5 млрд строк таблица/100Gb если без тюнинга кодеков на колонках

а вам точно КХ нужен, это противоестественное использование, КХ не для точечных запросов, может postgresql или с* ?

да это не точечные запросы. Там несколько десятков миллиардов линий. И надо делать выборку. Просто есть два типа запросов, в котором есть первичный ключ и второй где его дополняют два столбца. Вот поэтому интересуюсь индексами чтобы сделать оптимально...

ожидаемое поведение, все так и должно быть.


SELECT source_id, max(get_time) FROM table -- КХ не умеет max брать из индекса, если вы на это рассчитывали. Ну индекс sparsed поэтому ... .аааа

можно хранить max уже готовый в отдельной таблице

так не знаю я max/min - это для нахождения окружающих некую точку во времени записей. для самой последней я конечно MV сделал.
index granularilty если поменьше выкрутить? не поможет?