LSM Tree存储格式

(1)LSM Tree是什么

LSM Tree,即日志结构合并树(Log-Structured Merge-Tree),是一种被精心设计的数据结构,常用于处理大量写入的场景。通过对写入操作进行顺序写入优化实现性能提升。LSM tree 是很多数据库内部的核心数据结构。

(2)为什么要用LSM Tree

传统关系型数据库使用B-Tree或一些变体作为存储结构,能高效进行查找,但保存在磁盘中时它也有一个明显的缺陷,那就是逻辑上相离很近但物理却可能相隔很远,这就可能造成大量的磁盘随机读写。随机读写比顺序读写慢很多,为了提升IO性能,我们需要一种能将随机操作变为顺序操作的机制,在海量数据和高吞吐写的场景下,LSM Tree 诞生了,LSM 能解决更快速的写,更快速的读。LSM Tree 通过将数据增删改全部转化为顺序写入从而显著提高写的性能。这个特点在分布式系统上更为看重。

(3)Hubble数据库硬核技术价值

Hubble的LSM tree将随机写转化为顺序写,尽量保持日志型数据库的写性能优势,并提供相对较好的读性能。具体优势如下:
1)当有写操作(或update操作)时,写入位于内存的buffer,内存中通过某种数据结构保持key有序;
2)可以将数据追加写到磁盘Log文件,以备必要时恢复;
3)内存中的数据定时或按固定大小地刷到磁盘,更新操作只不断地写到内存,并不更新磁盘上已有文件;
定时对文件进行合并操作(compaction),消除冗余数据,减少文件数量。

混合逻辑时钟

(1)什么是混合逻辑时钟

混合逻辑时钟即混合了物理时钟PT和逻辑时钟LC,实质上,是对逻辑时钟的增强。物理时钟是机器本地的时钟,由于系统对时间流逝的感知和度量会出现频率稍高或稍低的状况,因此系统时间会比标准时间稍快或稍慢,一天的误差可能有毫秒甚至秒级。
逻辑时钟是通过happened-before关系确定事件的逻辑时钟,从而确定事件的偏序关系。在分布式场景下,不同机器的时间可能存在不一致,没办法对跨节点的事件确定的先后关系。

(2)为什么需要混合逻辑时钟

在逻辑时钟下,如果a, b是位于一个进程内的顺序事件,且a发生于b之前,那么a happened-before b。 
如果a,b事件是位于2个进程内,a为消息的发送事件,b为同一个消息的接收事件,那么同样a happened-before b。
a happened-before b记作:a hb b或者a->b,C(a)<C(b),C表示逻辑时钟。 
但在实际中我们不能通过C(a)和C(b)的大小推出a, b事件发生的先后顺序。因为分布式节点间的交互要在事件发生顺序上达成一致, 而不是对于时间达成一致。如何让逻辑时钟和物理时钟达成一致?一种“尽可能”的方式即混合逻辑时钟存在很有必要。

(3)Hubble数据库硬核技术价值

Hubble混合逻辑时钟能实现:
1)满足逻辑时钟的因果一致性happened-before。
2)尽可能接近物理时钟PT,当物理时钟推进时,逻辑时钟部分被置零。
3)记录时间的因果关系,保证和物理时钟的偏差是bounded。
4)消除中心节点,用本地的物理时间加上逻辑时间,为具备数据库定义的因果关系的事务排序。
5)可以替代wall time使用。

存储和查询统一实例

(1)什么是存储和查询统一实例

实例是“内存”和“后台进程”的集合。数据库是数据的物理存储。特别注意,一个实例可以用于一个数据库,多个实例也可以同时用于一个数据库,实例和数据库的关系是一对多的关系,存储和查询统一实例就是指存储和查询共用一个实例。

(2)为什么要存储和查询统一实例?

查询和存储如果分离,就好比为两个大的水库中间由一个水渠连接起来。那么水库之间的水量交换就取决于水渠的大小,如果其中一个水库干了、或者闸门坏了、或者出现了其他问题,两个水库都会受到影响。存储和查询统一实例,就相当于一个大的水库完全自治,直线降低了风险和运维成本。

