请点击输入图片描述(最多18字)
经常混迹于技术社区,频繁看到这个题目,今天干脆在自己博客重复一遍解决办法:
针对mysql,sqlserver等关系型数据库单表数据过大的处理方式
如果不是阿里云的分布式数据库 DRDS 那种多机器集群方案的话: 先考虑表分区 ;然后考虑分表 ;然后考虑分库。
这个题目是我所经历过的,我做的是GPS应用,早期版本就是选用的关系型数据库Sql Server。当时我选取的方案就是第一种:表分区。 表分区的优势是,如果表结构合理,可以不涉及到程序修改。也就是说,对程序来讲依然是单表读写的效果!
所有轨迹数据存入到一个巨大的表里。有多大呢?
最大存储量超过10亿行。具体数值应该是12亿多点,由于系统设计为只存储30天轨迹,所以线上期间最大存储只到这个数,再后来采用云架构,上云替换成非关系性数据库,获得了更高的写入性能和存储压缩能力。 每日写入量就超过1500万行。上下班交通高峰时候每秒写入量平均超过500行。也就是500iops,距离系统设计的压测指标3000还有一大截这张大型单表设计要点:(一个聚集索引用于写入,一个联合索引用于查询,没有主键,使用表分区)
明确主键用途:
真的需要查询单行数据时候才需要主键!
我采用无主键设计,用于避免写入时候浪费维护插入数据的性能。最早使用聚集的类似自增的id主键,压测写入超过5亿行的时候,写入性能缩减一半
准确适用聚集:
写入的数据在硬盘物理顺序上是追加,而不是插入!
我把时间戳字段设置为聚集索引,用于聚集写入目的设计。保证硬盘上的物理写入顺序,不浪费性能用于插入数据
职责足够单一:
用于精准索引!
使用时间+设备联合索引,保证这张表只有一个查询用途。保证系统只有一种查询目的:按照设备号,查询一个时间段的数据。
精确的表分区:
要求查询时候限定最大量或者最大取值范围!
按天进行表分区,实现大数据量下的高效查询。这里是本文重点,按照聚集索引进行,可以让目标数据局限在更小的范围进行,虽然单表数据上亿,但是查询基本上只在某一天的的几千万里进行索引查询
每张表会有各自的特点,不可生搬硬套,总结下我这张表的特点:
只增,不删,不改!
关于不删除中:每天使用作业删除超过30天的那个分区数据除外,因为要清空旧的表分区,腾出新的表分区!
只有一个业务查询:只按照设备编码查询某个时间段
只有一个运维删除:删除旧的分区数据
这张表,是我技术生涯中进步的一个大阶梯,让我我体会到了系统架构的意义。
虽然我的这张举行表看似只有4个关键点,但是这四个非常精准的关键点设计,耗费了我一个月之久!正是这么足够精准的表结构设计,才撑起了后来压测并发量超过3000的并发写入量!压测的指标跟数据库所在的硬盘有直接关系,当时选取的硬盘是4块10000转的SAS盘做了Raid10的环境
关于后来为什么没有更高的实际应用数值,是因为系统后来改版为云架构,使用了阿里云,更改为写入性能更高的非关系型数
10亿级别的什么数据?如果是 关系型很强,而且数据很值钱的数据, 例如 顾客--交易--商品--金额 一个系列的, 那么这种很重要的数据,建议是 Oracle, 因为 数据丢不起啊。如果是 关系型强, 但是数据不是很值钱的数据, 例如 A股 从开市以来, 所有股票的 每日,每小时,30分,15分,5分 钟的行情数据。 那么你可以使用 Mysql。 反正丢了就重新导入一次。如果是 关系型不强, 数据也不是很值钱的数据, 例如 论坛的帖子 这一类的, 那么用 mongodb 就更合适一些。10亿级流数据交互查询,为什么抛弃MySQL选择VoltDB在老版本的MySQL 3.22中,MySQL的单表限大小为4GB,当时的MySQL的存储引擎还是ISAM存储引擎。但是,当出现MyISAM存储引擎之后,也就是从MySQL 3.23开始,MySQL单表最大限制就已经扩大到了64PB了(官方文档显示)。也就是说,从目前的技术环境来看,MySQL数据库的MyISAM存储 引擎单表大小限制已经不是有MySQL数据库本身来决定,而是由所在主机的OS上面的文件系统来决定了。
而MySQL另外一个最流行的存储引擎之一Innodb存储数据的策略是分为两种的,一种是共享表空间存储方式,还有一种是独享表空间存储方式。
当使用共享表空间存储方式的时候,Innodb的所有数据保存在一个单独的表空间里面,而这个表空间可以由很多个文件组成,一个表可以跨多个文件存在,所 以其大小限制不再是文件大小的限制,而是其自身的限制。从Innodb的官方文档中可以看到,其表空间的最大限制为64TB,也就是说,Innodb的单 表限制基本上也在64TB左右了,当然这个大小是包括这个表的所有索引等其他相关数据。
而当使用独享表空间来存放Innodb的表的时候,每个表的数据以一个单独的文件来存放,这个时候的单表限制,又变成文件系统的大小限制了。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)