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

Question

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

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

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

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

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

Answer 1

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

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

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

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