Я готов сохранить График свойств в HBase. Граф свойств представляет собой граф узлов, и ребра имеют свойства, и несколько ребер могут связывать один и тот же набор узлов, если ребра принадлежат разным типам.
Мой шаблон запроса будет либо запрашивать свойства и окрестности, либо проходить по графику. Пример: Vertex [name = claudio] => OutgoingEdge [знает] => Vertex [пол = женский], который даст мне всех женщин, которых любит Клаудио.
Я знаю, что графическая база данных делает именно это, но они обычно не масштабируются на нескольких узлах в случае огромного набора данных. Поэтому я готов реализовать это в NoSQL ColumnStore (HBase, Cassandra ...)
Моя дата-модель следует.
Таблица вершин :
ключ: vertexid (uuid)
Семейство "Свойства:": <имя свойства> => <значение свойства>, ...
Семейство "OutgoingEdges:": <ключ ключа> => <другой вершинный номер>, ...
Семейство "IncomingEdges:": такое же, как исходящие ребра ...
Эта таблица позволяет мне быстро получить свойства вершины и
список соседей. Я не могу использовать вершину в качестве другой конечной точки
потому что несколько ребер (с разными типами) могут соединять одни и те же два
Вершины.
Таблица кромок :
ключ: ключ края (составной (<исходный вершинный>, <целевой вершинный>,
<имя типа ребра>)) (то есть vertexid1_vertexid2_knows)
Семейство "Свойства:": <имя свойства> => <значение свойства>, ...
Эта таблица позволяет мне быстро получить свойства ребра.
Типы кромок :
ключ: составной (
, "out | in", ) (т.е.
vertexid1_out_knows)
Семейство "Сосед:": <конечный вершина назначения> => пусто, ...
Эта таблица позволяет мне искать / сканировать ребра, которые либо поступают
или исходящий из вершины и принадлежат к определенному типу и будет
Ядро обходной способности API (поэтому я хочу, чтобы это было так быстро, как
возможно как с точки зрения сетевого ввода-вывода (RPC), так и с дискового ввода-вывода (поиска)). Это
следует также «масштабировать» на размер графика, что означает, что с
По мере роста графика стоимость этого типа операции должна зависеть от
количество ребер, исходящих из вершины, а не от общего числа
вершин и ребер.
В приведенном выше примере я бы рассматривал vertexid1 исходную вершину с
имя свойства: claudio я бы просканировал vertexid1_out_knows и получил список
вершины связаны. После этого я могу сканировать столбец
«Свойства: пол» на этих вершинах и ищите тех, кто имеет
«женская» ценность.
Вопросы:
1) Общие сведения: видите ли вы лучшую модель данных для моих операций?
2) Могу ли я поместить все в одну таблицу, где для определенных ключей некоторые
семьи будут пустыми (то есть семья "OutgoingEdges:" не создаст
смысл по краям) Я хотел бы, потому что, как вы можете видеть все ключи
состоят из префикса vertexid uuid, поэтому они будут очень компактными
и подходят в основном на одном сервере региона.
3) Я думаю, что для сканирования я бы широко использовал фильтры. я
думаю, регулярное выражение фильтра будет моим другом. Есть ли у вас опасения по поводу
производительность фильтров, примененных к этой модели данных?