Преимущества MySQL перед PostgreSQL

У меня опыта нет, но от тех у кого он есть, слышу что постгре куда лучше мускула.

Но в последнее время и по скорости постгрес обгоняет.

Он уже может вытягивать 20М запросов в секунду из кеша, как мускул?

Чего не знаю, того не знаю) Мне бы хотелось услышать мнение более компетентных товарищей, чем я на данный момент.

Преимущества MySQL перед PostgreSQL

MySQL несравнимо проще развернуть и запустить.

Товарищ Observer наблюдал экспоненциальную сложность операции вставки в MySQL, в то время как у постгрес она линейная.

MySQL производит впечатление более используемого продукта. Больше информации о нём, проще решать проблемы. Но так же производит впечатление недоделанности то тут, то там. Например через JDBC не работает streaming, нельзя загрузить гигабайтный файл в BLOB. Серверные PreparedStatements не реализованы (не знаю, насколько это даёт выигрыш, но мне кажется, что должен давать). Слышал про проблемы с целостностью транзакций.

Мне Postgres более симпатичен. Он более целостный, проработанный, академичный.

А скорость обычно вопрос решаемый тем или иным образом, для меня скорость стоит далеко не в приоритете при выборе РСУБД (если она разумная, конечно, не на порядки меньше).

Товарищ Observer наблюдал экспоненциальную сложность операции вставки в MySQL, в то время как у постгрес она линейная.

В огромных таблицах. Записей было что-то порядка 10-50 миллионов.

Лучше кеш продумать на стороне приложения, чем полагаться на кеш БД, если это надо.

А чем проще? Если сервер один, а не целый кластер, то разницы нет наверное?

Вот, уже конкретика пошла :)

MySQL cons: 1. не работает стриминг через JDBC 2. нельзя загрузить гигабайтный файл в BLOB 3. серверные PreparedStatements не реализованы

А чем проще?

Тем, что для установки mysql достаточно emerge/apt-get + init/start. И всё, можно работать.

Теперь смотри инструкцию по установке/настройке Postrge :)

Сначала нужно определиться что нужно - нормальная реляционка с ACID или что-то другое. Если первое, то это однозначно PG без каких-либо альтернатив (из открытых рСУБД). Это и по скорости, и по фичам, и по качеству поддрежки фич.

MySQL несравнимо проще развернуть и запустить.

звиздёшь.

Я сегодня развертывал постгрес. Разницы с мускулом не заметил особой. Разве что с ролями немного заморочился, но документация у постгрес отличная, сразу всё прояснилось.

Разве что с ролями немного заморочился, но документация у постгрес отличная, сразу всё прояснилось.

Вот о чём и речь. В одном — просто ставишь и работаешь. В другом — надо изучать документацию и проделывать массу дополнительных телодвижений.

А ещё есть преимущества у MySQL?

можно поставить потсгре из репов убунты и он сразу будет работать, даже дефолтный пользователь с дефолтным паролем поставится, так что звездёшь

Лучше кеш продумать на стороне приложения, чем полагаться на кеш БД, если это надо.

Это дополнительная работа. К тому же инвалидация кеша может быть достаточно сложной задачей.

Я так в центоси сделал. Оказалось - юникод не работает, вопросики вместо русского. Пришлось таки настраивать. В постгресе уже не помню, что настраивал, по-моему на внешний интерфейс вывесил (бд всегда в виртуалке кручу для разработки) и в pg_hba.conf прописал, ну и бд/юзера создал, в общем то если не в первый раз, то дело нескольких минут.

Скажем так, мускуль на дефолтный настройках работает лучше постгреса на дефолтных настройках :). Постгрес для реального использования необходимо настроить (как любую серьёзную базу данных), мускуль с успехом можно применять и не зная многих интимных моментов.
Но плюс это или минус можно и поспорить :)

Например, чтоб к постгре можно было коннектится по tcp, даже для localhost, необходимо отредактировать pg_hba.conf.

Это дополнительная работа.

Это необходимая работа, если реально нужна производительность. Потому что на кеш БД нельзя полагаться, на нём кто-нибудь запустит какой-нибудь отчёт и всё, на сайте время отклика увеличится в 10 раз? А после этого лавинообразное нарастание потоков и сервер встаёт колом?

Плюс - если БД на другой машине (а на это нужно рассчитывать), то даже кеш не сильно поможет, т.к. затык можно получить по сетевой пропускной способности. В то время как локальному кешу это не угрожает.

К тому же инвалидация кеша может быть достаточно сложной задачей.

Инвалидацию как в БД сделать тривиально. А если делать её сложной и продвинутой, то в БД просто не будет аналога, т.к. только ты знаешь, какая в твоём приложении логика работы.

Скажем так, мускуль на дефолтный настройках работает лучше постгреса на дефолтных настройках :).

Дефолтный конфиг PG расчитан на «поиграться», для продакшена нужно правильно задать размеры памяти. Практически вся начальная настройка.

Потому что на кеш БД нельзя полагаться, на нём кто-нибудь запустит какой-нибудь отчёт и всё, на сайте время отклика увеличится в 10 раз?

Не увеличится. Почему бы тогда вообще не развить твою мысль дальше, и не сказать: на эти БД нельзя полагаться, необходимо все делать руками.

