由于 Cassandra 基于 Dynamo 论文（分布式、自平衡哈希表）+ BigTable，并且有一些空间索引非常适合该范例（quadkey http://msdn.microsoft.com/en-us/library/bb259689.aspx or geohash http://en.wikipedia.org/wiki/Geohash）。地理空间支持尚未实施是否有原因？
您可以将 GeoPoint 数据类型添加为具有内部 geohash 的元组，并指定 CF 包含地理数据。从那里您可以选择将地理数据作为二级索引或非规范化 SCF 的行为。这可以为地理空间开发奠定基础，您可以从实现一些容易实现的目标开始，例如 .nearby() ，它可以只返回共享相同 geohash 的列。 （我知道这不会给你“最近的”，你必须走一圈周围的地理散列或使用形状和空间填充曲线，这可以稍后实现，但这是寻找一些的一般操作附近的列）
我知道 SimpleGeo/Urban Airship 在 Cassandra 中内置了地理支持，但看起来从未开放过。另外，请告诉我是否有更好的地方可以询问这个问题（quora、邮件列表等......）
我认为答案有两个部分。
之所以不存在，是因为向 Cassandra 提交代码的人都没有想到过此功能，或者认为此功能具有足够高的优先级，值得在其上花费大量时间。 Cassandra 的大部分开发都是由 Datastax 完成的，他们作为一个商业实体，了解用户的需求和建议，并且对于什么可以在新功能方面给他们带来最大的投资回报率也非常务实。
如果有足够好的第三方开发人员（或团队）并且有足够的时间，这是可以完成的，并且从概念上讲，C* 提交者在添加这样的主要功能方面可能不会有任何问题。
第二个方面是 Cassandra 支持 blob（字节数组），这意味着您所描述的内容可以以相对简单的方式在客户端应用程序/驱动程序中实现。在这种情况下，驱动器将负责将地理调用转换为适当的原始字节操作。我还怀疑这比在核心存储引擎中支持具有相关运算符集的全新数据原语的工作量要少。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
