由于Cassandra基于Dynamo论文（分布式，自平衡哈希表）+ BigTable，并且有一些空间索引非常适合该范式（四键或geohash）。地理空间支持尚未实施的原因是什么？
您可以将 GeoPoint 数据类型添加为具有内部地理哈希的元组，并将 CF 指定为包含地理数据。从那里，您可以选择将地理数据作为二级索引或非规范化 SCF 的行为。这可以为地理空间开发奠定基础，您可以从实现一些唾手可得的果实开始，例如 .near（），它可以只返回共享相同地理哈希的列。（我知道这不会给你"最近"，你必须对周围的地理哈希进行一次漫步，或者使用形状和空间填充曲线来稍后实现，但这是查找一些附近列的一般操作）
我知道SimpleGeo/Urban Airship在Cassandra中构建了地理支持，但看起来从来没有开放过。另外，让我知道是否有更好的地方来问这个问题（quora，邮件列表等...
我认为答案有两个部分。
之所以没有它，是因为没有人将代码提交到 Cassandra 中，或者认为此功能具有足够高的优先级，可以在其上花费大量时间。 Cassandra的大部分开发都是由Datastax完成的，作为一个商业实体，他们了解用户的需求和建议，并且对于什么可以在新功能方面为他们提供最大的投资回报率也非常务实。
如果有足够好的第三方开发人员（或团队）有足够的时间，这是可以完成的，从概念上讲，C* 提交者在添加这样的主要功能时可能没有问题。
第二个方面是 Cassandra 支持 blob（字节数组），这意味着你描述的内容可以以相对简单的方式在客户端应用/驱动程序中实现。 在这种情况下，驱动器将负责将地理调用转换为适当的原始字节操作。 我还怀疑，这比在核心存储引擎中使用相关运算符集支持全新的数据原语要少得多。