Работал ли ты с партиционированием в базах данных

Что проверяют

Понимаете ли вы, зачем режут таблицы, и отличаете ли секционирование от шардирования и от обычного индекса. Для Java-разработчика вопрос обычно про PostgreSQL и про то, доходит ли ключ секционирования до запроса, который порождает ваш код.

Как отвечать

Начните с разграничения. Партиционирование это разбиение одной таблицы на секции внутри одной базы, для приложения она остаётся одной таблицей. Шардирование это разнесение данных по разным узлам, и маршрутизацию делает приложение или прокси.

Виды: по диапазону (чаще всего по дате), по списку, по хешу. Польза не в абстрактном ускорении, а в двух вещах: планировщик отсекает лишние секции, когда в условии есть ключ секционирования, и старые данные убираются отсоединением секции вместо DELETE на миллионы строк с последующей чисткой.

Ограничения назовите сами: уникальный индекс и первичный ключ обязаны включать ключ секционирования, индексы живут у каждой секции, слишком мелкое дробление удорожает планирование. Со стороны Java добавьте: для JPA это обычная сущность, поэтому важно, чтобы дата попадала в where, а не только в фильтрацию на стороне кода. Секции на будущие периоды создаются заранее миграцией или планировщиком.

Где спотыкаются

Называют секционирование универсальным ускорением. Запрос без ключа секционирования обходит все секции и работает медленнее, чем по цельной таблице с подходящим индексом.

Смешивают уровни: секционирование, шардирование и индекс в ответе становятся одним и тем же. Отсюда и предложение «отшардировать таблицу», когда речь про одну базу.

Приводят множители из воздуха: «стало быстрее в пять раз». Спросят, что показывал план до и после и сколько секций осталось после отсечения, и ответа нет. Туда же попытка перевести живую большую таблицу одним ALTER: на деле создают новую и переливают данные.