Cassandra 没有地理空间支持是否有原因？

Question

由于 Cassandra 是基于 Dynamo 论文（分布式、自平衡哈希表）+ BigTable 的，并且有一些空间索引非常适合该范式（quadkey 或 geohash）。没有实施地理空间支持是否有原因？

您可以将 GeoPoint 数据类型添加为具有内部 geohash 的元组，并将 CF 指定为包含地理数据。从那里您可以选择将地理数据作为二级索引或非规范化 SCF 的行为。这可以为地理空间开发奠定基础，您可以从实现一些低悬的成果开始，例如 .nearby() ，它可以只返回共享相同 geohash 的列。 （我知道这不会给你“最近的”，你必须走一圈周围的 geohashes 或使用形状和空间填充曲线，这可以稍后实现，但这是寻找一些的一般操作附近的列）

我知道 SimpleGeo/Urban Airship 在 Cassandra 中内置了地理支持，但它看起来从未开放过。另外，如果有更好的地方可以问这个问题（quora、邮件列表等），请告诉我

Answer 1

我认为答案分为两部分。

它不存在的原因是因为没有人将代码提交到 Cassandra 中，没有人想到过这个功能，或者认为这个功能的优先级足够高，可以花大量时间在上面。 Cassandra 的大部分开发工作都是由 Datastax 完成的，作为商业实体，他们非常了解用户的需求和建议，并且非常务实地了解如何在新功能方面为他们带来最大的投资回报率。

如果有足够好的第三方开发人员（或团队）有足够的时间，这是可以做到的，从概念上讲，C* 提交者在添加这样的主要功能时可能没有问题。

第二个方面是 Cassandra 支持 blob（字节数组），这意味着您所描述的内容可以以相对简单的方式在客户端应用程序/驱动程序中实现。在这种情况下，驱动器将负责将地理调用转换为适当的原始字节操作。我还怀疑这比在核心存储引擎中使用相关运算符集支持全新的数据原语要少。