Как Titan обеспечивает постоянный поиск по времени с помощью HBase / Cassandra?

В книге О'Рейли «Графовые базы данных» в главе 6, которая рассказывает о том, как Neo4j хранит графовую базу данных, говорится:

Чтобы понять, почему обработка собственных графов намного эффективнее, чем графы, основанные на интенсивной индексации, рассмотрим следующее. В зависимости от реализации, поиск индекса может быть O (log n) по алгоритмической сложности по сравнению с O (1) для поиска непосредственных отношений. Чтобы пересечь сеть из m шагов, стоимость индексированного подхода, равная O (m log n), превосходит стоимость O (m) для реализации, в которой используется смежность без индекса.

Затем поясняется, что Neo4j достигает этого постоянного поиска времени, сохраняя все узлы и отношения как записи фиксированного размера:

С записями фиксированного размера и идентификаторами записей, похожими на указатели, обходы осуществляются просто путем поиска указателей вокруг структуры данных, что может быть выполнено с очень высокой скоростью. Чтобы проследить определенное отношение от одного узла к другому, база данных выполняет несколько дешевых вычислений идентификаторов (эти вычисления намного дешевле, чем поиск по глобальным индексам, как нам пришлось бы делать, если имитировать граф в неграфовой собственной базе данных)

Последнее предложение вызывает у меня вопрос: как Titan, использующий Cassandra или HBase в качестве бэкэнда хранилища, может добиться такого повышения производительности или восполнить его?

Ответы на вопрос(2)

Ваш ответ на вопрос