Мысли MongoDB и PostgreSQL

Question

У меня есть приложение, полностью работающее с PostgreSQL.После прочтения о MongoDB мне было интересно посмотреть, как приложение будет работать с ним.Через несколько недель я перенес всю систему на MongoDB.

Мне нравятся некоторые вещи с MongoDB.Тем не менее, я обнаружил, что некоторые запросы, которые я делал в PostgreSQL, я не мог эффективно выполнять в MongoDB.Особенно, когда мне пришлось объединить несколько таблиц, чтобы вычислить логику.Например, this .

Более того, я использую Ruby on Rails 3 и ODM под названием Mongoid.Mongoid все еще находится в бета-версии.Документация была хорошей, но опять же, время от времени я обнаруживал, что ODM очень ограничен по сравнению с тем, что Active Record предлагал с традиционными (SQL) системами баз данных.

Даже до сегодняшнего дня я чувствую себя более комфортно, работая с PostgreSQL, чемMongoDB.Только потому, что я могу объединять таблицы и делать что-либо с данными.

Я сделал два типа резервных копий.Один с PostgreSQL, а другой с MongoDB.Некоторые говорят, что некоторые приложения больше подходят для одного или другого типа БД.Должен ли я продолжить работу с MongoDB и в конечном итоге надеяться, что его RoR ODM (Mongoid) полностью завершится, или я должен рассмотреть возможность использования PostgreSQL?

Еще несколько вопросов: 1) Какой из них больше подходит для разработки сайта социальной сети, похожего на Facebook.2) Какой из них больше подходит для 4-страничного стандартного макета веб-сайта (Дом, Продукты, О нас, Контакты)

Answer 1

Вы бросили проверенную десятилетиями, полнофункциональную СУБД для молодого, тонкого, функционального хранилища документов бета-качества с небольшой поддержкой сообщества.Если вы уже не используете десятки тысяч долларов в месяц на серверах и считаете, что MongoDB лучше подходит для ваших данных, вы, вероятно, потратили много времени на отрицательную выгоду.С MongoDB интересно играть, и я сам по этой причине создал несколько приложений, использующих его, но это почти никогда не лучший выбор, чем Postgres / MySQL / SQL Server / и т. Д.для производственных применений.

Answer 2

Давайте процитируем то, что вы написали, и посмотрим, что это говорит нам:

"I like a few things with Mongodb. However, I found certain queries I was
 doing in PostgreSql, I couldn't do efficiently in Mongodb. Especially,
 when I had to join several tables to calculate some logic."

"I found the ODM to be very limiting compared to what Active Record offered
 with traditional (SQL) database systems."

"I feel more comfortable working with PostgreSql than Mongodb. Only because
 I can join tables and do anything with the data."

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

Делись и наслаждайся.

Answer 3

Прежде всего postgres - это СУБД, а MongoDB - это NoSQL.
но автономные технологии NoSQL не соответствуют стандартам ACID, поскольку они жертвуют защитой критических данных в пользу высокой пропускной способности для неструктурированных приложений.

Postgres 9.4, обеспечивающий возможности NoSQL наряду с полной поддержкой транзакций, хранящий документы JSON с ограничениями на данные полей.

, поэтому вы получите все преимущества как от RDBMS, так и от NoSQL

проверьте подробный артикул http://www.aptuz.com/blog/is-postgres-nosql-database-better-than-mongodb/

Чтобы испытать производительность Postgres NoSQL для себя. Загрузите pg_nosql_benchmark на GitHub. вот ссылка https://github.com/EnterpriseDB/pg_nosql_benchmark

Answer 4

Я еще не использовал MongoDB и, возможно, никогда не смогу обойти его, поскольку я не нашел ничего, что я не могу сделать с Postgres, но просто процитирую примечания к выпуску PostgreSQL 9.2:

В PostgreSQL 9.2 результаты запроса могут быть возвращены в виде типов данных JSON.В сочетании с новыми расширениями для программирования баз данных PL / V8 Javascript и PL / Coffee и дополнительным хранилищем ключей-хранилищ HStore пользователи теперь могут использовать PostgreSQL как базу данных документов NoSQL, сохраняя при этом надежность, гибкость и производительность PostgreSQL.

Похоже, что в новых версиях Postgres вы можете получить лучшее из обоих миров.Я также еще не использовал это, но как поклонник PostgreSQL (отличные документы / списки рассылки), я бы не колебался использовать его почти для всего, что связано с СУБД.

Answer 5

Мой опыт работы с Postgres и Mongo после работы с обеими базами данных в моих проектах.

Postgres (RDBMS)

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

Самое большое преимущество пребывания в Postgres - это то, что у нас есть лучшее из обоих миров. Мы можем хранить данные в JSONB с ограничениями, согласованностью и скоростью. С другой стороны, мы можем использовать все функции SQL для других типов данных. Базовый движок очень стабилен и хорошо справляется с хорошим диапазоном объемов данных. Он также работает на выбранном вами оборудовании и операционной системе. Postgres предоставляет возможности NoSQL вместе с полной поддержкой транзакций, хранит документы JSON с ограничениями на данные полей.

Общие ограничения для Postgres

Горизонтальное масштабирование Postgres значительно сложнее, но выполнимо.

Операции быстрого чтения не могут быть полностью выполнены с помощью Postgres.

НЕТ баз данных SQL

Mongo DB (Wired Tiger)

MongoDB может превзойти Postgres в измерении «горизонтальной шкалы». Хранение JSON - это то, для чего оптимизирован Mongo. Mongo хранит свои данные в двоичном формате, называемом BSONb, который (приблизительно) является просто двоичным представлением надмножества JSON. MongoDB хранит объекты в точности так, как они были спроектированы. Согласно MongoDB, для приложений с интенсивной записью Монго говорит, что новый механизм (Wired Tiger) дает пользователям увеличение производительности записи в 10 раз (я должен попробовать это) с 80-процентным сокращением использования хранилища, помогая снизить затраты на хранение. , добиться большего использования аппаратного обеспечения.

Общие ограничения MongoDb

Использование механизма хранения без схемы приводит к проблеме неявных схем. Эти схемы не определяются нашим механизмом хранения, а определяются исходя из поведения и ожиданий приложения.

Автономные технологии NoSQL не соответствуют стандартам ACID, поскольку они жертвуют защитой критически важных данных в пользу высокой пропускной способности для неструктурированных приложений. Несложно применить ACID к базам данных NoSQL, но это сделает базу данных медленной и до некоторой степени негибкой. «Большинство ограничений NoSQL были оптимизированы в новых версиях и выпусках, которые в значительной степени преодолели свои предыдущие ограничения».

1. Какой из них больше подходит для разработки сайта социальной сети, похожего на Facebook? В настоящее время Facebook использует комбинацию баз данных, таких как Hive и Cassandra.
2. Какой из них больше подходит для 4-страничного стандартного макета веб-сайта (Главная, Продукты, О нас, Контакты) Опять же, это зависит от того, как вы хотите хранить и обрабатывать ваши данные. но любая база данных SQL или NOSQL сделает эту работу.

Answer 6

У нас также есть исследования того же, что лучше.PostGres или MongoDb.но со всеми фактами и цифрами в руках мы обнаружили, что PostGres гораздо лучше использовать, чем MongoDb.в MongoDb, помимо того, что съедает память и процессор, он также занимает большой объем дискового пространства.Это увеличивает размер диска в 2 раза за определенный интервал.