Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
 Postgres vs MySQL  [new]
PostgreSQLvsMySQL
Guest
Тема конечно несколько старовата, и всё же пройти мимо не позволяет профессиональный интерес.
Некоторое время назад один из известных сервисов провел миграцию с PostgreSQL на MySQL:
Uber — причины перехода с Postgres на MySQL
И вот несколько позже один из 43 Major Contributors PostgreSQL разобрал пост Uber’а глазами разработчика PostgreSQL и сделал обзор предпринятых сообществом попыток преодолеть указанные недостатки.

И вот теперь немного мучает вопрос, сколько здесь правды, а сколько лукавства?
10 апр 17, 18:06    [20386267]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30233
PostgreSQLvsMySQL,

да вроде все верно расписал кривость индексов+версионности в PG. Ну и про репликацию тоже.

Собственно, "у всех есть свои недостатки".
10 апр 17, 22:35    [20387073]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Бумбараш
Member

Откуда: никем не победимая, самая любимая
Сообщений: 3057
https://www.sql.ru/forum/1225103/uber-ushyol-s-pg-na-mysql
10 апр 17, 23:44    [20387198]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
PostgreSQLvsMySQL,

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

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

в PG тоже есть проблемы, не без того, но у кого их нет?
13 апр 17, 07:20    [20396637]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Vladml
Member

Откуда:
Сообщений: 146
MasterZiv
PG на две головы лучше СУБД, чём MySQL.

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

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

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

Можно с этого места по подробней?
13 апр 17, 20:17    [20400429]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
Vladml
MasterZiv
PG на две головы лучше СУБД, чём MySQL.

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

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


Как я уже и говорил проблема MySQL в том, что если программист написал фигню, то MySQL в начале попробует выполнить это фигню, и только если что-то не получится будет ругаться.
PostgreSQL сразу начинает ругаться.
С uber'ом была это же проблема.
Они хотели странного от PostgreSQL, он активно сопротивлялся.
MySQL - позволял говнокодить.
MySQL - круто, т.к. дает нам говнокодить.

P.S. Сколько сталкивался с MySQL он везде мне доставлял проблемы.
Причем понять, почему очень сложно. Т.к. он не ругался на ошибки, а что-то делал.
Причем как сам это понимал.
С PostgreSQL проще. Он сразу говорит - тут фигня.
14 апр 17, 06:12    [20400984]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Vladml
MasterZiv
PG на две головы лучше СУБД, чём MySQL.

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

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


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

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

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

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


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

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

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

Вследствии plugable storage engine architecture в MySQL нет и, видимо, уже никогда не будет нормальных бэкапов , консистентных, транзакционных, и т.п., также никогда не будет целостной базы данных.
6 июн 17, 18:58    [20544575]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

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


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

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

Кстати, вот подсистема, которая в MySQL всё же сделана лучше, это -- кодировки строк и collations. В PG -- отдано на откуп библиотеке C, что ну совсем странно для СУБД.
6 июн 17, 19:03    [20544584]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Vladml
Member

Откуда:
Сообщений: 146
MasterZiv,

Я как-то думал что plugable engine это скорее приемущество чем недостаток. Да и транзакционность длеко не всегда нужна.
С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так?

Мне кажется хранилище PostgreSQL которое было разработано 20 лет назад и прибито гвоздями гораздо больший тормоз :)
6 июн 17, 22:29    [20545020]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
Vladml
MasterZiv,

Я как-то думал что plugable engine это скорее приемущество чем недостаток. Да и транзакционность длеко не всегда нужна.
С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так?


В случае MySQL - это недостаток, т.к. что то дерьмо, что это дерьмо.

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


С точностью до наоборот.
На простых запросах (как минимум раньше так было)
Да MySQL обгонял PostgreSQL и скорость чтения была почти такая как чтение текстового файла.
Ну а как только что-то было посложнее "select * from table", то PostgreSQL чувствовал себя более уверенно.

Кстати движек PostgreSQL достаточно активно переписывается.
Вводятся новые "фичи".
Просто разработчики PostgreSQL люди консервативные и основательные.
Поэтому каждое изменение проходит долгий путь.
7 июн 17, 07:14    [20545369]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
PostgreSQLvsMySQL
И вот теперь немного мучает вопрос, сколько здесь правды, а сколько лукавства?


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

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

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

Ну и уж совсем смешно даже напоминать товарищу Эвану, что вообще-то в WEB-приложениях нужно использовать пулы соединений, и таким образом проблема использования больших ресурсов на одну клиентскую коннекцию к СУБД(даже если бы это был на самом деле) вообще не важна для таких приложений.
7 июн 17, 11:09    [20545947]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Vladml
MasterZiv,

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


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

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


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

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


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

