区块链数据库SUNLIGHTDB 架构设计（一）

本文简要介绍 SunlightDB 架构设计，主要受众是想要了解 SunlightDB 内部结构的开发人员和用户。

 

基础模型

SunlightDB 是一个分布式数据库，可以部署到多台服务器中组成一个分布式数据库集群。集群中的每台SunlightDB服务器实例具有同等地位，这些SunlightDB 实例由统一的协调服务（比如 ZooKeeper）链接到一起。

SunlightDB 存储单元是表和行。支持行数据的查询、插入和更新（新版本支持更新不支持删除）操作。每个表都有一个强制主键。该主键用于自动将表拆分为多个大约 500MB 的分区。每个分区存储在集群中的 N 个服务器节点上。SunlightDB 分区的每个副本按照段文件的日志合并树结构，存储在相应服务器上。段文件使用 CSTable文件格式进行编码。CSTable 是一种支持列式存储的容器文件格式。

查询模式

可以通过 SunlightDB 客户端（连接到 SunlightDB 集群）创建和管理表，执行数据查询等操作。当客户端想要对数据执行 SQL 或 MapReduce 查询时，可以将查询语句发送到集群中的任何 SunlightDB 服务器节点。

SunlightDB 首先识别查询语句中引用的所有表，然后识别每个表需要扫描的分区。然后将查询语句重写为分片查询。分片查询中涉及到的所有分片在相应的 SunlightDB 服务器上并行执行，从而最大限度地减少数据传输。

在每个分片上，从服务器上的 CSTable 文件中加载响应查询所需的数据子集（即仅表中实际引用的列）。最后所有分片查询结果合并到一起，返回给客户端。

数据一致性

SunlightDB 支持最终一致性，即更新或插入操作最终是一致的（足够时间范围内所有副本都将同步）。数据写入冲突的解决是自动的（微秒粒度内最新写入胜出）。

数据分片和数据的重新平衡都是自动和透明的。每个表都有一个可配置的复制因子 N，用于控制每个分区存储的服务器节点数量。SunlightDB 最多可以容忍 N-1 次故障，并且仍然为每个分区提供读写服务。默认情况下，N 为 3，可容忍的故障数为2。

每个分区同时由 N 个服务器节点提供服务，其中 N 称为复制因子。从分区的所有副本中，我们选出一个作为领导者Leader，并指定其他副本为追随者Follower。所有分区都可以执行数据的读操作，只有Leader可以执行写入（比如Zookeper Raft算法）。