Hubble数据库开发使用规范.pdf

做人不能太段德

270

5页

3次

2023-01-31

免费下载

Hubble数据库开发使用规范

开发设计

命名规范

hubble数据库数据库命名规范可参考传统关系型postgresql数据库。

处理特定的错误码 40001

在客户端接受到服务端返回的异常错误，并且错误错误码为40001时，这意味着这个操作影响到的数据

与其他事务相冲突了，并在事务管理器内部尝试重试失败后，最后返回客户端。我们建议对此错误码进

行特殊处理，即客户端接受40001错误码后，主动进行五次以内的重试。

多节点进行写入

hubble数据库为去中心话架构，确保了每个节点服务都可等价的对外提供服务。我们建议上游单个主题

日志同步数据流，可以指定到固定的节点中。这样能一定程度的减少数据更新过程中的网络开销和事务

冲突。不必担心可能出现的单点故障情况，因为hubble数据库在协议层，很好的兼容了postgersql，可

直接使用postgresql-jdbc的高可用特性，配置多个连接目标服务。在出现单点因网络等问题无法访问的

情况下，自动按照顺序依次尝试连接访问目标服务节点。当然多个不同的数据源可以由开发人员指定分

散到等价的服务节点，避免单点的性能瓶颈，有效使用整个集群的资源。

查询可适用任何节点

hubble数据库为去中心话架构,针对于只有查询类的服务接口，可以通过HA Proxy、F5等来实现负载均

衡。这样查询类的服务不需要关心实际访问是哪个具体服务节点，完全避免故障切换的问题。同时面对

突然增长的连接数，整个集群也能有非常良好的吞吐表现。

尽可能确保表有主键

设计良好的多列组合主键，可以产生比 uuid 或自增主键更好的性能，这需要在前期模式设计工作与业

务数据的理解。我们建议一些单调递增的字段要位于主键的第一个列之后。这能带来如下收益：

主键具有足够的随机性，可以将表的数据和查询负载相对均匀的分布在集群中，从而避免出现热

点。所谓足够的随机性，是指主键的前缀应该相对均匀地分布在其域，而这域与服务节点数量相对

一致是最优的状态。

一个有实际业务含义的列在主键中，往往对查询速度也有帮助。

索引设计

在不使用主键查询的场景中，合理的使用索引，可以大幅度的提升查询效率。同时索引的设计是需要权

衡的，在带来查询速度极大提升的同时，也可能会略微影响列更新的操作，因为更新操作必须对表和索

引都进行写操作。

我们建议为所有常见的查询创建索引，为了能设计出权衡后最优的索引，符合业务场景的使用，我们可

以遵守如下两个设计准则：

索引包含的列，尽可能满足所有谓词条件

在索引中存有需要查询展现的列

在设计索引时，重要的是考虑查询条件是哪些列以及他们的顺序，以下是一些具体的建议：

需要满足索引前缀的要求，如果当前有一个（A,B,C）索引，查询条件为（A）或（A,B）都是可以

通过索引进行查询的，但（B）或（B，C）是无非是通过索引查询的。这意味着尽可能的避免创建

单列索引，增加索引的通用性，即可在多个场景下复用。

谓词条件中出现的列，需要注意等于和包含条件（= ，in），必须出现在范围（<，>）条件之前。

否则无法通过索引查。

索引中可以存储查用列，来避免回表的情况。命中率高的查询，是否回表对查询速度，将产生非常

大的影响。

尽量避免大表后建索引的情况

hubble数据库具备在线建索引的特性，且在建索引过程中，不会出现锁表的情况。但我们需要注意一

点，hubble数据库在完成创建索引前，需要做索引与数据一致性校验的必要动作，这个行为对于超大数

据量的表，无法避免的是一个大IO的任务。如果无法为超大数据量表创建索引，提供合理的运维窗口，

请给这个索引创建任务留出较大的时间窗口，耐心等待即可，尤其在非SSD存储介质基础上。当然几亿

数据的表，创建索引还是可以保证效率的，这里的大表，是指10亿、20亿上的表。

连接数的合理规划

hubble数据库创建多个活动连接，可以有效的使用可用的数据库资源。对于创建连接需要经过身份验证

的过程，这个过程是cpu和内存密集型的，客户端等待数据库验证连接的过程中还增加了延迟。因此合

理的控制连接数是必要的工作。我们建议连接数的量参考集群core数量进行衡量，计算公式是core数据

的两倍。

当然HA proxy模式也对连接数的规划会产生影响，如较高维度分析型的并发任务，实际最优连接数会比

计算公式得出的结果要低。如果集群使用ssd硬盘，能一定程度提升连接数的上限。

如应用类程序使用连接池，除了设置最大连接池大小外，还必须设置空闲连接池大小。我们的建议是将

空间连接池大小设置为最大连接池相等。这个设置可能会占用更多的应用程序服务器内存，但在并发较

高的情况中，可以避免创建新连接带来的性能损耗。

建表复制数据 CREATE TABLE AS SELECT

当执行 CREATE TABLE AS SELECT 语句进行建表并且进行数据复制的时候，将会导致新创建的表中丢

失主键分区和外键等约束。影响数据检索查询效率。强烈推荐先执行 create table t2（ like t1

INCLUDING ALL EXCLUDING CONSTRAINTS ）复制表结构和约束，再执行 insert into T2 select *

from T1 方式导入数据。

参考示例如下：

SQL规范建议

使用UUID生成唯一主键

建表设计过程中，无法使用业务字段作为主键，我们建议使用UUID来作为主键字段。这能提供更好的数

据分布情况。

CREATE TABLE t1 (id INT PRIMARY KEY, name INT NOT NULL, INDEX(name));

CREATE TABLE t2 (LIKE t1 INCLUDING ALL EXCLUDING CONSTRAINTS);

insert into T2 select * from T1;