Модель данных для графа свойств через HBase / Cassandra

Я хочу сохранить график свойств в HBase. График свойств - это узлы и ребра графа, которые имеют свойства, и несколько ребер могут связывать один и тот же кортеж узлов, если ребра принадлежат разным типам.

Мой шаблон запроса будет либо запрашивать свойства и окрестности, либо обходить граф. Пример: Vertex [name = claudio] => OutgoingEdge [знает] => Vertex [пол = женский], который даст мне всех женщин, которые нравятся клаудио.

Я знаю, что база данных графов делает именно это, но они обычно не масштабируются на нескольких узлах в случае огромного набора данных. Итак, я готов реализовать это в NoSQL ColumnStore (HBase, Cassandra ...)

Моя модель данных следует.

Таблица вершин :
ключ: vertexid (uuid)
Семейство «Свойства:»: <имя свойства> => <значение свойства>, ...
Семейство "OutgoingEdges:": => , ...
Семейство "IncomingEdges:": то же, что и исходящие ребра ...

Эта таблица позволяет мне быстро получить свойства вершины и его список смежности. Я не могу использовать vertexid в качестве другой конечной точки потому что несколько ребер (с разными типами) могут соединять одни и те же два вершины.

Таблица кромок :
ключ: ключ ребра (составной (<исходный идентификатор вершины>, <целевой вершинный идентификатор>, <имя типа ребра>)) (т.е. vertexid1_vertexid2_knows)
Семейство «Свойства:»: <имя свойства> => <значение свойства>, ...

Эта таблица позволяет мне быстро получить свойства кромки.

Типы кромок :
ключ: составной (, "out | in", ) (т.е. vertexid1_out_knows)
Семейство "Neighbor:": => null, ...

Эта таблица позволяет мне искать / сканировать ребра, которые являются входящими или исходящие из вершины и принадлежащие определенному типу, и будут ядро возможности обхода API (поэтому я хочу, чтобы он был таким же быстрым, как возможны как с точки зрения сетевого ввода-вывода (RPC), так и с точки зрения дискового ввода-вывода (поиск)). Это должен также "масштабироваться" по размеру графика, что означает, что с рост графика стоимость данного вида операции должна зависеть от количество ребер, выходящих из вершины, а не общее количество вершин и ребер. В приведенном выше примере я бы рассматривал vertexid1 как исходную вершину с имя свойства: claudio я бы просканировал vertexid1_out_knows и получил список вершины связаны. После этого я могу сканировать столбец «Свойства: пол» на этих вершинах и ищите те, у которых есть "женское" значение.

Вопросы:

1) Общее: видите ли вы лучшую модель данных для моих операций?
2) Могу ли я уместить все в одну таблицу, где для определенных ключей несколько семьи будут пустыми (то есть "OutgoingEdges:" семья не будет смысл по краям)? Я бы хотел этого, потому что, как вы видите, все ключи состоят из префикса vertexid uuid, поэтому они будут очень компактными и подходят в основном на одном региональном сервере.
3) Думаю, что для сканирования я бы широко использовал фильтры. я думаю, фильтр regexp будет моим другом. Есть ли у вас опасения по поводу производительность фильтров, примененных к этой модели данных?