在逻辑上，Hubble 数据库中的表统一表示为 KV 结构，其中键( Key )是表主键，值( Value )是表中所有剩余列。我们在 Hubble SQL 层介绍描述了该存储结构。
数据分布层将整体结构分解为大约 512 MB 的连续块。512 MB 块大小使得每个节点分片更容易管理。数据分布层保持数据在集群中均匀分布，同时向需要数据的应用程序提供数据的统一且整合视图。
Hubble 数据库元数据分片
分片分布存储在全局空间 第一层元信息(Meta1)和第二层元信息(Meta2)中。Meta1 可以被认为是一个“分片的元数据”，然后允许节点查找持有 Meta2 记录的节点的位置，该记录反过来指向持有“分片的元数据”内每个范围副本的节点。图 1-1 说明了这个两级查找结构。
节点 1 需要获取 key“Hub2”的数据。它在它的 meta1 副本中查找，这告诉它 node2 包含 G-M 范围的 meta2 信息。它访问来自节点 2 的相关元 2 数据，这表明节点 4 是范围 G-I 的租赁者，因此是相关分片的租赁者。
图 1-1。元分片
Hubble 数据库八卦协议
Hubble 使用八卦协议在节点之间共享临时的信息。八卦协议是分布式系统中广泛使用的协议，节点信息通过网络传播。
在所有的 Hubble 节点上，八卦协议维护着最终一致的 KV 地图。它主要用于引导:它包含一个“Meta0”记录，告诉集群在哪里可以找到 Meta1 范围，以及从存储在元记录中的节点 ID 到网络地址的映射。八卦协议还用于不需要强一致性的一些操作，例如维护每个节点上可用存储空间的信息以实现再平衡。
Hubble 数据库租赁者
租赁者是 Hubble 中的节点，负责为 特定范围的 Key (分片)提供读取和协调写入。我们在“Hubble 事务处理层”中讨论了租赁者的一些责任。当事务协调器或网关节点想要对一个分片发起读或写操作时，它会找到该分片的租赁者(参考元数据分片)，并将请求转发给租赁者。
租赁者使用 Raft 协议进行分配，我们将在“Hubble 副本处理层”中讨论。
Hubble 数据库分片切分
Hubble 默认分片大小为 512M。当一个分片超过值时，该分片将被分割为两个较小的连续分片。
如果分片超过负载阈值，也可以拆分。如果参数 kv.range_split.by_load_enabled 为 true，并且该分片内每秒的查询次数超过了 kv.range_split.load_qps_threshold 的值，那么一个分片可能被切分，即使该分片的大小低于切分的阈值。其他因素决定是否真实切分，包括拆分的两个新的分片是否针对可以拆分负载，以及对可能需要跨新分片的查询的影响。
当根据负载切分时，两个新分片的大小可能不相等。默认情况下，分片将在两个新分片上的负载大致相等的点上切分。图 1-2 演示了基本的分片切分，当插入操作导致分片超过 512M 的阈值时，将创建了两个新的分片。
图 1-2。分片切分
还可以使用 ALTER TABLE 和 ALTER INDEX 语句的 SPLIT AT 子句手动拆分分片。
分片也可以合并。例如 DELETE 语句从分片中删除数据，并且分片小于大小阈值，Hubble 可能会将该分片与邻近的分片合并。
Hubble 数据库多区域分布
地理分区是 Hubble 的一个特殊功能，它允许数据位于特定的地理区域内。从性能的角度来看，这可能是可取的，可以减少某个区域对该区域的查询延迟，或者从数据高可用的角度出发，可以配置两地三中心，或者多中心等特定地理区域内保存数据。Hubble 支持多区域配置，控制数据如何跨区域分布。以下是相关的核心概念:
- 集群区域是用户在节点启动时指定的地理区域。
- 区域可以有多个分区。
- 集群中的数据库被分配给一个或多个区域：其中一个区域是主区域。
- 数据库中的表可能具有特定的位置规则（全局、逐表区域、逐行区域），这些规则决定了其数据将如何跨区域分布。
生存目标决定了数据库可以同时生存多少次故障。有了分区级别(zone-level)生存目标，数据库将保持完全可供读取和写入，即使某个区域出现故障。但是，如果同一区域中的多个区域发生故障，数据库可能无法保持完全可用。生存区域故障是多区域数据库的默认设置。
区域级(region-level)生存目标具有这样一个特性，即使整个区域宕机，数据库仍将完全可供读取和写入。当然，这意味着数据的拷贝需要在其他区域维护，从而延长了写入时间。
默认情况下，多区域数据库中的所有表都是区域表，也就是说，Hubble 优化了从单个区域（默认情况下是数据库的主区域）对表数据的访问。区域表为来自单个区域的表的一行或多行提供低延迟读取和写入。表中的不同行可以针对不同区域的访问进行优化。
全局表针对所有区域的低延迟读取进行了优化。
