Hello DBA

本文发表在《程序员》杂志2010年第6期
引 言
数据库的可用性和扩展性一直是数据库厂商和用户最关注的问题。过去我们采用高端的设备，比如使用小型机和大型存储来保证数据库的可用 性。而扩展性主要采用向上扩展(Scale up)的方式，通过增加CPU，内存，磁盘等方式提高处理能力。这种集中式数据库的架构，使得数据库成为了整个系统的瓶颈，已经越来越不适应海量数据对计 算能力的巨大需求。近些年来，分布式系统成为了一种趋势，我们希望用廉价的设备堆叠出具备高可用性和高扩展性的计算集群，从而摆脱对大型设备的依赖。数据 库作为系统架构中的重要组成部分，如何做到即提供高可用性，又具备向外扩展(Scale out)的能力，数据库厂商和用户都做了很多的探索。
Oracle RAC
几乎每个数据库产品都有集群解决方案，Oracle RAC是业界最流行的产品。其架构的最大特点是共享存储架构（Shared-disk），整个RAC集群是建立在一个共享的存储设备之上的，节点之间采用 高速网络互连。Oracle RAC提供了非常好的高可用特性，比如负载均衡和应用透明切换(TAF)，其最大优势在于对应用完全透明，应用无需修改便可以切换到RAC集群。但 是，RAC的扩展能力有限，首先因为整个集群都依赖于底层的共享存储，所以共享存储的IO能力和可用性决定了整个集群的可以提供的能力，其依然无法摆脱对 大型存储设备的依赖。Oracle显然也意识到了这个问题，在Oracle的MAA(Maximum Availability Architecture)架构中，采用ASM来整合多个存储设备的能力，使得RAC底层的共享存储也具备线性扩展的能力，整个集群不再依赖于大型存储的 处理能力和可用性。
RAC的另外一个问题是，随着节点数的不断增加，节点间通信的成本也会随之增加，当到达某个限度时，增加节点可能不会 再带来性能上的提高，甚至可能造成性能下降。这个问题的主要原因是Oracle RAC对应用透明，应用可以连接集群中的任意节点进行处理，当不同节点上的应用争用资源时，RAC节点间的通信开销会严重影响集群的处理能力。所以使用 Oracle RAC有两个建议：1.节点间通信使用高速互联网络；2.尽可能将不同的应用分布在不同的节点上。基于这个原因，Oracle RAC通常在DSS环境中可以做到很好的扩展性，因为DSS环境很容易将不同的任务分布在不同的计算节点上，而对于OLTP应用，Oracle RAC更多情况下是用来提高可用性，而不是为了提高扩展性。
MySQL Cluster
MySQL cluster和Oracle RAC完全不同，它采用Shared-nothing架构。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组 成，不存在一个共享的存储设备。MySQL cluster主要利用了NDB存储引擎来实现，NDB存储引擎是一个内存式存储引擎，要求数据必须全部加载到内存之中。数据被自动分布在集群中的不同存 储节点上，每个存储节点只保存完整数据的一个分片(fragment)。同时，用户可以设置同一份数据保存在多个不同的存储节点上，以保证单点故障不会造 成数据丢失。
MySQL cluster的优点在于其是一个分布式的数据库集群，处理节点和存储节点都可以线性增加，整个集群没有单点故障，可用性和扩展性都可以做到很高，更适合 OLTP应用。但是它的问题在于：1.NDB存储引擎必须要求数据全部加载到内存之中，限制比较大，但是目前NDB新版本对此做了改进，允许只在内存中加 载索引数据，数据可以保存在磁盘上。2.目前的MySQL cluster的性能还不理想，因为数据是按照主键hash分布到不同的存储节点上，如果应用不是通过主键去获取数据的话，必须在所有的存储节点上扫描， 返回结果到处理节点上去处理。而且，写操作需要同时写多份数据到不同的存储节点上，对节点间的网络要求很高。
虽然MySQL cluster目前性能还不理想，但是share nothing的架构一定是未来的趋势，Oracle接手MySQL之后，也在大力发展MySQL cluster，我对MySQL cluster的前景抱有很大的期待。
分布式数据库架构
目前，除了数据库厂商的 集群产品以外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据做水平切分，类似于hash分区 的原理，通过应用架构解决访问路由和数据合并的问题。Sharding架构的优势在于，集群扩展能力很强，几乎可以做到线性扩展，而且整个集群的可用性也 [...]

