Titan如何使用HBase / Cassandra实现恒定时间查找?

时间:2014-09-24 05:19:19

标签: neo4j graph-databases titan

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

  

了解为什么原生图处理效率更高   比基于重索引的图表,请考虑以下内容。根据实现,索引查找可以是算法复杂度中的O(log n),而O(1)则用于查找直接关系。   要遍历m步的网络,索引方法的成本,在   O(m log n)使得使用的实现的O(m)成本相形见绌   无索引邻接。

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

  

对于固定大小的记录和类似指针的记录ID,遍历是   简单地通过追踪数据结构周围的指针来实现   可以以非常高的速度进行。穿越一个特定的   从一个节点到另一个节点的关系,数据库执行几个   便宜的ID计算(这些计算比便宜得多)   搜索全局索引,正如我们在伪造图形时必须做的那样   非图本机数据库)

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

2 个答案:

答案 0 :(得分:12)

当数据在同一JVM中的内存中时,Neo4j仅实现O(1)。当数据在磁盘上时,由于磁盘上的指针追踪,Neo4j很慢(它们的磁盘表示很差)。

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

请参阅以下定量解释上述内容的博文: http://thinkaurelius.com/2013/11/24/boutique-graph-data-with-titan/

因此,当人们说O(1)他们所处的内存层次结构的哪一部分时,了解它很重要。当你在一个JVM(单机)中时,它很容易快速,因为Neo4j和Titan都展示了各自的缓存引擎。如果无法将整个图形放在内存中,则必须依赖智能磁盘布局,分布式缓存等。

有关详细信息,请参阅以下两篇博文:

http://thinkaurelius.com/2013/11/01/a-letter-regarding-native-graph-databases/  http://thinkaurelius.com/2013/07/22/scalable-graph-computing-der-gekrummte-graph/

答案 1 :(得分:1)

OrientDB使用类似的方法,在没有索引的情况下管理关系(无索引邻接),而是在顶点之间使用直接指针(LINKS)。它与内存指针相似,但在磁盘上。通过这种方式,OrientDB在遍历内存和磁盘时实现了O(1)。

但如果你有一个顶点" City"有数千条边到顶点"人",你正在寻找所有有年龄的人> 18,然后OrientDB使用索引,因为涉及查询,所以在这种情况下它是O(log N)。