在这个大数据和强大的商品硬件时代，关于节点大小的争论不断

使用大量小节点来处理大数据工作负载有意义吗？还是我们应该只使用少数几个非常大的节点？例如，如果我们需要处理200TB的数据，那么使用200个具有4个内核和每个1 TB的节点，还是使用20个具有40个内核和每个10 TB的节点呢？

较大的节点具有充分证明的优点

在云环境中，您不太容易出现嘈杂的邻居问题，实际上，经过一定大小后，您很可能是框中的租户。节点较少但较大可以简化操作。但是，我们仍然看到许多系统充斥着小节点的海洋。为什么？我们听到的一个原因是，拥有所有这些处理能力并不重要，因为这完全取决于数据。如果节点被限制在一个TB内，那么提高处理能力实际上并没有帮助，只会使瓶颈恶化。

我们将进一步仔细研究这一推理

但是首先让我们看一下当今的硬件，CPU的数量从2到64。您还将注意到这些计算机的内存量成比例地增长，在i3.16xlarge实例中达到了近TB的大小。同样，存储量也从原来的0.5 TB增加到超过15 TB。

寻找拐点我们需要发现的件事是我们的软件堆栈停止扩展

如果我们将可用资源增加一倍，并且看到速度几乎没有增加，或者没有任何增加，那么无论考虑任何其他因素，我们都不应扩大该点，当然真正了解正在发生的事情的方法是进行一些实验，这就是我们在寻找拐点时所做的事情，我们使用Scylla NoSQL数据库进行了这些测试，全面披露NoSQL数据库的创建并不平等，我们将指出一些区别。

我们从一个具有三个I3系列机器的群集开始：i3.xlarge，具有2个CPU和大约15GB的RAM。我们让这三个节点相互充当副本，因此我们的复制因子为3。该实验包括使用一台装载机将尽可能快的1,000,000,000分区插入该集群。通过实验，我们进入了I3系列，在每一步将数据库可用资源加倍。我们还增加了装载程序的数量，使每一步的分区数量和数据集大小增加了一倍。

压实难题

您可能会想“好运！我们有一个将近5TB的节点，它将永远压缩。这是针对大节点的另一个论点，这里是有关压实的快速入门。当我们将内容写入数据库时，这些写入将进入称为Memtable的内存结构，并在节点发生故障的情况下与提交日志并行。有时，此Memtable会刷新为一个不变的数据结构，称为SSTable。从大量文件中读取数据非常昂贵，因此有时必须运行称为压缩的后台进程。它需要多个SSTable，并将它们折叠成更少的SSTable。

这个过程往往既缓慢又痛苦

如果压缩太慢，则会影响读取，如果它们太快，则前台工作负载会遭受损失，因为它们的资源已耗尽。为了避免这种情况，用户必须设置并行执行多少次压缩以及系统可以维持的压缩吞吐量。问题是，很难做到所有这些事情，特别是对于白天变化很大的工作负载。它对压缩的进行速度进行了人为的限制，该限制可能与硬件功能无关。因此，如果数据集增加，则紧随其后的是压缩时间。

但是有一些方法可以通过自动确定每个点的速率来避免压实吞吐量的人为限制

可以通过压缩和其他过程做到这一点的数据库具有自主操作能力，配备了自己的I / O Scheduler或其他类似技术，数据库可以避免向磁盘发送的请求超出可用磁盘并发性。请求不是在磁盘中排队，而是在数据库内部排队，在这里它们被标记为查询请求，提交日志请求，压缩请求等。这样，可以全速释放压缩，并且可以通过查询日志为所有对延迟敏感的查询提供服务。

一旦摆脱了压缩带宽的人为限制，我们就会拥有更多的CPU和更多，更快的磁盘

我们也应该能够更快地压缩该数据集，因为压缩是使用CPU和磁盘这两个资源的过程。真理还是神话？是时候进行另一个实验了！在本实验中，我们使用了与先前实验相同的群集，并在其中一个节点中将其称为nodetool compact，Nodetool compact是一种工具，可以将每个SSTable压缩为一个。