Hello DBA

根据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–

什么是NoSQL？wiki上的定义是“NoSQL is a movement promoting a loosely defined class of non-relational data stores that break with a long history of relational databases”。其实并不存在一个叫NoSQL的产品，它是一类non-relational data stores的集合。NoSQL的重点是non-relational，而传统的数据库是relational。
我们都知道，传统关系型数据库的最大缺陷是扩展性，虽然各个数据库厂家都有cluster的解决方案，但是不管是share storage还是share nothing的解决方案，扩展性都十分有限。目前解决数据库扩展性的思路主要有两个：第一是数据分片(sharding)或者功能分区，虽然说可以很好的解决数据库扩展性的问题，但是在实际使用过程中，一旦采用数据分片或者功能分区，必然会导致牺牲“关系型”数据库的最大优势-join，对业务局限性非常大，而数据库也退化成为一个简单的存储系统。另外一个思路是通过maser-slave复制的方式，通过读写分离技术在某种程度上解决扩展性的问题，但这种方案中，由于每个数据库节点必须保存所有的数据，这样每个存储的IO subsystem必然成为扩展的瓶颈，而且masert节点也是一个瓶颈。总的来说，传统关系型数据库的扩展能力十分有限。
在说NoSQL之前，首先得说两个重要的概念，一个是CAP理论，另一个是BASE模型。
CAP
Consistency(一致性)，数据一致更新，所有数据变动都是同步的
Availability(可用性)，好的响应性能
Partition tolerance(分区容错性) 可靠性
CAP原理告诉我们，这三个因素最多只能满足两个，不可能三者兼顾。对于分布式系统来说，分区容错是基本要求，所以必然要放弃一致性。对于大型网站来说，分区容错和可用性的要求更高，所以一般都会选择适当放弃一致性。对应CAP理论，NoSQL追求的是AP，而传统数据库追求的是CA，这也可以解释为什么传统数据库的扩展能力有限的原因。
BASE
Basically Availble：基本可用
Soft-state： 软状态/柔性事务
Eventual Consistency：最终一致性
BASE模型是传统ACID模型的反面，不同与ACID，BASE强调牺牲高一致性，从而获得可用性。基本可用是指通过sharding，允许部分分区失败。软状态是指异步，允许数据在一段时间内的不一致，只要保证最终一致就可以了。最终一致性是整个NoSQL中的一个核心理念，很多NoSQL产品就是基于最终一致性而设计的，包括Amazon的Dynamo.
NoSQL产品简介
NoSQL是很多non-relational data stores的集合，总体来说，他们基本都是基于Key-value形式的一种分布式存储，但是每一种NoSQL产品都面向一个特定的应用场景，根据这些应用场景，我们可以把NoSQL分为以下类型（参考了wiki上的定义，只列举了我们比较熟悉的产品）：
KV cache：Memcached
KV store：Tokyo Tyrand/Cabinet，Memcachedb，Berkley DB
Eventually consistent KV store：dynamo，voldemort，Cassandra
Wide columnar store：BigTable，Cassandra，Hbase
document store：MongoDB
KV Cache类型不具有持久化存储的功能，其中的memcached被我们广泛使用，用来缓解数据库的压力，至于数据持久化存储的功能则由数据库来替代了。
KV store具备了持久化存储的功能，其中的memcachedb是新浪在memcached的基础上，采用Berkley DB作为存储层开发的分布式KV store。Tokyo Tyrand/Cabinet是日本最大的SNS社交网站mixi.jp开发的KV store，其中TC是一个NoSQL的数据库，用来做持久化数据存储，TT则是TC的网络接口（兼容memcached协议）。至于Berkley DB则是一个嵌入式数据库，现在掌握在Oracle手中。
Eventually consistent KV store是以最终一致性原理设计的一类KV [...]

阿里B2B招聘应用DBA一名，要求：
1.热爱数据库，精通Oracle原理；
2.精通SQL优化，数据库性能优化；
3.良好的沟通能力和抗压能力；
4.具备开发经验者优先考虑。
有意者发送邮件至：freezr@gmail.com
由于简历数量比较多，恕不能一一回复，请见谅。对该职位不了解的，可以看看以前的招聘帖子。
–EOF–

