Эмуляция поведения соединения с Rails и Mongoid

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

Итак, если мне нужна гибкость и нужно, чтобы мои данные объединялись несколько раз, стоит ли мне использовать Postgresql? Я знаю, что mongodb имеет быстрое чтение/запись, но ему нужно запрашивать несколько раз, чтобы эмулировать соединения. Так когда же это станет хитом? Ограничивает ли mongodb вашу способность создавать новые сложные отношения с вашими данными, которых раньше не было?

Я предполагаю, что привлекательность mongodb заключается в его синтаксисе javascript и сходстве с json :)


postgresql mongodb ruby-on-rails-3 mongoid
person seogrady    schedule 20.09.2011    source источник

Ответы (3)


arrow_upward
4
arrow_downward

Начну с конца:

Я предполагаю, что привлекательность mongodb заключается в его синтаксисе javascript и сходстве с json :)

Не только это, но и стиль json не является главным преимуществом. Основными преимуществами mongodb являются возможность встраивания документов, высокая производительность и полная масштабируемость, полная поддержка индексов, сопоставление/уменьшение и т. д.

Итак, если мне нужна гибкость и нужно, чтобы мои данные объединялись несколько раз, стоит ли мне использовать Postgresql?

Это зависит от конкретной задачи, например, если вы разрабатываете систему отчетов, я предпочитаю использовать какую-либо реляционную базу данных. Но иногда вместо объединений и отдельных коллекций вы можете встраивать документы + mongodb, которые хорошо подходят для денормализации данных (и во многих ситуациях вы можете денормализировать в фоновом режиме, чтобы избежать объединений)

Я знаю, что mongodb имеет быстрое чтение/запись, но ему нужно запрашивать несколько раз, чтобы эмулировать соединения. Так когда же это станет хитом?

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

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

Никакой mongodb не ограничивает вас, потому что он не содержит никаких ограничений между коллекциями, такими как внешний ключ в любой базе данных sql + он позволяет встраивать и легко денормализировать данные в соответствии с потребностями вашего бизнеса и достигать наилучшей производительности.

person Andrew Orsich    schedule 20.09.2011
comment
Андрей, спасибо за подробный ответ! Мне также интересно, когда дело доходит до дизайна схемы, если у меня есть коллекции «Люди», «Места», «Автомобили» и «Группы», и все они должны иметь возможность быть связанными, какой будет наиболее эффективный способ сделать это? Таким образом, в группах могут быть люди и места, у людей могут быть места, у людей могут быть машины, а у мест могут быть машины. Буду ли я хранить все объекты в их собственных коллекциях, а затем создавать новые коллекции, включающие объекты данных, в которых хранится массив связанных идентификаторов объектов? Затем обновить все упомянутые объекты при обновлении? - person seogrady; 20.09.2011

arrow_upward
2
arrow_downward

Другой альтернативой может быть денормализация ваших данных.

Вы храните копии данных в нескольких таблицах/коллекциях. При этом вы избегаете необходимости в JOIN и поисковых запросах, необходимых для объединения связанных фрагментов данных.

Вы избегаете объединений и сохраняете больше данных, но ваше приложение в целом может работать быстрее.

В mongoid есть два отличных драгоценных камня, облегчающих это:

Mongoid_alize и Монгоид_деномализировать

http://blog.joshdzielak.com/blog/2012/05/03/releasing-mongoid-alize-comprehensive-field-denormalization-for-mongoid/

person holden    schedule 30.07.2012

arrow_upward
1
arrow_downward

Вы всегда можете использовать: http://www.mongodb.org/display/DOCS/MapReduce

Или http://www.mongodb.org/display/DOCS/Aggregation#Aggregation-Group

person twooface    schedule 20.09.2011