digital-garden/_inbox/Партиционирование в БД.md

3.2 KiB
Raw Blame History

aliases tags date zero-link parents linked
зрелость/🌱
2024-06-20
00 Базы Данных
00 HighLoad
Шардирование в БД

Тезисы

  • Данные разделяются по какому-то признаку.
  • Разделенные данные физически лежат раздельно. Разные таблицы. Но все данные остаются в пределах одного сервера.
  • Прирост производительности будет только в том случае, если данные для выполнения запроса будут хранится в одной партиции. Поэтому важно правильно определить ключ партиционирования

Приложение работает неограниченное количество времени, с каждым днем количество данных в БД увеличивается. При возрастании объема запросы начинают отрабатывать медленнее, в таком случае возникает необходимость в применении партиционирования.

На некоторых докладах партиции назывались вертикальным шардированием.

Минусы:

  • Некоторые запросы могут замедлиться. Для выполнения запросов, в которых нам нужно сходить в несколько партиций.
  • Так как данные лежат на одном сервере, то если уперлись в производительность диска, партиционирование не поможет.
  • Перестройка партиций дорогостоящая операция.

Плюсы:

  • Простая реализация. Разработчик продолжает обращаться к таблице, а СУБД понимает в какую партицию ей стоит идти.
  • Некоторые типы запросов может ускорить за счет уменьшения объема данных в партиции.

Основные типы разделения:

  • По ключу
  • По диапазону
  • По списку
  • По хэш значению поля

Советы:

  • Лучше не использовать BETWEEN для разбивки на партиции. Так как непонятно в какую партицию попадут пограничные значения
  • Не стоит создавать партиции одной таблицы по разным полям.

Особенности СУБД:

Когда стоит использовать?

  • Для отделения исторических данных от операционных

Пример создания в MySQL: