探讨面向可扩展系统关系型数据库架构.doc

探讨面向可扩展系统关系型数据库架构.doc

ID:57890238

大小:67.50 KB

页数:6页

时间:2020-04-02

探讨面向可扩展系统关系型数据库架构.doc_第1页
探讨面向可扩展系统关系型数据库架构.doc_第2页
探讨面向可扩展系统关系型数据库架构.doc_第3页
探讨面向可扩展系统关系型数据库架构.doc_第4页
探讨面向可扩展系统关系型数据库架构.doc_第5页
资源描述:

《探讨面向可扩展系统关系型数据库架构.doc》由会员上传分享,免费在线阅读,更多相关内容在工程资料-天天文库

1、探讨面向可扩展系统的关系型数据库架构几年各种新技术层出不穷,从Hadoop.Spark.Nosql到人工智能、区块链等等,各自都火了一段时间,而关系型数据库则相对比较平静,但我一直觉得关系型数据库依然是很多系统架构设计中非常重要甚至不可获取的组成部分,而且经过了这么多年的发展,关系型数据库技术已经可以做到非常的稳定、可氧一门技术的发展一般都会经历萌芽、发展、应用到淘汰的过程,这个过程中技术的应用范围或者叫普及程度会逐步提升。在互联网时代,_门技术可以很快火起来,但是真正落地到系统架构中是需要逐步发展的。我觉得数据库已经是发展到了大规模应用的阶段,而且还有

2、着旺盛的生命力,用〃大成若缺,其用不弊〃来形容,再合适不过。本文重点关注的是关系型数据库的设计如何才能满足可扩展架构的要求,总结了一些个人认为比较有用的架构方案,供大家参考。隔离关系型数据库非常容易上手,尤其在系统发展的初期,一般一个数据库、几张关系表可以支撑很长的时间,但是随着业务的不断发展,关系越来越复杂,数据量越来越大,就需要在合适的时候进行隔离。隔离的方案有许多种,这里简单介绍几种常见的:•读操作和写操作的隔离(AKF扩展立方体中的X轴扩展):读写分离1=1可以非常有效的提升系统查询的并发量,尤其是多副本的情况下,当然这种方式牺牲的是一定程度的一

3、致性;•事务型数据库与分析型数据库隔离:很多系统中数据库使用的初期只有事务性需求,但是随着业务发展越来越大,数据越来越多,分析型需求不可避免的会出现,须知这两种需求无论是在数据库选型还是表结构的设计都是存在一定冲突的,所以最好进行拆分,通过etl等方式将数据从事物型数据库同步到分析型数据库中;・热数据与冷数据的隔离:〜比较典型的例子是按照时间对数据进行隔离(分区、分片等),最近发生的数据一般是最常用的,而几年之前的数据使用的概率一般很低,这种数据的隔离有利于提升系统各方面的性能。当然按照时间进行隔离只是一个例子,根据业务的不同可以按照不同的方式对热点数据

4、进行隔离;•按照功能或者业务类型进行隔离(AKF扩展立方体中Y轴扩展):比如,建立专门的订单数据库、商品数据库、用户数据库等;・按照客户进行隔离(AKF扩展立方体中Z轴扩展):这是云服务商经常采用的方案,将重要付费客户数据单独存储,其他客户数据一起存储,这样也可以避免大客户的查询等影响了其他客户;•不同应用的隔离:在分布式数据库中,不同产品或者应用如果使用同一个数据库实例,相互之间可能会相互干扰,而且往往很难协调不同应用的优先级等,没有一个资深的DBA也很难管理这种相关干扰,这个时候可以考虑按照应用部署多个数据库实例;・业务处理逻辑与数据库的分离:这里指

5、的是滥用存储过程等场景,存储过程有其好处,但也因为如调试困难、可读性差、业务耦合等不足为系统的可扩展性带来影响,而且存储过程相关代码的维护和可测试性也往往存在一定不足,本着单一职责原则,建议还是将业务处理逻辑与数据库进行分离;性能监控数据库一般都是系统中的核心组件,其监控肯定是必不可少的,除了常规的运维监控项之外,在系统扩展时还需要持续关注数据库的性能参数,常见的性能监控项如下:・性能基线:为系统不同应用场景建立查询性能基线,并持续跟进,防止在系统扩展过程中逐渐变慢等问题,这种温水煮青蛙式的变坏,往往会在积累到_定时间后爆发;事务拆分关系型数据库的一大特

6、点是事务一致性,但是在分布式数据库应用等一些复杂场景下使用事务尤其是分阶段提交的事务需要在系统吞吐量上做非常大的牺牲。弓I用《架构真经》中提供的一个例子,系统中2%的业务使用2阶段提交后,系统整体能处理的事务量下降了75%以上!现在通过消息中心的发布订阅等方式都可以有效的达到最终一致性,有时候牺牲一定的实效性换来的可能是系统整体扩展性上质的飞跃。缓存数据库本身有非常有效的缓存机制,但其本身的缓存方式也存在着一定的局限性,例如,需要经过复杂计算才能得出的数据,数据库本身的缓存一般是不能对其进行缓存的,这时候需要应用自身进行缓存或者在系统架构中为数据库增加专

7、门的缓存层。采用向外扩展,避免一直向上扩展向上扩展指的是通过购买性能更强的硬件来实现对系统扩展的支持,向外扩展指的是通过复制、拆分等方式分散系统的负载。在系统发展的初期通过向上扩展可以快速解决性能瓶颈,而且不需要非常强的技术实力支撑,但这种方式不适合一直应用(当然,如果系统发展速度比硬件更新速度还慢是没问题的),一方面高性能硬件的性价比会下降,另一方面公司业务的发展速度往往很快会达到单机的性能瓶颈,所以向外扩展是不可避免的。慎重评估开源数据库与商业数据库软件开源数据库与商业数据库各有优势,相信大家都是了解的,这里我想要说明的一点是,商业数据库付出的授权费

8、用是看得见的,而开源数据库的学习成本,以及在运维等方面的投入成本,还有业务适配的

当前文档最多预览五页,下载文档查看全文

此文档下载收益归作者所有

当前文档最多预览五页,下载文档查看全文
温馨提示:
1. 部分包含数学公式或PPT动画的文件,查看预览时可能会显示错乱或异常,文件下载后无此问题,请放心下载。
2. 本文档由用户上传,版权归属用户,天天文库负责整理代发布。如果您对本文档版权有争议请及时联系客服。
3. 下载前请仔细阅读文档内容,确认文档内容符合您的需求后进行下载,若出现内容与标题不符可向本站投诉处理。
4. 下载文档时可能由于网络波动等原因无法下载或下载错误,付费完成后未能成功下载的用户请联系客服处理。