Комментарии 25
Простите, но зачем сравнивать квадратное с жидким? PostgreSQL это все же в первую очередь реляционная база, и она использует нормализованные данные. Монга на против, использует подход с агрегацией данных под каждый запрос и хранит данные в денормализованном виде.
Однако многие задаются вопросами «что выбрать SQL или no-SQL?».
Понятное дело, что принцип проектирования полностью меняется при переходе с одного на другое, однако можно же реализовать проект и так и эдак. У нас, например, используется и MongoDB и PostgreSQL. Тут смысл то в том, чтобы понять «а что мы вообще хотим»? Сравнение весьма поверхностно, но общую картину показывает (давайте я допишу вторую часть, а потом уже подытожу, не хочу заранее этого делать).
Понятное дело, что принцип проектирования полностью меняется при переходе с одного на другое, однако можно же реализовать проект и так и эдак. У нас, например, используется и MongoDB и PostgreSQL. Тут смысл то в том, чтобы понять «а что мы вообще хотим»? Сравнение весьма поверхностно, но общую картину показывает (давайте я допишу вторую часть, а потом уже подытожу, не хочу заранее этого делать).
«что выбрать SQL или no-SQL?» это вопрос из разряда «какая no-sql база лучше?». По сути это уже говорит о полном отсутствии у людей представления о том как взаимодействовать с этими вещами. Для хранения множества связей между объектами (по сути графов) вы же не будете применять mysql? скорее всего вы захотите специализированное хранилище (neo4j). И опять же если в этом же проекте вам необходимо реализовать платежи, то для этого скорее всего выбор падет на реляционные базы, которые идеально для этого подходят.
Из вашего теста (к слову без кода можно легко усомниться в его корректности) следует что скорость вставки в монги выше. Но опять же это пустое сравнение, ибо веселье начинается при обновлении связей и прочего. Монга хороша когда нужно делать много выборок и выборок с условиями для данных, которые не так часто меняются. Ибо если данные меняются постоянно (скажем, пользователи могут поменять свои имена, атрибуты какие-то могут менять свои названия, названия категорий меняются относительно часто), то изза подхода с агрегатами уже усложняются операции обновления записей и профит быстрых выборок нивелируется сложной и не удобной в поддержке логикой.
Из вашего теста (к слову без кода можно легко усомниться в его корректности) следует что скорость вставки в монги выше. Но опять же это пустое сравнение, ибо веселье начинается при обновлении связей и прочего. Монга хороша когда нужно делать много выборок и выборок с условиями для данных, которые не так часто меняются. Ибо если данные меняются постоянно (скажем, пользователи могут поменять свои имена, атрибуты какие-то могут менять свои названия, названия категорий меняются относительно часто), то изза подхода с агрегатами уже усложняются операции обновления записей и профит быстрых выборок нивелируется сложной и не удобной в поддержке логикой.
По сути MongoDB и хороша тем, что вместо реляционных таблиц можно хранить все необходимые параметры в одной коллекции. Опять же, из серии «что конкретно нам нужно?». Если эти параметры не требуют постоянного обновления — то почему нет? В том же интернет магазине — у каждого товара может быть свой набор характеристик. Зачем только из-за этого делать отдельную таблицу с ними и каждый раз при отображении страницы юзать джойны, когда можно обойтись хранением всех данных товара в самом объекте этого товара, уже готовом? Завод-производитель очень редко когда меняет описание своего продукта.
А такое огромное преимущество во вставке — очень полезно при необходимости логирования каких-то действий. При этом, опять же, не нужно обновлять несколько связанных таблиц, объект может иметь уже все необходимы атрибуты с практически любым уровнем вложенности.
Результаты теста ни на чем не настаивают, они лишь дают пользователю понять, что надо отталкиваться от текущей необходимости, а не от «брэнда», «моды», «у Васи так же» и т.п.
А такое огромное преимущество во вставке — очень полезно при необходимости логирования каких-то действий. При этом, опять же, не нужно обновлять несколько связанных таблиц, объект может иметь уже все необходимы атрибуты с практически любым уровнем вложенности.
Результаты теста ни на чем не настаивают, они лишь дают пользователю понять, что надо отталкиваться от текущей необходимости, а не от «брэнда», «моды», «у Васи так же» и т.п.
Я к тому и вел что средства надо из задачи подбирать. А приведенные тесты как раз таки могут подвести неокрепшие умы к мысли «монга супер все на монгу!».
По сути, в postgres есть такой замечательный тип данных, как JSON (а так же ARRAY), в котором тоже можно хранить свойства товаров, и даже строить индексы по их элементам. По поводу преимущества при вставке — попробуйте использовать prepared statements, чтобы не парсить sql запрос каждый раз. Часто на это уходит больше половины времени обработки запроса. Кстати, тестируя вставку в postgres, были ли настройки файловой синхронизации аналогичны mongo? По умолчанию mongo настроена на производительность, а postgres — на целостность данных. Какие настройки fsync и synchronous_commit вы используете в postgres при тестах?
>повышение параметров shared_buffers и т.п. ни к чему не приводили, глубже я копать не стал, ибо не принципиально
Дооо… очень Икспертно. Жду сравнение redis и oracle.
P.S. fsync=off превращает постгрес в монгу.
Дооо… очень Икспертно. Жду сравнение redis и oracle.
P.S. fsync=off превращает постгрес в монгу.
Для начала, вы хотя бы версии продуктов указали.
Желательно так же настройки. Было ли включено журналирование и т.д.
А так это профанация, а не сравнение.
Желательно так же настройки. Было ли включено журналирование и т.д.
А так это профанация, а не сравнение.
Какой сакральный смысл в тестах без индексов? Посчитать попугайчиков? Если вы проводите тесты для того, чтобы определиться что использовать, то какой смысл проводить тест таким образом, каким вы в реальной жизни не будете использовать данные бд.
Ну и опять же тестировать надо полноценно, есть к примеру данная статейка (ссылка ниже), где MongoDB выбирает данные быстрее чем MySQL, но просто нереально сильно сливает при fetch'e, так что без подобного подхода ваше тестирование бесполезно, разве что посчитать попугайчиков. Хотя конечно если данные не будут кэшироваться, то возможно и устроят результаты, но всё же кэширование результатов часто спасало.
www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/
Ну и опять же тестировать надо полноценно, есть к примеру данная статейка (ссылка ниже), где MongoDB выбирает данные быстрее чем MySQL, но просто нереально сильно сливает при fetch'e, так что без подобного подхода ваше тестирование бесполезно, разве что посчитать попугайчиков. Хотя конечно если данные не будут кэшироваться, то возможно и устроят результаты, но всё же кэширование результатов часто спасало.
www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/
Во-первых странно, почему для тестов pg использовался sql-файл, а не нормальное клиентское соединение с prepared statements. И какой формат вставки был использован, INSERT или COPY?
Во-вторых, в любой нормальной системе на базовые запросы ставятся индексы, и в первую очередь интересны тесты на производительность выборок с индексами.
В-третьих, хотел бы посмотреть на сравнение скоростей транзакций pg и двухфазных коммитов mongo при выполнении какой-нибудь простейшей операции перемещения значения между коллекциями/таблицами в условиях racing condition, поскольку почти любая система неизбежно с ними сталкивается в процессе своего развития. Мы ведь думаем о выборе субд для проекта, глядя в будущее, верно?
Во-вторых, в любой нормальной системе на базовые запросы ставятся индексы, и в первую очередь интересны тесты на производительность выборок с индексами.
В-третьих, хотел бы посмотреть на сравнение скоростей транзакций pg и двухфазных коммитов mongo при выполнении какой-нибудь простейшей операции перемещения значения между коллекциями/таблицами в условиях racing condition, поскольку почти любая система неизбежно с ними сталкивается в процессе своего развития. Мы ведь думаем о выборе субд для проекта, глядя в будущее, верно?
Добавил раздел «Среда обитания», где описал конфигурацию обеих СУБД.
> PostgreSQL: Версия: 8.4.13
А чего не 7?
А чего не 7?
Статья из прошлого? Почему не 9.3?
Расскажите подробней про вставку. Что-то мне подсказывает что у postgresql не было begin transaction; в начале commit transaction; в конце.
Мы используем postgresql вместе с расширениями postgis и hstore. Индексы и поиск по hstore работают достаточно быстро, так что нет препятствий для хранения произвольных данных в добавок к четко описанным.
p.s. Тесты хотелось бы видеть на актуальных версиях. postgresql последний стабильный — 9.3.
Мы используем postgresql вместе с расширениями postgis и hstore. Индексы и поиск по hstore работают достаточно быстро, так что нет препятствий для хранения произвольных данных в добавок к четко описанным.
p.s. Тесты хотелось бы видеть на актуальных версиях. postgresql последний стабильный — 9.3.
Т.е. для того, чтобы узнать, что Mongo пишет быстрее реляционного Postgres-а нужна была целая статья и тесты? Океееей…
остаётся поддержать предыдущих комментаторов:
1) Слишком старые версии серверов
2) Слишком несоотносимые настройки, особенно на запись (хотябы fsync=off в postgresql или synchronous_commit=off)
3) Код тестов тоже не привели
1) Слишком старые версии серверов
2) Слишком несоотносимые настройки, особенно на запись (хотябы fsync=off в postgresql или synchronous_commit=off)
3) Код тестов тоже не привели
А вы попробуйте сначала сравнить MongoDB и тот же PostgreSQL когда обе БД в оперативке а не читаются с HDD, и потом наоборот обе с HDD, т.е. чтобы монго база не влазила в оперативку. Вот тогда и появятся проблемы.
Мдя. Интересно. Тоже когда-то задавался таким вопросом. А потом решил, что лучший ответ дадут не подобные эксперименты (у меня база на 20 млн. записей, поэтому что только я не пробовал для ускорения), а просто опыт больших игроков рынка. У меня в свое врем получилась такая табличка:
1. Skype — использует Postgress, в котором более миллиарда клиентов. Естественно, все распределено, но тем не менее. Кстати, после покупки MS были планы перенести все на MongoDB, yо потом от них отказались.
2. Facebook — использует MySQL в режиме NoSQL, то есть как просто хранилище key=value. Для кеширования используется memcache. У них сейчас около 2,5-3 тыс. серверов. Кстати, подход, на мой взгляд, самый правильный. Тут и целостность, и скорость. Я примерно такого же придерживаюсь, но в связке Postgres + REDIS. И стараюсь делать несколько простых запросов, понятных планировщику, вместо нескольких сложных.
3. Craiglist — используется MySQL, были заявления о переходе на MongoDB для хранения архива сообщений пользователей и поиска комментариев в нем. Но статус текущий не знаю.
4. YouTube — использует MySQL, но данных об архитектуре найти не смог.
5. IMDB.com — использует Postgress, но деталей не знаю.
6. Twitter — использует MySQL с очень серьезными «доточками» под себя. Были планы по переходу на NoSQL, но от них отказались, так как тесты не показали существенного прироста производительности перед доточенной MySQL.
Если у кого есть еще какая информация, поделитесь, плз.
В целом, после месяцев двух разных мытарств я уже перестал смотреть разные бенчмарки. :)
1. Skype — использует Postgress, в котором более миллиарда клиентов. Естественно, все распределено, но тем не менее. Кстати, после покупки MS были планы перенести все на MongoDB, yо потом от них отказались.
2. Facebook — использует MySQL в режиме NoSQL, то есть как просто хранилище key=value. Для кеширования используется memcache. У них сейчас около 2,5-3 тыс. серверов. Кстати, подход, на мой взгляд, самый правильный. Тут и целостность, и скорость. Я примерно такого же придерживаюсь, но в связке Postgres + REDIS. И стараюсь делать несколько простых запросов, понятных планировщику, вместо нескольких сложных.
3. Craiglist — используется MySQL, были заявления о переходе на MongoDB для хранения архива сообщений пользователей и поиска комментариев в нем. Но статус текущий не знаю.
4. YouTube — использует MySQL, но данных об архитектуре найти не смог.
5. IMDB.com — использует Postgress, но деталей не знаю.
6. Twitter — использует MySQL с очень серьезными «доточками» под себя. Были планы по переходу на NoSQL, но от них отказались, так как тесты не показали существенного прироста производительности перед доточенной MySQL.
Если у кого есть еще какая информация, поделитесь, плз.
В целом, после месяцев двух разных мытарств я уже перестал смотреть разные бенчмарки. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение производительности MongoDB vs PostgreSQL. Часть I: No index