我们的cassandra 2.1.15应用程序'KS（使用STCS）在少于100个sstables / node中进行调平，其中一些数据sstable现在进入+ 1TB大小。这意味着重型/长时间的压缩加上墓碑及其被逐出的数据进入相同的压缩视图之前的时间更长（应用程序同时创建/读取/删除数据），因此在真正的磁盘空间被回收之前更长时间，这很糟糕：（
我们的应用程序供应商后来向我们透露，他们通常建议在应用程序KS中对10-20个CF的数据进行哈希处理，而不是我们当前创建的3个CF，猜测这是一种保持sstables与size的比率的方法。 ' 范围。现在我们已经开始在3 CF中散列数据，只有应用程序无法更改。
目前我们有14个Linux节点集群，相同硬件和大小的节点（运行w /等量的vnode），最初在每个逻辑卷上用两个xfs FS构建两个data_file_director - 每个由PV支持的LV（6 +1 raid5）。然后，当一些节点开始压缩这些数据dirs / LV中的数据时，在生成sstable大小时，我们将两个数据目录合并到一个LV上，并用这样释放的PV扩展这个LV。因此，我们现在在一个LV中有7个节点，两个数据目录由两个PV支持，7x节点在两个LV上有两个数据目录。
1）现在由于更多数据和使用STCS（由App Vendor推荐），sstable大小不断增长，我们认为我们可以通过简单地在LV中添加更多数据dirs来将数据传播到更多和更小的sstables上补偿较少的CF而不是增加更多的HW节点:)这是不是可以将数据传播到更多更小的sstables上，或者与使用更少的数据目录相比，是否更容易使用？
1）跟进：必须有一个大脑...当天，当然它不会:)压缩策略不打扰有多少数据目录CF的sstables分散只是困扰与根据策略，他们自己就是sstables。因此只有分散更多和更小的sstables的方法 才能在更多的CF上散列数据。太糟糕的供应商做了时间空间权衡，不记录CF分区密钥与自己的密钥长时间散列，然后散列可能已经重新接种到更多的CF.现在唯一的办法就是构建一个具有更多CF的新集群并在那里迁移数据。
2）然后我们可以在最大的sstables上使用sstablesplit，或者逐个节点地删除/重新加入两个以上的数据目录来获取当前真正的大型sstables的rit。两种方法都可以使得sstable尺寸缩小，哪种方式最值得推荐？
2）跟进：如果一个节点退役，则令牌范围将分散到其他节点，特别是当使用多个vnodes /节点时，因此一个大的sstables将分散在更多节点上并留给其他节点的压缩策略。但一般来说，如果14个节点中有1个节点，每个节点有256个节点，那么肯定会分散到其他13个节点，对吗？ 因此，仅将其他节点的数据量增加大约1/13的退役节点内容。但是再次重新加入这样的节点只会发送大致相同数量的数据，最终被压缩成类似大小的sstables，这意味着我们已经做了很多IO +流媒体，除非是原始数据中的墓碑，但只是远远不够除了足够幸运地进入相同的压缩视图（小sstable与大sstable）之外，这样的练习可能会让数据变得更好，从而获得更好/其他机会获得一些墓碑+他们通过分散驱逐的数据+重新加入比等待策略更快在相同的压缩视图中获取TS +数据，不知道......有没有可能做到这一点的价值？
答案 0 :(得分：0)
我会尽力直截了当。使用任何类型的raid（条纹除外）都是死亡陷阱。如果您的节点没有足够的空间，那么您可以将磁盘作为JBOD添加到节点或向外扩展。第二件事是您的应用程序创建，删除，更新和读取数据，您使用的是STCS吗？所有你每节点1TB +？我甚至不想质疑该设置的性能。
我的建议是重新考虑具有数据大小，访问模式，读/写/删除/更新比率和数据保留计划的设置。 14个节点，每个1TB +的数据都不是灾难性的（即使你的文件记录说超过600-800GB是坏的，但不是），但你需要改变方法。 LCS可以为像您这样的场景创造奇迹，并且通过适当的规划，您可以让该群集运行很长时间，然后才能以适当的性能扩展（或TTL您的数据）。