针对mysql,sqlserver等关系型数据库单表数据过大的处理方式
如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话: 先考虑表分区 ;然后考虑分表 ;然后考虑分库。
这个题目是我所经历过的,我的GPS汽车定位系统,早期就是选用的Sql Server数据库。当时我选取的方案就是第一种:表分区。 表分区的优势是,如果表结构合理,可以不涉及到程序修改。也就是说,对程序来讲依然是单表读写的效果!
所有轨迹数据存入到一个巨大的表里。有多大呢?
最大存储量超过10亿行。具体数值应该是12亿多点,由于系统设计为只存储30天轨迹,所以线上期间最大存储只到这个数,再后来采用云架构,上云替换成非关系性数据库,获得了更高的写入性能和存储压缩能力。
每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops,距离系统设计的压测指标3000还有一大截
这张大型单表设计要点:(一个聚集索引用于写入,一个联合索引用于查询,没有主键,使用表分区)
明确主键用途:
真的需要查询单行数据时候才需要主键!
我采用无主键设计,用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键,压测写入超过5亿行的时候,写入性能缩减一半
准确适用聚集:
写入的数据在硬盘物理顺序上是追加,而不是插入!
我把时间戳字段设置为聚集索引,用于聚集写入目的设计。保证硬盘上的物理写入顺序,不浪费