(3)Hubble数据库硬核技术价值

Hubble数据库将存储和查询共用Hubble Sever一个实例,Hubble将存储和查询统一实例的价值点有以下两点。
1)减少运维成本,存储和查询共用一个实例减少了后期大量的运维工作。
2)有效缩短了数据传输时间。

独占空间和非独占空间

(1)什么是独占空间和非独占空间

数据库底层是表,表分为大表(类似银行交易表,数据量非常大)和小表(可维护的表,数据量比较小)。独占空间是指表存储在一个独立空间里;非独占空间是指各类表共用一个空间。

(2)为什么需要独占空间和非独占空间

a)由于小表数据量比较少,占一个独立空间会造成资源浪费,非独占空间会把大量小表存储在一起,共同占用一个空间;
b)大表数据量非常大,一般单独存储在独占空间中,大表和小表分开存储,物理间有隔离,运行速度快。

(3)Hubble硬核技术价值

a)Hubble数据库既支持独占空间,又支持非独占空间;
b)在Hubble数据库中建表时可以指定独占空间和非独占空间;
c)Hubble数据库可以做到大表和小表分开存储,物理间有隔离,合理利用空间且不浪费资源。

事务隔离级别——可串行化

(1)什么是事务隔离级别可串行化

事务隔离级别,就是为了解决解决隔离级别中“脏读可能性、不可重复读可能性、幻读可能性、加锁读”的问题。事务隔离级别越高,在并发下会产生的问题就越少,但同时付出的性能消耗也将越大,因此很多时候必须在并发性和性能之间做一个权衡。
所以设立了几种事务隔离级别,以便让不同的项目可以根据自己项目的并发情况选择合适的事务隔离级别,对于在事务隔离级别之外会产生的并发问题,在代码中做补偿。

(2)为什么需要做到事务隔离级别可串行化

事务隔离级别有4种 ,串行化是最高的事务隔离级别,可以解决多个问题。
a)读未提交
读未提交,即能够读取到没有被提交的数据,所以很明显这个级别的隔离机制无法解决脏读、不可重复读、幻读中的任何一种,因此很少使用。
b)读已提交
读已提交,即能够读到那些已经提交的数据,自然能够防止脏读,但是无法限制不可重复读和幻读。
c)重复读取
重复读取,即在数据读出来之后加锁,明确数据读取出来就是为了更新用的,所以要加一把锁,防止别人修改它。这样就解决了脏读、不可重复读的问题,但是幻读的问题还是无法解决。
d)串行化
串行化,最高的事务隔离级别,不管多少事务,按顺序运行完一个事务的所有子事务之后才可以执行另外一个事务里面的所有子事务,这样就解决了脏读、不可重复读和幻读的问题了。

(3)Hubble硬核技术价值

a)无需关心锁表的问题;
b)支持最高的事务级别,可以保证数据一致性足够安全;
c)性能上支持百万级的QPS。

多源异构

(1)多源异构是什么

简单来说就是多个数据源,不同的数据存储架构。
多个数据来源,这里的来源可能是 Mysql,Oracle这些数据库中文件;也可能是一些非结构化的 HDFS,ES这些非结构化数据库中的文件;还有一些就是通过 WEB 页面传递过来的 RESTful,Josn 字符串。
异构主要指数据结构上的差异性。数据结构层把纷繁复杂的数据归为三大类,针对每一类数据设计了相应的数据存储模型,确保了城市操作系统的扩展性和一致性。这三类数据包括:
结构化数据:以银行系统数据为代表,通常以人或者机构的ID为锚点来聚合不同的信息,如名称、职业、收入等;后续会演变出基础库、主题库、专题库等一系列组织形式。
非结构化数据:以视频、图像、语音和文本为代表,后续大多需要经过分析处理变成结构化数据才能被使用。
时空数据:以地理信息、物联网、轨迹数据为代表。

(2)为什么要多源异构

