TitanDB загружает полный график в память при использовании g.V() от Tinkerpop?

Question

Я использую Titan сейчас.

Я хочу использовать «g.V(). Values ​​()», поддерживаемый Tinkerpop в моем приложении Titan, достигая обхода графика.

На мой взгляд, Tinkerpop загружает глобальный график в память при использовании этого итератора. Титан, похоже, вызывает этот метод напрямую и не переопределяет.

Итак, действительно ли Titan загружает полный график в память при выполнении g.V()?

Если ответ верен, я буду беспокоиться о размере памяти, когда график будет достаточно большим.

Answer 1

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

Я не уверен, где вы собрали этот вывод, но целью интерфейсов TinkerPop является противоположность. Графические базы данных, которые реализуют интерфейсы TinkerPop , должны использовать возможности сохранения памяти Iterator и быть умными о том, как они загружают данные. Я пишу «обязательно» курсивом, потому что TinkerPop действительно не имеет возможности обеспечить выполнение этого требования. Нет ничего, что помешало бы поставщику графа вытащить все данные в своей базе данных в память при вызове g.V().

Это говорит о том, что я не знаю каких-либо постоянных (т. Е. Не в памяти, где граф уже находится в памяти). Реализация TinkerPop, которая делает это, включая Titan. Титан не смог бы масштабироваться очень хорошо, если бы это было так. Конечно, это не означает, что вы выполняете глобальное извлечение всех вершин в миллиардном краевом графе в обходном режиме OLTP с g.V(), что означает, что вы получите хорошие результаты. Вы долго ждали завершения этого обхода, если он вообще вернется (т. Е. Тайм-ауты и другие экологические проблемы). Для глобальных запросов графов вы бы хотели использовать titan-hadoop и обход OLAP-стиля в этих случаях.