初探巨杉分布式数据库_巨杉数据库

网上介绍巨杉数据库的资料并不是很多。在这里记录一下我安装、使用SequoiaDB的基本流程，也算是作为使用分布式数据库的入门笔记，并尝试通过使用巨杉数据库，来理解巨杉数据库的原理。

下面引用的文字，如无说明均引自巨杉数据库官网。SequoiaDB的产品文档可以在产品文档查阅到¹。

SequoiaDB基本架构

SequoiaDB是一个分布式数据库，它通过分层的形式对于不同的数据源提供了支持。后文的基础实操中验证了这一点。

SequoiaDB 巨杉数据库采用计算存储分离架构。数据库底层以支持分布式事务能力的存储节点构建可横向扩展的存储集群，上层通过创建多实例的方式提供 MySQL、MariaDB、PostgreSQL、以及 SparkSQL 的支持。除了支持结构化 SQL 实例以外，SequoiaDB 巨杉数据库还支持创建 JSON 和 S3对象存储实例。

SequoiaDB 巨杉数据库的分布式架构一方面可以提供针对数据表的无限横向水平扩张，另一方面在计算层通过提供不同类型数据库实例的方式，协议级兼容 MySQL、MariaDB、PostgreSQL 与 SparkSQL，原生支持跨表跨节点分布式事务能力，应用程序基本可以在零改动的基础上进行数据库迁移。

除了结构化数据外，SequoiaDB 巨杉数据库可以在同一集群支持包括 JSON 和 S3 对象存储在内的非结构化数据，使整个数据库面向上层的微服务架构应用提供了完整的数据服务资源池。

SequoiaDB节点架构

SequoiaDB每个节点为一个独立进程，节点之间采用 TCP/IP 协议进行通讯，主要有以下三种角色：

• 协调节点
  协调节点不存储任何用户数据。作为外部访问的接入与请求分发节点，协调节点将用户请求分发至相应的数据节点，最终合并数据节点的结果应答对外进行响应。
• 编目节点
  编目节点主要存储系统的节点信息、用户信息、分区信息以及对象定义等元数据。在特定操作下，协调节点与数据节点均会向编目节点请求元数据信息，以感知数据的分布规律和校验请求的正确性。
• 数据节点
  数据节点为用户数据的物理存储节点，海量数据通过分片切分的方式被分散至不同的数据节点。在关系型与 JSON 数据库实例中，每一条记录会被完整地存放在其中一个或多个数据节点中；而在对象存储实例中，每一个文件将会依据数据页大小被拆分成多个数据块，并被分散至不同的数据节点进行存放。

真正的集群是由多个负责不同功能的主机协调完成分布式的任务，从而实现高可用、支持高并发等的分布式数据库的设计目标。这里节点的含义我认为跟Hadoop等大数据集群中的“节点”差不多，例如Spark的 local[*]模式也是用多线程模拟不同的节点，这三个角色设计的功能不同，所以它们在意外故障恢复时的策略也不一样。如协调节点不存储用户数据，直接重启即可。

对于分布式引擎的更多细节，可参阅分布式引擎。

SequoiaDB安装体验、踩坑经历

我本人比较喜欢通过动手实践来研究一个系统，因此接下来是我体验安装SequoiaDB并尝试研究数据库原理的过程。

部署方式

巨杉数据库SequoiaDB提供了多种部署方式：

• 线上主机（练习用 ）
• Docker 镜像容器部署
• VMWare Workstation、VirtualBox镜像
• 伪集群模式部署
• 独立模式部署
• 集群模式部署

伪集群模式部署跟独立模式部署的区别在于，伪集群是创建三个数据组，每个数据组单副本，并创建一个 MySQL 实例，所有这些节点都创建在同一主机中（跟Hadoop的伪集群模式差不多，方便在本机测试分布式节点的运行情况），而独立模式需要启动一个独立模式的数据节点，即可提供数据服务，该模式中所有信息都存放在数据节点，不存在编目信息，只支持JSON API。但是显然这两种模式都只适合在开发环境下使用，在实际生产中还是需要部署到分布式节点上以实现fault tolerant、高并发等的特性。

注意：不同安装方式提供的SequoiaDB版本可能是旧的3.x版本，