Hubble数据库架构
Hubble 数据库的目标是提供一个可扩展、高可用性、高性能、强一致性、支持 SQL 的关系数据库，能够在各种各样的硬件平台上运行。Hubble 的架构与这些目标是一致的。
有多种方法可以查看 Hubble 架构。在集群层面，Hubble 的部署由一个或多个无共享、无领导的节点组成，它们协作呈现分布式数据库系统的单一逻辑视图。在每个节点中，我们可以将 Hubble 架构视为一系列提供基本数据库服务的层，包括 SQL 处理、事务处理、复制、分发和存储。
Hubble 集群架构
Hubble 是由一个或多个数据库服务器进程组成。每个服务器都有自己的专用存储—“无共享”数据库集群模式。Hubble 集群中的节点是对称的——没有“主”节点。这个存储直接挂载到运行 Hubble 服务器的机器上，虽然有时候数据也可能物理上位于共享存储系统上，但依然是无共享模式。数据基于键(Key)范围跨集群分布。每个范围至少复制到集群的三个成员。
数据库客户端—应用程序、管理控制台、Hubble shell 等—连接到集群中的 Hubble 服务器。
数据库服务器和数据库客户端之间的通信采用 PG 协议。该协议描述了 SQL 请求和响应是如何在 PG 客户端和 PG 服务器之间传输的。由于 Hubble 使用了 PG 协议，所以任何 PG 驱动程序都可以用来与 Hubble 服务器通信。在更复杂的部署中，一个或多个负载平衡进程将负责确保这些连接在各个节点之间均匀而合理地分布。负载均衡器将客户端与集群中的一个节点连接，该节点将成为连接的网关服务器。
客户端请求涉及对集群中的单个节点或多个节点读写数据。对于任何给定的键值范围，租赁者(Leaseholder )节点将负责控制对该分片(Shard)的读写。租赁者(Leaseholder )通常也是 Raft 领导者(Leader)，负责维护数据副本。
图 1-1 说明了其中的一些概念。数据库客户端连接到负载均衡器(1)，负载均衡器作为 Hubble 集群的代理。负载均衡器将请求定向到一个可用的 Hubble 节点(2)。该节点成为此连接的网关(getaway)节点。请求需要范围 4 中的数据，因此网关节点与这个分片 Shard(3)的租赁者节点通信，租赁者节点将数据返回给网关，网关又将所需的数据返回给数据库客户端(4)。
图 1 - 1。 Hubble 集群架构
这种架构将负载均匀地分布在集群的各个节点上。网关职责通过负载均衡器均匀地分布在集群的各个节点上;租赁者的责任也同样按范围分布在所有节点上。
如果查询来自多个分片(Shard)的数据，或者数据必须更改(需要复制)，则工作流涉及更多步骤。
分片(Shard)和副本(Replicas)
Hubble 表中的数据被组织在一个键值(KV)存储系统中。KV 存储的键是表的主键。KV 存储中的值是该行中所有列的值的二进制表示。
索引也存储在 KV 系统中。对于非惟一索引，键是连接到表主键的索引键。在唯一索引的情况下，键就是索引键，主键显示为该键的相应值。
分片(Shard)存储连续的键值范围(spans)。图 1-2 说明了如何将“账号表”表划分为多个分片。
图 1 - 2 。 分片
如上所述，租约(leases)被授予给一个节点，让它负责对一个 Shard 的读取和写入。持有租约(leases)的节点称为租赁者(Leaseholder )。该节点通常也是 Raft 领导者(leader)，负责副本之间的一致性以及副本个数等维护。
