Cassandra性能：少行多列vs多行少列

我们正在评估是否可以从SQL SERVER迁移到cassandra进行OLAP。根据内部存储结构，我们可以有宽行。我们几乎需要在日期之前访问数据。我们经常需要访问日期范围内的数据，因为我们有财务数据。如果我们使用date作为分区键来支持按日期筛选，那么我们最终将拥有更少的行和大量的列。 如果将来我们每天处理数百万个事务时，一行键有数百万个列，这会影响性能吗

我们是否需要对访问模式进行一些更改，以使更多的行具有更少的每行列数

---

需要一些性能洞察力才能在任意方向上进行操作

使用宽行通常对Cassandra来说都是不错的，但是有几件事需要考虑：

• 确保在任何情况下都不会达到20亿列的限制
• 整个宽行存储在同一个节点上：它需要放在磁盘上。此外，如果某些日期的访问频率高于其他日期（例如今天），则可以在存储当天数据的节点上创建热点
• 但是，非常宽的行可能会影响性能：上一篇Pickle中的Aaron Morton有一篇有趣的文章： 它有点古老，但我相信这些概念仍然有效

---

为了做出良好的表格设计决策，需要了解所有典型的过滤条件。如果您有任何其他字段通常作为精确匹配进行筛选，您也可以将它们添加到分区键。

谢谢您的评论。达到20亿列的限制是非常不可能的。宽行不适合特定磁盘可能就是这种情况。cassandra不处理行不适合磁盘的情况。它应该将数据传输到另一个节点，因为选择保存行的节点是内部存储引擎的决定。Cassandra中的数据分区由分区键驱动：Cassandra使用简单快速的哈希算法识别保存数据的节点。在这方面，宽行是一个单元，它不会在节点之间分割。最后尝试在分区键中引入其他字段（例如，金融产品的id、年份甚至月份，如果有意义的话）。如果散列算法识别出一个节点，该节点上的行最初无法容纳或容纳，但随着宽行的最终增长，那么cassandra是否会将该行转移到其他机器上？cassandra不会在节点之间共享行，整行将放在单个节点上（现在不讨论复制）。没有实现任何传输机制，因为这将大大降低性能。有关分区和复制的更多详细信息，请参阅本文：