ScyllaDB 是什么？

ScyllaDB（又称：斯库拉数据库）是一种具有超高速度的数据库，它将Apache Cassandra从JAVA语言替换为C++语言，比Cassandra快10倍以上。通过利用其高速度，可以将节点数压缩为原来的“1/5～1/10”，实现了一种具有异次元特性的数据库。与Cassandra兼容，可以直接使用Cassandra的驱动程序、CQL、各种连接器和CLI进行开发。

现代高端服务器的出现，如高核数/高带宽网络/高吞吐量的DISK I/O，与当今云服务提供商作为服务器的最大购买者以及多媒体/机器学习/人工智能等越来越需要丰富计算资源的时代背景密切相关。

然而，在这些高端服务器上安装和使用类似传统的数据库的集中式应用程序时，功能性可能没有问题，但是可能出现超过CPU、网络和DISK I/O的有效工作限度的问题。简而言之，大量数据处理和数据流动会在各处引发瓶颈现象。

ScyllaDB的起源

ScyllaDB的创始人是曾经开发KVM的Avi Kivity先生。最初，他开发了类似Docker的Unikernel，并且与Docker竞争，但最终Docker更为广泛应用，因此放弃了产品化的想法。他利用这个Unikernel的基础技术参与了Hadoop、Cassandra、Kafka等存储引擎的加速工作。从那时起，他选择以C++为基础语言，并最终将其定位于Cassandra进行产品化，这就是ScyllaDB。在2015年发布了Alpha版本，并延续至今。

现代高端服务器的概念是什么？

这里所说的计算资源包括：拥有数十个核心的vCPU、超过数百GB的内存、10GB以上的网络带宽，以及超过每秒1GB的MAX吞吐量的存储。

ScyllaDB的架构

ScyllaDB在察觉到传统的基于线程池的应用程序依赖中断和锁定，在现代高端服务器上无法有效运行的问题后，进行了根本的架构改革。

传统架构(thread pool)

如果某台机器的核心数众多、网络带宽丰富、DISK I/O吞吐量高，那么数据处理速度会很快，通信也会很快，而且可以大量读写，理应是诸多优点的。但实际上，却会有意想不到的陷阱等待着。

在传统架构下的数据集中处理中，不论是CPU处理、网络还是DISK I/O，都会引发瓶颈现象。在传统架构中，通常被认为达到了十几个核心的极限。

• CPUの処理で過剰なロックが発生し、遅延を誘発する

 

• CPUが直接ネットワークのパケットを処理する能力をもっておらず、OSに依存するために、さらに事態を悪化させる

 

高性能のDISKでも、最大の同時実行数を超えたI/Oが発生すると、失速を引き起こすが、OSに依存しているために制御できない

换言之，要想在数据集聚处理中使用高核心数的机器，就必须从根本上改变应用程序的架构。

ScyllaDB的架构（共享无）。

ScyllaDB的架构将现代高端服务器的性能发挥到极致。

每个核心的碎片

• 各シャードは独自のメモリ、ネットワーク、I/O、自分のデータを持つ

 

ロックレスのコア間通信

单独的任务调度程序

タスクは、自分に与えられたデータだけを集中して処理

全部是异步的 shì de)

• ロックレス、データはすべてCPUにストリーム

 

コア間で明示的にデータの引き渡し

我把这部分的说明整理到了下一张PPT中。

首先扩展的NoSQL数据库，ScyllaDB。

ScyllaDB的特点是什么?

技术上的复杂问题暂且不论，作为ScyllaDB的用户，我感到非常高兴。

• 同規模のCassandra構築よりもノード数を「1/5～1/10」ぐらい圧縮できるためにトータルコストが下がる（スケールアップファースト）

 

• CassandraをC++でリプレースし、JVMの管理から解放される。

 

• とてもシンプルなキャッシュ―の仕組みを獲得し、Cassandraよりもクエリレスポンスが各段に高速であり、常に安定している

 

• Cassandraと互換性をと持っているので、開発ではCassandraのドライバ―やCQL、各種コネクター、CLIがそのまま利用できる。

 

• もし、Cassandraレプレースの場合、Cassandraの現在の実装を利用し、IPアドレスをScyllaDBクラスタに変更するだけで動作する

 

• Cassandraの高可用性、高拡張性はキープしている

 

最適なパラメーター設定を専用のユーティリティがやってくれる(scylla_setup)

优先考虑集群规模扩大的设计理念

由于ScyllaDB能够充分发挥现代高端服务器的性能，因此我们以“先尺度升级”思想来构建集群，在相同规模的数据处理中，可以将节点数量压缩为“1/5～1/10”，从而显著降低总成本。尺度扩展并非不可能，但已不再是唯一的选择。

扩展优先并不意味着只需在现代高端服务器上附加大容量存储并拥有大量数据就足够了。它需要在客户端和服务器之间、CPU之间、节点与节点之间、用户领域和磁盘之间进行高速且高吞吐量的数据处理。ScyllaDB之所以能够实现扩展优先的集群部署，是因为它能够进行快速处理。

假设我们设计一个节点上存储大约10TB数据的系统，考虑到复制备份，实际上每个节点需要存储大约30TB的数据。因此，我们需要从日常数据处理中追求高速和高吞吐量。

如果发生存储故障，节点之间会产生数十TB的数据流以进行恢复。ScyllaDB最近使用其独特的流技术，在1小时又6分钟内恢复了1.89TB的数据。这展示了其每秒钟恢复765MB的能力。

只考虑横向扩展的集群设计思想

在只有规模扩展的思想下设计的NoSQL，在现代高端服务器上无法发挥作用，因此计算能力的扩展仅仅依赖于规模扩展。这是一种故意购买故障率的设计思想，采购、开发和运营成本等方面都会随节点数量的增加而增加。

只使用规模可扩展的集群设计思想，可能是在2000年代Hadoop的出现时迅速流行起来，并影响了现今绝大部分NoSQL架构。在这个现代高端服务器被视为“画中之饼”的时代，这种思想是划时代的想法，可能是正确的选择。

然而，时至今日，情况正在发生变化。首先，现代高端服务器的获取变得相对廉价。另一个是数据量的失控。即使数据在每秒钟看起来并不重要，但很快就会达到TB级，并且在一年内常常会达到数十TB或数百TB。

假设想要将大约100TB的数据存储在Cassandra集群中，需要使用大约有「8~16核心/64~128GB内存」的服务器，规模为50到100个节点的集群。每个节点需要拥有1TB~2TB的存储容量。不推荐将超过此容量的数据存储在单个节点上。

有时人们也会向我们咨询，是否可以通过在现代高端服务器上安装Cassandra来增加每个节点的数据量并减少节点数。这个想法很自然，但是由于Cassandra无法有效地利用现代高端服务器作为软件，所以这是不可能的。就像之前说过的那样，如果压缩节点数，那么在客户端和服务器之间、CPU之间、节点和节点之间、用户空间和磁盘之间，都需要进行数量级更高的高速和高吞吐量的数据处理。

尝试构建ScyllaDB的独立集群。

如果您想先尝试一下ScyllaDB，可以参考下面的链接。

尝试构建ScyllaDB的独立集群。

尝试构建Schlla DB的多节点集群。

如果你想更深入学习ScyllaDB，可以参考下面的链接。

尝试构建ScyllaDB的多节点集群

总结

ScyllaDB 的出现可以说是提前预测到了现代高端服务器的出现。数据规模的暴增已经到了无法阻止的情况下。此外，对于实时处理大数据的需求也越来越强烈。我期待着ScyllaDB 的首要扩展思想能为我们开辟新的领域。