Обработчик транзакций Tinkerpop Gremlin с байт-кодом?

Я использую язык Gremlin для запроса JanusGraph (и других систем баз данных) и обычно отправляю свои запросы в формат ByteCode с использованием traversal op processor. Однако для некоторых запросов мне нужны транзакции (также известные как сеансы) для пакетной обработки нескольких операций чтения / записи, и для этого я должен использовать _ 3_ операционный процессор.

Проблема - процессор traversal принимает запросы в байт-коде гремлина, тогда как процессор session op принимает запросы в виде строк гремлина. Есть ли способ, которым я могу делать запросы, которые одновременно являются транзакционными (поскольку мне нужна последовательность кратных операций чтения и записи) и отправляются как ByteCode?

В основном я спрашиваю, поскольку обнаружил, что запросы, выполняемые как ByteCode через процессор traversal, имеют значительно меньшее время накладных расходов, чем те же запросы, выполняемые как строки с другими процессорами (разница примерно в 30 мс).

Заранее спасибо!


person Barak Itkin    schedule 01.04.2019    source источник
comment
Стивен Маллетт, я думаю, что есть какое-то решение, даже несмотря на то, что в настоящее время оно не идеально. обратитесь: issues.apache.org/jira/browse/TINKERPOP-2252 и я также считаю, что сеанс важен, потому что многим пользователям нужна эта возможность ,, а noe4j и многие другие системы также поддерживают сеанс   -  person Stark Arya    schedule 02.07.2019


Ответы (1)


Вы не можете использовать запросы на основе байт-кода с сеансами, и в будущем нет намерений поддерживать это. Фактически, сеансы обычно присутствуют для очень конкретных случаев использования, связанных с разработкой инструментов, таких как Gremlin Console (и аналогичные приложения для визуализации графиков), и, вероятно, в какой-то момент будут устаревать (и в TinkerPop 4.x полное удаление). Лучше не зависеть от этого. TinkerPop в основном исходит из определения транзакции как ограниченной до одного обхода.

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

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

person stephen mallette    schedule 01.04.2019
comment
Спасибо за разъяснения! В связи с этим мне интересно, как люди собираются реализовать атомарные операции чтения, ›логики приложения,› записи. Я надеюсь, что ответ заключается в том, что он должен выходить за рамки gremlin (т.е. непосредственно с API, специфичными для БД), поскольку это предотвратит полное использование транзакций в JanusGraph. - person Barak Itkin; 01.04.2019
comment
транзакционные возможности среди поставщиков графов довольно широки. tinkerpop, как правило, испытывает трудности с удовлетворением потребностей или всей различной семантики, поэтому один обход == одна транзакция является хорошим подходом с наименьшим общим знаменателем. в зависимости от логики приложения, вы можете иногда получить значительную часть этого встроенного в один обход. В конечном итоге вы всегда можете вернуться к API-интерфейсам конкретного поставщика, чтобы выполнить то, что вам нужно, но, очевидно, если вы кодируете на python (например), вы не можете напрямую использовать JanusGraph APis - вам нужно будет использовать Java. - person stephen mallette; 01.04.2019