Какая разница КОГДА они были разработаны ? Это вообще самая тупая часть СУБД -- пакеты страниц и система, позволяющяя их организовывать по требованию, выделять и освобождать.
7 июн 17, 11:15    [20545975]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
MasterZiv

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


Ну, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста.
7 июн 17, 11:20    [20546005]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Vladml
Member

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


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

MasterZiv
Например, раздел про многопользовательскую работу и потоки vs процессы. Всем известно, что далеко не на всех операционных системах процессы и потоки так уж сильно отличаются, например, в Linux этой грани вообще почти нет.

Разве создание процесса не требует вызова fork?
Если бы это было бы так, то наверное не появился PgBouncer.


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

Чем конкретно плох InnoDB например?
7 июн 17, 12:55    [20546554]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Vladml
Member

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


Если говорить о MySQL то нужно говорить о конкретном хранилище.
InnoDB was first released as a part of MySQL in 2001.
On 26 December 2008 Percona announced that they've created a forked version of InnoDB, called XtraDB, with additional features and performance enhancements.

В мире хранилищ РСУБД действительно не так часто бывают изменения, но все-таки они есть, и по моему очень хорошо иметь возможноть делать эти изменения. К тому-же есть несколько MySQL совместимых проекта, MariaDb и Percona.
7 июн 17, 13:05    [20546600]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
petalvik
Member

Откуда:
Сообщений: 737
PostgreSQLvsMySQL
Uber — причины перехода с Postgres на MySQL


А Яндекс не так давно перешёл с Oracle на PostgreSQL.

О чём это говорит? О том, что постгрес лучше оракла, а мускуль лучше постгреса. Вывод: мускуль лучше оракла. :D
7 июн 17, 13:20    [20546675]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
bochkov
Member

Откуда: Камчатка
Сообщений: 4093
да все СУБД нормальные
что поставили то и пилишь
нет таких задач, которые нельзя решить
просто одни задачи решаются легко, другие труднее
тут как "мед или малина"
7 июн 17, 13:58    [20546829]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

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


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



Это никому не нужно, поверь.
7 июн 17, 15:02    [20547175]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

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


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

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


Vladml

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


InnoDB великолепен, плохо само ядро MySQL.
7 июн 17, 15:08    [20547211]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709
Vladml

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


InnoDB до этого существовал вне MySQL. Был (и есть) SolidDB, его старший но непутёвый брат, и вообще.
Но это всё неважно.
7 июн 17, 15:10    [20547233]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
Vladml
Member

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



В том-то и дело что MVCC в InnoDB и Postgres реализораны абсолютно по разному.

InnoDB is a multi-versioned storage engine: it keeps information about old versions of changed rows, to support transactional features such as concurrency and rollback. This information is stored in the tablespace in a data structure called a rollback segment (after an analogous data structure in Oracle)

Вообще у MySQL много общего с Oracle что в общем-то и не удивительно :) и даже есть вещи которых нет в оракле например file per table и handle socket.
7 июн 17, 15:40    [20547359]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
softwarer
Member

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

Это мне напоминает один случай, когда знакомый по онлайн игре в какой-то момент написал в чат, мол, я вот сейчас исследую вопрос, и по моему опыту MySQL - рулез, Oracle - говно. Я решил чуть раскопать его опыт. В итоге выяснилось следующее. Во-первых, софтина, которую он хотел заставить работать, последовательно выполняла несколько десятков тысяч запросов методом "открыл соединение - послал селект - закрыл соединение - открыл соединение - ...". А во-вторых, он водрузил всё это дело на дисковый массив без резерва по питанию, при этом сконфигурировав ОС так, словно этот резерв есть. В общем, с первым ему помогло просто включить в Оракле MTS вместо dedicated, а исправив второе, он перестал жаловаться, что после каждого шатдауна оракл начинает восстановление базы.
7 июн 17, 19:19    [20548173]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
MasterZiv
Member

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

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


Ну, да, но сколько эта вот их статья шума наделала...
9 июн 17, 15:46    [20553555]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
mad_nazgul
Member

Откуда:
Сообщений: 5824
MasterZiv
Ну, да, но сколько эта вот их статья шума наделала...


Да шума никакого не было.
Постебались над программистами UBER, да и забыли. :-)
11 июн 17, 14:17    [20556576]     Ответить | Цитировать Сообщить модератору
 Re: Postgres vs MySQL  [new]
mayton
Member

Откуда: loopback
Сообщений: 52917
Я как-то делал экспорт (или дамп?) средствами mysql одного тестового проекта.
И меня очень сильно удивил формат dml операций insert, где вместо кавычек
по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону).
Словом шлак. Совершенно непонятно чем создателям не подошли
обычные quot, apos. И редактировать неудобно.
14 июл 17, 20:46    [20646032]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить