Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Опять вопрос из серии «Кто сильнее, кит или слон?». Ну нельзя их сравнивать. Они обеспечивают совершенно разный функционал. Mongo vs Postgre вопрос не скоростей работы, а архитектуры вашего приложения, ваших задач и ваших методов их решения.
Автору можно дать еще один иронический совет для «ускорения записи/чтения» — попробуйте писать в файлы. И сравнивать с полноценной СУБД.
У вас даже график построить не получится :-) Но собственно и полноценное приложение на фалах будет построить очень не просто.
Для каждой задачи — свой инструмент.
У вас даже график построить не получится :-) Но собственно и полноценное приложение на фалах будет построить очень не просто.
Для каждой задачи — свой инструмент.
А какая у меня мотивация может быть юзать mongo кроме скорости?
Все тесты проводились в однопоточном режиме?
Может, стоит провести многопоточный тест?
Может, стоит провести многопоточный тест?
Как часто Вы не кешируете результаты запросов в нагруженном проекте? :)
Интересно было-бы увидеть тесты параллельных операций вставки и выборки для этих СУБД.
MongoDB без getLastError() и без реплик ну никак не может сравниваться с PostgreSQL с fsync'ом, т.к. без этого монго не даёт никаких гарантий, что данные реально записались и не будут потеряны.
thebuild.com/presentations/pg-as-nosql-pgday-fosdem-2013.pdf
Тут еще интересные цифры.
Тут еще интересные цифры.
Ваши тесты без отключения синхронизации с диском в postgres, либо без включения её же в mogno — хрень. К тому же, как уже писали, данные СУБД решают различные классы задач, так что сравнивать их некорректно.
Уверен что большинство мелких и средних (что греха таить, и часть крупных) проектов в сети работают с СУБД «из коробки», т.е. с теми настройками какие заложил по умолчанию производитель. Учитывая этот фактор, сравнение коробочных версий весьма корректно. Не зря в статье написано что это весьма поверхностное тестирование. Но буду весьма рад, если вы сможете «разогнать» PostgreSQL (без ущерба стабильности системы) и выложить более глубокий анализ его максимальной производительности.
Что же до классов задач — это не совсем так. Одну и ту же задачу можно решить разными способами. Тот же Foursquare вполне же можно было написать и с использованием реляционных БД, согласитесь? )
Что же до классов задач — это не совсем так. Одну и ту же задачу можно решить разными способами. Тот же Foursquare вполне же можно было написать и с использованием реляционных БД, согласитесь? )
Уверен что большинство мелких и средних (что греха таить, и часть крупных) проектов в сети работают с СУБД «из коробки»
Мда, искренне сочувствую я тем проектам, где вы это встречали. Я лично не встречал ни одного проекта с настройкой СУБД по умолчанию.
если вы сможете «разогнать» PostgreSQL (без ущерба стабильности системы)
Как бы монго без реплик тоже стабильностью не блещет, в продакшн без этого её никто ставить не будет.
>>Как бы монго без реплик тоже стабильностью не блещет
Пруфлинк, пожалуйста. Интересно откуда этот слух пошел.
Пруфлинк, пожалуйста. Интересно откуда этот слух пошел.
docs.mongodb.org/manual/administration/production-notes/
docs.mongodb.org/manual/replication/
И это не слух, а реальный опыт.
docs.mongodb.org/manual/replication/
Replica sets provide redundancy and high availability, and are the basis for all production deployments
И это не слух, а реальный опыт.
«настройки по умолчанию» у постгреса такие, что бы он везде запустился. Учитывая этот фактор, тестировать постгреса с этими настройками смысла вообще нет.
PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system.
отсюда
PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system.
отсюда
Повторю комментарий к предыдущей статье:
1) Слишком старые версии серверов
2) Слишком несоотносимые настройки, особенно на запись (хотябы fsync=off в postgresql или synchronous_commit=off)
3) Код тестов тоже не привели
1) Слишком старые версии серверов
2) Слишком несоотносимые настройки, особенно на запись (хотябы fsync=off в postgresql или synchronous_commit=off)
3) Код тестов тоже не привели
Как вы производили вставки в MongoDB? По-умолчанию она не ждет ответа об успешности записи, поэтому создав 300000 записей, они еще могли в фоне создаваться несколько секунд. Тоже самое с удалением и другими операциями.
Видимо вы имеет в виду Write Concern ( docs.mongodb.org/manual/core/write-concern/ ) но не совсем понимаете его принципы.
Во-первых, никто не продолжает вставку в фоне. Write concern (далее будем называет его просто w) только определяет уровни оповещения об ошибках записи. Если операция завершена, значит она завершена. А вот нужно ли сообщать об ошибках в процессе операции — это уже другой вопрос.
Во-вторых, w по умолчанию выставлен не в -1 (Errors Ignored), и даже не в 0 (Unacknowledged), а в 1 (Acknowledged). Прибавим к этому еще и включенное по умолчанию журналирование (аналог полюбившегося здешними комментаторами fsync), мы получаем следующую картину:
docs.mongodb.org/manual/_images/crud-write-concern-journal.png
Полагаю, что этого более чем достаточно, чтобы сравнение «коробочного» MongoDB с «коробочным» же PostgreSQL имело место быть.
Печально, что большинство пользователей просто как «по-заученному» твердят про какие-то fsync=off, репликацию, отсутствие у монги getLastError, нестабильности этой СУБД и т.п. совершенно не пытаясь проверить актуальность своих познаний.
UPD: К сожалению тэги не сработали, пришлось вставить просто ссылками.
Во-первых, никто не продолжает вставку в фоне. Write concern (далее будем называет его просто w) только определяет уровни оповещения об ошибках записи. Если операция завершена, значит она завершена. А вот нужно ли сообщать об ошибках в процессе операции — это уже другой вопрос.
Во-вторых, w по умолчанию выставлен не в -1 (Errors Ignored), и даже не в 0 (Unacknowledged), а в 1 (Acknowledged). Прибавим к этому еще и включенное по умолчанию журналирование (аналог полюбившегося здешними комментаторами fsync), мы получаем следующую картину:
docs.mongodb.org/manual/_images/crud-write-concern-journal.png
Полагаю, что этого более чем достаточно, чтобы сравнение «коробочного» MongoDB с «коробочным» же PostgreSQL имело место быть.
Печально, что большинство пользователей просто как «по-заученному» твердят про какие-то fsync=off, репликацию, отсутствие у монги getLastError, нестабильности этой СУБД и т.п. совершенно не пытаясь проверить актуальность своих познаний.
UPD: К сожалению тэги не сработали, пришлось вставить просто ссылками.
По-моему этот режим не проверяет записалась ли физически информация на диск, а кстати такой режим записи в mongo есть и он такой же по скорости как и в Postgres. Я очень давно сравнивал.
Давайте всё же без «по-моему» )
Ну не забывайте еще что Postgres все это выполняет в транзакции. Не реализуя транзакции, мы прибавляем в производительности. Я пробовал и то и другое, у меня есть проекты и на Mongo и на обычных БД. Без транзакций жить тяжко конечно. Но со вставкой явно у вас что-то не то, не может так сильно проигрывать Postgres. Я помню первый ажиотаж, когда все трубили, что монго в 10 раз быстрее делает выборки, оказалось банально что вся нагрузка происходит в fetch. Тут нужно еще раз перепроверить. Может сравнить c Mysql.
Я еще сравнивал когда-то скорость обновления одного поля в Mongo, через set или inc (через атомарные операции), так вот они еще быстрее, у меня выходило так, что монго спокойно обрабатывал такую операции на 500 000 меньше чем за секунду.
Я еще сравнивал когда-то скорость обновления одного поля в Mongo, через set или inc (через атомарные операции), так вот они еще быстрее, у меня выходило так, что монго спокойно обрабатывал такую операции на 500 000 меньше чем за секунду.
Согласен. Но транзакции — нужны только при «релятивистском» подходе в проектировании.
Также согласен и с тем что тут сравнение действительно слишком общее и неполноценное.
Есть идея создать два абсолютно одинаковых (по доступной функциональности) проекта, но сделать различие в логике построения — один будет использовать Монго, а второй PostgreSQL со всеми вытекающими (транзакции, джойны и т.д.).
А потом прогнать какой-нибудь siege и/или ab. Тут и многопоточность и приближение к «боевым» условиям (те же блокировки, к примеру).
Хотя не знаю, стоит ли игра свеч…
Также согласен и с тем что тут сравнение действительно слишком общее и неполноценное.
Есть идея создать два абсолютно одинаковых (по доступной функциональности) проекта, но сделать различие в логике построения — один будет использовать Монго, а второй PostgreSQL со всеми вытекающими (транзакции, джойны и т.д.).
А потом прогнать какой-нибудь siege и/или ab. Тут и многопоточность и приближение к «боевым» условиям (те же блокировки, к примеру).
Хотя не знаю, стоит ли игра свеч…
Еще я вспомнил одну неприятную вещь про Mongodb, любая запись блокирует операции чтения то ли для всей базы, то ли для таблицы. В результате, если у нас приложение, которое часто что-то пишет в базу, то проседают выборки из базы, из-за блокировок.
Единственный способ снизить этот недостаток, создать реплики.
Единственный способ снизить этот недостаток, создать реплики.
Ну не забывайте что в постгресе также есть блокировки. Более того там еще более печальный эффект есть — deadlock называется: www.postgresql.org/docs/current/static/explicit-locking.html#LOCKING-DEADLOCKS
Так что «неприятные вещи» есть везде. Вопрос уже не в самой СУБД, а в проектировании таких образом чтобы снизить вероятность этих «неприятных вещей».
Так что «неприятные вещи» есть везде. Вопрос уже не в самой СУБД, а в проектировании таких образом чтобы снизить вероятность этих «неприятных вещей».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение производительности MongoDB vs PostgreSQL. Часть II: Index