内容编写于2020年11月,最新内容请自行查看官网。
概述
开源 实时大数据 NoSQL 数据库
C++编写,替换 Apache Cassandra
10倍的性能,更低尾部延迟(low tail latency)
由KVM hypervisor的创建者创建
ScyllaDB 是提供了一致的、高吞吐量、高可用性和高度可伸缩的NoSQL数据库。
ScyllaDB 属于列式存储数据库,代表数据库有: Apache Cassandra、Apache HBase、Amazon DynamoDB
CAP定理
CAP,即一致性,可用性和分区容错性。按照CAP定理:分布式数据库系统只能满足三项中的两项。
一致性保证每次读取都会收到最新的写入或错误
可用性保证每个请求都收到一个非错误响应。(请注意,这里不能保证响应包含最新的写操作)
分区容忍性可确保即使网络丢弃某些消息或出现网络故障,系统也可以继续运行。
在Scylla中,优先考虑分区容错性和可用性(HA,高可用性),而不是一致性。其他数据库(例如HBase)更喜欢一致性而不是可用性。
最佳使用场景
大数据量:处理TB级到PB级数据的应用程序
高可用性:需要始终可用的、多数据中心数据存储与处理的应用程序。
实时:需要非常快速的亚毫秒级读/写操作的应用程序。
高性能:每个节点每秒需要数百万个请求的应用程序。
用例:Kiwi.com 是美国的旅行网站,使用21个节点Scylla替换100个节点Apache Cassandra+50个节点Redis,不仅每年节省了27.5万美元的数据中心成本,而且降低了复杂性并提高了性能。
Scylla 优势
节点数少
性能稳定
降低复杂度
Apache Cassandra 兼容性
节点数少
有一家公司有120个Cassandra节点,每年的费用是60万美元,每秒对大约10TB的数据集执行大约几百万次操作。
使用Scylla替换:
第一步服务节点数从120降到24,这样使数据中心成本降低80%,并且减少了维护升级等方面的管理工作。
再进一步,使用成本相同的3台i3.16xlarge替换24台i3.2xlarge,获得更好的性能的同时也节省大量管理工作。
性能稳定
某个服务
黄线为Apache Cassandra,在执行垃圾回收、压缩等操作时延迟增大
绿线为Scylla,相比延迟较小,且比较稳定。
复杂性降低
自动调节
易于管理
较少服务器数量
当安装Scylla是,它将根据运行的硬件进行基准测试。记录有多少内核、IO吞吐量、网络带宽,之后Scylla根据这些参数与工作负载的变化自动调节任务等。大部分情况我们不需要配置这些参数,这样降低了使用的复杂性。
Apache Cassandra 兼容性
Scylla 与 Apache Cassandra:
Scylla从架构、使用、API来看 Scylla 就是 Cassandra,完全兼容Cassandra。
Scylla可以集成Spark、KairosDB、Presto、Elasticsearch、Apache Kafka等项目Scylla。
Cassandra应用只需要修改IP,就可以使用Scylla。
ScyllaDB 版本
ScyllaDB 提供三种版本。开源版、企业版、Cloud版。
企业版 需要联系销售
Cloud版 基于服务器类型与数量定价
3台 8C 1.9T 机器12W 授权10w
3台 64C 8*1.9T 机器120w 授权60w
数据模型
Scylla中的数据存储在按表组织的一组行中。
每行都有一个主键来标识它。数据通过此主键进行分区。可以根据主键检索数据。
Keyspace是数据模型的最高级别。它们通常包含许多表。
Table在键空间内定义。它们包含一组列和一个定义的主键。
Column定义表中的数据结构。每列都有一个定义的数据类型。
高可用性
要了解Scylla如何提供高可用性,我们首先需要了解一些基本术语。
Nodes 节点是Scylla中的存储单位。它由在计算机服务器上运行的Scylla数据库服务器软件组成。
Cluster 集群是Scylla用于存储数据的节点的集合。最小集群通常包含至少三个节点。
Consistency Level 一致性级别(CL)确定集群中的多少副本在被视为成功之前必须确认读取或写入操作。
Replication Factor 复制因子或RF等于要复制数据的节点数。
Scylla根据用户定义的复制策略复制数据。该策略将确定复制数据的位置。
Scylla在哈希环中运行节点。所有节点均相等,没有主,从或副本集。数据通常复制到多个节点。RF为1,表示集群中一行只有一个副本,并且如果该节点受损或发生故障,则无法恢复数据。RF为2表示集群中一行有两个副本。在大多数系统中,至少使用三个RF。数据总是自动复制。可能会对存储在任何复制节点上的数据进行读取或写入操作。
在上面的示例中,我们的客户端发送了一个将分区1写入节点V的请求;1的数据被复制到节点W,X和Z,因为我们的复制因子或RF为3。
架构
在大数据世界中,单个节点无法保存整个数据集,因此需要一个节点集群。Scylla集群是可视化为环的节点或Scylla实例的集合。令牌是一个范围内的值,用于标识节点和分区。分区密钥是分区的唯一标识符,并表示为从主密钥散列的令牌。
分区是数据的子集,存储在节点上并在节点之间复制。在物理层上,分区是存储在节点上的数据单元,并由分区键标识。分区键是查找组成分区的一组行的主要方法。集群中的一个节点,用于存储给定的分区,并在集群中的各个节点之间分配数据。分区程序或分区哈希函数使用分区键来确定数据在集群中给定节点上的存储位置。它通过为每个分区键计算一个令牌来实现。分区键的哈希输出确定了它在集群中的位置。
Gossip
ScyllaDB使用点对点的通讯协议Gossip来在集群中的节点间交换位置和状态信息。
Gossip进程每秒运行一次,与至多三个其他节点交换信息,这样所有节点可以很快了解集群中的其他节点信息。
写流程
先将数据记录到Commit Log中,同时写进内存中的数据结构Memtable中。
Memtable内容超出指定容量后会被放进将被刷入磁盘的队列中。
若将被刷入磁盘的数据超出了队列长度,会锁定写,并将内存数据刷到磁盘中的SSTable,之后Commit Log被清空。
读流程
Scylla数据存储在Memtable和SSTable中,因此读取数据需要将其合并。
读取流程:
从 Memtable 读取数据
从 row cache 读取数据,如有则与Memtable中数据合并直接返回
检查 Bloom filter
检查 partition key cache
如果在 partition key cache 中找到了分区键,则直接转到 compression offset map;如果找不到分区键,则直接检查partition summary
如果检查了partition summary,则访问分区索引,通过在小范围分区索引中找到分区键,然后转到 compression offset map
使用 compression offset map 定位磁盘上的数据
从磁盘上的 SSTable 中获取数据
一致性Hash
如上图所示:key的范围是0~2^32形成的一个环,叫做hash空间环,即hash的值空间。对集群的服务器(比如ip地址)进行hash,都能确定其在环空间上的位置。
定位数据访问到相应服务器上的算法:将数据key使用相同的hash函数计算出hash值,通常根据此hash值来确定此数据在环上的位置,从此位置沿环顺时针“行走”,第一台遇到的服务器就是其定位到的服务器。
由于一致性哈希算法在服务节点太少时,容易因为节点分布不均匀而造成数据倾斜的问题,所以引入了虚拟节点。如下图所示:
把每台server分成v个虚拟节点,再把所有虚拟节点(n*v)随机分配到一致性hash的圆环上,这样所有的用户从自己圆环上的位置顺时针往下取到第一个vnode就是自己所属节点,当此节点存在故障时,再顺时针取下一个节点作为替代节点。
在ScyllaDB中,每个节点分配了一个单独的token代表环中的一个位置。每个节点存储将row key映射为hash值以后落在该节点应当承担的唯一的一段连续的hash值范围内的数据。每个节点也包含来自其他节点的row的副本。
而使用虚拟节点允许每个节点拥有多个较小的不连续的hash值范围。在ScyllaDB集群中的节点就使用了虚拟节点,虚拟节点随机选择且不连续。数据的存放位置也由row key映射而得的hash值确定,但是是落在更小的分区范围内。
Scylla vs. Cassandra
AWS i3.metal 上 Scylla 的4个节点与 i3.4xlarge 上40个 Cassandra 的节点
AWS EC2成本降低2.5倍
通过将集群大小减小10倍,极大地提高了可靠性
99% 的延迟提高了11倍
Scylla 在所有测试中 99.9%延迟表现突出
以下为 Scylla 与 Cassandra 99.9% 延迟表现:
AWS机器配置
型号 | vCPU | 内存 (GiB) | 联网性能 | 存储 (TB) |
i3.4xlarge | 16 | 122 | 最高 10Gb | 2 x 1.9 NVMe SSD |
i3.metal | 72* | 512 | 25Gb | 8 x 1.9 NVMe SSD |