Сервер Neo4j против встраиваемых

Question

Я немного озадачен тем, что является лучшим решением для моего приложения. Как я уже видел, мне приходится выбирать между neo4j standalone (RestGraphDatabase) и EmbeddedGraphDatabase (RemoteGraphDatabase пока не предназначен для производственного использования).

Плюсы ОТДЫХ:

-> Различные службы могут обращаться к базе данных neo4j (пример: у меня есть одна служба, которая отвечает за узлы типа A, B и C. Вторая служба отвечает за узлы D и H и может подключать D-узлы к A -nodes). Таким образом, у меня есть чистые доменные структуры. Каждый сервис отвечает только за свои доменные узлы. Я могу обновить каждый сервис, и мне не нужно закрывать все приложение.

-> Я могу получить доступ к базе данных neo4j с разных языков (PHP)

Минусы: - Производительность не так хороша, как у EmbeddedGraphDatabase (поскольку сервер neo4j и сервисы находятся на одной машине, задержка невелика). - Нет транзакций

Мои вопросы: Это хорошее решение, чтобы пойти с автономным сервером? Или я должен использовать встроенный и смешать сервисы в один большой? Можно ли запустить большое (сложное) приложение без поддержки транзакций?

Answer 1

Вы правы, что производительность с REST-сервером будет меньше.Однако вы можете иметь что-то вроде транзакций с REST-сервером, используя пакетные операции;см. http://docs.neo4j.org/chunked/milestone/rest-api-batch-ops.html. Вы также можете создавать специфичные для домена серверные плагины, которые выполняют логику транзакций на стороне сервера: http://docs.neo4j.org/chunked/milestone/server-extending.html.

Если ваша архитектура требует, чтобы вы имели доступ к базе данных с нескольких клиентских компьютеров, вашими единственными вариантами являются сервер REST или Neo4j HA (высокая доступность).HA доступен только с лицензией Neo4j Enterprise.

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

Answer 2

Все зависит от вашего варианта использования.Вы уже перечислили некоторые плюсы и минусы.

Еще один профи для сервера - это web-admin / visualization.

У вас есть еще несколько вариантов.Вы можете иметь встроенный graphdb для высокой производительности и иметь только некоторые запущенные сервисы, а также использовать собственный, ориентированный на домен удаленный (REST или другой) API для предоставления базы данных графа для других сервисов.

То же самое может бытьдостигается за счет использования сервера Neo4j и добавления некоторых из наиболее критичных для производительности сервисов, таких как Плагины-серверы или Расширения , которые также могут предоставлять пользовательский удаленный API, который, вероятно, подходит для ваших сценариев использованиялучше.

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

В REST-API есть одна транзакция на запрос, для более крупных операций в API есть пакетная операция .