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

Question

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

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

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

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

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

Answer 1

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

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

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

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