数据库表数据量大读写缓慢如何优化(1)【冷热分离】 架构设计系列

数据库表数据量大读写缓慢如何优化(1)【冷热分离】

今天讨论的内容是冷热分离,也许概念并不陌生,对其使用场景也比较熟悉,但涉及锁的内容时仍然需要认真思考,这部分内容在我们实际开发中的“坑”还是不少的。业务场景一曾经经历过供应链相关的架构优化,当时平台上有一个订单功能,里面的主表有几千万数据量,加上关联表,数据量达到上亿。这么庞大的数据量,让平台的查询订单变得格外迟缓,查询一次都要二三十秒,而且多点击几次就会出现宕机。比如业务员多次查询时,数据库的CPU会立马狂飙,服务器线程也降不下来。当时,我们尝试了优化表结构、业务代码、索引、SQL语句等.
阅读全文
数据库表数据量大读写缓慢如何优化(2)【查询分离】 架构设计系列

数据库表数据量大读写缓慢如何优化(2)【查询分离】

上一篇聊到过,冷热分离解决方案的性价比高,但它并不是一个最优的方案,仍然存在诸多不足,比如:查询冷数据慢、业务无法再修改冷数据、冷数据多到一定程度系统依旧扛不住,我们如果想把这些问题一一解决掉,可以用另外一种解决方案——查询分离。(注意:查询分离与读写分离还是有区别的。)业务场景二某SaaS客服系统,系统里有一个工单查询功能,工单表中存放了几千万条数据,且查询工单表数据时需要关联十几个子表,每个子表的数据也是超亿条。面对如此庞大的数据量,跟前面的冷热分离一样,每次客户查询数据时几十秒才能返回..
阅读全文
数据库表数据量大读写缓慢如何优化(4)【分库分表】 架构设计系列

数据库表数据量大读写缓慢如何优化(4)【分库分表】

在第二篇文章中说到,查询分离中存在三大不足,其中一个不足就是:当主数据量越来越大,写操作缓慢,遇到这个问题我们该如何解决呢?为此,这篇文章我们主要围绕这个问题来讨论,拆分存储如何进行技术选型?分库分表的实现思路是什么?分库分表存在哪些不足?一、业务场景三为了便于理解,我们通过一个业务场景来入手。有一个电商系统架构优化工作,该系统中包含用户和订单2个主要实体,每个实体涵盖数据量如下表所示:实体数据量增长趋势用户千万级每日10万订单亿级每日百万级,后续可能千万级
阅读全文
本文目录
    Loading...