Проблемы тут от любых действий связанных с обновлением/удалением записей, которые нужны другим активным транзакциям, т.е. создающих цепочки версий.
Есть альтернативный вариант реализации: вместо удаления сохраняется текущее значение ID и далее обрабатываются записи после него. Оно в принципе подвержено тем проблемам, которые ты описывал для оракл-кластера (генерация сиквенсов пачкой) но мне некритично, т.к. не оракл, и ID генерятся локально. А вот что в этом плохого: бэкап БД будет линейно замедлятся, а удаление старых записей создает те же проблемы, только перенося их в обслуживающий процесс (т.е. вместо 100 раз удалить по 100 записей - 1 раз удалять 10000).
Поэтому я пытаюсь осмыслить, это проблема Firebird или принципиальная проблема реализации очередей с транзакциями поверх MVCC.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2015-05-04 05:32 pm (UTC)Есть альтернативный вариант реализации: вместо удаления сохраняется текущее значение ID и далее обрабатываются записи после него. Оно в принципе подвержено тем проблемам, которые ты описывал для оракл-кластера (генерация сиквенсов пачкой) но мне некритично, т.к. не оракл, и ID генерятся локально.
А вот что в этом плохого: бэкап БД будет линейно замедлятся, а удаление старых записей создает те же проблемы, только перенося их в обслуживающий процесс (т.е. вместо 100 раз удалить по 100 записей - 1 раз удалять 10000).
Поэтому я пытаюсь осмыслить, это проблема Firebird или принципиальная проблема реализации очередей с транзакциями поверх MVCC.