У меня есть проблема, которая, кажется, хорошо подходит для графовой базы данных, но я не уверен, как лучше всего ее применить.
Во-первых, это набор объектов, которые могут иметь направленные ссылки (их несколько десятков миллионов, типичное число входов/выходов ссылок составляет несколько тысяч на объект). Затем каждый объект может накапливать репутацию (подумайте о голосовании, карме и т. д.) от потенциально очень большого числа пользователей (также десятков миллионов).
Сложность заключается в том, что всякий раз, когда пользователь настраивает репутацию объекта, я хотел бы обновить репутацию всех связанных с ним объектов (возможно, выше первой степени) на основе некоторых довольно сложных правил.
В SQL это будет выглядеть примерно так:
CREATE TABLE objects (id INTEGER PRIMARY KEY);
CREATE TABLE object_links (from_object_id INTEGER, to_object_id INTEGER);
CREATE TABLE users (id INTEGER PRIMARY KEY);
CREATE TABLE object_reputations (object_id INTEGER, user_id INTEGER, reputation FLOAT);
UPDATE
object_reputations
SET
object_reputations.reputation = object_reputations.reputation + ... # some formula goes here
FROM
object_reputations
INNER JOIN object_links
ON object_reputations.object_id = object_links.to_object_id
WHERE
object_links.from_object_id = ...;
Поскольку речь идет о графе, база данных графа кажется естественной, но после быстрого чтения API-интерфейсов Neo4j / OrientDB / Blazegraph / Tinkerpop я не могу понять, как сопоставить эту проблему с тем, что они могут делать вообще.
Используя Tinkerpop в качестве примера, объекты — это вершины, связи между объектами — это ребра (пока все хорошо), а репутация…? Возможно, VertexPropetries, но я не уверен, как все будет масштабироваться с потенциально таким количеством свойств на вершину, сколько пользователей. Или, возможно, репутации являются взвешенными ребрами от пользовательских вершин... которые, казалось бы, имеют другой тип проблем с производительностью.
Можете ли вы дать простой перевод такого рода задач в одну из популярных графовых баз данных?
