我正在考虑Cassandra集群的设计.
用例将为时间序列数据存储大量微小样本(使用KairosDB),数据几乎是不可变的(非常罕见的删除,没有更新).那部分工作得很好.
然而,几年后数据将非常大(考虑到复制因素,它将达到几百TB的最大大小 - 超过一PB).
我知道建议不要在每个Cassandra节点上使用超过5TB的数据,因为在压缩和修复期间I/O负载很高(显然旋转磁盘已经非常高).由于我们不想为这个用例构建一个包含数百个节点的整个数据中心,我正在调查是否可以在旋转磁盘上使用高密度服务器(例如,在RAID10中使用旋转磁盘,每个节点至少10TB或20TB或JBOD,服务器将具有良好的CPU和RAM,因此系统将受I/O限制).
每秒Cassandra的读/写量可以通过一个没有任何压力的小集群来管理.我还要提到的是,这不是一个高性能的事务系统,而是一个用于存储,检索和一些分析的数据存储,而且数据几乎是不可变的 - 所以即使压缩或修复/重建需要几天的几个服务器同时它可能根本不会成为一个问题.
我想知道是否有人对使用旋转磁盘的高服务器密度以及您正在使用的配置(Cassandra版本,每个节点的数据大小,每个节点的磁盘大小,磁盘配置:JBOD/RAID,硬件类型)有经验反馈.
提前感谢您的反馈.
最好的祝福.
Jef*_*rsa 17
超级密集节点的风险不一定是在修复和压缩期间最大化IO - 它无法可靠地解决总节点故障.在您对Jim Meyer的回复中,您注意到不建议使用RAID5,因为重建期间失败的可能性太高 - 相同的潜在故障是针对超密集节点的主要参数.
在pre-vnodes的日子里,如果你有一个已经死亡的20T节点,你必须恢复它,你必须从邻近的(2-4)节点流20T,这将最大化所有这些节点,增加它们失败的可能性,并且需要(小时/天)来恢复下行节点.在那段时间里,您运行时冗余度降低,如果您重视数据,这可能会带来风险.
许多人都赞赏vnode的原因之一是它将负载分配给更多的邻居 - 现在,用于引导替换节点的流操作来自数十台计算机,从而分散了负载.但是,您仍然存在一个基本问题:您必须在节点上获得20T数据而不会引导失败.流媒体长期以来比期望的更加脆弱,并且在云网络上无故障地传输20T的可能性并不理想(尽管它再次变得越来越好).
你能运行20T节点吗？当然.但重点是什么？为什么不运行5个4T节点 - 您可以获得更多冗余,可以相应地缩小CPU /内存,而且您不必担心一次性重新引导20T.
我们的"密集"节点是带有Cassandra 2.1.x的4T GP2 EBS卷(x> = 7以避免2.1.5/6中的OOM).我们使用单个卷,因为虽然你建议"cassandra现在支持JBOD很好",但我们的经验是依赖Cassandra的平衡算法不太可能给你你想的那样 - IO会在设备之间咆哮(压倒一个,然后压倒下一个,等等),它们会不对称地填充.对我来说,这是对很多小卷的一个很好的论据 - 我宁愿只看到单个卷上的一致用法.
小智 2
我建议考虑应用程序的数据模型以及如何对数据进行分区。对于时间序列数据，使用由分区键 + 一列或多列组成的复合键 [1] 可能是有意义的。分区根据分区键的哈希分布在多个服务器上（取决于您使用的 Cassandra Partitioner，请参阅 cassandra.yaml）。
例如，您可以按生成数据的设备（[2] 中的模式 1）或按时间段（例如每天）对服务器进行分区，如 [2] 中的模式 2 所示。
您还应该注意，每个分区的最大值数限制为 20 亿个 [3]。因此，强烈建议进行分区。不要将整个时间序列存储在单个分区的单个 Cassandra 节点上。
[1] http://www.planetcassandra.org/blog/composite-keys-in-apache-cassandra/
[2] https://academy.datastax.com/demos/getting-started-time-series-data-modeling
[3] http://wiki.apache.org/cassandra/CassandraLimitations
| 归档时间： |
|
| 查看次数： |
2731 次 |
| 最近记录： |