gifts2017

1С и Postgres: Партиции

Опубликовал Александр Сединкин (alexcid) в раздел Администрирование - Системное

Мне нравится сравнивать MS SQL и Postgres по производительности. Много читал про то, что MS SQL быстрее, но реально на практике, на одном и том же железе у меня MS SQL не то чтобы медленнее, он гораздо медленней оО

Ну да ладно, статья не об этом. Я хочу поделится с вами очень полезной функцией Postgres Partitions.

Всем привет.

Замечали как быстро работает БД пока она мелкая? Думаю да. Но с ростом данных, поиск и запись становятся все медленней и медленней. Некоторые борятся с этим при помощи "супер" обработок "Свертка базы" и т.п., но настоящие "госу" либо комбинируют эти вещи, либо стараются разобраться с причиной тормозов.

Итак начнем. Партиция - это кусок таблицы, заполняемый по определенным правилам.

Партиция может создаваться: по диапазону значений (range) и по списку значений (list).

Для того чтобы вы все лучше поняли приведу пример из собственной 1С. Для примера возьмем регистр продаж (если не ошибаюсь :)) _accumreg4959

CREATE TABLE _accumreg4959
(
  _period timestamp without time zone NOT NULL,
  _recordertref bytea NOT NULL,
  _recorderrref bytea NOT NULL,
  _lineno numeric(9,0) NOT NULL,
  _active boolean NOT NULL,
  _fld4960rref bytea NOT NULL,
  _fld4961rref bytea NOT NULL,
  _fld4962_type bytea NOT NULL,
  _fld4962_rtref bytea NOT NULL,
  _fld4962_rrref bytea NOT NULL,
  _fld4963rref bytea NOT NULL,
  _fld4964_type bytea NOT NULL,
  _fld4964_rtref bytea NOT NULL,
  _fld4964_rrref bytea NOT NULL,
  _fld4965rref bytea NOT NULL,
  _fld4966rref bytea NOT NULL,
  _fld6031_type bytea NOT NULL,
  _fld6031_rtref bytea NOT NULL,
  _fld6031_rrref bytea NOT NULL,
  _fld4967 numeric(15,3) NOT NULL,
  _fld4968 numeric(15,2) NOT NULL,
  _fld4969 numeric(15,2) NOT NULL,
  _fld6032 numeric(15,2) NOT NULL
)
WITH (
  OIDS=FALSE
);
ALTER TABLE _accumreg4959 OWNER TO postgres;
ALTER TABLE _accumreg4959 ALTER COLUMN _recordertref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _recorderrref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4960rref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4961rref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4962_type SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4962_rtref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4962_rrref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4963rref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4964_type SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4964_rtref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4964_rrref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4965rref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld4966rref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld6031_type SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld6031_rtref SET STORAGE PLAIN;
ALTER TABLE _accumreg4959 ALTER COLUMN _fld6031_rrref SET STORAGE PLAIN;


-- Index: _accumr4959_bydims4970_rtrn

-- DROP INDEX _accumr4959_bydims4970_rtrn;

CREATE UNIQUE INDEX _accumr4959_bydims4970_rtrn
  ON _accumreg4959
  USING btree
  (_fld4960rref, _period, _recordertref, _recorderrref, _lineno);

-- Index: _accumr4959_bydims6035_rtrn

-- DROP INDEX _accumr4959_bydims6035_rtrn;

CREATE UNIQUE INDEX _accumr4959_bydims6035_rtrn
  ON _accumreg4959
  USING btree
  (_fld6031_type, _fld6031_rtref, _fld6031_rrref, _period, _recordertref, _recorderrref, _lineno);

-- Index: _accumr4959_byperiod_trn

-- DROP INDEX _accumr4959_byperiod_trn;

CREATE UNIQUE INDEX _accumr4959_byperiod_trn
  ON _accumreg4959
  USING btree
  (_period, _recordertref, _recorderrref, _lineno);

-- Index: _accumr4959_byrecorder_rn

-- DROP INDEX _accumr4959_byrecorder_rn;

CREATE UNIQUE INDEX _accumr4959_byrecorder_rn
  ON _accumreg4959
  USING btree
  (_recordertref, _recorderrref, _lineno);

-- Partitioning

