Секционирование: Выстрелил и забыл

[ccrypt]

> К сожалению в нем выяснилось несколько недостатков: при создании новой секции первая запись > в эту секцию терялась; при большом количестве секций вставка даже одной записи занимает слишком много времени

Уже известная проблема. Решение для нее и некоторых других предлагается здесь:

crypt47.blogspot.com/2012/05/partitioning-of-zabbix-database.html

[Borgius]

Да проблема известная, ваше решение я видел, но по моему мнению оно похоже на полумеру, чтобы не терялась запись вы предлагаете вставлять тестовые записи заранее — конечно лучше, чем вручную секции добавлять, но уже не автомат. По поводу скорости вставки я имел ввиду скорость вставки не первой записи которая создает таблицу и копирует индексы, а регулярной вставки в уже созданные секции, при большом количестве секций от 100. В этом методе кроме вычисления имени секции в триггере (не используется) обрабатываются правила по 1 на каждую секцию в результате если даже все просто то на 100 секций нужно 101 действие для вставки 1 записи. В моем случае если секции уже созданы выполняется всего 1 триггер с 100 простыми IF ELSIF. Пример созданного триггера можете увидеть в статье

[ccrypt]

> уже не автомат

крон делает автоматом.

> В этом методе кроме вычисления имени секции в триггере (не используется) обрабатываются правила по 1 на каждую секцию в результате если даже все просто то на 100 секций нужно 101 действие для вставки 1 записи.

В этом — это в методе в оф.доках забикс? Извините, из-за полного отсутствия знаков припинания, читал несколько раз и так до конца и не понял.

[Borgius]

> крон делает автоматом.
Конечно это работает, но если есть возможность обойтись без внешнего воздействия, лучше воспользоватся этим.

[ccrypt]

опять же 100 IF ELSE — это в каком случае? у меня партиционирование идет по дням, стало быть 365 IF ELSE?

[Borgius]

да, если у вас 365 секций, то в методе от zabbix, у Вас будет 365 rules. Каждое правило имеет больший overhead чем триггер. Грубо говоря это 365 триггеров vs 1 триггер с множеством условий.
Кстати Вы подсказали простую оптимизацию: расположить IF в обратном порядке, тогда условие о последних данных будет первым, и по сути для новых будет отрабатывать только первый IF.

[ccrypt]

Теоретически понятно, но лично мне было интереснее всего узнать, какой выигрыш реально получился у вас при использовании if else метода. Может, есть численные показатели?

Насчет просто оптимизации — это не для любого use-case, т.к. в середине года вставка будет приходиться на 364/2 день. Кроме того, по крайней мере раз в год придется проводить спецальные работы по обновлению тригера (это в контру крон-скрипту, который тоже ставится руками :)).

[xmm]

Для данного примера, когда шагом секционирования является строго один день (или месяц), гораздо эфективнее построить необходимое название таблицы, чем проверять кучу условий:

CREATE OR REPLACE FUNCTION stats_request_trigger ()
RETURNS TRIGGER AS $$
    date_parts = str(TD['new']['date']).split('-')
    table_name = '%s_y%s_m%s' % (TD['table_name'], date_parts[0], date_parts[1])
    if not SD.has_key('insert_plan'):
        SD['insert_plan'] = plpy.prepare('INSERT INTO %s (date, src, hostname, domain, hits, agent_id) VALUES ($1, $2, $3, $4, $5, $6)' %(table_name), ['date', 'inet', 'text', 'text', 'int', 'int'])
    n = TD['new']
    plpy.execute(SD['insert_plan'], (n['date'], n['src'], n['hostname'], n['domain'], n['hits'], n['agent_id']))
    return 'SKIP'
$$ LANGUAGE plpythonu;

И под высокой нагрузкой лучше кроном создавать нужные таблицы, чем при каждой вставке проверять наличие таблицы.
PS: Хотя где ещё осталась моя серебрянная пуля, которая все автоматиирует. ))

[Borgius]

Позволю не согласится: при последовательной вставке данных новые данные попадают в первый IF и на этом триггер заканчивает работу. Также при сравнении не используется никакое преобразование данных.
второе — после запуска, не нужно никаких телодвижений, все будет работать без крона, не нужно думать о новых секциях, индексах
третье — это универсально, можно ставить на любую таблицу одной командой.

[xmm]

Ключевое слово — при последовательной вставке, иначе — мой вариант лучше.

[Borgius]

Согласен, если данные приходят в случайном порядке, то функция будет лучше. Хотя тут свои «но» — нужно быть уверенным что таблица существует.
Обычно если делают секции по дате подразумевается что данные приходят последовательно. Судя по вашей структуре они у Вас тоже приходят последовательно :)

[xmm]

Да, мой пример выглядит не совсем удачным. )
Но эти данные могут поступать из внешних источников и с большими задержками.
А прикольно будет выглядить этот триггер через пару лет с шестьюстами if-ами. ) Все таки полностью этот вариант не автоматизируется.
В остальном согласен.

[Borgius]

> А прикольно будет выглядеть этот триггер через пару лет с шестьюстами if-ами.
Согласен, в нем реально будут работать только верхние несколько строчек. Но в любом случае не рекомендуется держать 730 активных секций — postgresql сам начнет тормозить, неактивные секции можно/нужно отключать/удалять и триггер автоматом уменьшится, так что пользуйтесь с удовольствием.