Плюс - если БД на другой машине

У меня именно так, брат жив.

Инвалидацию как в БД сделать тривиально.

Ты пробовал? Нужно знать таблицы, участвующие в запросе, нужно где-то хранить результаты для кеша, если у тебя кластер, нужно правильно сбросить кеш везде с правильными блокировками при insert/update.

Мутить свой кеш на стороне клиента, плохая идея.

Тебе на sql.ru. Тут на этот вопрос никто адекватно не ответит. И поиск по stackoverflow никто не отменял. Если говорить про хайлоад, то либо патчи во все места, либо самописные бд. А простым смертным вообще до лампочки, на крайняк оракл в руки.

Все зависит от задач/архитектуры. Вот у меня был опыт, что локальный кеш рулил и педалил. И еще раз сделаю упор на постановку задачи: допустим клиентское (по отношению к бд) ПО должно работать (и работать успешно) даже когда бд в даунтайме в состояние обновления. И что ты будешь делать с кэшом в бд? Переодично переключаться между резервными серверами? А если накроется медным тазом коннект до всех баз, а если место закончится? Вобщем, задача такая, что ПО должно все случаи понимать и адекватно их обрабатывать. Сложность возрастает? Это бизнес, а не хобби :)

месье походу никогда postgres не ставил...

Теперь смотри инструкцию по установке/настройке Postrge :)

а ты не смотри инструкцию, а возьми и поставь пакет, теоретик

и оно заработает

4.2, причём наглое совершенно.

Спасибо за наводку.

тебе уже ответили выше

Где-то был тред, в котором очень по делу перемывали кости монге с постгресом.

Из того что запомнил - у постгреса при апгрейде версии надо будет всё нах останавливать и апгрейдить базу в оффлайне. Во всём остальном база весьма крута. В последних посгресах есть много фич для работы со schemaless данными. И никто не жаловался на траблы для таблиц от миллиарда строк (в отличие от мускуля).

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

не слушай идиотов: нет такого понятия «скорость». Есть понятие «скорость определённой операции». Т.к. операции в разных задачах разные, то и скорость тоже. И спор идиотов будет продолжаться вечно, ибо в одних задачах «быстрее» одно, а в других — другое.

В первом приближении можно считать операции аддитивными, и протестировать скорость тех, которые тебе нужны в проекте в синтетике. Кроме того, нужно посчитать %% каждой операции. А затем синтетические скорости умножить на %% и сложить. Получишь «скорость» для своего проекта. Она конечно отличается от реальной, но обычно не настолько сильно, что-бы ты выбрал неправильно СУБД.

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

MySQL несравнимо проще развернуть и запустить.

это скорее минус. Больше тупых обезьян.

Товарищ Observer наблюдал экспоненциальную сложность операции вставки в MySQL, в то время как у постгрес она линейная.

ты бы не позорился, и почитал Кнута. И то и другое невозможно. Скорость вставки в обоих случаях логарифмическая. Зачем её делать линейной, а тем более экспоненциальной?

В огромных таблицах. Записей было что-то порядка 10-50 миллионов.

дай угадаю: индекс не влез в память, и лежал на дешёвом HDD ноута поциэнта?

нельзя загрузить гигабайтный файл в BLOB

а зачем? Это должна делать ФС, а не СУБД.

MySQL несравнимо проще развернуть и запустить.

звиздёшь.

он про свой локалхост на бубунте. Там мускул в короппке.

Именно так и апгрейдится - приходится останавливать.

Если в начало массива вставлять, то будет линейной.

Если в начало массива вставлять, то будет линейной.

нет. Тогда будет O(1). Но как вставить 10 в начало массива 1,2,4,8,16,32,64 ?

Для массива нужно будет сдвигать вправо все последующие элементы, что и приводит к «линейности»

Для массива нужно будет сдвигать вправо все последующие элементы, что и приводит к «линейности»

ну да, получится O(N), но это хуже O(log(N)). Зачем так делать? И это не «в начало», как ты предлагал выше.

Такое возможно как corner case. Индекс м.б. кластеризованным. Тогда вставка последовательности элементов с ключами отсортированными по невозрастанию приведет к вставке в начало массива. Скорее всего такое разруливается в субд посредством использования списка массивов (аналог контейнеру dequeue в c++).

Скорее всего такое разруливается в субд посредством использования списка массивов

а ты не гадай, а почитай. Там сильноветвящиеся деревья, которые топологически эквивалентны бинарному дереву. И время там пропорционально O(log(N)). Лучше не сделать, учитывая, что тебе нужно ещё и делать выборки «от и до». Это невозможно в разного рода хешированных списках(в которых скорость вставки теоретически можно сделать и O(1)).

B+-tree используются для некластеризованных индексов, для кластеризованных, записи хранятся в определенном порядке физически (на уровне ФС), т.е. просто как отсортированный массив.

B+-tree используются для некластеризованных индексов, для кластеризованных, записи хранятся в определенном порядке физически (на уровне ФС), т.е. просто как отсортированный массив.

дык я с самого начала предлагал отделить тот случай, когда индекс не лезет в память.

Спасибо за содержательные комменты.