CREATE TABLE _accumreg4959_2010m10 (
    CHECK ( _period >= DATE '2010-10-01' AND _period < DATE '2010-11-01' )
) INHERITS ( _accumreg4959 ) ;

CREATE INDEX _accumreg4959_2010m10__period ON _accumreg4959_2010m10 ( _period ) ;

CREATE OR REPLACE FUNCTION _accumreg4959_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
    IF ( NEW._period >= DATE '2010-10-01' AND NEW._period < DATE '2010-11-01' )
    THEN
    INSERT INTO _accumreg4959_2010m10 VALUES ( NEW.* );
    END IF ;
    RETURN NEW ;
END ;
$$
LANGUAGE plpgsql ;

CREATE TRIGGER insert__accumreg4959_2010m10_trigger
    BEFORE INSERT OR UPDATE ON _accumreg4959
    FOR EACH ROW EXECUTE PROCEDURE
    _accumreg4959_insert_trigger() ;

Теперь внимание. Я создал таблицу _accumreg4959_2010m10, которая наследует INHERITS базовую 

_accumreg4959 с проверкой вставляемых данных по полю _period.

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

Далее создаем индекс по полю _period.

Затем функцию вставки значениний _accumreg4959_insert_trigger, которая будет вызываться из триггера insert__accumreg4959_2010m10_trigger. Все.

Что в итоге. А в итоге 1С как работала с таблицей _accumreg4959, так и работает, для 1С ничего не изменилось. А вот Postgres ... :) Далее объяснять думаю не нужно, что так можно организовать партиции для каждого месяца на год вперед.

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

Будут вопросы пишите. Благодарю за внимание.


См. также

Подписаться Добавить вознаграждение

Комментарии

1. Артур Аюханов (artbear) 18.12.10 13:58
Наверное, я туп, но самое главное в итоге все равно непонятно :(
За счет чего все-таки ускорится Postgres ?
2. Игорь Исхаков (Ish_2) 18.12.10 14:03
(1) Не грусти. Тупишь не только ты.
3. Александр Цегельников (markers) 19.12.10 13:22
Если я понял, то наступило распределение по разным наследованным таблицам месячных порций одной общей таблицы и за счёт этого скорость чтения всех данных увеличилась. Т.е. читается не одна здоровая таблица а несколько (может быть даже параллельно) маленьких таблиц, в результате высокая скорость! Надеюсь я правильно понял!
4. Александр Сединкин (alexcid) 19.12.10 20:21
Да, совершенно верно. Да и вы правы даже в том, что параллельно.
5. Андрей Жданов (azhdan) 21.12.10 16:04
Хотелось бы услышать мнение автора по поводу решения вопроса конфликта блокировок в больших базах на POSTGREESQL
CTAKAH; cleaner_it; +2 Ответить 1
6. Alexey (alexex) 22.12.10 07:20
Вы написали пример патиции для Postgres ... не заметил сравнения производительности

я не силен Postgres, но в SQL тоже можно делать патиции, причем можете выносить на другой диск (raid)... производ. увелич. в разы, думаю в Посте аналогично.

но здесь обратная сторона, вы должны держать грамотного админа, ну и вообще дорогое удовольствие получиться )
7. Александр Сединкин (alexcid) 22.12.10 17:17
(5)
Блокировки это проблема любой СУБД и MSSQL в том числе. Другой вопрос, что программисты, либо реализуют блокировку на уровне записи для СУБД, либо нет.
Так вот в случае с СУБД Postgres этого не произошло, программисты 1С либо поленились, либо не захотели еще большей ссоры с Майкрософт.
И это кстати привело к тому, что многие стали думать, что Postgres кроме как на уровне таблиц блокировать вовсе не умеет. А это заблужедние.
Postgres это версионная СУБД, она кроме того, что управляет версиями для записей, еще и чудесно делает блокировки для этих же записей. Другое дело,
что эту особенность нужно программировать руками в 1С, которая называется "режим управляемых блокировок". Я предвижу, что вы скажете: "так это же огого сколько работы!",
да, работы много, но мы ее проделали, иначе, если вам дешевле обходится MSSQL то можете эту работу доверить программистам из 1С.
8. Александр Сединкин (alexcid) 22.12.10 18:42
alexex пишет:
причем можете выносить на другой диск (raid)... производ. увелич. в разы, думаю в Посте аналогично.
но здесь обратная сторона, вы должны держать грамотного админа, ну и вообще дорогое удовольствие получиться )