随着大数据与人工智能技术的应用普及,海量多源异构数据急剧增加,特别是非结构化数据的增加,当遇到复杂多场景混合事务分析型数据管理必然要涉及水平拆分,一旦进行拆分,就避免不了“原本在同一数据库里的查询,就变成跨多个数据库实例的查询”问题。随着技术的不断迭代,现在的数据库不仅仅只有关系型数据而且也有Nosql数据库等,这就对跨库关联提出了更大的挑战。
大数据的核心就是多源异构,每个源的数据都有自身的逻辑,有不同的形式进行描述。
而最终的目的是要把数据进行治理、融合、分析,这样就可以体现出整体数据中的现象和规律。

(3)Hubble硬核技术价值

Hubble数据库通过插件模式设计可以把Mysql、Oracle、Hbase、Hive等都可以作为Hubble的数据源,支持跨数据源查询。提供适配的多源异构数据资源接入方式,包括数据源的配置、数据任务的同步、数据的分发与调度、数据的ETL加工等;Hubble可以做到:
1)统一服务入口,接入各类数据库源系统;
2)自由编写SQL,实现数据访问服务;
3)无需将数据完全搬迁,即可以现有数据即席分析探查。

混合存储

(1)什么是混合存储

混合存储又称行列混合存储,TP 和 AP 传统来说仰赖不同的存储格式:行存对应 OLTP,列存对应 OLAP,混合存储简单理解就是AP+TP混合存储。

(2)为什么需要混合存储

OLTP需要处理涉及频繁写操作的事务型查询,OLAP侧重于处理涉及大量读操作的分析型查询,列存储在读操作中有较大的优势,适合OLAP查询,但不适合OLTP查询。
随着大数据存储时代的到来,人们对于大容量、高性能和低成本的存储系统的需求更加迫切。混合存储充分利用不同类型存储器件的特性组成高效的存储系统,既能支持存储系统容量的大幅扩展,又能在保证系统低成本的前提下,显著提高存储系统的性能,成为当前存储系统领域的研究热点。
先来看一下单独行存储和列存储的优缺点
1)行存储时,数据按照元组直接进行存储,写的效率较高;列存储时,元组必须首先拆分成独立的属性列,再独立存储。
2)行存储时,在查询密集型应用中需读取整条记录,属性较多时读取数据代价较大;按列存储时,只需要读取所需要的属性列,大大减少读取数据的代价。
3)采用列存储时可以获得较高的压缩率,行存储不利于压缩。
在数据存储层上, Hubble采用基于切片的行式存储、列式存储和KV存储的混合部署模式。通过行式存储方式存储海量数据,支撑数据TP操作;列式存储和KV存储的混合部署模式,支撑数据AP操作。

(3)Hubble数据库硬核技术价值

在数据存储层上, Hubble采用基于切片的行式存储、列式存储和KV存储的混合部署模式。通过行式存储方式存储海量数据,支撑数据AP操作;列式存储和KV存储的混合部署模式,支撑数据TP操作;通过KV存储保持高效率的写入速度,支撑大数据体量。
1)KV存储把不常变动的一些数据存储在kvstore中,需要的时候直接凭借key拿出value就好,事务处理速度更快,适合事务处理,速度快实时性更有保障。
2)列存性能在OLAP分析时比行存储性能倍速提升;
3)支持随机的增、删、改、查操作,降低查询响应时间;
4)在数据中高效查找数据,无需维护索引(任何列都能作为索引),避免全表扫描。
5)在大规模数据同时支持密集AP计算和TP并发场景下, 基于数据切片的混布存储策略可以弹性适应IO特性,快速做库内转换,避免数据复制和冗余。

分布式SQL

(1)什么是分布式SQL

分布式SQL可以称为分布式任务,分布式SQL是指SQL语句到任务执行的时候分布在多个机器上执行。

(2) 为什么要用分布式SQL

SQL是关系型数据库的通用语言,关系型数据库是单体式的,从架构而言它们无法在多个实例之间自动地分配数据和查询。
分布式SQL在查询上可以被自动地分配到目标群集的多个节点上,有效地避免了单个节点成为查询处理中的瓶颈问题。分布式SQL内置具有可扩容性、灵活性、以及地理分布特性。做TP(查询)计算时没有太大影响,在做AP(分析)计算时,性能会下降很多。

