Просто о партиционировании

Продолжаю цикл небольших материалов про сложные термины на темы БД: на этот раз разберемся с партиционированием

📌 Определение

Вспомним, что партиционирование – метод разделения большой таблицы на несколько маленьких на одном сервере

Но что такое большая таблица? В этом контексте это миллиарды строк😰. Представьте стог сена, где спрятана игла. Чтобы найти ее, нужно немало времени. Также и в системах: очевидно, с таким объемом данных она будет медленнее работать

💡 Виды партиционирования

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

➡️ Горизонтальное партиционирование

Представьте, что мы разрезаем таблицу горизонтально. Сделать это можно так:

• По диапазону значений (Range Based). Например, по ID или дате – в одной партиции храним записи с ID от 0 до 500 000, в другой от 500 000 до 1 000 000
• По спискам (List Based). Например, по странам или категориям – в одной партиции храним данные по России, в другой по Вьетнаму
• По хэшу ключа (Hash Based). Тут посложнее: берем хэш-функцию, в качестве значений – один из столбцов (например, user_id). Результат делится на N, где N – количество партиций. Остаток от деления определяет номер партиции, куда мы запишем данные. Плюс такого способа: равномерное распределение
• По ключу (Key Based). Как Hash Based, но используется само значение ключа

Где что подойдет:
• Range – для логов и исторических данных
• List – для географически распределенных систем
• Hash/Key – для равномерного распределения данных

➡️ Вертикальное партиционирование

А теперь таблицу делим вертикально, по колонкам

Предположим, у нас таблица с тремя атрибутами: ID, name, email. Вжух – и теперь у нас две таблиц:, в первой id и name, во второй id и email

На практике этот способ деления встречается редко

⚠️ Партиционирование – не панацея

Партиционирование не подойдет, если:

❌ Маленькие таблицы (до 1 млрд строк) – расходы ресурсов будут неоптимальными
❌ Если запросы затрагивают все партиции – скорость выполнения не снизится, а может даже и увеличится

И подойдет, если:
✅ У нас огромная таблица – свыше 1 млрд записей
✅ Мы столкнулись с техническими ограничениями сервера – физически нет места
✅ Нужно удалить/архивировать данные – например, логи
✅ Нужно распределить нагрузку из-за частых запросов по одному критерию (например, по дате)

🆚 Индексы vs партиционирование

Казалось бы, зачем пилить таблицу, если есть индексы? Да, они тоже ускоряют работу с данными, но они не подойдут для огромных таблиц, т.к. тоже занимают место на диске. И индексы используются для «точечных» поисковых запросов, а не для выборки групп данных. В общем, разные задачи

Однако оба метода можно комбинировать – разбить большую таблицу на партиции, а внутри сделать индексы

—————

Остался последний термин, который я хотел бы разобрать – шардирование. И о нем уже в следующем посте

А вы сталкивались с партиционированием на проекте? Пишите, если был опыт

#полезное_системный_анализ