今年在珠海休了一个长假，我参加了妹妹的婚礼，老婆去了香港和澳门大采购，老妈与久别多年的姐妹们重逢，儿子更是玩的乐不思蜀。
来杭州前，我曾经在珠海呆了五年，对这个地方还是挺有感情的，环境我很喜欢，就是发展机会少了些。这次见到了以前在L+G的老同事，大家都在感概光阴荏苒，岁月如梭。
儿子看起来比我更喜欢这个地方，因为有小狗，小朋友还有沙滩，一片看起来很普通的小沙滩，他就可以一个下午玩得不亦乐乎。他的内心比我单纯，要求很低，只要这么一小片沙滩，他就心满意足。而我，总是想要更多更好，欲望总是让我不自觉的陷入痛苦之中。我要努力找寻属于自己的那片小沙滩，在我的心灵深处，那里阳光明媚，有柔软的沙滩和各色的贝壳，我别无所求。

–EOF–

提起NoSQL这个话题，仿佛不应该是DBA要关注的事，而是架构师应该关心的。但是作为一名DBA，在使用传统的关系型思想建模时，应该有必要了解NoSQL的建模方法。
各种NoSQL数据库有很多，我最关注的还是BigTable类型，因为它是一个高可用可扩展的分布式计算平台，用来处理海量的结构化数据，而数据库同样也是处理结构化数据，所以除了没有SQL，在数据模型方面有相似之处。Cassandra是facebook开源出来的一个版本，可以认为是BigTable的一个开源版本，目前twitter和digg.com在使用。我们尝试从DBA的角度出发去理解Cassandra的数据模型。
NoSQL并不能简单的理解为No SQL，其本质应该是No Relational，也就是说它不是基于关系型的理论基础，而我们所有传统的数据库都是基于这套理论而发展起来的，所以SQL并不是问题的关键所在，比如有些NoSQL数据库可以提供SQL类型的接口，允许你通过类SQL的语法去访问数据。而Friendfeed则是反其道而行之，利用关系型数据库MySQL，采用了去关系化的设计方法，去实现自己的KeyValue存储。所以NoSQL的本质是No Relational.
Cassandra特点：
1.灵活的schema，不需要象数据库一样预先设计schema，增加或者删除字段非常方便（on the fly）。
2.支持range查询：可以对Key进行范围查询。
3.高可用，可扩展：单点故障不影响集群服务，可线性扩展。
Keyspace
Cassandra中的最大组织单元，里面包含了一系列Column family，Keyspace一般是应用程序的名称。你可以把它理解为Oracle里面的一个schema，包含了一系列的对象。
Column family（CF）
CF是某个特定Key的数据集合，每个CF物理上被存放在单独的文件中。从概念上看，CF有点象数据库中的Table.
Key
数据必须通过Key来访问，Cassandra允许范围查询，例如：start => ‘10050′, :finish => ‘10070′

Column
在Cassandra中字段是最小的数据单元，column和value构成一个对，比如：name:“jacky”，column是name，value是jacky，每个column:value后都有一个时间戳：timestamp。
和数据库不同的是，Cassandra的一行中可以有任意多个column，而且每行的column可以是不同的。从数据库设计的角度，你可以理解为表上有两个字段，第一个是Key，第二个是长文本类型，用来存放很多的column。这也是为什么说Cassandra具备非常灵活schema的原因。
Super column

