频道栏目
读书频道 > 数据库 > Oracle > 高并发Oracle数据库系统的架构与设计
1.1.2 问题就在那里
2014-11-28 13:43:41     我来说两句
收藏   我要投稿
Foreword?推 荐 序 一文以载道 书以自娱侯松的新书付梓,嘱我为序,品读精华章节,览其前言,心有所感,遂言而记之。关于写作之因由,于作者来说,一直是最为重要的缘起。认真地写作一本好书,其中的坚持、勤  立即去当当网订购
看过冗长的对话,我们来总结一下吧,问题到底出在哪里?
Oracle数据库架构设计之初,粗放设计,没有充分把握细节;
业务数据耦合度过高,无法充分解耦,革命性的变化成本太高,不能接受;
业务逻辑比较厚重,灵活性不高;
可以接受架构创新。
 
以上问题,相信很多架构师和数据库管理员们都会面临。更多时候,我们都是无力去推动业务的,让业务适应技术,一直都是技术人员美好的愿望,却鲜有实现。现实一点地来看,我们只能在一定程度上去引导业务,但不能完全让技术去适应业务,两者需要达到一种平衡。
 
立足于大多数的传统行业,来看一看应用的现状吧。业务逻辑都是经年累月沉淀下来的,要想做出革命性的变化确实很难,除非行业革命。谁能想象一下,让银行去拆分核心逻辑呢?业务看似刁难的要求,也蕴藏着行业的特点,架构师是需要充分认识到这一点的。
 
如图1-1所示,理想情况下的应用系统架构中的子系统应该是相对比较独立的,子系统之间关联较少,而且相互关联的子系统数量相对较少。实际情况往往是大相径庭的,子系统之间存在很高的耦合性。子系统内读写错综复杂,基本上不可能实现读写分离。面对这样的现实,出于成本和风险的考虑,很难做到子系统的解耦,理想情况也只能是理想了。

 
业务子系统与数据库的对应关系,如图1-2所示。在一套完整的数据库生态体系中,子系统和数据库也是无法独立开的。理想情况是若干子系统分布在一个数据库中,数据库基本上是自包含的。现实仍然是残酷的,往往是子系统和数据库出现多对多的关系。
 
那么,数据库架构设计就需要反映这样的业务架构,如图1-3所示。对于某一系列的业务应用来说,是不可能通过单个数据库来实现的。需要的是一个数据库群,其中包含核心库、业务应用库,以及各种功能的库,根据重要性做层级划分。数据库之间实现即时的数据同步,构成一套完整的数据库生态体系。
 
做到这些是不是就解决问题了呢?当然没有,如果解决了,也不会有以上那段对话。但是,这种架构的演化方向是正确的,将错综复杂的业务分为治之,如果某些业务上出现了很高的并发压力,也不会影响到其他业务的应用,还可以将影响面控制在最小范围内。
 
虽然本次在架构建模阶段没有充分考虑到Oracle数据库的细节问题,但是也可以作为一次经验教训,为下次的建模工作提供指导。可喜的是,我们也不必坐以待毙,架构的创新始终都是受欢迎的,因为这意味着数据库的并发处理能力的提升。
 

从技术层面来看待以上的问题,我们可以去做好两件事情:
Oracle数据库架构设计工作细化;
以Oracle数据库为中心,开展架构纵横扩展。
 
您对本文章有什么意见或着疑问吗?请到论坛讨论您的关注和建议是我们前行的参考和动力  
上一篇:1.1.1 从一次谈话说起
下一篇:1.1.3 你不是一个人在战斗
相关文章
图文推荐
排行
热门
最新书评
特别推荐

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 | Vip技术培训 | 举报中心

版权所有: 红黑联盟--致力于做实用的IT技术学习网站