Сохранение данных графика (Java)

Поскольку вы указываете, что существует большой объем данных, вам, вероятно, понадобится механизм, с помощью которого вы можете легко вводить данные по мере необходимости. Сериализацией, вероятно, не так-то просто справиться с большими объемами данных. Чтобы разбить его на управляемые части, вам нужно будет либо использовать отдельные файлы на диске, либо хранить их в другом месте. JCR (JackRabbit) - это скорее система управления контентом. Они хорошо подходят для объектов типа «документ». Похоже, отдельные части дерева, которые вы хотите сохранить, могут быть небольшими, но вместе они могут быть большими. Это не идея CMS.

Другой вариант, который вы упомянули, ORM, вероятно, будет вашим лучшим вариантом. JPA (Java Persistence API) отлично подходит для выполнения ORM на Java. Вы можете написать в спецификации JPA и использовать Hibernate, Eclipselink или любой другой вариант провайдера месяца. Они будут работать с любой базой данных, которую вы хотите. http://java.sun.com/javaee/5/docs/api/index.html?javax/persistence/package-summary. html

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

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

Можно ли выполнить некоторую предварительную обработку ваших данных? Если проблема аналогична, очень важно попытаться преобразовать данные в промежуточную форму, которая ближе к вашему представлению, чем исходный домен, и сохранить это в БД. Вы всегда можете ссылаться на исходный источник, используя тип отложенной выборки.

В основном мы использовали четырехуровневую систему: база данных домена, Гибрид ViewModel-DB (предварительно обработанный слой), ViewModel, View

Преимущество этого шага предварительной обработки (особенно с пользовательским интерфейсом в реальном времени) состоит в том, что вы можете страницы данных в ViewModel и визуализировать их красиво. Так много производительности в приложении реального времени незначительно, просто оставайтесь отзывчивыми и покажите им что-нибудь приятное, пока они ждут. В нашем случае мы могли отображать трехмерные области данных, в которых выполняется подкачка, данные, которые были связаны с данными загрузки, также могли отображать визуальный индикатор. Гибрид ViewModel-DB также может делать приятные вещи, такие как очереди LRU, которые соответствуют данным нашего домена. Однако самым большим преимуществом было удаление прямых ссылок. У узлов было что-то похожее на URL-адрес связанных данных. При рендеринге мы могли отобразить ссылку или отобразить, что есть ссылка, по которой мы просто просматриваем ее в данный момент.

Сохранение на уровне БД было JPA (Hibernate) для запуска, но в итоге таблицы, которые он генерировал для нашей структуры наследования, были ужасными и трудными в обслуживании. В конце концов, нам нужно было больше контроля над таблицами, чем разрешено JPA (или, по крайней мере, легко разрешено). Это было трудное решение, поскольку JPA упростила большую часть уровня БД. Поскольку в JPA все было хорошо, а в POJO, нам не нужно было возиться с нашими типами данных. Так что это было хорошо.

Надеюсь, вы что-то сможете извлечь из этого извилистого ответа, и удачи :)

ORM, например, с использованием JPA api (Hibernate, EclipseLink, ...), вероятно, позволит очень быстро реализовать постоянство. Чистая производительность персистентности всего дерева, как правило, сложнее достичь по сравнению с обычным JDBC. Так что, если ваш единственный критерий эффективности - сохранение всего дерева за один раз, это, вероятно, не лучший вариант.
С другой стороны, если вам также необходимо загрузить дерево, синхронизировать изменения дерева, тогда JPA предлагает эту встроенную функцию с (после небольшой настройки) лучшей производительностью, чем многие ручные реализации.

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

В той же категории, что и сериализация, вы можете сериализовать в XML и сохранить его в некоторой базе данных XML (Oracle XDB). Однако они предназначены больше для гибкости хранения / запросов, чем для чистой скорости.

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

рассмотрите возможность хранения ваших узлов в базе данных, подходящей схемой может быть:

t1(node_id,child_id)
t2(node_id,data1,data2,..,datan)

затем используйте JDBC для доступа / изменения данных. если вы используете правильные индексы, он будет работать достаточно хорошо при масштабировании около 100 миллионов записей. На мой взгляд, следует избегать сериализации общих объектов, если производительность действительно важна, потому что вы теряете некоторый контроль над характеристиками производительности кода с этими решениями.

если вам нужна более высокая производительность, вы можете использовать memcached слой.

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

Она решает две ваши основные проблемы: производительность и прозрачность . Он легко масштабируется до больших графов, сохраняя при этом высокую производительность, благодаря эффективному механизму синхронизации, который отправляет только различия экземпляров по сети. Он также сохраняет ваш график прозрачно, потому что он работает на уровне виртуальной машины, избавляя вас от проблемы несоответствия импеданса, с которой вы столкнетесь с альтернативами, упомянутыми в других ответах (ORM или OCM).

Чтобы быть ясным, Terracotta не настойчивое решение для любого случая. Это' Лучше всего использовать, когда вам нужны данные, доступные после перезагрузки машины, и вам это нужно быстро. Это не лучшее решение, если вам нужно «заархивировать» эти данные, например, если у вас есть требования для доступа к этим данным спустя много времени после того, как работающая система перестала с ними работать. Подумайте о заказах, поступающих в интернет-магазин. Вероятно, вы захотите хранить эти заказы в течение многих лет после того, как они будут выполнены. В этих случаях вы можете использовать гибридный подход, при котором выбранные данные, которые необходимо заархивировать, могут быть извлечены из кластера Terracotta и сохранены с использованием традиционной СУБД.

Для более полного обзора плюсов и минусов обязательно прочтите эту публикацию на StackOverflow , в которой освещается больше мелких деталей при выборе.