Library cache是Shared pool的一部分，它几乎是Oracle内存结构中最复杂的一部分，主要存放shared curosr（SQL）和PLSQL对象（function，procedure，trigger）的信息，以及这些对象所依赖的table，index，view等对象的信息。
Library cache需要解决三个问题：
1.快速定位的问题：Library cache中对象众多，Oracle如何管理这些对象，以便服务进程可以迅速找到他们需要的信息。比如某个服务进程需要迅速定位某个SQL是否存在于Library cache中。
2.关系依赖的问题：Library cache中的对象存在复杂的依赖关系，当某个objec失效时，可以迅速将依赖其的对象也置为失效状态。比如某个表发生了结构变化，依赖其的SQL语句需要重新解析。
3.并发控制的问题：Library cache中必须有一个并发控制的机构，比如锁机制，来管理大量共享对象的并发访问和修改的问题，比如某个SQL在重新编译的同时，其所依赖的对象不能被修改。
Library cache结构：

Oracle利用hash table结构来解决library cache中快速定位的问题，hash table就是很多hash bucket组成的数组：

原理与buffer cache中定位block的方式相同，将对象信息（比如SQL）hash定位到某个hash bucket中，然后顺序扫描bucket中的 List，实现快速定位对象的目的。
Library cache handle是对象的一个指针，其中的namespace属性表示其指向的对象的类型：比如CRSR(Cursor)，TABL(Table)，INDX(Index) ，PROD(Procedure)，TRIG(Trigger)等等。
LCO(Library cache object)是handel指向的对象，包含了以下几个部分的内容：
1.dependency table：
指向本对象所依赖的对象，比如：select * from emp这个cursor的对象，依赖emp这个表，这里指向了emp这个表的handle。
2.child table：
指向本对象的子对象，比如某个游标的子游标。子游标是指SQL文本相同，但是SQL的实际含义不同的情况，比如执行的用户不同，执行计划不同，执行的环境不同等等，我们一般称之为SQL的不同版本。一个SQL至少包含一个父游标和一个子游标。
3.authorization table：
对象的授权信息。
4.type
Library cache object的type，包括：shared cursor,index,table,cluster,view,synonym,sequence,procedure,function,package,table body,package body,trigger等等。
5.data blocks
data block是一个指针，指向了data heap，即存放真实数据的地方，主要包括：diana tree, p-code, source code, shared cursor context area等等，如下图：

Library cache对象依赖关系：
对象依赖关系是利用LCO中的dependency table来完成的，我们设想以下的情况，用来说明对象间的依赖关系：
两个共享游标：
SQL1: select * from emp;
SQL2: select * from emp和select a.name [...]

