но с партициями по YYYYMMDD
Если сделать запрос по датам с ключом --force_data_skipping_indices, то видим что индекс не используется ни в одном из двух.
Если использовать --force_primary_key, то видно что при партицировании по дням, примари кей то же не заюзан.
Вопрос: если нужен поиск данных по дням (и данные в запросе всегда только внутри дня), то как максимально оптимизировать таблицу?
Даст ли что-то дополнительное создание индекса на DateTime (если данные надо выбирать в интервале 1мин к примеру)?
сколько данных за день в сжатых байтах на диске получаться будет?
Если в целом по всем столбцам, то 1-2гиг в сутки
как часто в течении дня данные вставляете?
ну тогда у вас будет толпа мелких партов размером от 0.5 до 3 мегабайт которые clickhouse будет сливать данные вставляются монотонно или прошлый период тоже возможен? если EventTime будет в ORDER BY или в PRIMARY KEY и вставка монотонная (вставляются только данные новых периодов) то парты будет проще пропускать даже когда у вас партицирование по дням и сканировать их будет проще потому что в *.mrk файлах засечек EventTime будет
если савсем грубо то я так понимаю процесс PARTITION BY это логическое разбиение которое позволяет на раннем этапе очень быстро определить какие paratition сканируем ORDER BY / PRIMARY KEY если они по возрастанию времени и низко кардинальным колонкам позволяют быстрее через .mrk* файлы сравнивая значения из mrk с условиями запроса и принимая решешние находить нужные куски в .bin файлах просто делая fopen -> fseek -> fread -> uncompress -> compare
по PARTITION BY в теории да, но на практике почему-то при партиционировании по дням выборка данных внутри дня работала МЕДЛЕНЕЕ чем при партиционировании по месяцу. Логического объяснения этому так и не нашел.
ну МЕНЬШЕ партиций меньше партов внутри партиции размер парта такой что буфера хорошо пролазят в CPU Cache логическое объяснение простое, главный паттерн чтобы clickhouse работал быстро ему надо парты среднего размера по 50-100 мегабайт в которых есть PK который есть в запросе... и условия фильтрации которые меньше cpu cache miss порождают =)
просто запрос where неправильно написпн
хм, а в чем ошибка? Сейчас примерно так: CREATE table.... PARTITION BY toYYYYMMDD(time) SELECT ... WHERE toYYYYMMDD(time)>='20200901' and toYYYYMMDD(time)<'20200902'
В версиях до 20.10 (примерно) кликхаус хранил не toYYYYMMDD(time) значение а min-max значение что попадается в колонке, те toYYYYMMDD(time)>='20200901' такая штука в условиях потенциально могла сканировать все партиции
и все еще не хранит. Просто амос научил кх применять функции к minmax значениям партиций и угадывать для более сложных случаев.
Обсуждают сегодня