Секционирование большой таблицы на лету

@tascold · Регистрация: 16.02.2012

Студворк — интернет-сервис помощи студентам

Кейс:

Имеем большую таблицу (более 2.5 млрд. записей) с нагрузкой 24х7 read/write.
Записи таблицы имеют GUID объекта и привязку объекта к источнику, которых несколько десятков.
Данные в таблице используются неоднородно. Для некоторых источников данных много, для других нет.

Запросы начали тормозить.

Хочу:

Разделить таблицу на несколько фрагментов стандартными средствами PostgreSQL.
Желательно поделить следующим образом:

1. Сегмент № 1: Записи из источника № 1
2. Сегмент № 2: Записи из источника № 2
3. ...
3. Сегмент № n: Все остальные

где записи из источника 1..n-1 это несколько источников, по которым имеется по несколько сотен миллионов записей и которые создают наиболее дорогие запросы. Хотелось бы иметь возможность убирать такие данные в отдельные сегменты таблицы, чтобы они друг другу не мешали (большинство запросов оперируют в рамках одного источника данных).

Вопросы:

1. Как это сделать для 14.5+ версии?
2. Можно ли это сделать не нарушая доступность БД?

@grgdvo · 20.12.2022, 22:21

Сообщение от tascold

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

Если данные неоднородные, то тогда партиционирование не имеет смысл использовать. Все равно будет тормозить, потому что какая-то партиция будет раздутой и индексы будут раздутые или в процессе работы снова начнет разудваться и встанет вопрос партиционировать уже партиционированную таблицу. Найдите для начала способ как разделять так, чтобы было более менее однородно и понятно, какой объем будет накапливаться в новых партициях.

Вообще вариантов партиционирования (декларативного) три. Вы лучше знаете ваши данные, посмотрите по примерам.

Сообщение от tascold

1. Как это сделать для 14.5+ версии?

Теория и примеры здесь

Сообщение от tascold

2. Можно ли это сделать не нарушая доступность БД?

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

@tascold · 21.12.2022, 10:26 **[ТС]**

Сообщение от grgdvo

Найдите для начала способ как разделять так, чтобы было более менее однородно и понятно, какой объем будет накапливаться в новых партициях.

У меня нет такого способа. По сути мне нужно обслуживание рабочей БД "по требованию". Я не могу заранее сказать - какой объем данных будет у нового источника данных или когда старый хилый источник вдруг выдаст кратно повысившуюся нагрузку.

В принципе можно выделять секцию сразу, но есть множество источников в которых данных кот наплакал. Поэтому идеальным вариант (ИМХО) - выделение секций для данных, где это реально требуется, к тому же "ID источника" находится в условии выборки большинства запросов, так что тут и с этой стороны все по феншую получается.

Сообщение от grgdvo

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

На сколько я понимаю, PostgreSQL это может. Тут даже будет проще. Если я заранее знаю, что до 1 миллиарда записей в секции работают нормально, то когда придет время, просто добавятся подсекции с диапазонами "<дата" и ">= дата" вставки. Таким образом можно мониторить все секции по источникам и тоже добавлять подсекции "по требованию".

Поэтому и спрашиваю - сталкивался ли кто с такой задачей и можно ли ее сделать без боли?

@oktogen · 21.12.2022, 18:31

Я делал на старой базе, ещё на 9-й. Тщательно продумывается структура данных, с предметниками. Обсуждается и партицирование с предметниками и с теми кто будет писать выборки из партиций. В итоге всё пашет уже лет 12.

@grgdvo · 22.12.2022, 21:58

Сообщение от tascold

На сколько я понимаю, PostgreSQL это может. Тут даже будет проще. Если я заранее знаю, что до 1 миллиарда записей в секции работают нормально, то когда придет время, просто добавятся подсекции с диапазонами "<дата" и ">= дата" вставки. Таким образом можно мониторить все секции по источникам и тоже добавлять подсекции "по требованию".

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

Новые блоги и статьи Все статьи Все блоги /
моя боль iceja 24.01.2026 Выложила интерполяцию кубическими сплайнами www. iceja. net REST сервисы временно не работают, только через Web. Написала за 56 рабочих часов этот сайт с нуля. При помощи perplexity. ai PRO , при. . .	Модель сукцессии микоризы anaschu 24.01.2026 Решили писать научную статью с неким РОманом	http://iceja.net/ математические сервисы iceja 20.01.2026 Обновила свой сайт http:/ / iceja. net/ , приделала Fast Fourier Transform экстраполяцию сигналов. Однако предсказывает далеко не каждый сигнал (см ограничения http:/ / iceja. net/ fourier/ docs ). Также. . .	http://iceja.net/ сервер решения полиномов iceja 18.01.2026 Выкатила http:/ / iceja. net/ сервер решения полиномов (находит действительные корни полиномов методом Штурма). На сайте документация по API, но скажу прямо VPS слабенький и 200 000 полиномов. . .
Расчёт переходных процессов в цепи постоянного тока igorrr37 16.01.2026 / * Дана цепь(не выше 3-го порядка) постоянного тока с элементами R, L, C, k(ключ), U, E, J. Программа находит переходные токи и напряжения на элементах схемы классическим методом(1 и 2 з-ны. . .	Восстановить юзерскрипты Greasemonkey из бэкапа браузера damix 15.01.2026 Если восстановить из бэкапа профиль Firefox после переустановки винды, то список юзерскриптов в Greasemonkey будет пустым. Но восстановить их можно так. Для этого понадобится консольная утилита. . .	Сукцессия микоризы: основная теория в виде двух уравнений. anaschu 11.01.2026 https:/ / rutube. ru/ video/ 7a537f578d808e67a3c6fd818a44a5c4/	WordPad для Windows 11 Jel 10.01.2026 WordPad для Windows 11 — это приложение, которое восстанавливает классический текстовый редактор WordPad в операционной системе Windows 11. После того как Microsoft исключила WordPad из. . .

@tascold 1 / 1 / 0 Регистрация: 16.02.2012 Сообщений: 12

	Секционирование большой таблицы на лету 20.12.2022, 20:31. Показов 909. Ответов 4 Метки нет (Все метки) Кейс: Имеем большую таблицу (более 2.5 млрд. записей) с нагрузкой 24х7 read/write. Записи таблицы имеют GUID объекта и привязку объекта к источнику, которых несколько десятков. Данные в таблице используются неоднородно. Для некоторых источников данных много, для других нет. Запросы начали тормозить. Хочу: Разделить таблицу на несколько фрагментов стандартными средствами PostgreSQL. Желательно поделить следующим образом: 1. Сегмент № 1: Записи из источника № 1 2. Сегмент № 2: Записи из источника № 2 3. ... 3. Сегмент № n: Все остальные где записи из источника 1..n-1 это несколько источников, по которым имеется по несколько сотен миллионов записей и которые создают наиболее дорогие запросы. Хотелось бы иметь возможность убирать такие данные в отдельные сегменты таблицы, чтобы они друг другу не мешали (большинство запросов оперируют в рамках одного источника данных). Вопросы: 1. Как это сделать для 14.5+ версии? 2. Можно ли это сделать не нарушая доступность БД? 0

@oktogen 55 / 50 / 5 Регистрация: 30.06.2022 Сообщений: 251
	21.12.2022, 18:31
	Я делал на старой базе, ещё на 9-й. Тщательно продумывается структура данных, с предметниками. Обсуждается и партицирование с предметниками и с теми кто будет писать выборки из партиций. В итоге всё пашет уже лет 12. 0