Я использую встроенный janusgraph в своем java-бэкэнде, мой код зависит от janusgraph, созданного из graph = JanusGraphFactory.open(conf)
AFAIK это напрямую подключается к Cassandra и эластичному поиску и запускает процессор janusgraph в моем бэкэнд-приложении JVM. Но если я хочу масштабировать janusgraph, мне нужно запустить отдельные серверы janusgraph в кластере и подключиться к этим серверам в качестве клиента из моего бэкэнда.
Согласно пример удаленного janusgraph на github это достигается с помощью создания экземпляра EmptyGraph graph = EmptyGraph.instance();
, который не является экземпляром JanusGraph, а org.apache.tinkerpop.gremlin.structure.util.empty.EmptyGraph;
.
Из приведенного выше примера я могу понять, что я могу использовать запросы gremlin, только отправив их на сервер janusgraph, но я не смогу использовать API управления напрямую, если не отправлю код в виде строки на сервер.
Наконец, я могу понять, что для масштабируемости лучше запускать сервер janusgraph отдельно, но я потеряю прямой доступ в моем коде к janusgraph apis, поэтому я хочу знать, понимаю ли я что-то, что я упускаю, и каковы плюсы и минусы в подход удаленного развертывания и что я потеряю от встроенного подхода?
Изменить:
Согласно этому ответу исправьте его, если он ошибается:
Плюсы / минусы подключения к удаленному серверу gremlin
Плюсы
- У сервера гораздо больше контроля, и все запросы централизованы.
- Поскольку каждый выполняет обход / запросы через удаленный сервер gremlin, все они защищены транзакциями. Удаленный сервер gremlin по умолчанию выполняет ваш обход / запросы в транзакции.
- Централизованное управление стратегией
- Центральное управление схемой
Минусы
- Сложно выполнять ручное управление транзакциями
- Вы должны использовать Groovy-скрипт в качестве строки и отправить его на удаление (Cluster submit) для транзакционного выполнения вашего кода.