Вот есть ряд нареканий:
- совсем недавно у версии 8.3 появился нормальный инсталятор (под WIN ОС)
- совсем недавно появилась полноценной поддержки Win x64. И это при том, что СУБД вроде-бы как пригодна для работы с большими объемами данных в реальных приложениях и на реальных серверах
- 1 подключение(connection) == 1 процесс. Если у вас 3 БД и к каждой из них 10 подключений, то в диспетчере задач можно увидеть 30 процессов. Конечно-же может прийти в голову мысля об отказоустойчивости (мол если один процесс рухнет, то все остальные останутся), но практика не подтверждает эту надежду
- крайне не информативный лог. Пример сообщения: 'Фатальная ошибка. Процесс завершил свою работу. Exit code = 128'. Какой процесс? Почему завершил? Почему база не может автоматом подняться после краха и хоть как то восстановить свою работоспособность? И, в конце то концов, почему СУБД можно завалить простеньким DML запросом? Поиск по форуму показал, что данный exit code довольно универсальный, и может означать что 'что-то пошло не так' (гениально кеп!)
- крайне корявое взаимоотношение с Win платформами. Такое впечатление, что данная СУБД не умеет нормально работать с памятью в виндовсе. При нехватке этого ценнейшего ресурса (ОЗУ), приложение (сервис и пару десятков процессов) вываливаются и, как правило, помогает только перезагрузка ОС
- крайне убогий инструментарий администрирования. Например, для того, чтобы создать псевдо-оптимальные настройки СУБД (файл postgree.conf с учетом реального ОЗУ) пройдется поставить python, потом понять что нужна именно старая версия питона, потом разобраться со скриптом, его настройками и его использованием. Потом вам cгенерируют 'псевдо-оптимальный' конфиг, при использовании которого легко убедится в его 'псевдо-полезности'
- особого внимания заслуживает инструмент под названием pgadmin. Как то сразу вспоминаются лабораторные работы на C++ Builder. Вот, к примеру, для восстановления БД из дампа, существует диалог (написанный не иначе как студентом за зачет). Особенно радует в этом диалоге индикация прогресса: при нажатии кнопки OK все подвисает. Т.е. настолько, что окно не перерисовывается. И висит до того момента, пока не случится ошибка или не закончится восстановление ( может 20 сек, а может 30 минут). Исход процесса можно определить по строке exit code: '0' – повезло , '1' - предлагается возможность блеснуть своими знаниями, и интуицией
- особенно радует совместимость дампов. Дамп сохраненный версией 8.4.4 ни в коем случае не получится развернуть на СУБД 8.4.3.
...хотя находятся отважные люди, которые выбирают ее как основу для своего приложения для активной работы с большими объемами данных.
>> совсем недавно у версии 9.3
ОтветитьУдалитьТы не чего не путаешь, по-моему только недавно 9.0 вышла?
таки да, путаю.
ОтветитьУдалитьУ версии 8.3 появился.
Не могу ничего сказать, про Windows, но в Linux/Unix эта СУБД чувствует и ведет себя просто чудесно. В частности, используем эту СУБД для web-систем с большим и нагрузками, и все отлично и стабильно работает.
ОтветитьУдалитьХорошо вам.
ОтветитьУдалитьМы (вродибы) тоже 'подружились': а) отдал почти 1,5ГБ ОЗУ, отключил принудительный флуш данных на диски ограничил число подключений до 10-15. При таком раскладе она на Win чувствует себя неплохо...