需要避免哪些陷阱？您有任何交易中断吗？例如，我听说导出/导入 Cassandra 数据非常困难，这让我想知道这是否会妨碍将生产数据同步到开发环境。
顺便说一句，很难找到关于 Cassandra 的好的教程，这是我唯一的教程 http://arin.me/code/wtf-is-a-supercolumn-cassandra-data-model还是很基础的。
谢谢。
最佳答案
对我来说，最重要的是决定是使用 OrderedPartitioner 还是 RandomPartitioner。
如果您使用 RandomPartitioner，则无法进行范围扫描。这意味着您必须知道任何事件的确切 key ，包括清理旧数据。
因此，如果您有很多流失，除非您有某种神奇的方法可以准确地知道您已插入内容的键，否则使用随机分区器您很容易“丢失”内容，这会导致磁盘空间泄漏最终将耗尽所有存储空间。
另一方面，您可以询问有序分区程序“A 和 B 之间的列族 X 中有哪些键”？ - 它会告诉你。然后您可以清理它们。
但是，也有一个缺点。由于 Cassandra 不进行自动负载平衡，因此如果您使用有序分区器，您的所有数据很可能最终都会出现在一两个节点中，而不会出现在其他节点中，这意味着您会浪费资源。
对此我没有任何简单的答案，除了在某些情况下您可以通过在开头放置一个简短的哈希值(您可以从其他数据源轻松枚举的值)来获得“两全其美”的效果。键 - 例如用户 ID 的 16 位十六进制散列 - 这将为您提供 4 个十六进制数字，后跟您真正想要使用的 key 。
然后，如果您有最近删除的用户列表，您只需对他们的 ID 进行哈希处理并进行范围扫描即可清理与他们相关的任何内容。
下一个棘手的位是二级索引 - Cassandra 没有任何 - 所以如果您需要通过 Y 查找 X，您需要在两个键下插入数据，或者有一个指针。同样，当这些指针指向的东西不存在时，可能需要清理这些指针，但是没有简单的方法可以在此基础上查询东西，因此您的应用程序需要记住。
应用程序错误可能会留下您忘记的孤立键，并且您将无法轻松检测它们，除非您编写一些垃圾收集器来定期扫描数据库中的每个键(这将需要一段时间 - 但您可以分块进行)以检查不再需要的内容。
这些都不是基于实际使用情况，只是我在研究过程中发现的。我们不在生产中使用 Cassandra。
编辑:Cassandra 现在在主干中有二级索引。
关于database-design - 设计 Cassandra 数据模型的最佳实践是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1502735/