PostgreSQLvsMySQL,

PG на две головы лучше СУБД, чём MySQL.

MySQL всегда был и останется дрянной СУБД, как ее не переделывай, из-за начальных ошибок в базовой архитектуре.

в PG тоже есть проблемы, не без того, но у кого их нет?

VladmlMasterZivPG на две головы лучше СУБД, чём MySQL.

А как быть с этим ?
https://habrahabr.ru/company/centosadmin/blog/322624/

Я пытаюсь разобраться в архитектуре обеих БД и честно говоря MySQL нравится больше.


Мне тоже сначала MySQL больше нравился.

У него там доки более дружественные, комьюнити больше (существенно), утилиты удобнее и пр. пр

VladmlMasterZiv из-за начальных ошибок в базовой архитектуре.

Можно с этого места по подробней?

MySQL в центре архитектуры имеет понятие storage endine и plugable storage endine architecture.
Это -- самый мощный тормоз развития MySQL и самое дурацкое архитектурное решение, которое портит почти всё.
Самое главное -- много storage endgine никому не нужно. Нужен ОДИН, но ХОРОШИЙ и транзакционный.

Распределённые запросы например НЕВОЗМОЖНО нормально реализовать на той же архитектуре engine, что и обычные запросы --
нужны 2PHCommit, нужны другие подходы к оптимизации.

Как следствие plugable storage engine architecture кэш данных отдан на откуп в engine, а это -- один из главнейших ресурсов любой СУБД, в итоге MyISAM вообще не поддерживает кэш данных (!).

Вследствии plugable storage engine architecture в MySQL нет и, видимо, уже никогда не будет нормальных бэкапов , консистентных, транзакционных, и т.п., также никогда не будет целостной базы данных.

mad_nazgulКак я уже и говорил проблема MySQL в том, что если программист написал фигню, то MySQL в начале попробует выполнить это фигню, и только если что-то не получится будет ругаться.


Ну, это совсем не главное, но да, есть такое, MySQL всегда были популистами, "а давайте запилим такую кульную фичу для наших WEB-пользователей", типа например как преславутый и никому не нужный кэш результатов запросов.

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

Кстати, вот подсистема, которая в MySQL всё же сделана лучше, это -- кодировки строк и collations. В PG -- отдано на откуп библиотеке C, что ну совсем странно для СУБД.

PostgreSQLvsMySQLИ вот теперь немного мучает вопрос, сколько здесь правды, а сколько лукавства?

Лукавства в материале товарища Klitzke, скорее всего, нет, наверняка Evan искренен в своих заблуждениях, но материал, как минимум, не однозначен.

Например, раздел про многопользовательскую работу и потоки vs процессы. Всем известно, что далеко не на всех операционных системах процессы и потоки так уж сильно отличаются, например, в Linux этой грани вообще почти нет. А если вспомнить, что многие матёрые СУБД работают именно на процессах в Unix/Linux, например, тот же Oracle, то вообще становится смешно.

Модель же многозадачности MySQL, наоборот, заслуживает некоторой критики, поскольку там тупо и просто: соединение -- ПОТОК!.
И не важно, что это соединение 20 часов в сутки стоять будет, ресурс OS типа "поток" будет закреплён за процессом MySQL до дисконнекта клиента.

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

VladmlMasterZiv,

Я как-то думал что plugable engine это скорее приемущество чем недостаток.


Ты думал неправильно.

VladmlДа и транзакционность длеко не всегда нужна.
С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так?


Я не понимаю, то тебе не всегда нужна транзакционность, то MyISAM никто уже не испльзует...
Если тебе не нужна транзакционность, тебе и СУБД не нужна вообще.
Дело в том, что ACID -- это такая фундаментальная штука для СУБД, что без неё СУБД --- кусок говна, а не СУБД.
При этом это не всегда все замечают, это как воздух -- дышишь каждую секунду, но не думаешь, что его наличие так важно.
А вот когда его НЕТ...

VladmlМне кажется хранилище PostgreSQL которое было разработано 20 лет назад и прибито гвоздями гораздо больший тормоз :)

Ты в курсе, что все оба хранилища MySQL были разработаны, вообще-то, немного раньше, чем аналогичные в Postgres ?
А уж о хранилище в Oracle или DB2 я вообще молчу ...

Какая разница КОГДА они были разработаны ? Это вообще самая тупая часть СУБД -- пакеты страниц и система, позволяющяя их организовывать по требованию, выделять и освобождать.

MasterZiv
Ты в курсе, что все оба хранилища MySQL были разработаны, вообще-то, немного раньше, чем аналогичные в Postgres ?
А уж о хранилище в Oracle или DB2 я вообще молчу ...


Ну, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста.

VladmlMasterZivНу, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста.

Да, но в MySQL можно легко изменить хранилище, или даже написать новое с нуля, чего не скажешь про Postgres.



Это никому не нужно, поверь.

VladmlВ Postgres не нравится что версионность реализована на уровне строк, даже если ты изменил 0 на 1, все версии строк хранятся
там-же где и актуальная строка, соответсвенно достум не по индексу будет медленней, ну изменение ctid и соответсветенно обновление всех индексов.


А на уровне чего тебе нравится версионность ? В InnoDB ровно та же самая версионность.
Ровно так же создаются версии записей. Ровно так же в дереве они прописываются.
Ровно так же будет читаться, если что , и откидываться.

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


Vladml
Чем конкретно плох InnoDB например?

InnoDB великолепен, плохо само ядро MySQL.

Vladml
Если говорить о MySQL то нужно говорить о конкретном хранилище.
InnoDB was first released as a part of MySQL in 2001.

InnoDB до этого существовал вне MySQL. Был (и есть) SolidDB, его старший но непутёвый брат, и вообще.
Но это всё неважно.

softwarerMasterZivНу и уж совсем смешно даже напоминать товарищу Эвану, что вообще-то в WEB-приложениях нужно использовать пулы соединений, и таким образом проблема использования больших ресурсов на одну клиентскую коннекцию к СУБД(даже если бы это был на самом деле) вообще не важна для таких приложений.
Это мне напоминает один случай, когда знакомый по онлайн игре в какой-то момент написал в чат, мол, я вот сейчас исследую вопрос, и по моему опыту MySQL - рулез, Oracle - говно. Я решил чуть раскопать его опыт. В итоге выяснилось следующее. Во-первых, софтина, которую он хотел заставить работать, последовательно выполняла несколько десятков тысяч запросов методом "открыл соединение - послал селект - закрыл соединение - открыл соединение - ...". А во-вторых, он водрузил всё это дело на дисковый массив без резерва по питанию, при этом сконфигурировав ОС так, словно этот резерв есть. В общем, с первым ему помогло просто включить в Оракле MTS вместо dedicated, а исправив второе, он перестал жаловаться, что после каждого шатдауна оракл начинает восстановление базы.

Ну, да, но сколько эта вот их статья шума наделала...