面向应用的反范式化建模|学习笔记

开发者学堂课程【Cassandra数据库入门与实战面向应用的反范式化建模】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/784


面向应用的反范式化建模

 

一、基础:数据分布

1、展性:scale up & scale out

举例,如果一块盘存不下的话,我们可能会换一块更大的盘,但这种往往会触及到系统的上线,因为我们不可能把一块盘做得非常大,所以说现在业界最常用的扩展的方法是,如果一块盘不够的话,不是用更大的盘,而是用更多的盘,比如说用两块盘,三块盘,当一台机器的盘达到上限的时候,一台机器不够,那就用更多的机器。

2、基本问题:数据分布策略

负载均衡:

写:均匀的写到集群的每一台机器上,每一块盘上

读:均匀的从集群的每台机器上,每块盘上读取数据

线性扩展:

机器扩缩容,磁盘上下线,系统最终处于负载均衡状态

系统容量、吞吐与系统资源成正比

两种分布策略

(1)顺序分布

顺序分布就是根据用户定义的主键,从最小的组件开始,依次往后排。

代表产品:hbase,tidb

需要region的原数据管理机制(如hbase的meta表)

面向应用的反范式化建模|学习笔记

优点:

region的灵活分布可以人工干预

 region可以分裂合并

缺点:

依赖主键值:user_id分布不均匀时,容易产生热点,需要额外设计(例如较小的userid往往不活跃)

相同前缀的数据也可能会分开

路由表机制复杂

(2)Hash分布

对于hash分布来说,需要一个hash的算法,需要选出一个分区键,通过算法的来得到他机器的名字。

代表产品:cassandra ,dynamodb

与分库分表类似

优点:

简单无额外系统依赖

缺点:

扩缩容十需要处理所有数据(一致性hash方案)

分区无法灵活调整

超大分区问题

比如user id为1的用户是超大用户,海量记录

二、Cassandra的数据模型

1、Partition key Clustering key

分区键,partition key

聚类键,clustering key

非主键列,属性列

对于分区键和聚类键都是可以有很多个的,除了主键之外,还有一个属性列,或者叫非主键列,它存储一些数据,但是不参与数据的排序。

联合主键与前缀匹配

分区键本身来讲是不参与排序的,因为当我们进行hash排序的时候,分区键在整个的表里面是随机分布的。

多个key的排序

查询:前缀匹配原则

匹配中断:跳列,范围查询

扫描范围与filter

面向应用的反范式化建模|学习笔记

逻辑分区:一组具有相同前缀的行

面向应用的反范式化建模|学习笔记

分区键值域可能非常大,比(如long),分区键的每一个值都代表了一个分区

分区的数量可能会非常大

分区的本质,一组具有相同前缀的行,前缀即分区间的值

所有的分区都是逻辑分区

线性扩展

三、范式与反范式设计

1、范式与反范式化

范式化

目的:

(1)降低数据冗余度

(2)增加数据的完整性

(3)通常用于关系型数据库的设计

反范式化

(1)增加冗余度,用空间换时间

(2)数据在多个地方都有,存在一致性问题

例子:

面向应用的反范式化建模|学习笔记

反范式化

优点:

多个表的数据统一到1张表里

Join不是必须的,(大部分nosql也不支持join),查询更高效

查询简洁清晰,易维护

提高问题调查效率

缺点:

冗余,储存空间开销增加

2、原则

(1)根据读写模式来设计表,设计主键

(2)使用分区键来规划数据分布,一次查询需要的数据,尽可能在一个分区里

(3)使用聚类键来保证数据在分区内的唯一性,并控制结果集中的数据的排序

(4)使用非主键列来记录额外信息

(5)反范式化设计将原本需要通过join得到的数据都包含进来

3、物流详情

场景描述:

电商物流订单,每个订单会经历多轮中转,最后到达用户手中,每一次中转会产生一个事件,比如已揽收、装车、到达xx中转站、派送中、已签收。

需要记录全网所有物流订单的状态变化,为用户提供订变更记录的查询能力。

订单数据量极大,可能有上百亿体量,不能影响读写性能。

场景抽象:

写:记录一个订单的一次状态变更。

读:读取一个订单,最近n条记录;读取一个订单的全部记录。

面向应用的反范式化建模|学习笔记

4、物流详情:高表设计

面向应用的反范式化建模|学习笔记

高表设计:

一行描述一个订单的一个事件

一个订单的所有数据由连续性的一组行来描述

优缺点:

单个分区键下的key数量可以很多

过多的数据将导致髋分区的产生,应避免

无论数据量多大,单次next()的RT可控:流式ResultSet

5、物流详情:宽表设计(不推荐)

面向应用的反范式化建模|学习笔记

宽表设计:

(1)用一行来描述一个订单的所有事件,每一列是一个事件,用事件的发生事件做列名

(2)也可将所有世界encode到一个列里

优缺点:

(1)单行独

(2)无法预知列名,列数量,每一行的列都可能不一样 强依赖schema free能力

(3)只能读所有数据,不容易实现top N读取

(4)超大行风险:单各行的列特别多

6、时序类:监控系统

面向应用的反范式化建模|学习笔记

7、分区键:只使用metric

面向应用的反范式化建模|学习笔记

单分区限制所有机器的指标都聚集在一个分区里,被监控的机器可能无限增长,但单机的承受能力不会线性增长

业务侧:识别变量和不变量

CPU指标本身是不变量,即使未来新增指标通常也是低频事件

被监控的机器是变量会不断的增加,可能数量巨大,比如物流订单的数量

8、分区键:metric+host

这种分区键的优点是很好的控制了单分区的数据量,不会出现宽分区单机的所有类别的CPU指标都在一个分区里,并发读写同一个机器的CPU指标,请求都路由给同一台机器,不利于并发。

9、分区键:metric+host+type

这种分区键的优点是同一个机器的不同CPU类别的指标,在不同的分区里,很好的支持并发访问,host和type的顺序,对采用一致性hash的cassandra来说,没有区别。

10、优化:type合并至metric中

面向应用的反范式化建模|学习笔记

上图中Type是可枚举的,可以直接合并至metric中,减少列数可以提高性能,减少开销(数据量较大时体量小的时候看不出来)。

面向应用的反范式化建模|学习笔记

上图中procid是不可枚举的,不可能合并制metric中。

11、数据点位的存储:宽表or高表

面向应用的反范式化建模|学习笔记

高表设计一行储存一个数据点,如上表所示

容易扩展多值监控:如经纬度

宽表设计:行储存某个机器的某个指标的所有点

单行上线

融合设计:一行记录有限个点,如一分钟一小时内采集到的所有点

粒度选择:由指标的采集频率决定,以控制单行的列数

适当的控制行数,可以配合一些内部优化机制

注意:时序的建模的原理很简单,但生产使用时有很多考量因素,各TSDB都有不同的侧重点,应根据业务实际需要,选择合适的模型,没有银弹。

12、常见误区:分页查询

流式ResultSet:

为了避免单次RPC返回过多数据导致RT过高,CQL driver会自动对请求进行拆分。

第一次next()调用会从服务端load n行数据,之后的n- 1 次next只从内存消费数据。

下一次next()会再加载n行数据到客户端,如此往复,直到所有结果集返回。


常见误区:修改主键

场景一,修改主键的schema

不允许,只能重新建表

场景二,修改主键的值,这本身就是错误的说法。

 

上一篇:数据湖大数据处理之Lambda架构|学习笔记


下一篇:JSON的概述|学习笔记