Neo4j Titan如何使用HBase/Cassandra实现固定时间查找？

在第6章O'Reilly的书“图形数据库”中，关于Neo4j如何存储图形数据库，它说：

了解为什么原生图形处理效率更高 基于重索引的图形，请考虑下面的内容。根据实现的不同，索引查找的算法复杂度可以是O（logn），而查找直接关系的算法复杂度可以是O（1）。 要遍历由m个步骤组成的网络，索引方法的成本为 O（m logn），对于使用 无索引邻接

然后解释，Neo4j通过将所有节点和关系存储为固定大小的记录来实现此恒定时间查找：

对于固定大小的记录和类似指针的记录ID，遍历是 只需围绕数据结构追踪指针即可实现 可以在非常高的速度下执行。穿越某一特定区域 从一个节点到另一个节点，数据库执行多个 廉价的ID计算（这些计算比 搜索全局索引，就像在 非图形（本地数据库）

最后一句话引发了我的问题：使用Cassandra或HBase作为存储后端的Titan如何实现或弥补这些性能提升？

Neo4j仅在数据位于同一JVM的内存中时才实现O（1）。当数据在磁盘上时，Neo4j速度很慢，因为指针在磁盘上追逐（它们的磁盘表示形式很差）

Titan仅在数据位于同一JVM的内存中时实现O（1）。当数据在磁盘上时，Titan比Neo4j更快，因为它具有更好的磁盘表示

请参阅下面的博客文章，从数量上解释上述内容：

因此，理解人们何时说O（1）他们在记忆层次结构的哪一部分是很重要的。当您在单个JVM（单机）中时，它很容易变得很快，Neo4j和Titan都用各自的缓存引擎演示了这一点。当无法将整个图形放入内存时，必须依赖智能磁盘布局、分布式缓存等

有关更多信息，请参阅以下两篇博文：

使用类似的方法管理关系，不使用索引（无索引邻接），而是使用顶点之间的直接指针（链接）。它就像内存中的指针，但在磁盘上。通过这种方式，在内存和磁盘上遍历时实现O（1）

---

但是如果你有一个顶点“City”，它的顶点“Person”有数千条边，你要查找所有年龄>18岁的人，然后使用索引，因为涉及到一个查询，所以在这种情况下是O（logn）。

我会为OrientDB投相同的票！好问题，是的。OrientDB处理自己的存储，所以我猜它们与Neo4j有类似之处，但我很想知道。Neo4j在算法复杂性方面是O（1），无论您是访问缓存对象还是磁盘上的对象，因为它只是追逐指针，而不是调用外部索引来遍历关系。Neubauer和Rodriguez（见上文）称之为“无索引邻接”，我怀疑它是所有有意义的图形数据库的核心。假设一个边谓词。在Neo4j（即顶点中心线性扫描）中，获取顶点v的最新友元需要花费O（| out（v）|）。为什么？因为Neo4j不会在内存（或磁盘）中对其数据进行排序。Neo4j必须迭代v的所有传出友元边，以确定哪个边具有最新的时间戳。在土卫六中，这可能是一个O（1）操作。你可以在这里学到更多：这一进步是通过Titan在磁盘和内存中实现的。我相信你错了。在Neo4j（2.1.x）的最新版本中，Neo4j还实现了一个所谓的“顶点中心索引”来解决这个问题。Neo4j在算法上始终是O（1），因为它是一个id*偏移计算，生成一个记录。机械上，与任何疲劳的存储方法一样，有更短和更长的路径。点击一个缓存的对象，你就短路了从数据库到磁盘再到磁盘的路径；点击冷缓存，您将进入磁盘。这仍然是O（1）。没有要执行的索引或其他O（logn）或更糟糕的搜索。这是一个巨大的好处，从一开始就是图形原生的。@Marko非常感谢你的回答。我仔细阅读了你所有的博客文章。我学到了很多，但说实话，我仍然感到困惑。据我所知，Titan通过托管大大减少了缓存未命中的数量，但仍然需要在存储级别对顶点进行对数时间查找。你说Neo4j比Titan慢，因为它是非顺序磁盘表示，但在我看来，这对于一个图形数据库来说是一个公平的折衷，因为它都是关于遍历的。显然你不同意：为什么？是什么让你如此确信你不需要这种“本机”存储模型。@RikVanBruggen我知道这只适用于标签，而不适用于属性，对吗？