沃趣科技高级数据库专家 魏兴华
概述
云是当今最为热门的一个话题或者说技术，在数据库界也一样，Oracle 12G这个名字不硬生生被掰弯成了Oracle 12C,数据库云在我看来能给企业带来的第一价值是节省资源，提高服务器资源的利用率，随着更快速CPU、更廉价大内存的出现，企业传统孤岛式的数据库使用方式，一个主机一个实例，会导致大量的资源浪费，想当年在阿里B2B，有多少服务器的CPU利用率平均只有15%，现在都在倡导绿色数据中心，只有数据库整合了，消耗的电少了，空调吹的少了，数据中心才能绿，地球才能绿（人可不能绿????）。在电刚出现的时候，每个富豪家里都得买个发电机装家里，昂贵，噪声大，扰民，还不环保，后来慢慢发展成电网，每一家只需要接入电网就可获取电资源，不用去买发电机，现在的云很大程度上跟这个很像，私有云平台就像电网，用户只需要接入云平台，就可以便捷的获取资源。本篇文章主要讲解如何构建一个Oracle的私有云平台，主要从以下三个方面进行论述：
●数据库整合技术的选择
●资源快速供应
●服务质量管理
在开始阐述这三部分内容之前，有必要带各位客官了解一些数据库的部署现状和相关的基本概念，例如DBaaS是什么？为什么要用Oracle RAC来构建DBaaS。以及Oracle RAC的版本的一个发展历史。【PS：本文都指的是私有云】
DBaaS
当今一些中大型企业有着成百上千的数据库，这些数据库可能有着不同的版本，不同的配置，甚至是在同样的大版本下打着不同小版本补丁，这给企业带来了非常大的成本和负担：管理的成本、运维的成本、人员的成本、机房的成本、数据库软件licence的成本、存储的成本等等，用一句话概括就是TCO的成本非常的大。此外，由于传统的孤岛式的数据库使用方式，也导致了数据库数量的激增和非常糟糕的敏捷性，每上一个业务，就要申请一批设备，一个机柜，一个数据库项目从立项到项目实施完成往往需要几周甚至几个月之久，如下图:
由于非标准化的东西非常多：硬件环境多变、配置多变、架构多变，这给数据库的可用性带来了非常大的风险，由这些风险带来的非计划性的停机也给企业带来了直接或间接的经济损失、企业信誉的损失。由于近些年PC服务型的CPU性能越来越强劲，内存的价格越来越低，企业往往采购的服务器配置相对都较高，而很多企业还采用着一个主机只部署一个实例这种方式，导致了数据库服务器的资源利用率非常的低下。根据GOOGLE的数字，28%的用户平均每年的数据库增长超过20%，50%的用户数据库是没有经过整合的。怎么办？
什么是DBaaS?
以上面临的场景和解决方案就是构建一个企业的DBaaS平台对数据库进行标准化整合，DBaaS 是一个标准化的、弹性可扩展的平台，基于网络访问，通过一系列共享的数据库服务，整合现有应用，以及快速部署新的应用。DBaaS私有云是部署于企业防火墙内的共享的数据库服务。DBaaS一方面用来满足开发、测试、QA的数据库服务要求，通过简单易用的自服务来满足申请数据库，schema等的需求。一方面帮助IT人员、DBA简化了数据库在标准平台上的部署，减少维护工作，更好的支持客户需求，更多的时间和预算用于创新。
RAC发展史概述
对于Oracle公司来说，构建数据库云的重担会落在RAC上，RAC天然具有高可用、可扩展的特性，RAC版本变化与Oracle一样，经历了从I时代到G时代C时代，I是Internet，G是Grid，C是Cloud，可以看出来Oracle的版本非常迎合时代标签，这个G稍微有点悲剧，其实跟云的概念非常像，但是最终Grid还是不敌Cloud包装的好，最终还是得投入了云的怀抱。Oracle 10G，11GR1虽然都以G冠名，但是产品层面其实并没有得力的配套技术，比如截止到11GR2之前，用户使用RAC，客户端还需要在连接描述符里配置多个条目：
Grid的概念类似于电网的概念，作为用户只需要通过像插头这样的工具接入电网即可，不用去知道后面有多少发电站。对于11GR2之前的RAC来说，如果集群的节点数发生了变化，还需要把客户端里配置都更新一遍，实在是很麻烦。所以Oracle到了11GR2版本发明了SCAN- Single Client Access Name，用户只需要使用SCAN Name，在连接描述符里配置一个条目就可以了：
不管集群有多大，都只需要配置这么一行描述符就可以（ADDRESS所在行）。如同你使用Google，不管谷歌后台有多少台服务器，你都只需要输入google.com，你不需要关心到底是后台的哪个server为你提供的服务。
以前客户选择使用RAC，大多数是由于单实例的性能不足，可用性不够，现在云的概念如日中天，使用RAC的理由可能已经演变为建数据中心，做数据库的整合。下图为Oracle各个版本的一些核心特性图：
Oracle的核心功能在8I时就已经基本稳定下来了，但是这句话用在Oracle RAC产品上并不妥当，如上图，在Oracle 8I时，Oracle RAC只能算是初具雏形，当时的名字还不叫Oracle RAC，而是叫OPS-Oracle parallel server，在这个版本里，Oracle推出了自己的动态锁管理机制，Cache Fusion也已经出现，对于多个节点间的读读操作都已经能够完全在内存中实现，但是多实例之间的写操作仍然要通过磁盘作为媒介。Oracle 9I版本，出现了GRD-Global Resource Directory，Cache Fusion算法变得成熟，充分利用了私有网络的带宽，通过集群的私网来传递数据块包括脏数据块，真正的实现了内存融合。RAC区别于单机的最大一点是集群间需要协商，通过协商来保证多个实例的行为一致，而GRD、DML、Cache Fusion是实现协商的最重要技术，从Oracle RAC 8I到9I，RAC的这几个核心功能变得成熟，但是不管是Oracle 8I还是9I，Oracle都没有自己的集群件产品、没有自己的存储解决方案，都要借助于第三方厂商的集群件产品和存储解决方案，例如IBM，veritas等。
但是到了Oracle 10G版本，霸气显露，Oracle已经不满足于RAC数据库本身了，一口气推出了自己的集群件Oracle ClusterWare 和存储管理软件ASM，并且Oracle ClusterWare在对外宣传上不仅支持Oracle，还提供了API接口支持其他类型的APP。鉴于RAC是shared nothing的技术架构，共享存储和集群文件系统变得非常的迫切，在10G之前的版本，用户必须借助于第三方的存储解决方案，例如veritas等第三方产品，无形中增加了产品的复杂度，因此在9I版本裸设备倒成了一个很大众化的选择。而10G出现的ASM解决了这一困境，ASM本身集卷管理和文件系统功能与一体，让Oracle真正的具有了管理卷，管理文件的能力，不过这个版本下的ASM有点像是“备胎”的味道，毕竟是新技术，不成熟，很多DBA那时候还不敢用它。到了11GR1这个版本，单就Oracle RAC来说，非常让人失望，几乎没有任何大的功能创新，似乎是为了保证每五年左右推出一个大版本下的产物，集群所有的核心功能都没有任何改变，不过对于旧的功能像是ASM，在这个版本变得较为稳定，而且也越来越多被DBA所接受。
到了11GR2发行后，一堆亮瞎眼的功能出现，似乎让我们想明白了为什么11GR1会没什么新特性，因为11GR2发布的这些新特性是一揽子的云化解决方案：RAC One Node ,ServerPool ,Scan,Instance Caging、ACFS等等这些新技术都是为数据库整合，为云而生的，之前的ClusterWare也在11GR2版本被重新包装成为了Grid，ASM也被整合进Grid中作为集群的基础组件。后续的章节，我们也会对其中一些关键的技术做详细的讲解。到了12C版本，Oracle推出了Flex Cluster ,Flex ASM，更大程度提高了RAC的可用性和可扩展性，IN-Memory的出现也更让实时计算变得可能，CDB让数据库整合的方式更加多样，密度也可以更大。从以上RAC的发展史可以看出来，从11GR2版本开始，Oracle开始真正的从产品层面配合云的概念，我们本文讲解的技术也都是在11GR2之后出现的技术。
数据库整合技术
整合所需要的硬件平台
云的核心是整合，既然要做数据库的整合，对于平台的整体能力要求会比较高，这个能力不但包括性能，对于可用性、可扩展的要求都会比较高。笔者认为做数据库整合的理想平台是一体机平台，像Exadata、QData，但是Exadata的价格实在是过于昂贵，性价比非常低，一般用户难以负担得起。笔者所在的沃趣科技是一家业界知名的做高性能解决方案的公司，我们是国内最早开始做一体机的厂商，QDATA一体机也是我们的明星产品，价格上相对于Exadata优势很大。很多朋友会问到，Exadata最为亮眼的地方是它的存储卸载功能，你们QDATA一体机有吗？对于这点我本人实在不敢苟同，试问有多少客户真的从卸载功能里受益非常大？就像Oracle 12C 推出了IN-Memory，理论上可以提升几十上百倍的性能，但是我去的几位客户那里做性能调优，发现客户业务系统的SQL并没有因为使用了IN-Memory而变快，因为使用IN-Memory有一些前提条件，而客户系统并不满足这样的前提条件，其实不管是针对In-Memory还是存储卸载功能，都需要DBA做一定的技术学习和精细化的调优工作，否则想发挥出它的能力是很难的，而且很多业务本身并不适合用这些特性，因此并不是上了这个IN-Memory或者卸载就能得到巨大的性能提升，例如使用上存储卸载必须要全表扫描，而你的SQL可能使用到了索引，那么你就要考虑是否需要把这个索引干掉以用到卸载功能，而这个索引是不是能被干掉，你又不确定，怕其他SQL引用这个索引，这种情况可能在客户那是一种非常普遍的情况。
就我这些年的从业经历来看，传统的数据库架构最大的问题是它的整体性能不匹配，例如传统IOE架构最容易成为瓶颈的地方，不是CPU、Memory，而是IO，笔者在沃趣工作的不到两年里，接触了N多客户的性能瓶颈，很多都是IO问题（还有少数是索引没优化好）。对于热点数据较多较离散的OLTP系统来说，最为关注的是IO的延迟和整体的IOPS，而传统架构大多跑在机械盘上，因此IO的延迟非常大，并且机械盘能够提供的IOPS也非常的低，因此传统架构对于OLTP的支持就有明显的瓶颈，我们的QDATA一体机是通过使用全SSD闪存或者FLASHCACHE方案来加速IO的读写时间，解决IO性能瓶颈。而对于OLAP系统来说，最为关注的是数据库系统能够提供的IO吞吐量，传统IOE架构，吞吐量往往在几百M到1，2GB的量级，因此吞吐量就成为明显的瓶颈，Exadata通过使用infiniband网络来解决存储到计算节点的IO带宽的问题，同样对于我们的QDATA也是通过使用infiniband来提供高带宽。在传统架构中，由于性能组件之间配置的失调，导致了很多资源虽然非常的充足但是根本利用不到，就如刚才分析的，IO成为瓶颈后，即使CPU资源再富足，也没法利用到，因为都在等IO。
而新的高性能解决方案，如一体机产品，基本都是聚焦于解决传统架构里性能组件之间失调的问题，让IO延时、IO吞吐、CPU、内存这些性能组件更加好的匹配在一起，不会在任何一点上成为明显瓶颈。而一体机作为一款高性能解决方案，完全符合了这些要求。它能提供的IOPS动辄几十万，几百万，IO吞吐更是轻轻松松几十GB，特别是随着100Gb的infiniband的出现，一体机能够提供的吞吐量会更加的大。我相信一体机的市场以后也会越来越大，不管是用它做私有云，还是为核心业务保驾护航，都是一个非常值得考虑的选择。同时一体机产品因为都是预先集成与优化的，这里面包含了我们十几年的运维经验和性能优化经验，例如我们对高TPS的系统预先做了REDO写的优化，把REDO放在了具有RAID卡缓存的磁盘上，保证日志的写延迟足够的稳定足够的低。
作为一名技术人员非常喜欢聊一些炫酷的技术，例如Exadata的卸载，我也是如此，如果你有兴趣，我可以跟你滔滔不绝聊上一整天的Exadata，理论上讲起来非常的浪漫和美好，但是现实情况比较残酷，很多甲方DBA认为上了Exadata后利用卸载功能就能让查询快的飞起来，结果大失所望。学习Exadata的成本非常高，并不是一种用了就能好的万能药。如果你有比较强的DBA团队，还有大把的钞票，还是可以考虑使用下Exadata的，如果你的DBA团队暂时还达不到这个要求，那么建议还是不要花这冤枉钱。
Exadata的卸载看似一项跨时代的创新，其实不然，它其实是向MPP架构致敬的一项功能，Oracle的Share Everything 的架构导致了存储一定需要是共享的，进而导致计算与存储必须分离，这种架构里存储不具备MPP架构中，每个节点都能处理数据的能力，因此Oracle的Exadata的出现一定程度上解决了这个问题，让存储节点在某些条件下具备了处理数据的能力。
数据库整合方案比对
虚拟化一度成为一种流行的数据库整合的方案（特别是MYSQL、PG），但是它的弊端非常的明显，虚拟化整合方案需要额外管理更多的OS，而且虚拟化本身会带来IO性能的大幅度衰减，因此性能上比较差，能够整合的数据库的密度也就比较小，不过就隔离性来说，由于每个虚拟机都有独立的OS，因此除了共享宿主机以外，OS，实例等等都是隔离的，很多用户选择这种整合方案很大程度上也是被它的强隔离性所吸引。
单机多实例也是很多客户在使用的整合方案，在一个主机上部署多个实例，由于共享了主机和OS，性能损耗小，因此整合的密度可以比较大（相对于虚拟化整合），而且通过11GR2的Instance Caging技术可以做实例间CPU资源的隔离，由于单机多实例方案比虚拟化整合方案多共享了OS这一层，因此隔离线上相对于虚拟化方案来说，降低了一些，不过上面已经提到通过Instance Caging技术可以做到CPU的隔离。多schema方式的整合，就我们接触到的客户来说，也有客户在用，它的缺陷非常的明显，资源隔离不好做，业务上限制也比较大，同名的schema怎么做整合？几个schema间创建的一些公共权限有冲突怎么办？而且本身由于在一个数据库内，数据库的权限隔离也比较难做，就隔离性来看，因为共享了主机、操作系统、实例，它的隔离级别非常低，从长远来看，后期如果要做拆分，只能使用逻辑迁移，而逻辑迁移往往是非常复杂的。Oracle在12C版本发布了可插拔数据库，它是一个优缺点都比较中和的解决方案，相对于单机多实例来说，它的隔离性没那么强，但它整合的密度可以做到非常的大，因为它像schema整合方案一样，共享了主机、OS、实例（下图），因此性能损失非常的少，总体上，它的隔离性和安全性又比schema方案要强很多，因为本质上每一个PDB都是一个完整独立的DB，DB之间没办法互相访问，除非通过DBLINK这样的工具。
以上种种，笔者推荐的整合方案是基于单机多实例或基于12C的可插拔的方案，但是12C毕竟目前使用的人还不多，因此需要仔细考虑BUG带来的一些风险。
本文出自 “沃趣科技” 博客，请务必保留此出处http://woqutech.blog.51cto.com/11483267/1775335
原文地址：http://woqutech.blog.51cto.com/11483267/1775335
