JCR против JPA для DMS: производительность, преимущества, недостатки

Краткая версия: Документы представляют собой структурированное или полуструктурированное содержимое. Это вариант использования иерархически организованного хранилища данных. Вы должны пойти на JCR, если вы не хотите реализовывать все основные вещи dms/cms для себя (учтите это, вы, вероятно, делаете это в первый раз, в то время как они делали это все время).

Длинная версия: JCR охватывает большую часть основных вариантов использования систем управления документами или контентом по спецификациям, таким как управление версиями, блокировка, управление жизненным циклом или ссылочная целостность. Кроме того, это позволяет вам расширять ваши данные без изменения схемы (конечно, вы можете определить свои типы узлов в модели, но это не обязательно). Большинство реализаций JCR (например, Jackrabbit) используют базу данных в бэкэнде, что делает их «немного больше», чем слой абстракции над вашим реляционным бэкендом. Для работы с большими данными вы можете использовать хранилище файловой системы (что намного быстрее, чем хранение всех двоичных данных в базе данных) при сохранении структурированных данных (узлов и свойств) в базе данных.

При переходе на JPA вам придется иметь дело со всеми этими вещами dms/cms самостоятельно. Конечно, вы можете это сделать, но это гораздо более низкоуровневое программирование, которое уже было сделано в реализации JCR. Каждое изменение модели требует изменения схемы, а макет таблицы не так тривиален (вы хотите иметь большую таблицу для ваших документов, где каждое свойство является столбцом? вы хотите иметь отдельную таблицу для каждого класса документов? как вы моделируете жизненные циклы, как вы моделируете управление версиями?)

Для первых прыжков с JCR я бы рекомендовал Модель Дэвида, считайте все ваше приложение контентом . Я работал в проекте, где мы отказались от сочетания JCR и JPA, чтобы нам не приходилось иметь дело с разными API для хранения.

И есть по крайней мере несколько реализаций JCR.

• Jackrabbit 2 (Эталонная реализация, оптимизированная для операций чтения, в настоящее время находится в режиме обслуживания)
• Jackrabbit OAK (нацелен на высокомасштабируемые репозитории контента с балансировкой производительности чтения/записи. Он принадлежит той же основной команде, что и Jackrabbit)
• Jackrabbit FileVault (бэкенд исключительно в файловой системе)
• Modeshape (альтернативная реализация, быстрая и масштабируемая, с REST API, довольно хорошая документация)

Кстати. JCR API и реализации в значительной степени сделаны с учетом архитектуры RESTful. Поэтому, если вы рассматриваете REST API, сопоставление тоже довольно простое. Кроме того, это позволяет потребителю исследовать контент напрямую через JCR API, что упрощает интеграцию контента в другие приложения (т.е. только для чтения), в то время как вам нужно раскрыть внутреннюю структуру вашей базы данных с помощью JPA, что повышает вероятность нарушения потребительских контрактов. на изменения.

По оставшимся вопросам:

• У меня нет сравнительных диаграмм, и, как обычно, это зависит от структуры данных и индексов, а также от дизайна вашего запроса. Реализации JCR имеют встроенное кэширование, и вы обычно перебираете наборы результатов. Таким образом, нет общего утверждения о том, что быстрее/медленнее, все зависит от варианта использования.
• Я сделал нечто подобное, и мы остались довольны реализацией Jackrabbit, но мы были на JDK7. У нас были все данные (включая пользовательские настройки, настройки приложения и т. д.) в репозитории и вообще не сохранялись JPA. Также доступно сопоставление содержимого объектов, если оно вам нужно.
• Да, стоит представить. В Jackrabbit есть собственное управление пользователями — вам не нужно реализовывать его самостоятельно. А управление доступом доступно через JCR API и JAAS. Хотя я рекомендую не использовать JCA ResourceAdapter для администрирования управления пользователями и контроля доступа, так как он не предоставляет API Jackrabbit.
• Вопрос о целостности данных и резервном копировании не является особенным для JCR или JPA, оба обеспечивают целостность на некотором уровне (целостность базы данных, JCR выполняет ссылочную целостность), и оба могут быть скопированы (резервное копирование db, резервное копирование fs). И оба являются стандартизированным способом доступа к данным, так что вы даже можете создать свою собственную логику резервного копирования.