прошу подсказать как правильнее задать параметры таблицы...
ORDER BY (Date, id, rtime, srtime)
PARTITION BY yyyymmdd(Date)
PRIMARY KEY пустой
кол-во записей за сутки ~ 1 млрд.
При этом уникальность id 100%, rt и str (95%)
В каждом select в БД есть в cекции where запрос по Date и rtime или Date и srtime + order по id
Вопросы:
1. Нужен ли id в ключе сортировки или достаточно будет ORDER BY (Date, rtime, srtime)
2. Имеет ли смысл в PRIMARY KEY прописать Date, убрав его из ORDER BY
3. Есть еще 5-6 полей с уникальностью ~50%, которые достаточно часто могут появляться в select-ах. Имеет смысл их добавлять в ORDER BY (Date, rtime, srtime, ....). Повысит ли это скорость select, сильно ли увеличит нагрузка на сервер.
4. Дневные партиции выбрали с целью удобства их удаления/бэкапа при переполненнии хранилища. Повысится ли скорость при переходе на недельные?
Буду признателен за совет.
По пунктам не отвечу, поэтому поделюсь соображениями общего характера. Мне кажется, что ставить ID со 100% уникальностью в ключ сортировки вперёд менее уникальных rtime/strime - это плохая идея. Это делает бесполезным два последующих поля в ключе (т.к. внутри одного уникального ID всегда только один rtime и одного stime), а ресурсы при заполнении индекса и память под сам индекс они кушают. Эффект от смены ключа партиционирования зависит ещё от того, за какой период выбираются данные. Если всегда за день, то +- так же будет, а если за бОльший период, то станет быстрее, ибо надо будет меньше файлов перебирать. Отдельно предлагаю проверить меняется ли скорость запроса и число прочитанных строк, если добавить в запрос отбор вида prewhere toYYYYMMDD(Date) = 20210331 У меня партишн прунинг на 20.8 не всегда работал если партиционирование по toYYYYMMDD(Date), а в условии отбора запроса просто Date. А вот если указать явным образом, то всегда работает. Это может сильно ускорить.
Обсуждают сегодня