Firebird vs Postgres vs Oracle, MVCC и очереди

[metaclass]

Кто руками трогал Postgres или Oracle (или прочие MVCC СУБД)?

Как они реагируют на такое: в таблице ~1 млн записей, в нее долбятся 2-3-5-10 клиентов, каждый над своим подмножеством записей делает что-то вроде "3/4 записей делаем update, 1/4 удаляем, добавляем еще столько же" и повторять это 24/7. Т.е. антипаттерн "очередь поверх MVCC БД, да еще сделанная через пень-колоду".

Firebird с его реализацией MVCC на такое реагирует нехорошо - накапливается мусор в БД и если, не дай бог, рядом будет длинная транзакция (например бэкап) - то мусора будет охрененно много, после чего какая-то из рабочих транзакций станет собирать мусор, и тоже станет длинной, в результате чего есть шансы поиметь бесконечное накопление мусора и нужно будет отключать рабочие процессы и собирать мусор или же базе будет проще сделать backup-restore (с ключиком -g - отключенной сборкой мусора), чем ждать.

Т.е. при определенном проценте версий записей, сборка мусора в Firebird становится настолько тяжелой по i/o, что прочитать базу целиком один раз без сборки мусора для бэкапа и потом восстановить намного быстрее, чем ждать сборки мусора стандартными механизмами.

Что больше всего смущает в этом - то что сборка мусора на ходу читает базу по кругу какое-то неимоверное количество раз (судя по i/o), т.е. для 100 мб базы может быть прочитано-записано 10-100 гб.

Каждый раз это вызывает желание залезть в кишки сервера и поискать там какой-нибудь неявно окопавшийся алгоритм маляра шлемиеля, потому что оно имеет явно нелинейную зависимость от количества записей в целевой таблице. Или же там что-то вроде нелокальности данных - там не кластерный индекс, соответственно версии записей могут лежать по всему файлу БД как попало, а оно их пытается сканировать линейно.

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

PS: Вот собственно описание аналогичной проблемы и ответы на нее http://osdir.com/ml/firebird-db/2013-01
/msg00003.html

Comments

[dennis_chikin.livejournal.com]

Лучше б кто-нибудь сказал, как можно сделать так, чтобы база о 5000 записей (ну правда объем - около сотни мег), перетащенная с access на FB при работе с одним клиентом дает адское слайд-шоу, и, главное, нельзя-ли это сладшоу как-то "разделать" обратно, при условии, что показывалка - вся из себя проприетарная. Ну вот просто с очередной версии стал fb вместо ацесса, и началось. Версия привязана к железу.

[metaclass.livejournal.com]

Надо посмотреть какая версия FB, если более менее новая - в ней есть таблицы мониторинга и трейс выполнения запросов.
Далее, надо глянуть - где именно косяки - i/o, проц сервера, задержки сети, проц клиента - обычно это легко различимо. Ну и дальше по обстоятельствам - крутить кэш FB, ставить SSD, искать плохие индексы и прочее такое.

[dennis_chikin.livejournal.com]

2.1, "сервер" живет на одной машине с клиентом. Совершенно жутко жрет проц. То есть, ощущение такое, что про индексирование оно ничего не знает, и при каждом запросе ползает по всем этим 100 мегабайтам.

[metaclass.livejournal.com]

Ага, мониторинга в ней нет.
Жрет проц - это значит или они в FB вычисления массово делают, или же база целиком в кэше но на каждый чих сканируется целиком. Проверяется запуском process explorer и втыканием в i/o статистику.

Еще можно попробовать запустить на новой версии с мониторингом, хотя неадекватные люди вполне способны прибить клиентский софт к определенной версии сервера (что, теоретически, можно отлечить, похачив fbclient.dll чтобы возвращала всегда правильную версию).

[norguhtar.livejournal.com]

С 46 страницы
http://momjian.us/main/writings/pgsql/mvcc.pdf

[vit-r.livejournal.com]

А можно в одной транзакции копировать старую таблицу в новую копию, сделать VACUUM и переименовать новую в старую?

[norguhtar.livejournal.com]

А не жирно ли по накладным расходом будет.

[vit-r.livejournal.com]

Ох, это не самое страшное, что тут происходит.

[metaclass.livejournal.com]

vacuum нет, truncate нет, переименования таблиц нет.
копирование таблицы эквивалентно ее чтению со сборкой мусора, если не указать в подключении спецфлаг "без сборки мусора"

Т.е. обходных путей против транзакций в стиле "грохаем таблицу под ноль" вообще нету.

[falcrum.livejournal.com]

Как-то странно выглядит "1/4 удаляем" - не отсюда проблемы?

[metaclass.livejournal.com]

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

Есть альтернативный вариант реализации: вместо удаления сохраняется текущее значение ID и далее обрабатываются записи после него. Оно в принципе подвержено тем проблемам, которые ты описывал для оракл-кластера (генерация сиквенсов пачкой) но мне некритично, т.к. не оракл, и ID генерятся локально.
А вот что в этом плохого: бэкап БД будет линейно замедлятся, а удаление старых записей создает те же проблемы, только перенося их в обслуживающий процесс (т.е. вместо 100 раз удалить по 100 записей - 1 раз удалять 10000).

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

[http://users.livejournal.com/_slw/]

возьми да проверь, постгрес поставить несложно

[metaclass.livejournal.com]

Блин, я похоже доработался.
Идея прогнать эту же нагрузку на Postgresql мне не пришла в голову вообще, хотя там работы на 2-3 дня вообще.

[http://users.livejournal.com/_slw/]

если что -- обращайтесь.
всегда ваш,
К.О.

[thetvv.livejournal.com]

ME> 1/4 удаляем, добавляем еще столько же

Я конечно не знаю, какая там задача, но может быть имеет смысл вообще избегать удалений и добавлений, или хотя бы свести их к минимуму? Апдейты, пусть это и реплейс значений всех колонок, намного быстрее же (возможно, в несколько раз быстрее), меньше расход памяти, меньше "мусора", да и фрагментация будет меньше. Например, если нужно одну запись удалить, и одну добавить, то один апдейт полюбому лучше делита и инсерта. Прошу прощения, если не в тему.

[kuaw26.livejournal.com]

Не в курсе че да как там у вас, но может вам поможет "отложенное" удаление?
Вместо удаления помечай записи как "удаленные", а по ночам или когда нагрузка минимальна проводи реальное удаление?

[metaclass.livejournal.com]

Да, сейчас в основном так и делается - основное обслуживание делается по ночам.

[jdevelop.livejournal.com]

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

[kranov.livejournal.com]

oracle хранит старые версии в отдельном пространстве undo (rollback segment(in-memory-undo)), поэтому пухнуть таблица будет если только из-за апдейтов, строка при апдейте не влезает в зарезервированное место в блоке и сплитится, ну и индексы будут разбалансироваться постепенно из-за делитов (раз в n-лет можно поребилдить (онлайн)), т.е. надо настроить заранее резерв (pctfree/pctused). В общем-то что-то похожее у меня было (объемы правда в 10раз побольше), транзакции (транзакция 2-5 строк) банкоматов и посов пишутся в таблицу (апдейтятся), и в течении месяца удаляются (перетекают в бэкофис).

[fraks-nsk.livejournal.com]

А что мешает спросить про Firebird у непосредственно разработчиков?
http://sql.ru/forum/actualtopics.aspx?bid=2

[metaclass.livejournal.com]

Они нервно реагируют на слова "сборка мусора" и "фрагментация данных".
Но меня больше интересует ситуация в других СУБД.