Момонд и мысли PostgreSql

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

Мне нравится кое-что с Мондомбом. Тем не менее, я нашел определенные запросы, которые я делал в PostgreSql, я не мог эффективно работать в Mongodb. Особенно, когда мне пришлось присоединиться к нескольким таблицам, чтобы вычислить некоторую логику. Например, this.

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

Даже до этой даты я чувствую себя более комфортно, работая с PostgreSql, чем Mongodb. Только потому, что я могу присоединиться к таблицам и делать что-либо с данными.

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

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

Ответ 1

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

Ответ 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 теперь лучше подходит вам.

Поделитесь и наслаждайтесь.

Ответ 3

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

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

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

Ответ 4

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

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

чтобы вы получили все преимущества как из СУБД, так и из 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

Ответ 5

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

Ответ 6

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

Postgres (СУБД)

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

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

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

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

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

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

Mongo DB (Wired Tiger)

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

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

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

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

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