|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Тема конечно несколько старовата, и всё же пройти мимо не позволяет профессиональный интерес. Некоторое время назад один из известных сервисов провел миграцию с PostgreSQL на MySQL: Uber — причины перехода с Postgres на MySQL И вот несколько позже один из 43 Major Contributors PostgreSQL разобрал пост Uber’а глазами разработчика PostgreSQL и сделал обзор предпринятых сообществом попыток преодолеть указанные недостатки. И вот теперь немного мучает вопрос, сколько здесь правды, а сколько лукавства? ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2017, 18:06 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PostgreSQLvsMySQL, да вроде все верно расписал кривость индексов+версионности в PG. Ну и про репликацию тоже. Собственно, "у всех есть свои недостатки". ... |
|||
:
Нравится:
Не нравится:
|
|||
10.04.2017, 22:35 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PostgreSQLvsMySQL, PG на две головы лучше СУБД, чём MySQL. MySQL всегда был и останется дрянной СУБД, как ее не переделывай, из-за начальных ошибок в базовой архитектуре. в PG тоже есть проблемы, не без того, но у кого их нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2017, 07:20 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivPG на две головы лучше СУБД, чём MySQL. А как быть с этим ? https://habrahabr.ru/company/centosadmin/blog/322624/ Я пытаюсь разобраться в архитектуре обеих БД и честно говоря MySQL нравится больше. MasterZiv из-за начальных ошибок в базовой архитектуре. Можно с этого места по подробней? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.04.2017, 20:17 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlMasterZivPG на две головы лучше СУБД, чём MySQL. А как быть с этим ? https://habrahabr.ru/company/centosadmin/blog/322624/ Я пытаюсь разобраться в архитектуре обеих БД и честно говоря MySQL нравится больше. Как я уже и говорил проблема MySQL в том, что если программист написал фигню, то MySQL в начале попробует выполнить это фигню, и только если что-то не получится будет ругаться. PostgreSQL сразу начинает ругаться. С uber'ом была это же проблема. Они хотели странного от PostgreSQL, он активно сопротивлялся. MySQL - позволял говнокодить. MySQL - круто, т.к. дает нам говнокодить. P.S. Сколько сталкивался с MySQL он везде мне доставлял проблемы. Причем понять, почему очень сложно. Т.к. он не ругался на ошибки, а что-то делал. Причем как сам это понимал. С PostgreSQL проще. Он сразу говорит - тут фигня. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.04.2017, 06:12 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
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 нет и, видимо, уже никогда не будет нормальных бэкапов , консистентных, транзакционных, и т.п., также никогда не будет целостной базы данных. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 18:58 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mad_nazgulКак я уже и говорил проблема MySQL в том, что если программист написал фигню, то MySQL в начале попробует выполнить это фигню, и только если что-то не получится будет ругаться. Ну, это совсем не главное, но да, есть такое, MySQL всегда были популистами, "а давайте запилим такую кульную фичу для наших WEB-пользователей", типа например как преславутый и никому не нужный кэш результатов запросов. Postgres более тяжёлый в этом плане, у него комьюнити более строгое, меньше раздолбаев и лохов. Но и с этим есть проблемы, конечно -- тяжелее процесс изменения. Кстати, вот подсистема, которая в MySQL всё же сделана лучше, это -- кодировки строк и collations. В PG -- отдано на откуп библиотеке C, что ну совсем странно для СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 19:03 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZiv, Я как-то думал что plugable engine это скорее приемущество чем недостаток. Да и транзакционность длеко не всегда нужна. С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так? Мне кажется хранилище PostgreSQL которое было разработано 20 лет назад и прибито гвоздями гораздо больший тормоз :) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.06.2017, 22:29 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlMasterZiv, Я как-то думал что plugable engine это скорее приемущество чем недостаток. Да и транзакционность длеко не всегда нужна. С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так? В случае MySQL - это недостаток, т.к. что то дерьмо, что это дерьмо. VladmlМне кажется хранилище PostgreSQL которое было разработано 20 лет назад и прибито гвоздями гораздо больший тормоз :) С точностью до наоборот. На простых запросах (как минимум раньше так было) Да MySQL обгонял PostgreSQL и скорость чтения была почти такая как чтение текстового файла. Ну а как только что-то было посложнее "select * from table", то PostgreSQL чувствовал себя более уверенно. Кстати движек PostgreSQL достаточно активно переписывается. Вводятся новые "фичи". Просто разработчики PostgreSQL люди консервативные и основательные. Поэтому каждое изменение проходит долгий путь. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 07:14 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PostgreSQLvsMySQLИ вот теперь немного мучает вопрос, сколько здесь правды, а сколько лукавства? Лукавства в материале товарища Klitzke, скорее всего, нет, наверняка Evan искренен в своих заблуждениях, но материал, как минимум, не однозначен. Например, раздел про многопользовательскую работу и потоки vs процессы. Всем известно, что далеко не на всех операционных системах процессы и потоки так уж сильно отличаются, например, в Linux этой грани вообще почти нет. А если вспомнить, что многие матёрые СУБД работают именно на процессах в Unix/Linux, например, тот же Oracle, то вообще становится смешно. Модель же многозадачности MySQL, наоборот, заслуживает некоторой критики, поскольку там тупо и просто: соединение -- ПОТОК!. И не важно, что это соединение 20 часов в сутки стоять будет, ресурс OS типа "поток" будет закреплён за процессом MySQL до дисконнекта клиента. Ну и уж совсем смешно даже напоминать товарищу Эвану, что вообще-то в WEB-приложениях нужно использовать пулы соединений, и таким образом проблема использования больших ресурсов на одну клиентскую коннекцию к СУБД(даже если бы это был на самом деле) вообще не важна для таких приложений. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:09 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlMasterZiv, Я как-то думал что plugable engine это скорее приемущество чем недостаток. Ты думал неправильно. VladmlДа и транзакционность длеко не всегда нужна. С MyISAM понятно, уже никто не использует, а вот с InnoDB или XtraDB что не так? Я не понимаю, то тебе не всегда нужна транзакционность, то MyISAM никто уже не испльзует... Если тебе не нужна транзакционность, тебе и СУБД не нужна вообще. Дело в том, что ACID -- это такая фундаментальная штука для СУБД, что без неё СУБД --- кусок говна, а не СУБД. При этом это не всегда все замечают, это как воздух -- дышишь каждую секунду, но не думаешь, что его наличие так важно. А вот когда его НЕТ... VladmlМне кажется хранилище PostgreSQL которое было разработано 20 лет назад и прибито гвоздями гораздо больший тормоз :) Ты в курсе, что все оба хранилища MySQL были разработаны, вообще-то, немного раньше, чем аналогичные в Postgres ? А уж о хранилище в Oracle или DB2 я вообще молчу ... Какая разница КОГДА они были разработаны ? Это вообще самая тупая часть СУБД -- пакеты страниц и система, позволяющяя их организовывать по требованию, выделять и освобождать. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:15 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZiv Ты в курсе, что все оба хранилища MySQL были разработаны, вообще-то, немного раньше, чем аналогичные в Postgres ? А уж о хранилище в Oracle или DB2 я вообще молчу ... Ну, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 11:20 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivНу, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста. Да, но в MySQL можно легко изменить хранилище, или даже написать новое с нуля, чего не скажешь про Postgres. MasterZivНапример, раздел про многопользовательскую работу и потоки vs процессы. Всем известно, что далеко не на всех операционных системах процессы и потоки так уж сильно отличаются, например, в Linux этой грани вообще почти нет. Разве создание процесса не требует вызова fork? Если бы это было бы так, то наверное не появился PgBouncer. В Postgres не нравится что версионность реализована на уровне строк, даже если ты изменил 0 на 1, все версии строк хранятся там-же где и актуальная строка, соответсвенно достум не по индексу будет медленней, ну изменение ctid и соответсветенно обновление всех индексов. Чем конкретно плох InnoDB например? ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 12:55 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 13:05 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PostgreSQLvsMySQLUber — причины перехода с Postgres на MySQL А Яндекс не так давно перешёл с Oracle на PostgreSQL. О чём это говорит? О том, что постгрес лучше оракла, а мускуль лучше постгреса. Вывод: мускуль лучше оракла. :D ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 13:20 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
да все СУБД нормальные что поставили то и пилишь нет таких задач, которые нельзя решить просто одни задачи решаются легко, другие труднее тут как "мед или малина" ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 13:58 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlMasterZivНу, может про возраст обеих СУБД я немного приврал, вроде как PG c 85-го разрабатывалась, а MySQL с 95, но всё равно они примерно одного возраста. Да, но в MySQL можно легко изменить хранилище, или даже написать новое с нуля, чего не скажешь про Postgres. Это никому не нужно, поверь. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 15:02 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlВ Postgres не нравится что версионность реализована на уровне строк, даже если ты изменил 0 на 1, все версии строк хранятся там-же где и актуальная строка, соответсвенно достум не по индексу будет медленней, ну изменение ctid и соответсветенно обновление всех индексов. А на уровне чего тебе нравится версионность ? В InnoDB ровно та же самая версионность. Ровно так же создаются версии записей. Ровно так же в дереве они прописываются. Ровно так же будет читаться, если что , и откидываться. Одно там не так -- нет отложенного удаления старых версий, vacum не делается отложенно, а делается сразу. Как думаешь, почему ? Одна из причин -- в интерфейсе Engine нет места, куда можно было бы воткнуть этот функционал. Vladml Чем конкретно плох InnoDB например? InnoDB великолепен, плохо само ядро MySQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 15:08 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Vladml Если говорить о MySQL то нужно говорить о конкретном хранилище. InnoDB was first released as a part of MySQL in 2001. InnoDB до этого существовал вне MySQL. Был (и есть) SolidDB, его старший но непутёвый брат, и вообще. Но это всё неважно. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 15:10 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
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. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 15:40 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivНу и уж совсем смешно даже напоминать товарищу Эвану, что вообще-то в WEB-приложениях нужно использовать пулы соединений, и таким образом проблема использования больших ресурсов на одну клиентскую коннекцию к СУБД(даже если бы это был на самом деле) вообще не важна для таких приложений. Это мне напоминает один случай, когда знакомый по онлайн игре в какой-то момент написал в чат, мол, я вот сейчас исследую вопрос, и по моему опыту MySQL - рулез, Oracle - говно. Я решил чуть раскопать его опыт. В итоге выяснилось следующее. Во-первых, софтина, которую он хотел заставить работать, последовательно выполняла несколько десятков тысяч запросов методом "открыл соединение - послал селект - закрыл соединение - открыл соединение - ...". А во-вторых, он водрузил всё это дело на дисковый массив без резерва по питанию, при этом сконфигурировав ОС так, словно этот резерв есть. В общем, с первым ему помогло просто включить в Оракле MTS вместо dedicated, а исправив второе, он перестал жаловаться, что после каждого шатдауна оракл начинает восстановление базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.06.2017, 19:19 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
softwarerMasterZivНу и уж совсем смешно даже напоминать товарищу Эвану, что вообще-то в WEB-приложениях нужно использовать пулы соединений, и таким образом проблема использования больших ресурсов на одну клиентскую коннекцию к СУБД(даже если бы это был на самом деле) вообще не важна для таких приложений. Это мне напоминает один случай, когда знакомый по онлайн игре в какой-то момент написал в чат, мол, я вот сейчас исследую вопрос, и по моему опыту MySQL - рулез, Oracle - говно. Я решил чуть раскопать его опыт. В итоге выяснилось следующее. Во-первых, софтина, которую он хотел заставить работать, последовательно выполняла несколько десятков тысяч запросов методом "открыл соединение - послал селект - закрыл соединение - открыл соединение - ...". А во-вторых, он водрузил всё это дело на дисковый массив без резерва по питанию, при этом сконфигурировав ОС так, словно этот резерв есть. В общем, с первым ему помогло просто включить в Оракле MTS вместо dedicated, а исправив второе, он перестал жаловаться, что после каждого шатдауна оракл начинает восстановление базы. Ну, да, но сколько эта вот их статья шума наделала... ... |
|||
:
Нравится:
Не нравится:
|
|||
09.06.2017, 15:46 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivНу, да, но сколько эта вот их статья шума наделала... Да шума никакого не было. Постебались над программистами UBER, да и забыли. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
11.06.2017, 14:17 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Я как-то делал экспорт (или дамп?) средствами mysql одного тестового проекта. И меня очень сильно удивил формат dml операций insert, где вместо кавычек по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону). Словом шлак. Совершенно непонятно чем создателям не подошли обычные quot, apos. И редактировать неудобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 20:46 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonЯ как-то делал экспорт (или дамп?) средствами mysql одного тестового проекта. И меня очень сильно удивил формат dml операций insert, где вместо кавычек по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону). Словом шлак. Совершенно непонятно чем создателям не подошли обычные quot, apos.А ты подумай. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 21:43 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mad_nazgulP.S. Сколько сталкивался с MySQL он везде мне доставлял проблемы. Причем понять, почему очень сложно. Т.к. он не ругался на ошибки, а что-то делал. Причем как сам это понимал. С PostgreSQL проще. Он сразу говорит - тут фигня. Присоединяюсь. Не раз с майсиквелом попадали в ловушки. С PG как то все более предсказуемо. Шо касаемо производительности, дак вот чего хотел бы сказать, На простых вещай, равного майсиквелу нет и не будет, он всех обскачет. Но как только база росла, то нетривиальные запросы он начал жутко ступорить, я бы сказал даже впадал в кому на пару минут. Чего тока не делали. Кончилось тем что сделали миграцию с майсиквела на Аракакл и готовы были купить стандард эдишэн. Но та миграция так и не попала на продуктовку. когда Аракакл обрезал ядра у стандарт эдишэн, решили его прокинуть и смигрировать на Постгрес. На одинаковом железе и одной и той же оське ( OEL7 ) Постргес и Аракакл показали примерно одинаковые результаты. Тесты не какие то абстрактные бэнчи, а реальное Web приложение. Не, не подумайте, я не загоняю майсиквел в полный ацтой, у него есть своя ниша, и он ее прекрасно держит. Но для энтерпрайс систем или тем более банкинга я бы его не пользовал. Его красота и простота в конце концов апсирается кучей проблем и косяков. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 21:57 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
ad-dc, Да ладно вам. Раньше и банкинг и энтерпрайз на dBase и клиппере писали и ничего. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:13 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HunterА ты подумай. Это прозвучало грубо. Как-то ... недостойно пятничной дискуссии. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:42 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton, Просто не ожидал от такого уважаемого мембера поста, как этотmaytonИ меня очень сильно удивил формат dml операций insert, где вместо кавычек по какой-то странной причине вставлены символы back apos (апостроф в обратную сторону). Словом шлак. Совершенно непонятно чем создателям не подошли обычные quot, apos Если-бы были апострофы (') то поля превратились бы в литералы-строки. И меня это не удивило ни разу. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 22:59 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HunterЕсли-бы были апострофы (') то поля превратились бы в литералы-строки. И меня это не удивило ни разу. А почему они не превращаются в других форматах экспорта или дампа от других производителей dbms? ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:13 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton, У MSSQL скобками полей являются [field], что еще хуже, т.к. их два а не один, как в MySQL. По-моему довольно изящное решение. Респект создателям однозначно. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:21 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonА почему они не превращаются в других форматах экспорта или дампа от других производителей dbms?По-моему одинарный квот - везде признак строки-литерала. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:27 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Relic HuntermaytonА почему они не превращаются в других форматах экспорта или дампа от других производителей dbms?По-моему одинарный квот - везде признак строки-литерала. А ты подумай (с) тролл на самом деле нет,и уж тем более обратный ` ... |
|||
:
Нравится:
Не нравится:
|
|||
14.07.2017, 23:54 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
MasterZivКстати, вот подсистема, которая в MySQL всё же сделана лучше, это -- кодировки строк и collations. В PG -- отдано на откуп библиотеке C, что ну совсем странно для СУБД. В Postgres 10 обещают поправить ситуацию с collation ICU support ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2017, 17:41 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Любая СУБД в тех или иных вопросах идёт навстречу пользователю. Одна больше, другая меньше. Если бы какая-то СУБД строго придерживалась стандарта - у неё не было бы массы проблем, но и почитателей было бы мало. Те же квотеры для имён - да нахрен они не нужны, если твёрдо сказать, что строго А-набор, никаких там кириллиц-пробелов-ведущих цифр-зарезервированных слов. Вот только идиотов дохрена, и все они, за редчайшим исключением, дружно взвоют и бросятся искать другую СУБД, где их будет не гнобить, а холить, лелеять и облизывать. Вот и придумывают в плюс к стандарту, кто квадратные скобки, кто бэктики, кто двойные кавычки... MasterZivмного storage endgine никому не нужно. Нужен ОДИН, но ХОРОШИЙ и транзакционный. Не говори ерунды. Нафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? Значит, уже как минимум два движка, а не один... ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2017, 17:00 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinaНе говори ерунды. Нафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? Значит, уже как минимум два движка, а не один...Значит, там и СУБД, скорее всего, не нужна. ;) Т.е. остаётся только DWH... или что-то ещё? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2017, 19:11 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
PgSQLanonymous3Значит, там и СУБД, скорее всего, не нужна.Ага, и давайте по старинке работать с plain text. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2017, 07:37 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Мы и сейчас работаем с plain text в части ini-files, properties, cfs-s. e.t.c. Весь линукс конфиг стоит на таких маленьких текстовых файликах. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.08.2017, 16:55 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 07:57 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinamaytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? потому что удобно. в mysql оно из коробки. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 14:32 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
ScareCrowв mysql оно из коробкиИ какой движок обрабатывает таблицы, хранящиеся в формате таких файлов? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 19:59 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
AkinamaytonВесь линукс конфиг стоит на таких маленьких текстовых файликах.Ты тему не забыл? ну или хотя бы почему всплыл plain text, глянь - всего 3 сообщения прочитать. Да и за каким рожном получать доступ к этим файликам средствами СУБД ? Какие три сообщения? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 20:24 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton AkinaНафига, скажем, транзакционный движок там, где никаких транзакций гарантированно не будет? PgSQLanonymous3Значит, там и СУБД, скорее всего, не нужна. AkinaАга, и давайте по старинке работать с plain text. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 21:48 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Akina, по большему счету именно наличие транзакций и разделяет DBMS от обычных сериализуемых на диск структур данных. Обычно DBMS дает гарантии. Лично для меня DBMS - это как Швейцарский банк. Если я что-то туда положил - то я уверен что это что-то там надёжно хранится. Бэкапится. И версионно шарится. Если вам вдруг (на минуточку) показалось что это неважно. И что mayton гонит чепуху. И эту часть теории можно отбросить и каким-то образом перепрыгнуть из согласованного чтения в грязное - то представьте что в этой базе лежат Ваши Деньги. Натурально... там лежит мать его ваш счёт. И с этого момента ваши отношения и пожелания по технологиям DBMS станут внимательными и проникновенными. Вот почему MyISAM нужно выбросить в печку. А всех кто его использует - подвергнуть химической кастрации по всем Европейским нормам этой мед-процедуры. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 22:00 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton , как я понял, Вы принципиально отказываете в праве на существование, например, RO-данным в БД. И даже insert-select данным. Т.е. тем, где от наличия транзакций не холодно не жарко. Вот нехрен в DBMS лезть, сериализуйтесь в текст, а если хотите потом быстрые выборки и статистики - придумайте, нафига вам нужны транзакции, и используйте их. Мало ли, что они тут ни к селу ни к заднице, есть такое слово - надо! Не все БД - это БД Швейцарского банка. Не смотрите на мир одним глазом - кривая картинка получится. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.08.2017, 22:24 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Я не отказываю. Пускай живут. Просто вывеску сменить нужно. Это как в математике. Я говорю пусть X - комплексное число. И все глубоко вздохнули и представили. Окей. Теперь корень их отрицательных излекается. Сложение - как векторное. Умножение - вращение и т.д. Всё! Действуют законы и гарантии. Если вы говорите окей. Пусть я работаю с табличкой в базе данных. Все представили себе ACID и совокупность правил и гарантий как с этим работать. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2017, 08:45 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
VladmlВ Postgres не нравится что версионность реализована на уровне строк, даже если ты изменил 0 на 1, все версии строк хранятся там-же где и актуальная строка, соответсвенно достум не по индексу будет медленней, ну изменение ctid и соответсветенно обновление всех индексов. Это идеальное решение для пост-реляционных систем. Данные и сегмент отката лежат вместе. Фактически нет разницы. При наличии толстого диска и редких OLTP операций мы можем поднять историю всех изменений за все года. При этом не нужен бекап. Это просто ретроспективный запрос по той-же таблице. В Oracle такое достигается только после активации flashback технологии. А это дополнительные дисковые расходы к тому что уже и так есть. В Postgres это из-коробки. Вобщем оба кейса хороши. Надо только найти им подходящие бизнес постановки. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2017, 23:30 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton В Postgres это из-коробки. гм, поясните пожалуйста. Нет в версионности ничего такого "При наличии толстого диска и редких OLTP операций мы можем поднять историю всех изменений за все года". Такое потребовало бы хранить абсолютно все версии всех записей, что означало бы, что данные не заменяются, а просто накапливаются. И уже через пару месяцев производительность такой системы была бы близка к нулю. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 01:05 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonЭто идеальное решение для пост-реляционных систем. "Постреляционная" - всего лишь реклама СУБД Cache, за которой не кроется ничего реального. Но кроме реляционных, есть более новые NoSQL-базы (правильнее было бы называть их нереляционными). Они в овсновном делятся на документо-ориентриованные (вроде MongoDB) и базы для больших объёмов данных (big data) (пример - HBase). В MongoDB и HBase транзакций нет, и смысл в их отсутствии есть. А популярность этих систем показывает, что они разработаны удачно. В общем, заглянул сюда за сравнением, но знатоков не оказалось. По-моему, участниками обсуждения упущено важное условие выбора - средства обеспечения сохранности данных: архивации и репликации (входящие в комплект и дополнительные, бесплатные и коммерческие, их возможности и качество работы). ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 10:09 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Я готов согласиться что для pg я не тот термин подобрал. Но какой взять? Ретроспективная? Консистентная на любой срез времени? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 19:56 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonНо какой взять? Ретроспективная? Консистентная на любой срез времени? Вот это что-ли? http://pgcookbook.ru/programming/snapshots.html по тексту чушь собачья, никакие там "на любой момент времени" срезы не предоставляются, речь идет просто о механизме реализации транзакций snapshot. И уж тем более никакой ретроспективности нет. В Firebird снапшоты реализуются почти так же, и тоже никаких "срезов" и ретроспективности нет. Для среза или ретроспективности нужно делать то же самое, что делается у Оракла во flashback, и у MS SQL что-то там - нужно где-то "заморозить" состояние БД на момент времени, то есть, фактически держать копию базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 22:15 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
kdvДля среза или ретроспективности нужно делать то же самое, что делается у Оракла во flashback, и у MS SQL что-то там - нужно где-то "заморозить" состояние БД на момент времени, то есть, фактически держать копию базы. Как минимум к flashback эти слова не имеют никакого отношения. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2017, 23:37 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
kdvДля среза или ретроспективности нужно делать то же самое, что делается у Оракла во flashback, и у MS SQL что-то там - нужно где-то "заморозить" состояние БД на момент времени, то есть, фактически держать копию базы. Ничего Оракл не морозит. Сегмент данных меняется так же как и раньше. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 00:03 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
kdvmaytonНо какой взять? Ретроспективная? Консистентная на любой срез времени? Вот это что-ли? http://pgcookbook.ru/programming/snapshots.html по тексту чушь собачья, никакие там "на любой момент времени" срезы не предоставляются, речь идет просто о механизме реализации транзакций snapshot. И уж тем более никакой ретроспективности нет. Возможно вы правы. Я поищу где я это читал. Возможно в очень старых версиях. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 00:07 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
maytonНичего Оракл не морозит. Сегмент данных меняется так же как и раньше я имел в виду, что для доступа к старым данным их как-то нужно сохранять. flashback как раз делается через архивы. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 11:44 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
kdvflashback как раз делается через архивы. flashback делается через логи . ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 11:52 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Таки flashback разный в Oracle бывает. Есть flashback query, есть flashback database, есть flashback table, есть flashback transaction. Они через разную физику делаются ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 13:51 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Alexander RyndinТаки flashback разный в Oracle бывает. Есть flashback query, есть flashback database, есть flashback table, есть flashback transaction. Они через разную физику делаются у них разговор четко про flashback query шел maytonПри наличии толстого диска и редких OLTP операций мы можем поднять историю всех изменений за все года. При этом не нужен бекап. Это просто ретроспективный запрос по той-же таблице. я лет 10 назад говорил, что отдельный UNDO на оракловый манер у innodb большое преимущество, похоже начинает и до индустрии доходить ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 14:04 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Yo.!Alexander RyndinТаки flashback разный в Oracle бывает. Есть flashback query, есть flashback database, есть flashback table, есть flashback transaction. Они через разную физику делаются у них разговор четко про flashback query шелТогда flashback query работает без всяких там логов. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 14:33 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Alexander RyndinТогда flashback query работает без всяких там логов. да ладно, в 11g помню через UNDO лог работало, причем на SE редакции ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 15:12 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Yo.!Alexander RyndinТогда flashback query работает без всяких там логов. да ладно, в 11g помню через UNDO лог работало, причем на SE редакцииЧерез undo лог работало... Что такое UNDO лог? Вы как-то очень невнятно формулируете свою мысли. Flashback Query использует для работы UNDO, это да, но не лог. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 16:11 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Alexander RyndinЧерез undo лог работало... Что такое UNDO лог? Вы как-то очень невнятно формулируете свою мысли. Flashback Query использует для работы UNDO, это да, но не лог. UNDO это лог, потому что у Bernstein UNDO это лог. у innodb тоже UNDO лог , а вот то что оракл его логом прямо не завет для меня открытие ... хотя мне кажется во времена семерки, он логом был. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2017, 17:27 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Yo.!я говорил, что отдельный UNDO на оракловый манер у innodb большое преимущество, похоже начинает и до индустрии доходить индустрия уже убежала вперед, я что-то ни в HIVE, ни в sparke, ни простигоспади в монгодб вообще никаких логов не видел. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2017, 15:00 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Ivan Durak, Это в той монгоДБ, которая медленнее постгреса на аналогичных данных? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2017, 15:37 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Ivan Durakиндустрия уже убежала вперед, я что-то ни в HIVE, ни в sparke, ни простигоспади в монгодб вообще никаких логов не видел. ты плохо смотрел. индустрия давно сделав круг прибежала назад, к оракловым UNDO, REDO и нормальному MVCC. вот из новомодного на хадуп Apache Kudu https://blog.cloudera.com/blog/2017/04/apache-kudu-read-write-paths/ UNDO, REDO, MVCC все как полагается. причем у нас даже работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2017, 07:47 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
Ivan DurakYo.!я говорил, что отдельный UNDO на оракловый манер у innodb большое преимущество, похоже начинает и до индустрии доходить индустрия уже убежала вперед, я что-то ни в HIVE, ни в sparke, ни простигоспади в монгодб вообще никаких логов не видел. Монго DB использует WAL. Здесь пишут об этом. https://docs.mongodb.com/manual/tutorial/manage-journaling/ По поводу HIVE. Это другой класс систем. Отличающийся от транзакционных Oracle,MS-SQL,e.t.c. У биг-даты "усечены" многие возможности связанные с транзакциями. Потому-как грузят в биг-дату данные которые уже не меняются. Исторические. В идеале там не должно быть updates. Один раз загрузили и оно лежит там себе. По ним строят разные материальные views но сами исходные данные уже как правило не меняют. Spark это вообще не DBMS. Это фреймворк который позиционируется как замена устаревшему Hadoop. Не путайте господа классы систем. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2017, 08:37 |
|
Postgres vs MySQL
|
|||
---|---|---|---|
#18+
mayton, spark позиционируется как замена map-reduce, лишь одному из винтиков в экосистеме hadoop. при этом его активней всего продвигают именно в связке с хадуп: интеграцией с yarn, писаниной на hdfs плюс spark как энжин к Hive ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2017, 10:34 |
|
|
start [/forum/topic.php?all=1&fid=35&tid=1552235]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
198ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
91ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 351ms |
0 / 0 |