我们都知道Latch是Oracle用来在内存中做串行控制的机构，从10g R2开始，Oracle引入了一个新的技术-Mutex。Mutex并不是Oracle的发明，而是系统提供的一个底层调用，Oracle只是利用它实现串行控制的功能，并替换部分Latch。
Mutex中有两个变量：分别是Holider identifer和Reference count，Holider identifer记录持有mutex的SID，而Reference count是一个计数，记录了当前正在以share方式访问mutex的数量，每当session以share方式持有mutex时，计数会加1，而释放时会减1。如果Reference count大于零，则表示该内存结构正在被Oracle pin住。
我们看一段伪代码，演示mutex的申请过程：
Function Mutex_get(mutex_name)
{
if mutex.holder:=SID
case mode:
‘exclusive’:
if mutex.ref_count=0
return TRUE
else
mutex.holder.clear;
[...]

最近一直在思考一个问题：如何为一个数据库建立性能模型？作为一名DBA来说，我们面临的一个巨大挑战是：如何保证数据库的性能可以满足快速变化的应用的需求，如何在数据量和访问量持续增长的情况下，保证应用的响应时间和数据库的负载处在合理的水平下。我们可能会经常面对以下的问题：某个SQL每秒要执行100次，响应时间是多少？某个应用发布后，对数据库的影响如何？所以，评估应用对数据库所产生的影响，优化应用并预测风险，保证数据库的可用性和稳定性，这是应用DBA真正有价值的地方。
响应时间为中心：
如果要选择一个评价系统优劣的性能指标，毫无疑问应该是响应时间。响应时间是客户体验的第一要素，所有的优化都应该为降低响应时间而努力。对于数据库系统也是如此，我们优化系统，优化SQL，最终目标都是为了降低响应时间，单位时间内可以处理更多的请求。
数据库时间模型：
响应时间一般分为服务时间(Service time)和等待时间(Wait time)，服务时间指进程占用CPU的时间，包括前台进程(Server process)和后台进程(Backgroud process)，我们一般只关注前台进程占用的CPU time。等待时间包括很多类型，一般最常见的是IO等待和并发等待，IO等待包括sequential read，scattered read和log file sync等等，而并发等待主要是latch和enqueue。SQL execute elapsed time指用户进程执行SQL的响应时间，包含CPU time和wait time。
以下是Oracle数据库的时间模型：

在Oracle系统中，我们可以利用AWR或Statspack报告，看到数据库的时间信息：

Statistic Name
Time (s)
% of DB Time

sql execute elapsed time
3,062.17
91.52

DB CPU
2,842.08
84.95

parse time elapsed
25.87
0.77

PL/SQL execution elapsed time
11.75
0.35

sequence load elapsed time
7.55
0.23

hard parse elapsed time
5.06
0.15

connection management call elapsed time
3.13
0.09

hard parse (sharing criteria) elapsed time
0.04
0.00

repeated bind elapsed time
0.01
0.00

PL/SQL compilation elapsed time
0.00
0.00

DB time
3,345.74

background elapsed time
204.91

background cpu [...]

建立数据库性能模型，这是我最近一直在思考的一个问题。这个命题还是非常有意义的，因为我们在很多情况下都需要对数据库做性能评估，容量规划和风险预测。很多DBA的优化经验都局限在一个很小的数据库技术领域内，而对整个系统的性能容量并不十分了解。我希望能够给大家一些简单的模型和经验数据，帮助大家对系统的整体性能有一个更深层次的了解。
这篇PPT可能还达不到模型的理论高度，甚至很多数据还不是十分准确，只是我个人思考的一个结果，希望能抛砖引玉，大家一起思考和进步。
Oracle数据库性能模型
View more presentations from freezr.

之前，我对Sequential和Scattered的理解是Oracle读取IO的顺序不同，今天又讨论起这个问题，另外一种解释是两者在内存中的保存方式有差异，Sequential read在内存中是连续的，而Scattered read是离散的。以下解释来自于Oracle文档：
Scattered read：
This event signifies that the user process is reading buffers into the SGA buffer cache and is waiting for a physical I/O call to return. A db file scattered read issues a scatter-read to read the data into multiple discontinuous memory locations. A scattered read is usually a multiblock [...]

最近整理了一些关于数据库架构方面的技术专题，并整理成为PPT，准备拿出来和大家一起分享。
为什么要这么做，并不是要为了证明我自己，更不是为了其他什么目的。因为最近一直有一种强烈的执着，想要做成一些事情，在这之前，必须找到很多志同道合的人一起来努力，所以需要先布道。我并不是为了分享而分享，而是希望这些东西能够改变大家对现在一些架构的理解，真正了解我们现在面对的问题和未来的挑战。
蔡学镛说：大多數的工程師並不是「做了五年的系統開發」，而是「做了一年的系統開發，然後重複五次」。我不希望我和周围的同事们都是如此，所以我分享，帮助别人，也帮助我自己。
下面是第一个专题，《数据库高可用架构》，PPT写的很一般，关键看讲的人了。如果哪个部门有兴趣，可以联系我。
数据库高可用架构
View more presentations from freezr.

分布式系统的hash策略，决定了数据的分布。传统的方式采用mod n的算法，非常简单，但是一旦节点发生变化，所有的数据都需要重组，代价非常大。一致性哈希(Consistent hash)很好的解决了这个问题，当节点发生变化时，只会影响到部分数据，而且永远可以找到一个提供服务的节点。
对于数据库Sharding的架构，Consistent hash并不十分适合，我们采用了一种新的hash策略，我将其称之为“Virtual Partition Hash”策略。
为了解决节点数量变化时，全部数据需要重组的问题，我们采用了预分区的策略，将整个系统分为很多个Virtual Partition，每个物理节点由多个Virtual Partition组成。比如整个系统分为128个VP，共有8个物理的服务器，每个服务器包含16个VP的数据，只要整个系统的物理节点小于128个，增加节点只需要移动部分VP就可以了，避免了数据重组的问题。另外，为了提高可用性，每个物理节点都有一套备机，如果节点失效则切换至备用节点。
新增一个物理节点：

只需要移动部分VP至新节点，不需要数据重组。

Virtual partition hash策略非常简单，实现也很容易，实际上它是Consistent hash策略的一个简化版本，Oracle hash分区也是类似的做法，尽可能的减少数据重组的代价，可以参考我以前的文章《Oracle hash分区的秘密》。
这个策略的另外一个好处是非常灵活，可以根据服务器压力的情况，通过移动VP的来达到负载均衡的目的。利用MySQL数据库复制的特性，移动VP是非常容易的，而且配合我们的分布式数据库架构，可以做到对应用透明。
这个方案的缺点是：每个节点都准备一台备机，硬件资源比较浪费。但是如果可以和读写分离架构配合起来，备机可以承担部分读的服务，那么这个缺点就不存在了。
“Simple but Incomplete Solutions Win！”
—EOF—

根据CAP理论，一致性(C)，可用性(A)，分区容错性(P)，三者不可兼得，必须有所取舍。而传统数据库保 证了强一致性(ACID模型)和高可用性，所以要想实现一个分布式数据库集群非常困难，这也解释了为什么数据库的扩展能力十分有限。而近年来不断发展壮大 的NoSQL运动，就是通过牺牲强一致性，采用BASE模型，用最终一致性的思想来设计分布式系统，从而使得系统可以达到很高的可用性和扩展性。
但是，对于CAP理论也有一些不同的声音，数据库大师Michael Stonebraker就撰文《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》，表示为了P而牺牲C是不可取的。事实上，数据库系统最大的优势就对一致性的保证，如果我们放弃了一致性，也许NoSQL比数据库更有优势。那么，有没有可能实现一套分布式数据库集群，即保证可用性和一致性，又可以提供很好的扩展能力呢？回答是：有的。
目前，有很多分布式 数据库的产品，但是绝大部分是面向DSS类型的应用，因为相比较OLTP应用，DSS应用更容易做到分布式扩展。Michael Stonebraker提到了一种新型的数据库VoltDB，它的定义是Next-Generation SQL Database for Fast-Scaling OLTP Applications。虽然产品还没有问世，但是从技术资料上来看，它有几个特点：
1.采用Share nothing架构，将物理服务器划分为以CPU core为单位的Virtual node，采用Sharding技术，将数据自动分布到不同的Virtual node，最大限度的利用机器的计算资源；
2.采用内存数据访问技术，类似于内存数据库(In-memory database)，区别于传统的数据库(Disk-based database)，消除了传统数据库内存管理的开销，而且响应速度非常快；
3.每个Virtual node上的操作是自治的，利用队列技术将并发访问变为串行访问，消除了传统数据库串行控制的开销(比如Latch和Lock)；
4.数据同步写多个副本，不存在单点故障，而且消除了传统数据库需要记录redo log的开销。

VoltDB与传统数据库的对比，可以看到VoltDB即支持传统数据库的ACID模型，又提供了类似NoSQL产品很高的扩展能力。

这个产品，让我想到了MySQL cluster，同样是shared-nothing架构，NDB存储引擎也要求将数据存放在内存中，数据根据PK被分布到多个不同的节点上，同一份数据可以保存多个副本，防止单点故障。

MySQL cluster目前的主要问题是性能不佳，但是我认为MySQL cluster的架构是分布式数据库未来的趋势，Oracle收购MySQL后，很多人对MySQL的前途表示担忧，而我作为一个用户，除了可能会收费这件事以外，我一点也不担心MySQL的前景，反而有所期待，因为在数据库领域没有任何一个公司比Oracle更懂数据库，而Oracle也正在大力发展MySQL cluster，MySQL cluster一定会成为分布式数据库领域内最好的解决方案之一。
–EOF–

本篇文章不得以任何形式转载或发表。

这不是一篇关于Oracle和MySQL技术比较的文章，而是我对Oracle和MySQL甚至 NoSQL产品选择上的一些想法。
我们过去和现在使用了大量的Oracle数据库，几乎我们所有的数据都存放在Oracle数据库里面，我们有高端的小型机，大型存储和全国最牛的DBA团队。这些都让我们引以为傲。
随着业务不断增长，数据量和计算量越来越庞大，我们发现小型机都无法满足我们的需求，除了Oracle我们别无选择，我们被“绑架”了，被IBM，EMC，Oracle绑架了，我们辛辛苦苦赚的血汗钱都交给他们了。
2009年开始，我们引入了MySQL数据库，采用sharding技术，利用PC服务器搭建高可用的数据库集群，极大的降低了我们的成本，并提供了充足的扩展能力，让业务有更大的发展空间。
最近，我们遇到了一些困惑：应用如何选择Oracle还是MySQL？从Oracle迁移到MySQL的意义是什么？Oracle收购SUN之后，MySQL何去何从？
我们的目标不是要用MySQL数据库替代所有的Oracle，事实上，这不现实也不是我们的目标，目前很多应用都依赖于Oracle数据库的特性，相当长的一段时间内，Oracle依然是我们的首选。但是，这并不意味着Oracle是我们唯一的选择，我们选择MySQL和PC服务器来搭建大规模数据库集群，最终的目标是要证明我们具备更换数据库的能力，具备用廉价设备替换小型机的能力，能够用我们自己的软件搭建高可用可扩展的架构。所以说，MySQL只是一个数据库而已，如果某天Oracle将MySQL收费，我们可以换成其他的数据库（比如 PostgreSQL）。我们正在做的事，其中的价值并不能简单的用节省 Oracle license的费用来评估。
阿里巴巴正在研发云计算系统，同样要证明阿里巴巴具备这种能力，这是每一个伟大的公司都要具备的能力。我相信，未来的数据存储肯定不仅仅局限于数据库，数据库和其他NoSQL产品一定会百花齐放。
我们做了大量的努力和尝试，包括Sharding和功能分区，SSD的尝试，MySQL高可用架构，数据同步工具等等，都是为了一个目标：证明的是我们能够设计出一种架构，可以做到用PC server和开源数据库（不仅仅局限于MySQL）来替换高端设备和Oracle，不被设备厂家和Oracle所绑架，将主动权掌握在自己手中。所以，我们不要过分纠结于Oracle和MySQL 在具体性能上的差异，作为一个数据库产品，MySQL无法和Oracle相比，单个PC server的可用性更是无法同小型机相比，但是我们用架构去弥补，整体上达到更高的可用性。
所以，我们不应该单纯用MySQL和Oracle本身的优劣，来评估技术方案，更不能用pc server的可用性和小型机去相比。关键是我们的技术架构能否用廉价的东西搭建出高可用可扩展的系统，这才是我们真正引以为傲的地方。
–EOF–