企业互联网+转型实战：如何进行PB级别数据的架构变迁(2)

单独使用一种分片规则是很难支撑大量数据的存储,哪怕使用一致性hash在生产环境中也是很麻烦的事情,光是数据迁移就是一件让运维头疼的事了,这时候我们需同时采用垂直分片和水平分片,甚至多次水平分片,下面聊一下我们在实际生产中如何使用这些分片规则的.

以监控宝API监控为例,先介绍下应用场景,现在我们手机里安装的是各种APP,其架构中必然存在大量的API,我们的用户不但要监控单个API请求,还要监控连续请求构成的事务,监控宝API监控的正确性是以断言来判断的,每个监测点都会对用户的API做出请求,请求数据及断言的结果都将被存储到数据中心.

我们借助于cobar,对数据做了两次分片,分片逻辑图如下：

a、 首先我们是通过cobar,采用枚举法按监测点ID对DB这层进行了数据分片,这样做的话物理上同一个监测点的数据在一起,业务上也是好理解的.

b、在程序逻辑中按天对表进行了分片.每天都会有脚本将一月之内的表都创建好.

从上图中大家可以看到,这里扩展上是存在问题的.我们一共有200多个监测点,在第一阶段,数据量没有那么大的时候,为了节约成本,我们仅使用了10台机器做存储,一台机器存有多个监测点的数据.

随着数据量增大,发展到第二阶段,当某台机器硬盘快存满的时候,我需要将一些监测点的数据迁移至新增进集群的机器中,按这个架构,最多我们可以扩展到200+台机器.

在生产环境中用户对北上广的监测点是最有兴趣的,所以这些监测点的数据量是最大的. 这样就会发展到第三阶段,部分监测点的数据量大到单台机器的硬盘存不下了.

这时候如何解决问题呢,我们来分析一下数据,单个数据库中是按日期来分表的,而大于3个月的历史数据较少有人查询,用户也可以接受历史数据查询时间稍长一些,于是我们选用了TokuDB来压缩历史数据,基本上1T的数据压缩之后在100G左右.1:10的压缩例,即使这样,理论上最多也只能存储4P左右的数据(数据放在UCLOUD上,云主机支持的最大硬盘为2T).

我们在网站监控的数据分库中解决了这个问题,逻辑图如下,我们从4个维度对数据进行了分片

1、按日期为第一维度对数据库分片,必须按日期做第一次分片,并且分片时间点可以在配置文件中自定义.

2、按监测点ID为第二维度对数据库分片

3、按实际分片数量对任务ID动态取模为第三维度对数据库分片

4、对任务ID 100取模为第四维度对数据表分片.

创建后的数据库类名似于db-201501-monitor01-01、 db-201501-monitor01-02 ……??每个库是有100张表.这样可以的好处：

1、冷热数据自然分离

2、可以根据日期无限次分片

3、在同一个时间段里实际分片数可以自定义.理论上可以无限次分片.每次分片服务器的数量是可控的,并且下次分片的时间也变的可预期.可以在最大程度是节约成本.

4、数据无需迁移

细心的同学会发现这样对数据分片造成一个小问题,我们对任务ID做了两次取模,会造成部分实例中的某些表中数据是空的,不过并不影响应用.

以上就是云智慧在过去几年里从传统数据架构向大数据迁移过程中的一些经验,希望为大家的数据架构迁移提供参考.

（编辑：ASP站长网）