Xpoint
   [напомнить пароль]

Опыт эксплуатации PostgreSQL

Метки: [без меток]
2007-08-27 11:14:29 [обр] Thirteensmay(0/157)[досье]
Рассматривается вопрос разработки новых проектов под эту СУБД, сильно облизываюсь на возможности внутреннего процедурного программирования и лицензию. Кто имеет опыт поделитесь пожалуйста, возможно есть какие то подводные камни ? Остались ли проблемы с вакуумом, etc... ?
спустя 2 часа 14 минут [обр] Давид Мзареулян(8/1003)[досье]
Какие «проблемы с вакуумом»?
спустя 10 минут [обр] 30-ый(4/584)[досье]
Ну на возможности "внутреннего процедурного программирования" вы уж там не очень то облизывайтесь. Если у вас есть опыт работы с Oracle или MS-SQL, они вас разочаруют...
спустя 12 минут [обр] Thirteensmay(0/157)[досье]

Хм, вопрос радует ;)
Ну, для старых версий судя по статеинам в сети и постам на форумах была актуальной необходимость периодического выполнения команды VACUUM для очистки базы ибо она в противном случае сильно начинала тормозить, т.е. необходимо периодически останавливать сервак, что не есть гуд... Потом эту проблему решали, сначала похоже через выделение в отдельный процесс (AUTOVACUUM), а в последних нескольких релизах вроде как в основной процесс сервера встроили (судя по последнему комменту http://www.postgresql.org/docs......ing.html#VACUUM-FOR-WRAPAROUND) Так вот, Давид Мзареулян[досье] Вас в первую очередь и ждал, насколько мне известно Вы с этой СУБД работаете, есть ли сейчас вышеозначенная проблема или вылечили совсем ? и вообще, какие есть особенности (подводные камни) эксплуатации PostgreSQL ? нехочется както напоротся на какойнить неочевидный косяк через год-другой...

30-ый[досье] К этому я уже внутренне готов ;) Да, есть опыт работы с Oracle, классно, но уж больно дорого, поэтому постгре думаю будет разумным компромиссом, особенно в сравнении с MySQL. Да, пакетов как я понял там нет в принципе ?

спустя 45 минут [обр] Давид Мзареулян(8/1003)[досье]

Thirteensmay[досье] Ну, я могу сказать, что даже пока был ручной вакуум, это абсолютно ничему не мешало. Сервак для этого останавливать не надо, вакуумирование производится на ходу. Если не делать “vacuum full analyze” (который реально блокирует базу), то все прочие вакуумы происходят практически незаметно. Но полный вакуум нужен только после каких-нибудь мощных апдейтов, когда затрагивается значительная доля записей (заливка данных в базу, восстановление из бэкапа и т.п.). У меня вакуум (на старой версии базы, где нет автовакуума) просто запускается в три часа ночи, работает минут пять, и никому особо не мешает.

Автовакуум — это ровно тот же вакуум, только база сама следит, когда в таблице накапливается достаточно мусора. В принципе, тоже, совершенно прозрачная операция.

В остальном, поверите ли, вообще никаких проблем никогда с этой базой не имел. Разве что один раз после хард-ресета посыпалась одна активно обновляемая таблица, пришлось из бэкапа доставать. Но это был единственный заметный случай за семь лет. Правда, должен сказать, что у меня сайты не то чтобы очень глобальные (десятки тыс. уникальных хостов в день максимум) и, скажем, с БД-кластерами я не работал.

спустя 3 часа 19 минут [обр] Thirteensmay(0/157)[досье]
Ага, спасибо
спустя 15 часов [обр] Дмитрий Кононов(0/16)[досье]

Внесу и я свои два цента.
Уже около года использую Постгрес в одном проекте + различная обработка тестовых данных.
Про vacuum тут уже сказали, можно сильно не волноваться, autovacuum работает нормально.
Однако надо помнить, что дефолтный конфиг не является оптимальным, потому надо тюнинговать — в инете есть масса инфы по этому поводу. В основном, это касается размеров различных буферов.
В написании хранимок не вижу проблемы, ибо есть хорошая среда EMS SQL Manager for PostgreSQL.
Говорят, что синтаксис схож с оракловским (сам Оракл не юзал), потому для вас проблемы не составит.

На что еще наткнулся.
Дампить базу лучше с ключиком -Fc. Первое время использовал -Ft + gzip, но на больших объемах при дампе/восстановлении начинает сильно жрать /tmp так, что место заканчивается.
Восстанавливает без проблем. Не слышал, чтобы нужно было постоянно проверять дампы, как с жарптицей.

Еще в ОС надо бы поднять всякие sysctl-переменные для семафоров и разделяемой памяти.
Что-то типа:

kern.ipc.shmall=32768
kern.ipc.shmmax=134217728
kern.ipc.semmap=256

Советую ставить последнюю версию 8.2.x — там много интересного добавлено.

Работает стабильно, очень доволен.

спустя 7 часов [обр] 30-ый(4/584)[досье]

Во! Вспомнил проблему (по крайней мене с 8.1). Там нет безгемморойного инкрементного бэкапа. Стандартный dump бэкапит все одной транзакцией. Большая база такого подхода под нагрузкой не выдержит.

Есть функции кластеризации, и сохранения transaction-логов. Но это много морочнее обычного инкрементного лога как, например, в MS-SQL.

спустя 56 минут [обр] Дмитрий Кононов(0/16)[досье]
30-ый[досье] Да, через обычный pg_dump, похоже, не сделаешь.
Нашел вот что:
http://www.postgresql.org/docs/8.2/static/continuous-archiving.html
В MS-SQL с этим лучше?
Недавно перегонял данные из базы MS-SQL, так там в каждой таблице была добавлена колонка, содержащая GUID записи. Как потом объяснили, для выполнения репликации.
спустя 20 часов [обр] Thirteensmay(0/157)[досье]

Бог с ними с дампами, базы не гигабайтные, думаю переживем, dump(all) есть, если будет напряжно то можно переносить на ночь/тормозить выгребать быстренько прям из /data. Ну а в перспективе можно задуматься и о репликации master-slave или снапшотах ФС.

Однако натолкнуло, а есть ли у Postgre какие нибудь основы сбора ченьджей ? Желательно обеспечить возможность переноса изменений c девелоперского сервака на боевой, структуры (DDL), и желательно выборочно данных. Хотябы лог SQL инструкций, желательно по таблицам и DDL/DML отдельно. Настраиваемый ? Или возможность навешивания триггеров на базу/схему для расчленения этого там ? Или чтото готовое ?

спустя 26 минут [обр] 30-ый(4/584)[досье]

Дмитрий Кононов[досье] Да, да, именно этот "write ahead log" я и назвал "transaction-лог" в своей реплике. В MS-SQL тоже есть такая штука, но она нужна только для репликации или "бекапа до последней транзакции".

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

Thirteensmay[досье] Синхронизировать две базы стандартным комплектом нельзя. A где-то можно???. Рекомендую DB Comparer и Data Comparer.

Powered by POEM™ Engine Copyright © 2002-2005