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

  • 时间:
  • 浏览:0
  • 来源:神彩大发快3_彩神大发快3官方

无缘无故混迹于技术社区,频繁看得人这俩 题目,今天干脆在当事人博客重复一遍出理 办法:

这张表,是我技术生涯中进步的一个大阶梯,你要 我体会到了系统架构的意义。

只增,不删,不改!

每日写入量就超过50万行。上下班交通高峰时候每秒写入量平均超过50行。也后来 50iops,距离系统设计的压测指标50还有一大截

最大存储量超过10亿行。具体数值应该是12亿多点,可能系统设计为只存储50天轨迹,好多好多 有线上期间最大存储只到这俩 数,再后来采用云架构,上云替添加非关系性数据库,获得了更高的写入性能和存储压缩能力。  

只一个业务查询:只按照设备编码查询某个时间段

我采用无主键设计,用于出理 写入时候浪费维护插入数据的性能。最早使用聚集的之类自增的id主键,压测写入超过5亿行的时候,写入性能缩减一半

准确适用聚集:

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

按天进行表分区,实现大数据量下的高效查询。这里是本文重点,按照聚集索引进行,都都能否 让目标数据局限在更小的范围进行,嘴笨 单表数据上亿,为什么我么我让查询基本上只在某一天的的几千万里进行索引查询

所有轨迹数据存入到一个巨大的表里。有多大呢?

精确的表分区:

最后提一句, 好多好多 有人嘴笨 SSD就足够高的性能了,为什么我么我让对于云服务器,ssd的性能才跟传统物理机的iops相持平,这是可能虚拟化层面的损失原因分析的!

职责足够单一: 

使用时间+设备联合索引,保证这张表只一个查询用途。保证系统只有某种查询目的:按照设备号,查询一个时间段的数据。

可能也能 阿里云分布式数据库 DRDS 那种多机器集群方案语录: 先考虑表分区 ;为什么我么我让考虑分表 ;为什么我么我让考虑分库。

这俩 题目是我所经历过的,我做的是GPS应用,早期版本后来 选着 的关系型数据库Sql Server。当时我选着 的方案后来 第某种:表分区。 表分区的优势是,可能表特性合理,都都能否 不涉及到tcp连接修改。也后来 说,对tcp连接来讲依然是单表读写的效果!

要求查询时候限定最极少量可能最大取值范围!

这张大型单表设计要点:(一个聚集索引用于写入,一个联合索引用于查询,没了主键,使用表分区)

我把时间戳字段设置为聚集索引,用于聚集写入目的设计。保证硬盘上的物理写入顺序,不浪费性能用于插入数据

关于不删除中:每天使用作业删除超过50天的那个分区数据除外,可能要清空旧的表分区,腾出新的表分区!

关于后来为那些没了更高的实际应用数值,是可能系统后来改版为云架构,使用了阿里云,更改为写入性能更高的非关系型数据库MongoDB存储轨迹数据。好多好多 有嘴笨 距离压测指标还差很远,为什么我么我让也没了实际跑到这俩 数据!单机应用再为什么我么我么改造,每次升级也能 一件麻烦事,好多好多 有应当尽可能将瓶颈点提高,甚至消除,云架构的意义就在于弹性扩展,嘴笨 我在数据库方面还没了这方面的成功案例可分享,为什么我么我让这俩 架构的意义很明白:将来面对更大的压力,只也能 增加服务器数量!    

每张表会有每所有人的特点,不可生搬硬套,总结下我这张表的特点:

明确主键用途:

针对mysql,sqlserver等关系型数据库单表数据过大的出理 办法

用于精准索引!

只一个运维删除:删除旧的分区数据

真的也能 查询单行数据时候才也能 主键!

嘴笨 我的这张举行表看似只一个关键点,为什么我么我让这俩 个非常精准的关键点设计,耗费了我一个月之久!正是没了足够精准的表特性设计,才撑起了后来压测并发量超过50的并发写入量!压测的指标跟数据库所在的硬盘有直接关系,当时选着 的硬盘是4块500转的SAS盘做了Raid10的环境

写入的数据在硬盘物理顺序上是追加,而也能 插入!