46 lines
3.0 KiB
Markdown
46 lines
3.0 KiB
Markdown
---
|
||
aliases:
|
||
tags:
|
||
- зрелость/🌱
|
||
date:
|
||
- - 2024-06-20
|
||
zero-link:
|
||
- "[[00 Базы Данных]]"
|
||
- "[[00 HighLoad]]"
|
||
parents:
|
||
linked:
|
||
- "[[Шардирование в БД]]"
|
||
---
|
||
## Тезисы
|
||
- Данные разделяются по какому-то признаку.
|
||
- Разделенные данные физически лежат раздельно. Разные таблицы. Но все данные остаются в пределах одного сервера.
|
||
- Прирост производительности будет только в том случае, если данные для выполнения запроса будут хранится в одной партиции. Поэтому важно правильно определить ключ партиционирования
|
||
|
||
***
|
||
Приложение работает неограниченное количество времени, с каждым днем количество данных в БД увеличивается. При возрастании объема запросы начинают отрабатывать медленнее, в таком случае возникает необходимость в применении партиционирования.
|
||
|
||
На некоторых докладах партиции назывались вертикальным [шардированием](Шардирование%20в%20БД.md).
|
||
|
||
**Минусы:**
|
||
- Некоторые запросы могут замедлиться. Для выполнения запросов, в которых нам нужно сходить в несколько партиций.
|
||
- Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
|
||
- Перестройка партиций дорогостоящая операция.
|
||
|
||
**Плюсы:**
|
||
- Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
|
||
- Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.
|
||
|
||
**Основные типы разделения:**
|
||
- По ключу
|
||
- По диапазону
|
||
- По списку
|
||
- По хэш значению поля
|
||
|
||
**Советы:**
|
||
- Лучше не использовать BETWEEN для разбивки на партиции. Так как непонятно в какую партицию попадут пограничные значения
|
||
- Не стоит создавать партиции одной таблицы по разным полям.
|
||
|
||
Особенности СУБД:
|
||
- [Партиционирование в PostgreSQL](Партиционирование%20в%20PostgreSQL.md)
|
||
|
||
Пример создания в MySQL:  |