想要将当前集群数据分布在更多和更小的 sstable 上

Posted 2023-04-18

【中文标题】想要将当前集群数据分布在更多和更小的 sstable 上

【英文标题】：Want to spread current cluster data over more and smallere sstables

【发布时间】：2016-12-11 13:35:16

【问题描述】：

我们的 cassandra 2.1.15 应用程序的 KS（使用 STCS）在少于 100 个 sstables/节点的情况下进行了调整，其中一些数据 sstables 现在已达到 +1TB 大小。这意味着在 tombstones 和它们被驱逐的数据进入同一个压缩视图之前需要更长时间/更长的压缩时间（应用程序同时创建/读取/删除数据），因此在实际磁盘空间被回收之前需要更长的时间，这很糟糕:(

我们的应用程序供应商后来向我们透露，他们通常建议在应用程序 KS 中对 10-20 个 CF 上的数据进行散列处理，而不是我们当前创建的 3 个 CF，猜测是为了将 sstables 与大小的比率保持在“可行”范围内' 范围。现在我们已经开始在我们的 3 个 CF 中散列数据，只有应用程序不能对此进行更改。

目前我们有 14 个 linux 节点集群，相同硬件和大小的节点（运行 w/相等数量的 vnode），最初在每个逻辑卷上的两个 xfs FS 中使用两个 data_file_directories 构建 - 每个 LV 由一个 PV（6 +1 突袭5)。然后，随着一些节点在增加 sstable 大小时开始压缩偏斜在这些数据目录/LV 中的数据，我们将两个数据目录合并到一个 LV 上，并用由此发布的 PV 扩展这个 LV。所以我们现在得到了 7x 节点，在一个 LV 中具有两个数据目录，由两个 PV 支持，7x 节点在每个 PV 上的两个 LV 中具有两个数据目录。

1) 现在，由于更多数据和使用 STCS（如 App Vendor 推荐），sstable 的大小不断增长，我们认为我们可以通过在我们的 LV 中添加更多数据目录来将数据分布在更多和更小的 sstable 上对拥有更少 CF 而不是添加更多硬件节点的补偿 :) 这是否可以将数据分布在更多和更小的 sstables 上，或者与更少的数据相比，使用多个数据目录是一个问题？

1) 跟进：那天一定有脑子，当然不会了:) 压缩策略不关心 CF 的 sstable 分散了多少数据目录，只关心sstables他们自己根据策略。因此，散布在更多和更小的 sstable 上的唯一方法是在更多的 CF 上散列数据。太糟糕了，供应商做了时空权衡，没有记录哪个 CF 分区键与它自己的键一起长时间散列，然后散列可能已经重新播种到更多的 CF。现在唯一的方法是构建一个包含更多 CF 的新集群并在那里迁移数据。

2) 然后我们可以在最大的 sstables 上使用 sstablesplit，或者逐个节点地删除/重新加入两个以上的数据目录，以获取当前真正的大 sstables。任何一种方法都可以缩小 sstable 的尺寸吗？哪种方法最值得推荐？

2) 跟进：如果一个节点被停用，令牌范围将分散到其他节点，特别是在使用多个 vnodes/node 时，因此一个大的 sstables 将分散在更多节点上并留给其他节点的压缩策略。但一般来说，如果 14 个节点中的 1 个，每个节点有 256 个 vnode，肯定会分散到其他 13 个节点，对吧？ 因此只会将其他节点的数据量增加大约 1/13 退役节点的内容。但是再次重新加入这样一个节点只会正确地发送大致相同数量的数据，最终被压缩成类似大小的 sstable，这意味着我们已经做了很多 IO + 流式传输......除非墓碑在原始数据中，但只是到目前为止除了幸运地进入相同的压缩视图（小 sstable 与大 sstable）之外，这样的练习可能会使数据在周围乱序，从而提供更好/其他机会来获得一些墓碑+他们的数据通过分散驱逐+重新加入比等待策略更快在相同的压缩视图中获取 TS+数据，不知道......对可能这样做的价值有什么想法吗？

【参考方案1】：

嗯，这是一个巨大的思想垃圾场。

我会尽量直截了当。使用任何类型的突袭（除了条纹）都是一个死亡陷阱。如果您的节点没有足够的空间，那么您可以将磁盘作为 JBOD 添加到您的节点或向外扩展。第二件事是您的应用程序创建、删除、更新和读取数据并且您正在使用 STCS？并且每个节点都有 1TB+ 的容量？我什至不想质疑该设置的性能。

我的建议是重新考虑具有数据大小、访问模式、读/写/删除/更新比率和数据保留计划的设置。 14 个节点，每个节点都有 1TB 以上的数据并不是灾难性的（即使文档指出超过 600-800GB 是不好的，但不是），但您需要改变方法。 LCS 在像您这样的场景中创造了奇迹，并且通过适当的规划，您可以让该集群运行很长时间，然后才能以良好的性能横向扩展（或 TTL 您的数据）。

【讨论】：

感谢回复！

初始节点使用 JBOD，但他们在压缩期间发现 IO 热点，然后缺乏，因此更改为 raid5 以激活每个 IO 更多的主轴，它使压缩能够跟上当时 w/更少的数据。现在它是 5-6TB/节点，总共 +80TB，单个 sstables 进入 +1-1.5TB 大小:( 应用程序供应商推荐 STCS 并且没有 vnode，但这是基于使用 v.1.2 测试。你认为 STCS 是不好，LCS 宁愿在更多更好的大小控制的 sstables 上扩展。不能使用 TTL，因为它是应用程序用户决定何时删除数据。

自 1.2 版本以来发生了很多变化。拥有 raid5 就像放弃了由数据库本身处理的冗余数据冗余的性能。由于性能原因，我们与 Cassandra 一起使用的唯一 raid 是条带化，其他一切都是多余的。我建议您检查 LCS，甚至在该集群上对其进行测试（您可以在运行时轻松更改它）并查看结果。 LCS 的 IO 密集度更高，但对于那种工作负载，我会推荐它。

好吧，我知道，但是再次将我们的主机共享 HDS SAN 阵列与一个共享控制器进行比较，该控制器具有/+64GB 缓存，几乎总是在后端使用 raid5，并且具有单个主机和一个带 2GB 缓存的 smartctlr做HWraid，有人会想……LCS可以换回STCS吗？不确定是否将 LCS 作为 AppVendor 正确地支持它，有点像我们的 vnode 使用。除了 STCS，他们似乎没有其他数据可以建议获得。

好吧，你问了，我根据我的知识和经验给了你答案。如果你被那个 AppVendor 困住了，那么要么抛弃他们，要么面对他们的限制和好运的后果。