Недостатки PostgreSQL?

Question

[Валерий]

Пишу диплом, описываю что из себя представляет PostgreSQL. Достоинства написал, а вот с недостатками у меня проблема.
Кто долгое время работал с данной СУБД, опишите максимально подробно с какими проблемами сталкивались?
Спасибо за внимание!

Comments

[Владислав Лысков]

А какие достоинства?

[Валерий]

Владислав Лысков, Я выделил для себя такие особенности PostgreSQL

1. Модель данных – PostgreSQL не просто реляционная, а объектно-реляционная СУБД. Это даёт ему некоторые преимущества над другими SQL базами данных с открытым исходным кодом, такими как MySQL, MariaDB и Firebird. Фундаментальная характеристика объектно-реляционной базы данных – это поддержка пользовательских объектов и их поведения, включая типы данных, функции, операции, домены и индексы. Это делает PostgreSQL невероятно гибким и надежным. Среди прочего, он умеет создавать, хранить и извлекать сложные структуры данных.
2. Структуры и типы данных – cуществует обширный список типов данных, которые поддерживает PostgreSQL. Кроме числовых, с плавающей точкой, текстовых, булевых и других ожидаемых типов данных (а также множества их вариаций), PostgreSQL может похвастаться поддержкой uuid, денежного, перечисляемого, геометрического, бинарного типов, сетевых адресов, битовых строк, текстового поиска, xml, json, массивов, композитных типов и диапазонов, а также некоторых внутренних типов для идентификации объектов и местоположения логов.
 
3. Многомерные массивы – поскольку PostgreSQL это объектно-реляционная база данных, массивы значений могут храниться для большинства существующих типов данных. Сделать это можно путём добавления квадратных скобок к спецификации типа данных для столбца или с помощью выражения ARRAY. Размер массива может быть задан, но это необязательно;
4. Поддержка JSON – в PostgreSQL позволяет вам перейти к хранению schema-less данных в SQL базе данных. Это может быть полезно, когда структура данных требует определённой гибкости: например, если в процессе разработки структура всё ещё меняется или неизвестно, какие поля будет содержать объект данных;
5. Целостность данных – PostgreSQL стремится соответствовать стандарту ANSI-SQL:2008, отвечает требованиям ACID (атомарность, согласованность, изолированность и надежность) и известен своей ссылочной и транзакционной целостностью. Первичные ключи, ограничивающие и каскадные внешние ключи, уникальные ограничения, ограничения NOT NULL, проверочные ограничения и другие функции обеспечения целостности данных дают уверенность, что только корректные данные будут сохранены.

[galaxy]

Валерий, позвольте прокомментировать:

1. "PostgreSQL не просто реляционная, а объектно-реляционная СУБД" - маркетинг какой-то, честно говоря, не понимаю, что это значит, даже после пояснений. В PG есть условно объектные фишки (наследование таблиц, полиморфизм, те же композитные типы), но, на мой взгляд, часто это призраки из прошлого.

2. По-моему, это примерно то же, что и 1. Я бы оба этих пункта объеденил и назвал "расширяемость" или "гибкость".

PostgreSQL может похвастаться поддержкой uuid, денежного, перечисляемого, геометрического, бинарного типов, сетевых адресов, битовых строк, текстового поиска, xml, json, массивов, композитных типов и диапазонов

ну, многое из этого есть и в других СУБД.

3. Такая небольшая фишка, ограниченного применения, особенно многомерные массивы. Уж если нужно работать с денормализованными данными, тот же json мощнее.

4. Это сейчас общая тенденция. До этого все внедряли xml, теперь json (да и в стандарте SQL все это появилось).

5. Вот это реальное преимущество, точнее несколько. Следование стандарту (тут как раз другие СУБД часто кто в лес, кто по дрова; иногда у них по историческим причинам своя реализация, иногда просто художник так видит).
ACID - конечно, тоже. Хотя это заметно в основном на фоне mysql, нормальные СУБД все же всегда уважали ACID.

Накидаю еще особенностей/преимуществ:

• Поддержка разных процедурных языков (и реальное наличие многих из коробки)
  
• Специальные типы индексов и возможность создания новых
  GIN/GIST позволяют индексировать вещи, которые по-другому вообще непонятно, как индексировать. Причем их часто несложно расширить на новые типы. Можно вообще создавать полностью свои виды индексов, хотя не то чтобы это работа для DBA/DBD.
  
• Геометрические типы
  Вы отмечали про множество типов и расширяемость, я бы просто выделил именно это, как минимум за PostGIS.
  
• Расширямые операторы
  Вы это тоже упоминали вскользь. На самом деле редкая фишка, позволяет PG синтаксически очень упростить использование тех же новых типов XML/JSON и геометрии
  
• FDW (Foreign data wrappers)
  Позволяет прозрачно работать с удаленными БД, файлами и другими источниками данных, включая многие другие СУБД
  
• Расширения (extensions)
  Немало интересных и полезных. Конечно, можно писать свои, имея соответствующие навыки.
  

Без какого-то рейтинга, просто (неполный) список того, что мне кажется важным и уникальным (или редким в мире СУБД)

Answer 1

[galaxy]

Самая большая проблема - это архитектура MVCC, которая вызывает распухание таблиц, требует наличие vacuum'инга, и в многих случаях не способствует производительности.

