本书是阿里云团队组织编写的，书中提到最多的和数据库相关的三个产品分别是RDS，MaxCompute，AnalyticDB
RDS，用于OLTP类业务，采用多个RDS数据库，前端加上DRDS中间层，通过分库分表支撑中大型业务系统。为了解决分库分表过程引入的副作用，又会涉及到数据库表的重新设计和业务流程的设计改造；
AnalyticDB，定位于准实时大数据分析；
MaxCompute，则专注在离线大数据分析；
在线联机交易系统是数据的直接来源，后端通过DTS服务，实时或定期将数据同步到AnalyticDB和MaxCompute，构建出一个同时具备大型联机交易处理能力，又能够进行大数据统计分析的综合应用系统。
互联网产品通常专注于某个垂直细分领域，比如数据库类产品，MySQL最早的定位就是一个单纯保存关系型数据的软件，Mongodb只用于存储文档类数据，Redis则仅用于前端数据缓存。每个产品都专注于解决某一个问题，所以一个完整的解决方案需要很多产品的配合，像是搭积木，需要将不同功能的产品有机组合，形成完整的解决方案。
很多时候架构层也解决不了所有的问题，还需要业务上的配合，架构师要和业务进行密切的沟通，产品上的不足由业务层来弥补，相互之间形成良好的互动。这两年流行DevOps概念，其实就源自这种业务和架构上的沟通越来越频繁，连接也越来越紧密，你中有我我中有你，谁也离不开谁。
所以互联网行业架构师的作用非常重要，他不是专注某一个点，而是从全局的角度去把控。项目的成败，架构师尤其关键。
反观Oracle数据库架构，基于传统的IOE架构，每个层次上的分工非常清晰。以前我们也常在想，为什么在基础架构层中，数据库DBA的职责相对来说比其他管理员要大的多，究其原因就是DBA在传统行业的分工中起到了承上启下的作用，连接了更多的角色。对下需要对接网络、存储，对上有中间件、业务开发人员，所以在传统行业中对DBA的要求很高，出了问题往往是背锅侠。如果不想做背锅侠，就老老实实的去分析问题，找出罪魁祸首。所以很多时候最终的问题定位，都是DBA找出来的，哪怕不是数据库的问题。
由于Oracle数据库功能完善，处理能力强，大多数问题Oracle都提供了解决方案，所以Oracle DBA只需要努力学习好数据库产品就已经能够立足，资深的DBA更多的时候是一种权威的角色出现，因为很多其他层解决不了的问题，能够从Oracle数据库解决；很多其他层收集不到的信息，可以从Oracle数据库中获取到相应的指标；业务层需要花大力气解决的问题，在Oracle数据库中可能通过简单的几条命令即可实现。这个状况一方面导致企业对于Oracle数据库的依赖程度越来越高，另一方面也导致Oracle DBA的视野更多的专注在数据库本身，没有太多业务和运维层没有密切连接的动力，也失去了向其他方向发展的机会。
但这个世界是在高速的发展中，近些年随着互联网、云计算技术的深入发展，传统的IOE架构面临诸多的挑战。
系统处理能力增长难以跟上数据量快速增长
大多基于成熟的商业产品，不能很好的满足定制化的需求
IOE架构不能满足业务系统多变的需求
传统数据库不能满足互联网时代多样化的数据存储需求
部署成本高昂
所以，Oracle的产品也在变化，12C推出了多租户架构，另外还推出了GDS组件，以及数据库Sharing功能。传统的Oracle DBA也需要对架构有所了解，也会逐渐的学会去和应用连接，学会从整体去看问题。或许这将是最后的机会。
网友评论