(3) Hubble硬核技术价值

分布式数据库,可以分为如下几类场景:第一种存储分布式、SQL单机化;第二种存储分布式、SQL分布式。
第一种只支持简单的增删改查,稍微复杂的分析SQL执行性能下降就会非常明显。第二种存储分布式、SQL分布式优点:1.可以把任务进行拆分充分利用计算资源,提升计算效率;2.对于有些大任务无法完成的,可以利用分布式任务来完成,提升了大任务的完成度。同时也存在了开发复杂度高、增加了调度的复杂度的问题。
a)Hubble数据库既可以支持存储分布式、SQL单机化也可以支持存储分布式、SQL分布式;
b)Hubble可以在不重启服务的情况下,通过修改配置,做到两种模式之间的切换;
c)Hubble数据库可以方便应对更多场景。



数据一致性

(1)什么是数据一致性

事务机制ACID和CAP理论是数据库和分布式系统中两个重要的概念,这两个概念中都有相同的“C”代表 "Consistency" 一致性。
ACID体现在数据库领域,其中ACID中的“C”数据一致性是指事务的执行不能破坏数据库数据的完整性和一致性,一个事务在执行之前和执行之后,数据库都必须处于一致性状态。 比如:A向B转账,A扣款的同时B到账。
CAP体现在分布式领域,其中CAP中的”C”数据一致性是指是所有副本在同一时间的数据完全一致,比如:A、B、C三个副本,A中写入数据”Hello”,写完马上读B和C,就一定要读出“Hello”读出来我们就称之为符合一致性。

(2)为什么需要数据一致性

为了更清楚的体现出数据一致性的重要程度,用举例的方式表达为什么需要数据一致性。举个简单的例子来描述一下这里数据一致性的含义。
程序员小张向女友小丽转账125元,转账过程是:先扣除小张125元,再为小丽的账户添加125元。如果在转帐过程中,扣款操作和打款操作要么同一时间执行,要么同一时间都不执行,我们就认为转帐过程保证了数据一致性。数据能否实现一致性,对金融、公安等重要行业来说至关重要。

(3) Hubble硬核技术价值

Hubble的数据一致性技术既包括ACID数据库中的数据一致性,又包括CAP分布式系统中的数据一致性,Hubble数据库可以做到最高级别可串行化。
a)用户体验感好;
b)支持串行化事务;
c)能保证多个事务并发时的执行顺序对数据的一致性没有影响。

去中心化技术

(1)数据中心化的问题

a)数据中心化在查询涉及多关联场景时,会导致查询性能严重低下。
b)当大量数据存在于同一个数据库时会容易造成数据库访问瓶颈,从而影响数据访问性能,并为系统可用性埋下隐患。

(2)为什么需要去中心化

a)在云计算、大数据等新技术的带动下,越来越多的企业需要对结构化的数据进行查询、分析、处理和更新。
b)随着创新业务的不断增加,业务的复杂及庞大的体量会产生错综复杂且规模巨大的结构化数据,这些都必然迫使企业对数据库的需求指向大规模、高可靠、高扩展及高性能。

(3)Hubble去中心化技术

Hubble去中心化技术,实现在一个分布众多节点的系统中,每个节点都可以高度自治。去中心化过程就是将数据拆分的过程,让每个节点成为自己的领导者,进而依据服务划分将数据从主体数据剥离出来。
示例:中心化就是在餐厅柜台点餐,柜台是中心,所有人都需要排队点餐;去中心化是餐厅在每个桌子上都有一个独立的二维码,顾客通过扫码即可点餐。

(4)Hubble硬核技术价值

a)支撑高并发业务:应用入口可无限水平扩展,高效支撑高并发事务交易。
b)减少运维成本:去中心化后所有的节点配置、硬件配置都是一样的,减少运维和硬件管理的复杂度;多个入口不会存在单点故障问题,减少了运维成本。
c)提高查询效率:每个节点都可以提供入口和查询服务,大大提升了资源利用率。