肇庆制作企业网站,网站长期建设运营计划书,网站建设div ass,模板建站优缺点前言
为了保证有一个更健康的身体#xff0c;所以慢慢降低了更新频率#xff0c;在有了更多休息时间的前提下#xff0c;思考了一下接下来准备分享的一些内容。
决定在更新一些技术干货的同时#xff0c;会穿插一些架构知识#xff0c;放在单独的专栏里面#xff0c;希…前言
为了保证有一个更健康的身体所以慢慢降低了更新频率在有了更多休息时间的前提下思考了一下接下来准备分享的一些内容。
决定在更新一些技术干货的同时会穿插一些架构知识放在单独的专栏里面希望大家能喜欢里面包含了这些年工作中遇到的一些内容以及自己充电后总结的一些知识希望大家会喜欢。
标题做了较为详细的划分大家不必一次看完以免视觉疲劳。
场景
本篇分享以前在广州一家互联网公司工作时遇到的状况及解决方案这家公司有一个项目是SOA的架构这个架构那几年是很流行的哪怕是现在我依然认为这个理念在当时比较先进。
我在这家公司待的时间不长但因为平台不错确实学习和实践了一点东西所以整理一下分享给大家。
当时的项目背景大概是这样这家公司用的是某软提供的方案这公司贼喜欢提供方案且要钱多忍不住吐槽哈项目已经运行3年多整体稳定。 数据库是MySQL订单表的数据量已经达到3000多万条记录并且随着项目的推广最近那一年订单表数据量也在快速增长。 结果就是客户方查询订单相关的业务时速度越来越慢后期不论打开还是刷新都差不多要七八秒。 可以说已经严重影响了客户体验降低了对方日常办事的效率要求我们尽快解决且敦促我们这是一件优先级非常高的事情。
在客户和公司领导的双重压力下如何快速优化几千万数据的订单表对于当时的团队着实是一个难题摆在面前。
我依稀记得自己当时还比较青涩更多的是一个听众不敢参与深入讨论哈哈。
整体方案
首先常规方案能想到的无非是这些增加合理的数据库索引、优化核心SQL语句、优化代码等。
我这里可以告诉大家一般的IT公司但凡团队Leader是个有经验的人这些基础方案都是会提前做的会对项目上线后可能遇到的瓶颈有个基本的评估因为真正运营周期变长以后数据量逐渐增多修改生产库是一种风险操作。 我不知道大家有没有过给某个生产库数据量比较大的表添加字段或索引的经历而且是在白天上班操作或者说你自己见过别人这么干我只能说……这些都是狠人要对其常怀敬畏之心。 我目前所在的公司就比较规范研发人员建表时一定要提交申请走流程且附带合理的索引一起提交审核最终通过了才能由主管审核执行。
至于这种流程怎么走其实工具挺多我这里就提一个用过的开源项目Yearning大家可以自己去了解下。 话题扯回来正因前面所讲在当前的问题下这些基础方案实际上已经存在在这里显然是用不上了加上紧急问题紧急处理没有那么多时间给你去对既有架构大动干戈。 因此当时立马能想到且有效的临时性方案迅速在团队讨论中率先冒出来就是数据库分区。
1、数据库分区
理解数据库分区只需要记住以下两点
数据库分区是把一张表的数据分在了不同的硬盘上但仍是一张表说硬盘可能不完全准确但就这样理解是最容易的。不要把数据库分区和分库分表混淆一个是数据库级别的操作一个是代理工具的操作前者限制较多后者更灵活。
知道这两点其实就足够了数据库分区和分库分表也是面试中喜欢问的因为确实有一些类似的地方。
好了有了基本认识那接下来就说下数据库分区如何操作的先看个图有个画面。 接着举个示例我们假设有一张订单表那么对这张订单表按照年份进行分区的命令如下
-- 创建订单表
CREATE TABLE orders (id INT PRIMARY KEY AUTO_INCREMENT,order_number VARCHAR(20),order_date DATE,customer_id INT,total_amount DECIMAL(10, 2)
);-- 按照年份对订单表进行分区
ALTER TABLE orders
PARTITION BY RANGE(YEAR(order_date)) (PARTITION p2018 VALUES LESS THAN (2019),PARTITION p2019 VALUES LESS THAN (2020),PARTITION p2020 VALUES LESS THAN (2021),PARTITION p2021 VALUES LESS THAN (2022),PARTITION p2022 VALUES LESS THAN (2023),PARTITION p2023 VALUES LESS THAN (2024)
);这样一来数据库就会将这张表的数据按照YEAR(order_date)的值分别存在 p2018 ~ p2023 这6个分区中。
如果结合本篇的问题3000多万条记录那么按照年份分区大概一个分区是1000万记录左右然后可以优化查询语句只去扫描特定的分区是不是一下就轻松了很多。
再深入点按照年份一个分区1000万还是有点多了我们是不是可以找到一个更合理的分区字段让每个分区的数据更少呢
这里就要结合实际业务了没有真正的通用方案。
你要先明确一点做分区的目的最终是为了让某个业务环节的查询更快就比如本篇这里主要是为了让客户查询订单相关业务更快那么你就要先把这块的查询语句摘取出来分析一下里面的where条件有哪些。 比如客户要查询某个或某些状态的订单可能会这样写where order_status in (?) 比如客户要查询某个特定群体的订单可能会这样写where user_flag_id ? 比如客户要查询某个或多个业务类型的订单可能会这样写where order_type in (?)
甚至还可能有其他的组合条件掺杂进来你千万别以为你去的每个公司都把表设计的很漂亮很合理我这么多年工作下来真见过不少奇葩设计订单表里面能给你塞上openId或者某些单纯为了方便而加的冗余字段完全把订单表自身的功能性打碎。 这个时候如果分区字段本身存在且刚好能把分区数据分的很合理有利于查询比如前面按照年份划分每个分区如果只有两三百万记录再结合本身的索引查询就会很快那么一切安好搞完收工。 但如果分区字段很难定位就像上面讲的一些主要SQL语句的where条件并不包含相同的字段那就头大了。 而且MySQL还有一个需要注意的点就是它的分区本身是有限制的。 MySQL分区字段必须是唯一索引的一部分。 也就是说如果没有其他能用的唯一索引我们只能结合主键ID和分区字段组成复合主键才行。
这就更难了纯粹看这表长什么样了。
话到这里其实大家也看出来了数据库分区的优缺点很明显。 优点遇到合适的场景优化起来就是一个命令的事情。 缺点限制太多稍微复杂一点的场景你就很难定位分区字段。 那么真的就没法分了吗其实还有一个迂回的方案。
2、迂回方案
我们可以在表中新增一个专门为了分区而量身定做的字段比如archive_flag表示一种数据归档状态当值为1时表示已归档值为0时表示未归档。
这个字段可以没有业务意义但一定要有分区意义。 我们可以把半年内的数据刷成 archive_flag0半年以外的数据刷成 archive_flag1。 接下来我们按照归档状态进行分区即可半年内的活跃数据是一个分区其他非活跃数据是一个分区。 最后只需要把核心的查询语句where条件中都新增一个 archive_flag0 就可以了这样就会扫描这个非归档状态的分区也就是活跃数据的分区。 试想一下这个分区只有半年的记录按照本篇的场景最多也就是500万了结合自身表索引已经完全可以解决当前存在的问题。
好了这个迂回方案其实挺不错的但一定有人会有疑问。
1、加字段真的好吗
2、为什么一定要半年内的数据
首先解答第一个问题答案是不好在我这里的话甚至可以说非常不好几千万数据量的表为了解决一个查询问题刻意新增一个没有实际意义的字段是舍本逐末的行为如果除了这张表还有其他表也有类似问题难道每个都要加字段吗显然是不可行也是不安全的。
第二个问题半年内的数据完全可以结合实际业务做修改。
举个简单的例子你如果经常逛京东商城购物一定会打开我的订单看看实际上给你展示的就是近3个月的订单你可以理解成这就是非归档的活跃数据。
当你想查询以前的记录时就会给你一个链接叫历史记录点击后跳转到历史记录列表或者通过其他方式如下拉框让你选择其他更早时间的订单数据这种其实就是已经归档的数据。
这些数据一般不会直接从业务表里查出来而是从其他归档表或者非关系型数据库如mongodb、EasticSearch等查询出来。 这种方式就类似做了分区把你经常访问的数据和访问频率较低的数据分布存储达到一个数据分离的目的。 这样你就懂了数据分区大体就是这样的思考方式。
现在回过头来想想前面说的优缺点数据库分区真的合适吗 实际情况下很少有情况合适主要原因还是前面讲过的限制真的太多了而业务往往又是复杂的。 另外数据库分区对于很多程序员来说其实是陌生的在中小企业更是如此有这样的现实摆在面前加上短期内就要解决问题随便使用的话对于团队来讲也是一种风险。 所以另一种更合理的方案也就呼之欲出了数据的冷热分离。
3、冷热分离
前面讲了那么多其实就是为了过渡到这里来上面的迂回方案或多或少已经摸到了冷热分离的边缘主要是为了让大家知其然并知其所以然。
1、基本概念
冷热分离听起来很高端其实本质很简单就是把活跃数据和非活跃数据区分开一热一冷频率高的查询只操作热数据频率低的只操作冷数据。 2、存储方案
既然要分离就要考虑清楚热数据和冷数据分别放在哪里。
这里我提供两种选择 中小企业我推荐依然用MySQL。 一来是不需要额外成本降本增效哈哈二来是中小企业相对大厂业务复杂度低一点且数据量小很多那么此时完全可以用MySQL新增一张表来存储某个业务的冷数据比如订单。
如果需要冷热分离的业务较多也可以建一个单独的冷库来专门存放冷数据不过这种我也不太推荐因为涉及到跨库查询增加了维护难度咱们程序员尽量对自己好一点哈。
一个项目里面其实两三张冷表的出现已经可以处理核心业务数据冷热分离的问题了如果真有那么多大数据的表我觉得要从其他方面找问题了一些老项目设计上本身有问题那是真的没好办法。 大厂推荐HBase。 大厂的资源较多平台较大冷热分离不单是解决这种问题的唯一方案但大厂比较推荐更合适的数据库来存储这样的冷数据。
其中HBase是我从各种资料中见过的最多的一种当然也有其他的但HBase应该是里面最受欢迎的一类。
当然我个人是没有大厂经验的我只能把我掌握到的讯息告诉你们。
如果有兴趣的话可以去学习下HBase它是一种在 Hadoop 上构建的分布式、可扩展的列式数据库。
它最大的优势就是快速读写海量数据且具有强一致性。
一般大厂对于冷数据的处理往往都是因为冷数据在业务中也有相当的查询体量如果太慢也不符合大厂维护项目的标准所以有必要专门优化。
好了这里之所以提到HBase主要是为了扩充大家的知识面其实中小企业的工程师也没啥必要特地去学依靠自身兴趣驱动即可。
3、区分冷热数据
既然要冷热分离那么一张表中如何区分哪些是热数据哪些是冷数据 要分析这张表的字段特征拿订单表举例马上能想到的就是订单状态、创建时间。 订单状态的话其实也类似于前面数据库分区提过的归档状态你可以将状态是已完成的数据归类为冷数据而待处理、处理中的都归类为热数据这个要视你们自己的业务决定。
创建时间的话就比较常见了也是我推荐中小企业使用的方法因为几乎所有的核心业务表都一定会有创建时间这个字段我们可以把查询频繁的时间区间的数据归类为热数据其他时间都归类为冷数据。
比如本篇我讲的案例当时我们公司就是半年内的数据是查询非常频繁的因此直接按照最近半年作为区分冷热数据的规则。
4、如何冷热分离
这里有四种方案
代码中处理 这个很好理解比如订单表中当状态从处理中改为已完成时你就可以将这条记录归类为冷数据放到冷表或冷库中。 优点是很灵活而且实时性高。 缺点是相关的代码位置你都要做修改另外如果是按照时间做冷热分离这个方案基本就不可取。 你想想你怎么判断呢我们按照半年内的数据作为热数据那么你在哪个方法哪个事件触发时将这笔订单归类为冷数据可以说做不到。 任务调度处理 这种就是定时任务去扫描数据库比如xxl-job新建一个调度任务定时去扫描数据库判断哪些是冷数据然后归档到冷表或冷库中去。 这种的优点一来是不用大量修改代码二来就是非常适合按照时间划分冷热数据的场景。因为它是一种延迟处理方式你可以设置为半夜去运行。 比如我之前的那家公司就是设置为凌晨以后执行因为那个时候很少有用户在使用了没有什么新的订单产生哪怕有新的订单也属于误差范围内可以接受。 监听binlog 这种方案我是从书本上获取到的给我涨了点知识。 监听binlog的目的说白了就是判断订单状态是否变化和代码中处理很类似唯一的区别在于如果你维护的这个项目又老又复杂代码很难改也改不全监听binlog就是很好的方案了你可以不改代码监听数据库变更日志然后做相应处理即可。 当然缺点和前面一样当按照时间来划分冷热数据时这种方案也不可取因为你不知道如何监听。 人工迁移 冷热分离操作的最终还是数据分离实质上也就是一种数据迁移因此人工干预其实是很靠谱的选择。 上面每种方案都有自己的优势但也有各自的局限性。 代码处理你只能处理发布上线以后的新数据。 任务调度当数据量庞大的情况下你一次可能根本无法完成分离对于紧急的要快速优化的场景显然不适合。 监听binlog除了前面提到的缺点还需要工程师对其比较熟悉否则短时间内上手容易带来不确定性。 此时DBA或集成工程师(俗称打杂工程师)的优势就体现出来了备份后抽某天晚上直接把半年以外的数据迁移到冷库即可。 这样不仅简单也避免了其他技术方案可能存在的问题及风险。专业的人做专业的事才是最靠谱的。 4、最终方案
通过上面简述的几种方案我们已经有了较为清晰的认知。 现在我可以告诉大家当初的公司所采用的方案是其中两种方案的结合人工迁移 任务调度。 人工迁移用于一次迁移完成冷数据到冷库任务调度用于对后续新产生的数据进行解耦且延迟的冷热分离。
思维导图大概是这样 基本步骤如下 1、定位冷热分离的规则比如本篇就是按照订单交易完成时间以半年内和半年外作为分离的基准 2、冷数据迁移由公司的DBA或集成工程师对数据进行备份然后在发布当晚将冷数据迁移到冷库中去 3、开发人员新建一个调度任务并实现任务调用的接口专门扫描数据库将超过半年的订单数据通过程序逻辑迁移到冷库保证热数据一直维持在半年内任务可以每天凌晨执行一次或根据自身业务决定调度频率。 这样一来既解决了冷热分离规则的问题不管是什么规则你最终都可以通过人工迁移数据来做到分离。 也解决了时间上的紧迫性你只需要开发一个用于调度的接口不再需要考虑其他任何技术层面的影响时间成倍缩短。 这在中小企业算是比较适合的方案了当初我们在一周内就优化完成了研发工程师用了1天完成调度接口的实现剩下的时间都是集成工程师进行数据迁移的演练。
最终客户还是很满意的核心业务的查询速度一下就提升了近10倍。
优缺点
好了临近尾声我们来说一下冷热分离方案整体的优缺点吧。
1、优点
优点我归纳了3点
1、提高性能
很明显冷热分离后将更多计算资源集中在了热数据上将查询性能最大化。
2、降低成本
对于千万级的数据表冷热分离方案不需要额外的第三方中间件极大地节约了成本。尤其是在中小公司老板对成本还是很在意的。
3、简化维护
冷热分离之后对于数据的维护更直观可以把更多精力放在热数据的处理上。
比如备份策略冷热数据可以分别采用不同的策略维护更关注热数据备份简化冷数据备份。
2、缺点
缺点我归纳了2点
1、场景限制多
冷热分离并不是万能的一定要根据业务来分析查询的复杂度较高很可能你冷热分离后热数据的查询依然没有得到明显优化。 比如你有一张表查询的语句关联很多表数据量也挺大那么这个时候冷热分离一点作用都没有因为你分离完了查询语句还是关联那么多速度依然很慢。 这个时候类似的场景就无法使用冷热分离方案了而是要考虑其他方案比如读写分离比如查询分离这样才能从根源上解决查询慢的问题。
2、统计效率低
这种也是冷热分离方案比较明显的一个缺点当你们的业务中需要对数据做一些复杂的统计分析甚至要求一定的实时性。
那么这个时候因为已经冷热分离冷数据的统计分析效率会非常低对于客户提出的一些五花八门的统计分析就难以操作了。
因此又需要引入其他方案来配合比如ElasticSearch这样又增加了额外的成本不仅要考虑ES的资源成本还要考虑诸如部署方案、维护方案、安全性问题等等。 今年我们内部就公布了一个小道消息某家业内还挺不错的互联网公司因为ElasticSearch的未授权漏洞导致千万用户敏感信息被泄露直接被行业除名了。 所以在实际工作中中间件的引入是个需要审慎考虑的问题而不是你想当然了就可以使用。
总结
通篇写的还是挺长的主要是一开始列出了大纲但在写的过程中又想起了新的知识点就一起加进来了。
前面讲的数据库分区等方案主要是为了过渡因为这是一个线性的思维展现出来让大家知道一个方案最终落地的脉络是怎样的。
今后还会继续写一些架构相关的知识放在单独的专栏里面希望大家支持和喜欢。 如果喜欢请点赞关注↓↓↓持续分享工作经验及各种干货哦
