应用开发中的存储架构进化史——从起步到起飞
2021-09-27 09:40
555 查看
按楼主的经验和知识,本文总结了应用开发中的各种存储架构,从易到难,从起步到起飞。如有不对之处,欢迎留言。
1、单库
最简单的初始架构,适用于千万级以下的数据,并发量低的场景。
- 单库、单表
- 或单库、多个分表:之所以分表是为了给后续分库做预留准备
2、分库分表、读写分离
最常见的存储架构,适用于十亿级别以下的数据(单表控制在千万级别或以下),并发量较大、主备高可用的场景。
- 分库分表:对业务id(如用户id、商户id)取模,散列到各个分库的分表中
- 读写分离:适用于读多写少的场景,利用数据库一主多从的方式,提高并发量,对主库读写,对从库只读
此时还需要分片中间件来实现对分库分表的读写分离访问,有2种类型:
- client侧分片:较为常见,以jar包库的方式内嵌在服务中,需要与所有的数据库实例,各自建立和维护连接池,性能好
- proxy侧分片:proxy是一个数据库访问中间层服务,应用与proxy建立少量连接,proxy与所有的数据库实例建立连接,优点是对应用开发简单透明,缺点是有性能损耗、需要专门的团队维护
client侧分片
proxy侧分片
3、引入缓存
高并发标配,当QPS高到只靠mysql扛不住流量时引入,适用于高并发、流量尖峰的场景
- 本地缓存(堆内缓存、或堆外缓存):如caffeine、ehcache、guava等
- 分布式缓存:如Redis集群
缓存查询:先查本地缓存,如果查不到再查Redis并写入本地缓存和Redis,如果Redis也查不到再查数据库并写入本地缓存和Redis 缓存更新:数据库更新后,触发变更消息,通过消息驱动更新Redis
4、冷热数据分离
引入多级存储,保证热数据量可控、读写迅速,冷数据全量储存,适用于数据量巨大、增长迅速,且分库分表已经不能解决的场景。
- MySQL热数据:优先读写mysql,预期能覆盖绝大部分QPS
- Hbase冷数据:从mysql查询不到数据时,才查询hbase,hbase可支持海量数据的存储和查询,预期只有少量QPS
- 归档:定期把数据从mysql归档至hbase,mysql只保留最新的热数据,hbase存储全量数据
5、引入搜索引擎、离线查询
适用于复杂条件的查询、或对运营类统计有需求的场景,此时mysql索引已不能满足高效查询,且会影响在线业务。
- 引入ElasticSearch:可支持各种条件的灵活查询,再也不用担心mysql因为缺少合适索引而造成慢查询的问题了
- 大数据分析:引入hive数仓做离线查询,需要把mysql的数据同步至hive
最终架构图
从单库,逐步演化成各种存储紧密配合,满足不同的需求和场景。切勿为了架构而架构,选择适合自己的、能解决实际问题的架构,才最重要。
相关文章推荐
- 从架构设计到系统实施-基于.NET 3.0的全新企业应用之开发Vista边栏应用
- 想换个工作 Windows 8 应用市场开发,培训,架构或者咨询类的都行
- VC6.0上基于MFC的应用开发软件架构3
- Android-应用开发-数据存储和界面展现(三)
- iOS开发UI篇—ios应用数据存储方式(归档)
- Android应用开发SharedPreferences存储数据的使用方法
- 【Android存储权限问题】AS开发的应用,manifest配置了读写SD卡权限,安装却无法创建文件夹
- Android应用开发基础之二:数据存储和界面展现(二)
- 纪念日:服务构件环境(SCE)挑起企业级架构的栋梁,下一代的应用开发模式日渐清晰
- SSH架构的应用开发—部署SSH(一)
- SQL SERVER数据库开发之存储过程应用---[Microsoft Sql Server 2005]
- 安卓开发 第八篇 我的安卓应用架构设计-----图片选择以及剪裁
- 用MVP架构开发Android应用
- iOS开发UI篇—ios应用数据存储方式(XML属性列表-plist)
- 大前端时代,浅谈JavaScript开发重型跨平台应用以及架构
- (转)创新性应用-使用脚本加速DB2存储过程的开发-常红平
- ASP存储过程开发应用详解第1/2页
- Android应用开发SharedPreferences存储数据的使用方法
- 大前端时代,浅谈JavaScript开发重型跨平台应用以及架构
- iOS开发UI篇—ios应用数据存储方式(XML属性列表-plist)