数据库系列(二)数据库瓶颈
数据库瓶颈,数据量的增加,并发的增加:
1、加强硬件,换商业化软件====》花钱解决
2、架构设计上来解决,让数据库最少的做事,放弃触发器、外键、存储过程、函数
数据库复杂均衡
多要数据库完成一台的事,数据库要保证一致性的
负载均衡:
利用多台服务器的读写能力,但是数据同步和访问分配交给第三方软件
Moebius:
读的压力分配到不同的服务器,写其实是多态服务器都得完成,对外只有一个IP,使用者是不知道细节的。
读写分离
二八原则:数据库中80%操作都是读,只有20%是写。
实现原理:就是把读和写的压力分开,降低IO压力;一主多从,主库写从库读;数据同步的问题,从主库到从库(肯定是有延迟的,网速没问题,两三秒吧)
1、数据库里面列别的数据库?link到主要+定时的job,是不是就可以了?【效率低】
2、日志传送,SQLserver2005,备份----复制----复制,这种方式简单,但是有局限性(局域网,只能文件夹共享)
3、镜像,snapshot:内存拍照;主库,对外提供服务;从库,通过快照回复,数据跟主课一直;监控转移,负责检查状况,有问题切到从库
4、数据复制(发布/订阅)
主库---发布到服务器---从库;延迟小,配置方便,但是需要程序配合。发布订阅后,从数据库是可以水平卓展的,查询就不是大问题。业务量进一步增加,写库还是抗不住===》分库/分区/分表
分库/分表/分区(最考验设计和开发)
多台服务器
分库:
1、系统里面有订单/物流/仓储/论坛/博客/客服
垂直分库,按照业务拆分库,不同的库不同的服务器
2、订单增删改查特别大
水平分库,每个库结构一致,数据不一致(地域/时间/类别/随机算法)
分表
垂直分表:
1、文章表,10个常规字段,还有一个很长很长的内容字段
垂直分表,直接减小表的体积,提升增删改查的效率
2、单表数据量太大(订单表/商品表)
水平分表(地域/时间/类别/随机算法)
分完之后,数据的查询怎么办呢?
拆分的时候要根据产品特点来
房产-----按照城市拆分
订单/流水-----按时间拆分
追求平均----随机算法
抛砖引玉,自己要根据业务特点来拆分,考虑业务,拆分的维度,最好不要再被聚合查询,但是又无法完全避免业务操作。
1、跨库垮表join---很不推荐
2、汇总表,定时任务定时作业====》专门应该特殊要求
3、特殊要求,就是为难你,同步一个报表库(总库),专门满足需求,性能肯定低
4、向业务妥协
表分区:就是水平分表的意思,也可以垂直分(用的少)
付费内容,请联系本人QQ:1002453261
本文来自博客园,作者:明志德道,转载请注明原文链接:https://www.cnblogs.com/for-easy-fast/articles/12483611.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· 在鹅厂做java开发是什么体验
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析