У меня было что-то похожее, по моей вине, некоторые данные просто дублировались из-за неправльной репликации. Проверь запросом GROUP BY по какому нибудь уникальному полю

У меня таблица сама по себе, репликации нет. Проверил итоги на одном id, ситуация всё та же: общие итоги сходятся, а группировка по toStartOfFifteenMinutes даёт разное кол-во записей.

Коллеги, добрый день! Никто не сталкивался с таким явлением с матвью. Есть два идентичных по результату запроса: один к таблице с детальными данными, второй к матвью. Запрос к таблице с детальными данными отрабатывает быстрее чем к матвью. Это первое. И второе. В обоих запросах использутеся функция toStartOfFifteenMinutes. Так вот, запрос к детальным данным возвращает одно количество строк, а запрос к матвью в 10 раз меньше. Т.е. второй запрос пропускает какие-то времена. Хотя общие итоги совпадают. Я перестал что-то понимать в матвью. У кого-то было что-то подобное? П.С. Матвью создавалось на рабочей боевой таблице с ключевым словом populate. Т.е. во время работы команды CREATE MATERIALIZED VIEW... данные понемногу загружались в таблицу с детальными данными небольшими порциями (сотни-несколько тысяч записей в минуту, записываются не непрерывно, а квантами). Про то что таблицу надо "останавливать" для CREATE в курсе. Но в итоге общие count и uniq на таблице с детальными данными и матвью совпадают, потому сделал вывод, что рабочий процесс по загрузке данных не повлиял на матвью и данные не потерялись.

Как выглядит запрос на создание въюхи, какие запросы делаете и что ожидаете увидеть?

Создание: CREATE MATERIALIZED VIEW td_stats.mvw_td_stats_site_zone_position_all_resp_by_15minute ENGINE = AggregatingMergeTree(created_date, (created_date, position_id), 8192) POPULATE as select created_date, toStartOfFifteenMinutes(created) as created_15minute, site_id, zone_id, position_id, countState() as total, uniqState(user_id) as unique from td_stats.td_stats group by created_date, toStartOfFifteenMinutes(created), site_id, zone_id, position_id Запрос к матвью (время работы ~450 мс): select created_15minute as date, toInt32(countMerge(total)) as total, toInt32(uniqMerge(unique)) as unique from td_stats.mvw_td_stats_site_zone_position_all_resp_by_15minute where position_id = 6103 group by created_15minute order by created_15minute Запрос к таблице с детальными данными (время работы ~170 мс !!!): select toStartOfFifteenMinutes(created) as date, toInt32(count()) as total, toInt32(uniq(user_id)) as unique from td_stats.td_stats where position_id = 6103 group by toStartOfFifteenMinutes(created) order by toStartOfFifteenMinutes(created)

1) Для данного набора колонок у вас достаточно странный ПК 2) Если версия КХ >= 18.1.0, то смысла использовать AggregatingMergeTree нет, берите Summing и храните стейты только для того что нужно, например тотал легко считается без хранения состояния.

toInt32(uniq(user_id)) as unique -- это нельзя посчитать в MV. u +u+u 1+1+1 = 3, а должно быть 1

но тогда как уже правильно заметили в order by нужен created_15minute чтобы для каждого значения created_15minute хранились стейты

ну и если вы пишете group by created_date, toStartOfFifteenMinutes(created), site_id, zone_id, position_id то логично все тоже самое перечислить и в PK

скорее всего uniqMerge работает медленно. сколько строк во вью и сколько в таблице? optimize final ?

матвью пересоздал с прежним ключём. Время запроса по конкретному position_id прежнее - около 700-800 мс. Пересоздал матвью с ключом, в котором position_id поставил на первое место. Время выполнения запроса по position_id стало лучше - около 350 мс. Но всё равно, на таблице с детальными данными запрос отрабатывает быстрее - 170 мс.

тогда сделайте еще одно вью без site_id, zone_id иначе неравноценное сравнение

ну не знаю, возможно у вас такие хитрые юзеры, может из-за времени, у меня MV делает таблицу, и если много уникальных пользователей и если мало https://gist.github.com/den-crane/a72614fbe6d23eb9c2f1bce40c66893f

Доброго дня. Никто не подскажет со следующей проблемой: Есть слежующее железо: Dell PowerEdge T610 (http://www.dell.com/ru/business/p/poweredge-t610/pd) Как носители информации используются обычные HDD, памяти ОЗУ тоже не сильно много, около 16Гб. Нужно работать с большими выборками, при крупных запросах и операциях добавления данных сервер фризит. Может ли решить проблему установка SSD, или же проблема скорее суммарно в слабом железе?

свопит может? Но 16 ГБ вообще не вариант если данных много, и ssd не поможет, потому что запросы выполняются в памяти, тупо будет падать каждый второй запрос.

примерно так и происходит. Сейчас база еще наполнена примерно только на 30%, объем базы уже привысил 300Тб. Вот про ссд впервые подумал, когда по статистике I/O увидел то, что CH занимает почти весь тайминг у HDD. Потом решил усомниться в своем предположении. На моей практике это первый проект с такими объемами. Толком вот не знаю, сколько по хорошему надо рессурсов и каких

Доброе утро, правильно я понимаю, что после INSERT батча в MergeTree движках новые данные для SELECT будут доступны сразу после завершения INSERT. Но если я хочу использовать специфику типа Summing/Collapsing/Replacing то мне нужно чтоб случился merge либо ипользовать FINAL ?

Привет. Подскажите пожалуйста, использую движок ReplacingMergeTree делаю count получаю 1.7млн записей делаю count с final получаю 580к записей, делаю optimize table но записи все равно не чистятся и результаты получаю такие же самые, в чем может быть причина? Ключ версии выбрал поле типа DateTime

MergeTree

а state надо в PK включать? или достаточно user-id?

Подскажите, какой Engine использовать для следующего кейса: постоянно создаются и меняются новые объекты (до 100 000 в сек) для разных пользователей, объект может быть в 3 состояниях - Started -> InProgress -> Completed (иногда Started->Completed), нужно считать количество объектов в каждом состоянии по каждому пользователю и выдавать их список за какой-то диапазон времени. Изменение состояния большинства объектов происходит в течние минуты. Финальное состояние хотелось бы видеть сразу в SELECT, а не после непредсказуемого merge. Первое, что приходит в голову, - вставлять запись о каждом состоянии в MergeTree (но непонятно, как выбирать только последний стейт каждого объекта) или ReplacingMT и делать SELECT FINAL (но, по тому, что я читал, скорость выборки падает в разы), а так же делать AggregatedMT MV для каждого состояния, чтоб считать объекты в каждом состоянии. Есть какие-то best practice для подобной задачи в КХ?

Если это игра и результаты запроса нужны не для анализа постфактум, а для хода игры, то не полетит, кх eventual consistent и время выполнения запросов непредсказуемо и слишком медленно для маленьких выборок.

Ну да, можно больше запросов делать. И можно тяжёлые запросы выполнять сразу двумя репликами, но это не всегда помогает и ускоряет не кратно числу реплик.