日志表:亿级数据量的日志系统怎么设计?

[数据库技术] 季雨林 2019/9/30 11:18:43

前言

本站多次分享“传感器采集”类需求的关系型数据库表设计。在这类“只增,不删,不改”的特征下:其实数据库应用场景并非仅限于“传感器”。常见系统的日志系统也是这样的业务特征。


首先,这类需求我也是优先提倡大家使用非关系型数据库(NoSQL)

NoSQL数据库举例:HBase,MongoDB等。由于其业务特征的简单,因此关系型数据库用来做这个数据的存储确实有些浪费,加上计算索引等开销带来的写入能力损失,NoSQL确实太适合这类业务了


其次,补充说明下关系型数据库不是不可以。

大部分人的系统,依然还停留在使用单一阶段:使用单一服务器、使用单一数据库、使用单一数据库实例、甚至放在单一的硬盘上等等。所以上来就建议扩展额外的数据库,需要做的工作有些太庞大。所以这时候建议继续使用原有关系型数据库进行实现更为合理。


数据库如何设计?

关系型数据库,数据采集业务特征的设计,我们来个“夺命三问”:

1,主键是否需要?

数据采集业务,查询需求往往特别简单:查看某个目标最新结果,查询某个目标某个时间范围结果

这时候主键真的未必需要,很多人设计关系型数据库,思维定式导致上来就有个主键字段,而且还是默认的聚集索引列。显然这时候需要思考一下了。毕竟数据采集场景下,不需要删除,不需要修改。

回想下主键的用途:唯一识别。那么唯一识别的目的在于什么呢?删除和修改为主,当然也有查询,但是在于数据采集需求下,查询需要用主键吗?

2,查询条件是否明确?

前文提到,数据采集业务的查询需求往往特别明确:查看某个目标最新结果,查询某个目标某个时间范围结果

既然这样,一个联合索引“时间+标识Id”的用途显然远大于主键用途,有了这个联合聚集索引,查询需求也就完全解决了

3,数据量太大怎么办?

有了前两步的决策,我们的表结构已经是:无主键+有联合聚集索引的架构设计了,接下来要考虑的是容量问题。只有把解决了容量问题也解决了,最终设计的亿级表才能有效投入使用,成功解决掉文章标题的问题。

数据库表扩容方案一般这么几个:表分区,分表,分库,分服务器


重点:数据库扩容方案

表分区:

优势是对外依然以单表的表现方式,可以不用修改代码!适合DBA等数据库知识丰富的人使用

不足是依然属于单数据库实例下,扩容能力特别依赖服务器硬盘大小!


分表:

一模一样的表结构,仅仅是表名不同。优势是开发人员很容易理解,因此适合开发人员选取,这一优势使得这个方案是大部分小企业里的首选方案。

缺点也是依然局限在单数据库实例下,扩容能力特别依赖服务器硬盘大小!

另外缺点是查询逻辑的改动会比较多,需要编码将多个表的返回结果进行整合


分库:

既然可以分表,那么在高一层来看,那就一定可以考虑分库

分表和分库对于开发人员都是比较容易理解的,分表是相同结构下同库不同表,分库是相同结构下的同表不同库。分库之后不能再像分表那样可以使用Union的sql语法来合并结果集,虽然可以考虑链接服务器,但是不建议继续在分库架构下使用分表架构的方案。

分库比分表多了个优势就是可以跨数据库实例。因此容量也就可以突破单机硬盘限制,可以配合内网多服务器实现容量“大幅提升”

分库也有缺点,就是分库太多带来的“内网连接”错综复杂。因此选用这个方案的人需要“网络知识”相对丰富,建议请教下网络管理或者系统运维人员的建议。尤其是多个系统需要读取同一个表的情况下,需要注意跨VLAN等问题


分服务器:

首先需要区分解释下不同的理解:分库这种方案也算是分服务器。优缺点同分库

接下来说下“云数据库”方式的分服务器:参考下阿里云分布式云数据库DRDS产品。数据库对外表现只有一个连接,看起来像是一个库,但是在表设计,使用等环节,有了不一样的要求。符合这些要求,就可以轻松使用“分布式云数据库”来更容易的解决容量问题。

公司自己搭建一套云数据库不大现实,所以一般未上云的用户使用到内网多台数据库服务器就可以了



附录:以前写过的两篇相似主题文章

《分享一个我用过的压测SqlServer写入能力的方法代码》

《mysql,sqlserver数据库单表数据过大的处理方式》


原文地址: https://www.opengps.cn/Blog/View.aspx?id=470 文章的更新编辑依此链接为准。欢迎关注源站原创文章!

评论

暂无评论!

发表评论:

用于接收作者回复信息
点击更换验证码 - openGPS提示

广告区

京东


鲁ICP备14008001号-2