3.2 KiB
3.2 KiB
| aliases | tags | date | zero-link | parents | linked | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
Тезисы
- Данные разделяются по какому-то признаку.
- Разделенные данные физически лежат раздельно. Разные таблицы. Но все данные остаются в пределах одного сервера.
- Прирост производительности будет только в том случае, если данные для выполнения запроса будут хранится в одной партиции. Поэтому важно правильно определить ключ партиционирования
Приложение работает неограниченное количество времени, с каждым днем количество данных в БД увеличивается. При возрастании объема запросы начинают отрабатывать медленнее, в таком случае возникает необходимость в применении партиционирования.
На некоторых докладах партиции назывались вертикальным шардированием.
Минусы:
- Некоторые запросы могут замедлиться. Для выполнения запросов, в которых нам нужно сходить в несколько партиций.
- Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
- Перестройка партиций дорогостоящая операция.
Плюсы:
- Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
- Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.
Основные типы разделения:
- По ключу
- По диапазону
- По списку
- По хэш значению поля
Советы:
- Лучше не использовать BETWEEN для разбивки на партиции. Так как непонятно в какую партицию попадут пограничные значения
- Не стоит создавать партиции одной таблицы по разным полям.
Особенности СУБД:
Когда стоит использовать?
- Для отделения исторических данных от операционных
Пример создания в MySQL: 