mysql表过大怎么解决 mysql表大小限制( 二 )


所有轨迹数据存入到一个巨大的表里 。有多大呢?
最大存储量超过10亿行 。具体数值应该是12亿多点,由于系统设计为只存储30天轨迹,所以线上期间最大存储只到这个数 , 再后来采用云架构,上云替换成非关系性数据库,获得mysql表过大怎么解决了更高的写入性能和存储压缩能力 。
每日写入量就超过1500万行 。上下班交通高峰时候每秒写入量平均超过500行 。也就是500iops,距离系统设计的压测指标3000还有一大截
这张大型单表设计要点:(一个聚集索引用于写入,一个联合索引用于查询,没有主键,使用表分区)
明确主键用途:
真的需要查询单行数据时候才需要主键mysql表过大怎么解决!
我采用无主键设计,用于避免写入时候浪费维护插入数据的性能 。最早使用聚集的类似自增的id主键 , 压测写入超过5亿行的时候,写入性能缩减一半
准确适用聚集:
写入的数据在硬盘物理顺序上是追加 , 而不是插入!
我把时间戳字段设置为聚集索引,用于聚集写入目的设计 。保证硬盘上的物理写入顺序,不浪费性能用于插入数据
职责足够单一:
用于精准索引!
使用时间+设备联合索引 , 保证这张表只有一个查询用途 。保证系统只有一种查询目的:按照设备号,查询一个时间段的数据 。
精确的表分区:
要求查询时候限定最大量或者最大取值范围!
按天进行表分区,实现大数据量下的高效查询 。这里是本文重点 , 按照聚集索引进行,可以让目标数据局限在更小的范围进行,虽然单表数据上亿,但是查询基本上只在某一天的的几千万里进行索引查询
每张表会有各自的特点,不可生搬硬套,总结下我这张表的特点:
只增,不删,不改!
关于不删除中:每天使用作业删除超过30天的那个分区数据除外,因为要清空旧的表分区 , 腾出新的表分区!
只有一个业务查询:只按照设备编码查询某个时间段
只有一个运维删除:删除旧的分区数据
这张表,是我技术生涯中进步的一个大阶梯,让我我体会到mysql表过大怎么解决了系统架构的意义 。
虽然我的这张举行表看似只有4个关键点 , 但是这四个非常精准的关键点设计,耗费了我一个月之久!正是这么足够精准的表结构设计 , 才撑起了后来压测并发量超过3000的并发写入量!压测的指标跟数据库所在的硬盘有直接关系,当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境
关于后来为什么没有更高的实际应用数值,是因为系统后来改版为云架构 , 使用了阿里云,更改为写入性能更高的非关系型数
mysql表过大怎么解决的介绍就聊到这里吧,感谢你花时间阅读本站内容,更多关于mysql表大小限制、mysql表过大怎么解决的信息别忘了在本站进行查找喔 。

推荐阅读