Но советую все же самому погуглить (для затравки - https://habr.com/ru/company/southbridge/blog/322624/). Будет гораздо проще и полезнее, если вы нагуглите какие-то особенности, а специалисты тут подскажут, насколько они актуальны и критичны.

Comments

[Валерий]

Я вот как раз читал данную статью и вот у меня возникли сомнения в актуальности данных описанных в ней, все таки статья 2017 года. PostgreSQL пережил, множество обновлений с того времени.

[galaxy]

Валерий, там есть неактуальные вещи, да, как и в куче других статей типа mysql vs postgres. Поэтому и предлагаю: найдите сами недостатки и попросите местное сообщество дать им оценку с учетом современных реалий.

Answer 2

[ky0]

"Как бы недостатки", постоянно обсасываемые ораклово-майкрософтовскими фанбоями - отсутствие мультимастера из коробки и автоматической настройки в зависимости от параметров железа (процессор, память, диски).

Comments

[Ерлан Ибраев]

Согласен. У PostgreSQL "все удобства во дворе".
А так. PostgreSQL у меня вызывала наименьшее количество вопросов.
От Oracle, MS SQL периодически хочется плеваться.
Ну а MySQL, по моему, это жесть, как она есть.

[Евгений]

Ерлан Ибраев, а чего с mysql то не так?

[Александр Черных]

Ерлан Ибраев,

Ну а MySQL, по моему, это жесть, как она есть

Расскажите Ваш опыт

[ky0]

Я понял, что с mysql мы не сработаемся в промышленных масштабах, когда узнал, что любой пишуший запрос по реплике ставит её колом и требует потом приседаний для восстановления синхронизации :) Мне это на фоне постгреса прямо что-то так не понравилось... Мелочь, конечно, но неприятно.

[Ерлан Ибраев]

Мой опыт
1) Кодировки. Когда админ создал БД в не той кодировке, мне потом пришлось долго это править. Т.к. кодировку пришлось менять не только на БД и таблицах по отдельности. Но ещё и на конкретных полях.
2) Тихое закрытие соединения, если не было долго запросов. Тут проблема с двух сторон с MySQL и JDBC-драйверов MySQL. MySQL по тихому закрывает соединение если не было долго активности. При этом ничего не сообщает драйверу. Из-за этого в пуле соединений сервера-сервлетов куча "протухших" соединений, которые лечатся только рестартом.
3) Своебразное работа с типами. Вместо того чтобы честно "упасть" пытается привести тип к чему-то. Пару раз налетал.
В принципе мне этого хватило, чтобы обходить MySQL десятой дорогой. :-)

[Vitsliputsli]

Ерлан Ибраев,
1) кодировки - это структурные изменения, а это всегда и везде боль, если мы говорим о нагруженной системе.
2) не понимаю, зачем держать открытым соединение и не использовать его? Наоборот, всегда закрываешь соединение, если оно не исопльзуется, если бережешь ресурсы.
3) Есть такое, некая динамическая типизация. Согласен, польза очень сомнительная, а проблем от нее огребаешь много, пока не привыкнешь всегда о ней помнить.
И это не все проблемы, но проблем хватает и в других СУБД, по-сути всегда приходится мириться с чем-то, ради чего-то. MySQL очень быстрая СУБД, это отличный выбор для нагруженных систем (если говорить о Percona), с оговоркой, что вы используете СУБД как базу данных, если нужно чтобы СУБД варила кофе, это точно не про MySQL.

[Ерлан Ибраев]

Vitsliputsli,
1) В других СУБД при смене кодировки на БД, следующие данные сохраняются в нужной кодировке. У MySQL "свое мнение"
2) Затем, что так работает сервер приложений/сервлетов. Создает пул соединений. И сервер, если их "закрывает" должен подать сигнал, что соединение разрывается. MySQL это не делало, либо драйвер JDBC для MySQL этот сигнал не обрабатывал.

С PostgreSQL таких WTF лично у меня не было. PostgreSQL вела себя всегда логично. И "помнить особенности" не нужно было.
Даже когда при переходе с PostgrSQL 7 на PostgrSQL 8 функциям (ХП) запретили отдавать не типизированные RecordSet, это было логично, хотя и не удобно.

С MySQL это как ходить по минному полю, непонятно где и что вылезет.

[Vitsliputsli]

Ерлан Ибраев, спасибо.
Кодировка вещь структурная, не очень понимаю, как можно одновременно в разных кодировках хранить?
Интересный момент, вроде не было таких проблем с proxySQL. Может действительно проблема в jdbc.
По поводу типизации, как уже писал, согласен абсолютно, хрень полная.

[Ерлан Ибраев]

Vitsliputsli, У меня такой же был WTF с MySQL. Ну я же поменял кодировку в БД, почему в таблице сохраняет по старому? Оказывается нужно было не только в БД, но и таблице и в текстовых полях менять кодировку. Зачем?!
В общем после таких приключений я обхожу MySQL стороной. :-)

[Vitsliputsli]

Ерлан Ибраев, а, вы про это, да, каждое поле может иметь свою кодировку - это нормально, и вероятно даже где-то удобно, мне тоже это никогда не было нужно, но кому-то может понадобится.

[Ерлан Ибраев]

Vitsliputsli, Да. Но если я меняю кодировку на всей таблице, то я предполагаю, что она поменяется на всей таблице. Но нет. Мне нужно пройтись по всем таблице и полям в таблице, чтобы поменять кодировку.