Super column是一种特殊的column，里面可以存放任意多个普通的column。而且一个CF中同样可以有任意多个Super column，一个CF只能定义使用Column或者Super column，不能混用。下面是Super column的一个例子，homeAddress这个Super column有三个字段：分别是street，city和zip：
homeAddress: {street: “binjiang road”,city: “hangzhou”,zip: “310052″,}
Sorting
不同于数据库可以通过Order by定义排序规则，Cassandra取出的数据顺序是总是一定的，数据保存时已经按照定义的规则存放，所以取出来的顺序已经确定了，这是一个巨大的性能优势。有意思的是，Cassandra按照column name而不是column value来进行排序，它定义了以下几种选项：BytesType, UTF8Type, LexicalUUIDType, TimeUUIDType, AsciiType,  和LongType，用来定义如何按照column name来排序。实际上，就是把column name识别成为不同的类型，以此来达到灵活排序的目的。UTF8Type是把column name转换为UTF8编码来进行排序，LongType转换成为64位long型，TimeUUIDType是按照基于时间的UUID来排序。例如：
Column name按照LongType排序：
{name: 3, value: “jacky”},
{name: 123, value: “hellodba”},
{name: 976, value: “Cassandra”},
{name: 832416, value: “bigtable”}
Column name按照UTF8Type排序：
{name: 123, value: “hellodba”},
{name: 3, value: “jacky”},
{name: [...]

自从Oracle和HP推出Exadata之后，我就很关注这个产品，之前也写了一篇Oracle database machine介绍它。去年，Oracle和SUN合并后，推出了Oracle Exadata V2，相比较上一代产品有几个变化：第一，使用SUN的硬件；第二，宣称支持OLTP应用；第三，Oracle 11g R2提供了更多的新特性。
Exadata Smart Flash Cache
Exadata V2整体架构并没有太多改变，换用了SUN的硬件，除了采用intel最新的nehalem CPU以外，每台storage cell更是配置了384GB的flash，这也是为什么V2可以支持OLTP应用的关键。

Flash cache完全是自动管理，Oracle会根据数据的访问情况，决定哪些数据放在flash cache中。所有的数据都是先被写到普通磁盘上，再根据访问情况读入flash cache的，所以如果flash card发生故障，数据不会丢失。当然，Oracle提供了方式，可以让用户手动将表或者索引pin在flash cache中。
在自动管理的方式之外，Oracle还允许用户人工创建flash disks，和普通磁盘一样，这些flash disks通过ASM输出给数据库使用，用户可以把一些访问非常频繁的数据文件放在上面。这些flash disks不仅仅是cache了，所以ASM会在cell和cell之间做镜像。如果某块卡发生故障，那么整个storage cell上的flash disks会offline，保证数据不会丢失。
Smart scan
Smart scan是Exadata最重要的一个功能，它的作用就是把SQL放在每个cell上去运行，然后每个cell只返回符合条件的数据给数据库，这样就极大的降低了数据库服务器的负载和网络流量，并充分利用了cell的计算资源和IO资源。
传统方式：所有的数据都需要返回给数据库服务器，网络带宽要求高，所有的计算在数据库服务器上完成。

Smart scan：只返回符合条件的数据，减少网络带宽，并充分利用了cell上的计算和IO资源。

这里有一点要注意，在使用smart scan时，每个cell返回给DB server的是结果集，而不再是传统的block，DB server完成结果集的处理，并返回给客户端。
Smart scan如何处理join？是我一直想要搞清楚的问题。事实上，smart scan只能处理join filtering，而真正join的工作必须在DB Server上完成，而且smart scan仅适合于处理DSS环境的复杂join，对于OLTP类型的简单join，smart scan并不能发挥其优势。设想下面的查询：
select e.ename,d.dname from emp e, dept d where and e.ename=’Jacky’ and e.deptno=d.deptno;
假设采用nested loops join，smart scan只能完成e.ename=’Jacky’这个条件的过滤，然后将符合条件的emp表的数据返回到DB server，然后由DB Server完成join的工作，逐条查询dept表(e.deptno=d.deptno)的数据。所以smart scan并不适合nested loop join（我认为smart scan只有在适合的条件下才会启用），只有DSS环境的大数据量复杂join才会发挥出优势。而且smart [...]

对于一个高并发的OLTP系统，SQL执行计划的改变往往意味着灾难。很多因素都可能导致执行计划发生不可预期的改变，比如表结构，索引，统计信息等变化，甚至我们发生过一个小小的grant操作，导致执行计划失效，重新解析后生成了一个不正确的执行计，让整个系统Crash的案例。最近，我们对一个分区表增加分区后，导致了执行计划发生改变，故障再次重演。
如何控制SQL的执行计划就成为了一个课题，之前我曾经写过一篇关于调整SQL执行计划的文章，但是内容比较粗略。因为Oracle提供了很多手段去控制执行计划，所以我打算为每个版本都整理一个最佳实践。
我们设想一个场景，一个SQL本来应该走nested loop join，但是由于某种原因，突然变成了hash join，调整统计信息无效，数据库load不断升高，只留给你很少的时间，怎么办？最直接有效的方法是在SQL上加hints，但是需要程序发布，或者程序根本无法修改。
9i为我们提供了Stored outline，大家都非常熟悉，但是对于上面的场景，还是需要点技巧。方法是：生成两个stored outline，一条是错误的，一条是正确的（加hints），两个然后将其执行计划交换。看下面的步骤：
1.创建两个public stroed outline，第一个是目前运行的，第二个是加了hints.
create or replace outline OUTLN1 on select e.ename from emp e, dept d where e.deptno=d.deptno;
create or replace outline OUTLN2 on select /*+ use_nl(e d)*/ e.ename from emp e, dept d
where e.deptno=d.deptno;
拷贝成为private outline
create or replace private outline PRIV_OUTLN1 from OUTLN1;
create or replace private outline PRIV_OUTLN2 from OUTLN2;
交换两个stored outline的执行计划
update ol$ [...]

朋友遇到一个问题，当建立一个包含varchar2(4000)的索引时，直接创建没有问题，但是如果加上online子句，则报错：
ORA-00604: error occurred at recursive SQL level 1
ORA-01450: maximum key length (3215) exceeded
这里实际上包含了两个问题：
1.索引的key到底可以有多大？因为索引的key是不可以跨越block的，所以最直接的决定因素是block size，Oracle的文档给出了一个计算公式：
DB_BLOCK_SIZE: Maximum Index Key Length:
============== =========================

2K (2048) [...]

不知不觉，来杭州已经五年了。翻看了以前的blog，里面记录了我这五年的心路历程。
2004年12月27日，《新的征程》
“上帝关上了一扇门，总会打开一扇窗。所以，别担心。”
2005年3月19日，《杭州两个月》
“说说工作吧，刚来的时候，我感觉到很大的压力，毕竟我和周围的同事相比，水平还差很多。但是发现 BITI，RUDOLF，GRASSBELL，FENNG，WANGHAI，CHENYP，CHENJP，都对我非常的好。虽然我的水平很差，但是有什么 问题，都耐心的给我讲，让我很感动，尤其是BITI，能在这样的环境中工作，我感觉很满足。”
2005年7月28日，《一致读的实现》
第一次有点技术含量的文章，现在看起来依然很优雅，短短几句话，就将一致读的原理解释的清清楚楚:)
2007年3月4日，《细节决定成败》
做DBA的第一次犯错。
2007年5月19日，《IBM P570+DMX3》
第一次跟着老大做项目，学到了很多东西，现在仍然受益匪浅。
2008年1月1日，《我的2007》
2007年，终于实现了梦寐以求的目标，正式当上了DBA。比当DBA更重要的是，当上了别人的爹。
2008年3月6日，《我有压力 未解决》
“工作是挣扎滴，前途是渺茫滴
压力是很大滴，解决是没有滴
抱怨是没用滴，开心是重要滴
未来是光明滴，什么都会有滴”
五年时光，很快就过去了，虽然没成就什么大事业，不过也算是小有成就，感谢家人和朋友的支持，真是挺不容易的。
一直一来，我的梦想是成为象BITI那样的技术大牛，也一直为了这个目标而努力，但是今年情况可能发生了变化，我从技术岗位调整为管理岗位，这本不是我的意愿和初衷，但是我也欣然接受。未来我将把更多的心思放在团队身上，努力让每个人都能从团队发展的过程中受益。
我不会放弃自己的梦想，大师说过：只有自己坚信，才会有人同路。我坚信现在的工作是有价值的，我坚信所有的痛都是暂时的，我坚信付出总有一天会有回报的，我坚信……
–EOF–