加载中…

加载中...

个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,757,653
  • 关注人气:6,006
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

企业级PAAS平台-数据库资源池

(2012-03-03 19:19:47)
标签:

paas

daas

数据库即服务

分类: 随笔文章
对PAAS平台层的能力,比较核心的有两个,一个是数据库资源池,一个是中间件资源池,其达到的目标是相同的,即让数据库资源和中间件资源对应用系统来说变化为黑盒,实现集中化的资源分配和管理监控,实现数据库和中间件资源的弹性扩展。在这里DAAS个人有两个方面的理解,一个是数据库即服务,一个是数据即服务,前者的重点是数据库各种管理操作转化为服务提供,后面一种则更加强调的数据的访问和存储操作以服务的方式提供。

对于数据库即服务,可以看做是数据库管理即服务,比如用户提出申请,最终可以返回一个可用的数据库实例SID给用户,至于数据库创建在哪里,资源是如何分配的用户不用关系。那到数据库SID后,可以很方便的进行后续的数据即服务操作。而对于数据即服务可以看做是对数据访问和数据CRUD操作的进一步封装,类似于传统构建应用系统时候的DAL数据访问层的封装。所有的业务系统开发都遵循相同的数据访问和操作接口。

在IAAS层的时候我们实现了物理资源的集中化,但是物理资源最终还是承载的应用,这就要求我们更多的去考虑承载应用的逻辑资源的集中化。而数据库资源池可以讲重点是解决数据库的集中和统一的问题。而对于数据库的集中化本身有包括了两个方面的重要内容。其一是访问集中,其二是数据集中。

访问集中重点是构建统一的数据库访问层和标准的数据访问API框架,但是底层仍然可能有多个数据库,数据库本身也可能是异构的多种数据库。对于数据集中即对于关系型和非关系型各自采用一个完全集中化的数据库。不再存在以往业务系统构建过程中出现了跨数据库的数据交换和数据集成。对于访问集中可以看到通过对底层数据库的封装和适配是比较容易实现的。对于数据集中关系型数据库和非关系型数据库各自又有不同的实现。

关系型数据库的集中必然带来数据库本身的水平扩展能力的要求,对于Oracle数据库我们看到有RAC集群方面的支持。对于MySQL数据库现在也有Cluster的方案,而对于MySQL数据库的集群本身又包括了两种实现模式,一种是基于NDB的存储引擎的完全双向同步和数据表的分片,而对于innodb引擎通过单向复制实现的读写分离仍然可以实现数据库的扩展性要求。下面对数据分片和读写分离两种模式再做一个说明:

数据分片包括了对数据表数据的水平切分和纵向切分,但是一般较难以实现同时存在两个切分。数据切片类似于hash区分,通过应用架构来解决数据路由和数据合并的问题。数据分片有很强的水平扩展性而且基本可以保持线性扩展,而且由于采用多副本技术,完全可以解决单节点故障的问题。但是数据分片模式下往往是降低了数据库查询的性能,特别是对于一些复杂的多表查询往往都需要跨多个物理数据库节点进行路由和合并。而对于NDB的MySQL集群基于内存数据库,对于数据库内存要求很大,大数据量的查询往往是重要瓶颈。

读写分离是另外一种现在常用的数据库集群和扩展性的解决方案。读写分离分为master和slave节点,在master写入数据后通过数据复制技术实现快速的数据复制操作到slave节点。对于多个slave节点完全保持和master节点的准实时一致性,于多个slave节点可以形成数据库的读集群,也可以架构在四层交换机之上实现负载均衡。

对于NoSQL数据库本身就有很强的水平扩展能力,但是现在企业信息化应用中能够采用NoSQL数据库的场景并不是很多,特别是对于有很强的数据关系和事务要求的场景,往往很难通过NoSQL数据库来实现。我一直在考虑的一个问题是基于NoSQL数据库的系统分析和设计和原有的基于关系型数据库的分析和设计有很大的区别。基于NoSQL数据库分析和设计更加要求有面向对象分析和设计意识,包括最近分析的对于DDD领域驱动设计的分析设计思路更加适合基于NoSQL数据库的系统构建。

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有