По поводу выноса на другой сервер, сторадж и прочее, это называется "шардинг". Но это тема для другого разговора.
В рамках одного сервера вы можете ускорить чтение/запись, только в рамках партиций.

Тест производительности? Хороший вопрос. Нужно сделать. Обещаю. Сравню 2-е БД 1С размером 70-90 ГБ и выдам результаты.
9. Андрей Жданов (azhdan) 23.12.10 16:39
(7) для того чтоб заставить переписать конфу под управляемые блокировки потратил почти 9 месяцев, пройдя сказки типа "увеличьте скорость винтов и т.д.", это было еще в восьмом году. Конечно поначалу пришлось пройти все приколы нестабильной работы платформы(перезапуск процесса сервера 1с) на 64-х разрядной системе при использовании менеджера блокировок (Начинали на 11-й платформе, а 1С поправила эти бока только в 14-й), хотя как выяснилось потом что косые руки программеров тоже имели место. С тех пор самому пришлось много чего изучить. На сегодня настройка сервера с нуля (с установкой системы)занимает у меня 45 мин. На сегодня использую версию Постгреса 8.3.3. хочу обновить, вот только не могу решить 8.4.3. или 8.3.8 использовать. что посоветуете?
10. Роман Осадченко (cleaner_it) 16.01.11 07:21
(0) После обновления конфигурации проблем не было? 1С, кажется, при реструктуризации БД меняет наименования таблиц?
11. udaff kaa (udaffkaa) 19.07.12 16:32
так можно организовать партиции для каждого месяца на год вперед


Можно ли организовать партиции для уже существующих данных (за прошлые периоды)?
Каким образом?
Есть мысль что необходимо создать партиции, а затем загрузить базу стандартными средствами 1С. Не сбросит ли созданные партиции 1С при загрузке из *.dt?


Затем функцию вставки значениний _accumreg4959_insert_trigger, которая будет вызываться из триггера insert__accumreg4959_2010m10_trigger.

CREATE OR REPLACE FUNCTION _accumreg4959_insert_trigger()
RETURNS TRIGGER AS $$
BEGIN
IF ( NEW._period >= DATE '2010-10-01' AND NEW._period < DATE '2010-11-01' )
THEN
INSERT INTO _accumreg4959_2010m10 VALUES ( NEW.* );
END IF ;
RETURN NEW ;
END ;


Будет ли правильно отрабатывать в случае удаления или обновления данных по периоду в таблице которая в партиции или необходимо ещё писать несколько процедур?
12. Юрий Былинкин (ardn) 29.08.12 12:25
(11) udaffkaa,
Присоединяюсь к вопросу - что делать с прошлыми периодами?
13. Александр Сединкин (alexcid) 16.09.13 14:06
(12) ardn,
- Можно ли организовать партиции для уже существующих данных (за прошлые периоды)?
Каким образом?
Есть мысль что необходимо создать партиции, а затем загрузить базу стандартными средствами 1С. Не сбросит ли созданные партиции 1С при загрузке из *.dt?

Ответ: Можно. Для начала создать триггеры на вставку, затем выгрузить требуемую таблицу в дамп, очистить ее (TRUNCATE) и загрузить заново, отработают триггеры при вставке и значения попадут каждый в свою партицию.
Средствами 1С не стоит, потому как она может переименовать таблицу, тем более удалять она будет долго ибо не использует TRUNCATE и проверяет ссылочную целостность.

- Будет ли правильно отрабатывать в случае удаления или обновления данных по периоду в таблице которая в партиции или необходимо ещё писать несколько процедур?
Для удаления нужно брать мою сборку Postgres, в ней я реализовал каскадное удаление по умолчанию, иначе работать не будет. А с обновлением проблем не будет, триггер отработает что при вставке значений, что при обновлении.
14. Александр Сединкин (alexcid) 16.09.13 14:07
(9) azhdan,
Чем свежее, тем лучше. На сегодня 9.2
15. Art Fa (artfa) 03.12.13 13:17
по поводу блокировок, 1с постепенно переводит все конфигурации на управляемые блокировки, новые конф. такие как УТ 11 или БП 3.0 полностью на управляемых блокировках
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа