什么是设计Cassandra数据模型的最佳实践？

还有哪些陷阱需要避免？你有什么优惠吗？例如,我听说导出/导入Cassandra数据非常困难,让我想知道这是否会妨碍生产数据与开发环境的同步.

顺便说一句,很难找到关于Cassandra的优秀教程,我唯一的http://hab.me/code/wtf-is-a-supercolumn-cassandra-data-model仍然非常基础.

谢谢.

对我来说,主要的是决定是使用OrderedPartitioner还是RandomPartitioner.

如果使用RandomPartitioner,则无法进行范围扫描.这意味着您必须知道任何活动的确切密钥,包括清理旧数据.

因此,如果你有很多流失,除非你有一些神奇的方法来确切知道你插入的东西,使用随机分区器你很容易"丢失"东西,这会导致磁盘空间泄漏,最终消耗所有存储空间

另一方面,您可以询问有序分区器"A和B之间的列族X中有哪些键"？ - 它会告诉你.然后你可以清理它们.

但是,也存在不利因素.由于Cassandra不进行自动负载平衡,如果使用有序分区器,很可能所有数据最终只会在一个或两个节点中,而在其他节点中则不会,这意味着您将浪费资源.

我没有任何简单的答案,除了在某些情况下你可以通过在键的开头放一个简短的哈希值(你可以从其他数据源轻松枚举的东西)来获得"两全其美" - 对于例如,用户ID的16位十六进制哈希 - 它将为您提供4个十六进制数字,然后是您真正想要使用的密钥.

然后,如果您有最近删除的用户列表,您可以只是哈希他们的ID和范围扫描来清理与他们相关的任何内容.

下一个棘手的位是二级索引 - Cassandra没有 - 所以如果你需要通过Y查找X,你需要在两个键下插入数据,或者有一个指针.同样,当他们指向的东西不存在时,可能需要清理这些指针,但在此基础上查询内容并不容易,因此您的应用需要Just Remember.

应用程序错误可能会留下您忘记的孤立密钥,除非您编写一些定期扫描数据库中每个密钥的垃圾收集器,否则您将无法轻易检测到它们(这需要一段时间 - 但你可以用块来检查那些不再需要的东西.

这些都不是基于实际用法,正是我在研究过程中想到的.我们不在生产中使用Cassandra.

编辑:Cassandra现在确实在trunk中有二级索引.

这太长了,无法添加评论,所以要清除问题列表回复中的一些误解:

任何客户端都可以连接到任何节点; 如果您选择的第一个节点(或通过负载均衡器连接)发生故障,只需连接到另一个节点即可.此外,客户端可以自行指导写入"胖客户端"API.一个例子是在http://wiki.apache.org/cassandra/ClientExamples上

在服务器没有响应而不是无限期挂起时进行定时是大多数处理过载rdbms系统的人所希望的功能.Cassandra RPC超时是可配置的; 如果你愿意,你可以自由地将它设置为几天并且无限期地处理.:)

确实没有多次删除或截断支持,但是在审查中有两个补丁.

在群集节点之间保持负载均衡显然存在权衡:您尝试保存的内容越平衡,您将要执行的数据移动越多,这不是免费的.默认情况下,Cassandra集群中的新节点将移动到令牌环中的最佳位置,以最大限度地减少不均匀性.实际上,这已被证明效果很好,你的群集越大,加倍就越不正确.http://wiki.apache.org/cassandra/Operations中对此进行了详细介绍

另一个教程在这里:http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/.

你有什么优惠吗？不一定是交易破坏者,而是需要注意的事情

客户端连接到最近的节点,该节点应该事先知道它与通过它代理的所有其他Cassandra节点的所有通信.一个.读/写流量不是均匀分布在节点之间 - 一些节点代理的数据多于它们自身的数据b.如果节点发生故障,客户端无能为力,无法读取,无法在群集中的任何位置写入.

尽管Cassandra声称"写作从未失败",但他们确实失败了,至少在他们发言的那一刻.如果目标数据节点变得迟缓,请求超时并且写入失败.节点有很多原因导致无响应:垃圾收集器启动,压缩过程,无论如何......在所有这些情况下,所有写入/读取请求都会失败.在传统的数据库中,这些请求会成比例地变慢,但在Cassandra中它们只是失败了.

有多个get但没有多重删除,也不能截断ColumnFamily

如果新的空数据节点进入群集,则来自密钥环上的一个邻居节点的数据部分将仅被传送.这导致数据分布不均匀和负载不均匀.您可以通过始终加倍节点来修复它.还应该手动跟踪令牌并明智地选择它们.

我认为自从Cassandra 1.2最近推出以来,这值得更新.

在过去的18个月中,我一直在使用Cassandra进行社交游戏.

我的问题是你必须使用Cassandra来发挥其优势.因此,有必要了解使用哪种数据模型,以及确定使用哪种数据模型,甚至确定其他数据库解决方案是否对您更有用.

OrderedPartitioner仅在您的应用程序依赖于键范围查询时才有用,但是您放弃了Cassandra最强大的功能之一:自动分片和负载平衡.而不是行键范围查询尝试使用同一行中的列名称范围来实现所需的相同功能.TL; DR读/写将不使用此节点在节点之间进行平衡.

如果你想支持大数据和高访问频率,RandomPartioner(md5哈希)和MurmurPartitioner(Murmur哈希,更好,更快)是你必须去的方式.你唯一放弃的是关键范围查询.同一行中的所有内容仍然位于群集中的同一节点上,您可以对这些节点使用比较器和列名称范围查询.TL; DR:使用这个进行正确的平衡,你将不会放弃任何重大的东西.

你应该知道的关于cassandra的事情:

卡桑德拉总是很稳定.Cassandra选择交换Consistency以获得高可用性和出色的分区(http://en.wikipedia.org/wiki/CAP_theorem).但是你可以从cassandra获得一致性,当你读写它时,它就是你的一致性政策.在讨论使用cassandra时,这是一个非常重要且复杂的主题,但您可以在http://www.datastax.com/docs/1.2/dml/data_consistency中详细阅读.

根据经验(并保持简单)我在QUORUM ConsistencyLevel上读写(因为在我的应用程序中,读取的频率与写入的顺序相同).如果您的应用程序写得非常繁重,并且读取的次数少得多,那么请使用"在ONE写入"并在"全部"读取.或者,如果您的用例相反(写入比读取的频率低很多),那么您可以尝试在ONE上读取并在ALL上写入.如果一致性是您要解决的问题,那么使用ANY作为写入的一致性级别并不是一个好主意,因为它可以保证突变已经到达集群但不是已经写入任何地方.这是我在cassandra上静默失败的唯一一种情况.

这些是简单的规则,可以让您轻松开始使用cassandra.为了从生产集群中获得尽可能多的一致性和性能,您应该努力学习这个主题,并自己真正理解它.

如果你需要一个人类可读的数据模型,实体(表格)之间的关系复杂,那么我认为Cassandra不适合你.MySQL和NewSQL可能对您的用例更有帮助.

值得一提的是,cassandra大致如何保存和读取数据.无论何时写入(删除实际上是在cassandra中写入"墓碑"值),系统都会将新值及其时间戳放在新的物理位置.

当您阅读时,cassandra会尝试为某个key/column_name位置提取所有写入内容并返回他能找到的最新内容(具有最高时间戳的内容,该内容已由客户端提供).因此,节点所需的存储器直接取决于写入的频率.cassandra中有一个压缩过程,负责清理旧的突变.Cassandra有一个内部缓存,在读取时使用最新的位置值进行更新.

SSTables的磁盘上的合并/压缩(持久化数据的数据结构)可以通过读取来激发,但最好不要指望它.清除逻辑删除和过期列(使用生存时间功能)是由垃圾收集器管理的不同机制(有关详细信息,请参阅GC宽限时间设置).

这让我想到了我想要做的最后一点:确保你的集群中的写入和读取都是平衡的!

我们假设您的所有用户都需要经常更新单个位置.
不要将理论上的单个位置映射到只有一个行键!这将使您的所有写入仅落在群集中的一个节点上.如果它没有降低一切(因为你有摇滚明星系统控制器),它至少会严重削弱集群的性能.
我的建议是将您的写入存储在足够多的不同行键中,您将在集群中的所有节点上分配写入.要检索该单个理论位置的所有数据,请在所有"子行键"上使用multi_get.

示例:
我想要一个包含所有活动http会话(已分配给它们的uuid)的列表.不要将所有内容保存到一个"会话"行键中.我用作6个节点的cassandra集群的行密钥是:_sessions.然后我有一个小的16键multi_get来检索所有活动的会话,或者我仍然可以通过使用一个简单的get来判断会话是否处于活动状态(如果我知道它的uuid当然).如果您的群集更大,您可能希望使用哈希函数来生成桶密钥.