为何进行数据切分
海量数据的存储和访问成为系统设计的瓶颈问题。每天海量数据的增长无疑对数据库造成了相当高的负载。给系统的稳定性和扩展性造成了极大的问题。通过数据的拆来提高系统整体性能,扩充系统整体容量,横向扩展数据层已经成为分布式数据库架构师及开发人员首选的方式。因此,需要能数据库的数据进分切分存储。
为何进行数据合并
存储文件会被后台的管理进程仔细地监控起来以确保它们处于控制之下。随着memstore的刷写会生成很多磁盘文件。会生成很小文件,如果文件的数目达到阈值,合并(compaction)过程将把它们合并成数量更少的体积更大的文件,便于数据库更好地进行数据维护的目的。
原理
数据的切分(Sharding)原理:依据其切分规则的类型,能够分为两种切分模式。一种是依照不同的表(或者Schema)来切分到不同的数据库(主机)之上。这样的切能够称之为数据的垂直(纵向)切分。第二种则是依据表中的数据的逻辑关系,将同一个表中的数据依照某种条件拆分到多台数据库(主机)上面,这样的切分称之为数据的水平(横向)切分。
数据合并原理:
小合并,指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile,在这个过程中不会处理已经Deleted的文件。一次Minor Compaction的结果是更少并且更大的StoreFile。
大合并,将所有的StoreFile合并成一个StoreFile,这个过程会清理三种数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据(VERSION)。
实现方式
切分 一个Region代表一个表的一段数据集合,当Region太大,hubbleMaster会将其拆分。Region太大会导致读取效率太低,遍历时间太长,通过将大数据拆分到不同机器上,分别查询再聚合。
Region可以手动和自动拆分
手动拆分
在建表的时候就定义好拆分点的算法,创建表,并传入拆分点算法,就可以在建表同事定义拆分点算法。开始的时候定义预拆分,导入初始数据,之后使用自动拆分来让Hubble数据库自动管理Region。不要关闭自动拆分。避免因为直接使用预拆分导致的热点Region问题。
自动拆分
固定大小拆分策略,如果单个Region大小超过了阀值那么就拆分为两个Region,这种策略使得集群的Region大小很平均。动态限制拆分策略,是新版本的默认策略。有的数据库文件增长是翻倍的数据量大小时,进行拆分,如64M、128M、256M等。
热点拆分策略,这是唯一考虑到热点数据的拆分策略,如果数据库中的Region某些短时间内被访问很频繁,承载了很大压力,就是热点Region。
合并
在进行合并的过程中,不同机器上的Region需要进行合并,Region中的文件夹需要合并,文件夹中的sst文件也需要合并,合并过程会进行大量的读写操作,极大程度上占用资源;Region的合并称之为大合并,一般情况下是关闭的,尤其是业务高峰期;平时只会进行sst文件之间的小合并;只有在业务低峰期(节假日)进行Region之间的大合并。一般存放标签性质的数据报表,当达到过期时间时需要进行Region之间的合并操作。
合并有两种方式:
手动合并(又称冷合并)
通过客户端命令行的方式,通过人工指定所所需合并文件,调用合并的工具类来实现两个Region的合并,但是有一个前提,必须保证这两个Region已经下线,保证HubbleMaster和所有的HubbleRegionServer都停掉,否则会报错,但是这样太麻烦了,而且不适合生产使用。
自动合并(又秒热合并)
在合并策略中配置文件合并策略阀值,当系统文件数据达到这值后,系统自动触发合并任务。
优势与劣势
优势
1、拆分规则明确。
2、系统之间进行整合或扩展很容易。
3、按照成本、应用的等级、应用的类型等将表放到不同的机器上便于管理。
4、切分的表结构相同,应用层改造较少,只需要增加路由规则即可。
5、提高了系统的稳定性和负载能力。
劣势
1、提高了系统的复杂度。
2、事务处理复杂。
3、切分后,数据是分散的,跨库join操作难和性能差。
面临挑战
1、分片事务的一致性机制实现复杂。
2、分布式事务的问题。
3、数据迁移的时候麻烦。
以上为数据切分与合并,「分布式技术专题」是国产数据库hubble团队精心整编,专题会持续更新,欢迎大家保持关注。