Scylla如何运用控制理论驯服野兽，实现压实控制？

本文共计4951个文字，预计阅读时间需要20分钟。

但与RocksDB类似的存储引擎在遇到交错的同学生成时，往往会有一个困扰：在大规模写入时，compaction过程很容易把CPU和磁盘带宽占满，影响了业务的正常读写。如何解决这个问题，让磁盘运行更顺畅呢？

但凡跟rocksdb一类的存储引擎打过交道的同学一定会有一个烦恼，就是在大量写入的时候引发的compaction很容易把cpu和磁盘带宽占满，影响了业务的正常读写，如何解决这个问题，让磁盘读写和compaction自动根据业务负载有条不紊地进行，scylladb给出了他自己的答案。

教程翻译自Seastar官方文档：www.scylladb.com/2018/06/12/scylla-leverages-control-theory/

转载请注明出处：www.cnblogs.com/morningli/p/16170046.html

从鸟瞰的角度来看，数据库的任务很简单：用户插入一些数据，然后再获取它。但是当我们仔细观察时，事情变得更加复杂。例如，为了持久性，数据需要进入提交日志，需要被索引，并且被多次重写以便可以轻松获取。

所有这些任务都是数据库的内部进程，它们将争夺有限的资源，如 CPU、磁盘和网络带宽。然而，授予其中一个或另一个特权的回报并不总是很清楚。这种内部过程的一个例子是compactions，这是任何具有基于日志结构化合并 (LSM) 树的存储层的数据库中的一个事实，比如 ScyllaDB。

LSM 树由源自数据库写入的append-only的不可变文件组成。随着写入的不断发生，系统可能会变成相同的key的数据会出现在许多不同的文件中，这使得读取非常昂贵。然后，这些文件根据用户选择的压缩策略在后台由compaction process进行压缩。