Titan地理数据在Cassandra上的存储

Question

Titan地理数据在Cassandra上的存储

6

我正在考虑使用Titan创建可扩展的地理空间数据存储（我正在考虑R树）。在文档中，有一个GeoShape查询，并且文档说titan可以使用Lucene或ElasticSearch处理地理数据。但是，似乎这样做会非常慢，因为在cassandra中遍历节点本质上是在cassandra中执行联接查询，这是一个非常糟糕的想法。我认为我可能误解了数据表示方法。

我阅读了Titan Data Model doc，但仍然不太明白。如果所有边都存储在Cassandra行中，则Titan仍然必须在顶点表上“连接”。解决此问题的一种方法是使列值等于边属性数据，然后您可以将顶点数据和边数据整齐地打包到行中。但是，当您想要进行深度超过1个节点的查询时，这种方法就会失败，我们又回到了联接问题。

所以。Titan是否模拟了Cassandra中的联接查询？ - 以及 - 在这些条件下，它的地理查找性能如何？

- Peter Klipfel

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Dan LaRocque · Accepted Answer

我认为这个问题混淆了边缘遍历和地理空间索引查找。在API和实现层面上，它们是分开的。数据模型图片中没有展示索引。

让我们更具体一些。假设我使用Murmur3Partitioner或RandomPartitioner在Titan中运行ES和Cassandra。我声明了一个名为"place"（如Getting Started页面所述）的ES地理空间索引。通过地理空间查询查找边缘，例如在Getting Started文档中的"WITHIN"，首先会命中ES。ES返回ID，Titan可以使用这些ID快速查找关联的顶点/边缘数据，而不需要进行类似于关系连接的操作。

这些地理空间数据的边缘查找成本应该大致相当于ES的WITHIN实现的成本（我认为这是委托给Spatial4j的），加上Titan在获取ID后对Cassandra进行的查找，这应该大致呈线性关系与ES找到的边的数量。这只是一个粗略的估计，请谨慎对待。

如果我通过地理匹配获得了地点边缘，如果我想在集合中的每个边缘附近运行任意遍历，则应查看在头/尾顶点上根据MultiQuery设置和启用数据库级缓存。如果查询未命中缓存或缓存处于冷启动/禁用状态，则Titan仍将尝试在可能的情况下以单个Cassandra切片检索遍历所关心的所有边缘。如果您担心Titan的边缘遍历效率，则可能会发现Boutique Graph Data with Titan有趣。

希望能帮到你。