Документно-ориентированные базы данных больше подходят для сохранения объектов, чем реляционные?

Что касается использования баз данных, последнее десятилетие было эпохой ORM, когда сотни конкурировали за сохранение наших объектных графов в простом старомодном RMDBS. Сейчас мы, кажется, являемся свидетелями наступления эры документно-ориентированных баз данных. Эти базы данных высоко оптимизированы для документов без схемы, но также очень привлекательны своей возможностью масштабирования и параллельного запроса кластера.

Документно-ориентированные базы данных также обладают рядом преимуществ перед РСУБД для сохранения моделей данных в объектно-ориентированных проектах. Поскольку таблицы не содержат схемы, можно хранить объекты, принадлежащие разным классам, в иерархии наследования бок о бок. Кроме того, при изменении модели предметной области, если код может справиться с получением объектов из старой версии классов предметной области, можно избежать необходимости переносить всю базу данных при каждом изменении.

С другой стороны, преимущества в производительности документно-ориентированных баз данных, по-видимому, в основном проявляются при хранении более глубоких документов. В объектно-ориентированных терминах классы, которые состоят из других классов, например, сообщение в блоге и его комментарии. В большинстве примеров этого, которые я могу придумать, например, в блоге, выигрыш в доступе для чтения, по-видимому, компенсируется штрафом, заключающимся в необходимости писать весь «документ» сообщения в блоге каждый раз, когда появляется новый комментарий. добавлен.

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

Так является ли случай реляционных баз данных по сравнению с документно-ориентированными базами данных колебаниями и обходными путями? Меня интересуют мнения и советы людей, особенно если кто-нибудь создал какие-либо важные приложения на базе данных, ориентированной на документы.


database orm document-oriented-db
person Owen Fraser-Green    schedule 25.02.2010    source источник

Ответы (1)


arrow_upward
5
arrow_downward

Ну, это зависит от того, как структурированы ваши данные и от шаблонов доступа к данным.

Базы данных документов хранят и извлекают документы, а базовая атомарная хранимая единица - это документ. Как вы сказали, вам нужно подумать о своих шаблонах / вариантах использования доступа к данным, чтобы создать интеллектуальную модель документа. Когда ваша модель предметной области может быть разделена на несколько документов, база данных документов работает как шарм. Например, для программного обеспечения для блогов, CMS или вики-программ очень хорошо работает document-db. Пока вы можете найти хороший способ втиснуть данные в документ, у вас не будет никаких проблем. Но не пытайтесь для соответствия реляционной модели базе данных документов. Как только в шаблонах доступа к данным используется много «навигации» по отношениям, граф или объектные базы данных становятся более естественным выбором.

Другое дело - компромисс между производительностью чтения / записи. Например, программное обеспечение для блогов. В переходной модели данных РСУБД данные нормализованы. Это означает, что чтение данных стоит дорого, потому что чтение из разных таблиц, вычисление отношений с объединениями и т. Д. Для чтения сообщения в блоге. Взамен замена тега обходится недорого. Напротив, в базе данных документов чтение сообщения в блоге обходится дешево, потому что вы просто загружаете пост-документ. Однако обновление, вероятно, обходится дороже, потому что вам нужно хранить весь документ. Или, что еще хуже, просмотреть кучу документов, чтобы что-то изменить (переименовать тег-сценарий). В большинстве систем чтение намного важнее письма. Так что действительно имеет смысл использовать перенормированные хранилища данных.

Я думаю, что в больших базах данных дизайн без схемы может иметь свои преимущества. В СУБД вам необходимо обновить схему, что является действительно болезненным процессом. Специально для преобразования существующих данных в новую схему. В базе данных без схемы ваше приложение должно иметь дело с этим, что дает большую гибкость. Например, вы можете обновить схему на лету, когда есть доступ к старому документу. Таким образом, вы можете поддерживать свою гигантскую базу данных в рабочем состоянии, в то время как приложение обрабатывает старые версии на лету.

person Gamlor    schedule 13.06.2010
comment
Спасибо за это. Я участвую в презентации MongoDB, и докладчик не очень хорошо освещал тему сравнения между реляционными и документальными. Этот ответ, в частности, с примером обновления тегов, был очень полезен. - person Domenic; 26.05.2011