Мой вариант использования — это граф из нескольких сотен миллионов вершин (скажем, от 100M до 1B). Каждая вершина имеет набор из 10 свойств, которые в основном представляют собой оценки, вычисляемые на основе весов ребер вершины и оценок смежных вершин. При добавлении (или удалении) узлов в графе оценки всех вершин потенциально должны быть пересчитаны. Это не обязательно делать в режиме реального времени, и, таким образом, это определенно вариант использования OLAP/пакетной обработки. Есть также несколько очень простых требований к графовой OLTP, которые в основном просто считывают оценки данной вершины и смежных с ней узлов. Я пытаюсь определить, следует ли мне использовать любой из следующих подходов: 1- Giraph: это подразумевает экспорт всего графа в формате файла, загрузку его в Giraph, а затем загрузку результатов обратно в любое хранилище данных, используемое для сохранения. граф (Neo4J, Neptune, JanusGraph, HBase, RDBMS...). 2- Tinkerpop3's GraphComputer: если я правильно понимаю, я мог бы запустить алгоритм обновления графа OLAP непосредственно в базе данных графа, совместимой с Tinkerpop3 (JanusGraph, Neptune, другой?), и, таким образом, решить оба случая использования OLAP и OLTP с помощью одного инструмента, без необходимости импортировать/экспортировать дополнительные данные.
Обработка графов OLAP — Giraph против Tinkerpop3 GraphComputer
Ответы (1)
Если вы еще не получили необходимую вам производительность Graph OLAP или перенос данных в Spark оказался медленным или громоздким, я предлагаю вам взглянуть на AnzoGraph. Его запрограммировала та же команда, которая создала Netezza и ParAccel/Redshift.
AnzoGraph — это разработанная с нуля C/C++ высокопроизводительная реализация собственного механизма Graph OLAP (GOLAP) с массовой параллельной обработкой, т. е. интерактивная или пакетная аналитика в стиле хранилища данных и агрегация графических данных. Это очень высокая производительность и линейное масштабирование на обычных компьютерах, поэтому он будет обрабатывать упомянутый вами набор данных (вам может даже не понадобиться кластер для данных такого размера). На момент написания он не поддерживает Tinkerpop/Gremlin, что может быть проблемой для вас. Он поддерживает SPARQL1.1, а также RDF* (поддержка графов свойств, которая еще не является частью стандарта W3C SPARQL) и многие дополнительные функции расширения/агрегированные функции, необходимые для регулярной аналитики. Он также поддерживает вывод, именованные запросы, представления, различные алгоритмы графов и т. д.
Отказ от ответственности: я работаю в Cambridge Semantics.
