2024-06-20 21:49:23 +03:00
|
|
|
|
---
|
|
|
|
|
aliases:
|
|
|
|
|
tags:
|
|
|
|
|
- зрелость/🌱
|
|
|
|
|
date:
|
|
|
|
|
- - 2024-06-20
|
|
|
|
|
zero-link:
|
|
|
|
|
- "[[00 Базы Данных]]"
|
2024-06-20 21:54:23 +03:00
|
|
|
|
- "[[00 HighLoad]]"
|
2024-06-20 21:49:23 +03:00
|
|
|
|
parents:
|
|
|
|
|
linked:
|
2024-06-20 21:54:23 +03:00
|
|
|
|
- "[[Шардирование в БД]]"
|
2024-06-20 21:49:23 +03:00
|
|
|
|
---
|
|
|
|
|
- Берем данные и разделяем по какому-то признаку
|
|
|
|
|
- Разделенные данные физически лежат отдельно. Разные таблицы
|
|
|
|
|
- Но все данные остаются в пределах одного сервера.
|
|
|
|
|
|
|
|
|
|
**Минусы:**
|
2024-06-20 21:54:23 +03:00
|
|
|
|
- Некоторые запросы могут замедлиться. Кросс-партиционные запросы.
|
2024-06-20 21:49:23 +03:00
|
|
|
|
- Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
|
2024-06-20 21:59:23 +03:00
|
|
|
|
- Кажется перестройка партиций дорогостоящая операция.
|
2024-06-20 21:49:23 +03:00
|
|
|
|
|
|
|
|
|
**Плюсы:**
|
2024-06-20 21:59:23 +03:00
|
|
|
|
- Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
|
2024-06-20 21:49:23 +03:00
|
|
|
|
- Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.
|
|
|
|
|
|
|
|
|
|
Основные типы разделения:
|
|
|
|
|
- key. По ключу
|
|
|
|
|
- range. По диапазону
|
|
|
|
|
- list. По списку
|
|
|
|
|
- hash. По хэш значению поля
|
|
|
|
|
|
|
|
|
|
Пример создания в PostgreSQL: ![](Pasted%20image%2020240620214723.png)
|
|
|
|
|
|
|
|
|
|
Пример создания в MySQL: ![](Pasted%20image%2020240620214648.png)
|