Hello DBA

什么是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 [...]

提起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) [...]

一个数据库的同步系统，可以分为三部分：抓取变化，传输和加载。抓取数据库变化，最通常的做法是用trigger记录到表中，或者通过解析Oracle redo log中的信息来抓取。传输是将数据库变化记录到特定格式的文件中，通过网络推送到目标数据库上。加载则是指在目标数据库上应用这些变化（SQL），这里主要是讨论并行加载的实现思路。
我们通过trigger或者redo log得到了数据库变化的事务流，这个流是按照事务的提交顺序排列的，最简单的方法是在目标端按照这个事务流顺序执行，就是串行执行。这么做的最大优点是可以完全保证事务的一致性，但是缺点是性能很差。如果采用并行加载，就需要考虑事务相关性的问题，所谓事务相关性，是指两个或多个事务更新了同一条或者多条记录，他们之前存在时间上的依赖关系。如果将具有相关性的事务分在不同的并发进程上加载，可能出现后面的事务被前面的事务覆盖掉的情况，最终导致事务混乱。
我们设计一个并行加载的方法，目标是尽可能快的加载数据，保证不会产生数据混乱的情况，但是不能保证事务完全的一致性。这句话如何理解，假设两个事务不相关，A事务只更新A表，B事务只更新B表，如果在源库A事务先于B事务完成，那么在目标库可以让B事务先于A事务执行，或者两个事务并行执行，虽然事务的顺序与主库并不一致，但是数据是正确的，因为两个事务不相关。
我们如果按照事务去分拆并行的话，设计比较困难，因为涉及到事务的相关性分析。换个思路，我们可以按照数据来拆分并行，也就是把同一个事务拆分到不同的并发进程中，保证表的同一行记录的所有更改都由一个并发进程处理。按照这个思路，我们首先把事务流加载到一个队列或者一个内存结构中去，为了理解方便，我们可以认为放在了一张内存表中，这个表有以下几个字段，事务ID，表名，PK，SQL，时间序列号。首先按照不同的表分组，将不同的表的操作分配给不同的进程处理，每个并发进程按照事务提交的时间顺序来执行。比如：A事务更新A,B,C三张表的A1,B1,C1记录，B事务更新A,B,C三张表的A2,B2,C2记录，C事务更新A,B,C三张表的A3,B3,C3记录。三个事务的提交顺序是A,B,C，这时我们可以启动三个并发进程，分别处理A表，B表和C表的操作，顺序是A1,A2,A3……这样就实现了最简单的并行，虽然目标库的事务与主库并不一致，但是数据是完整和正确的。
按照表来做并行可能还不足够，如果某张表的更改量特别大，这时我们还可以进一步分组，针对同一张表中的操作再按照行（PK）分组，保证同一行的不同操作分配到同一个的并发进程处理。这里有一些小的技巧，在很多情况下，我们可以只关注某行的最后一个操作就可以了，比如某行的最后一个操作是delete，那么我们只需要执行delete，之前的操作就可以直接丢弃，如果是insert，那么我们可以在目标库先执行delete，然后再insert，针对我们自己的系统，有些表的update是全部字段更新，所以我们直接采用了merge操作，相当于对同一行的不同操作，我们做了合并处理。因为系统是自己开发的，所以可以针对我们自己的特性定制了功能。
有人说这个思路有些土，Oracle logical standby，Goldengate或者Shareplex这些商业软件是怎么做的？我之前也写过一篇文章探讨这个问题：Oracle Logical Standby SQL Apply Architecture，这些商业软件都声称自己分析了事务的相关性，可以做到并行加载，但是同样也存在事务不一致的问题，但是分析事务的相关性肯定要按照表或者行来分析，所以思路应该不会差太远，无非是他们包装得更好。
PS:这个方法并不是我想出来的，是团队的智慧。现在看起来思路挺简单，但是其实困扰了我们很长的时间。当然如果你有更好的方法，欢迎和我讨论。
–EOF–

大牛jonathan lewis在圣诞节出了一个小题目：Holiday Quiz
I have a table with one million rows, there are no indexes on the table. The table has a column called sortcode which has no nulls, and has been generated in a highly random way so that no value appears more than four times. Consider the following queries:

select sortcode
from t1
order by sortcode;
select  sortcode
from (
select [...]

普通PC本地磁盘，没有共享存储，如何实现HA？Dataguard挺好，但是存在数据丢失的可能性，而且很难做到应用透明切换。我们用ASM,Heartbeat和iSCSI可以实现一个廉价的HA方案，如下图：

用iSCSI将本地磁盘输出到对方的机器上，利用ASM的failgroup做mirror，保证数据mirror在两台不同的机器上，就算一台机器完全损坏，数据可以做到百分之百不丢失。用Heartbeat作HA探测，如果发现主机故障，则强行关闭DB和ASM，并在备机启动ASM和DB。如果使用Oracle 11g R2，还可以利用Preferred mirror read的特性，保证主库读自己的本地磁盘，而不是通过iSCSI读备机磁盘，这样可以达到更好的性能。
缺点：Heartbeat作为HA软件，我们并不是十分了解其探测机制，可能出现误判或者无法切换的情况。但是其实IBM hacmp这种HA软件一样有问题，比如Oracle hang住时，现在的hacmp根本无法探测，因为hacmp只是判断Oracle的进程在不在，而不管数据库是否活着。
我想不管什么HA软件，都无法处理所有的异常情况，我们只要有完善的监控和应对措施就可以了。比如我们现在所有的DB都有一个监控，就是定时模拟应用去更新数据库中的数据，如果发现超时或者报错，就认为数据库出现hang的情况，并发出报警。
–EOF–
另：之前我有一篇文章介绍用ASM和iSCSI搭建RAC的文章，在实际测试过程中，发现存在一些问题，因为在11g R2之前，voting disk和OCR都必须放在RAW devices上。因为没有共享存储，如果发生某台机器全部宕机，voting disk可能会丢失一部分，造成RAC的cluster机制发生误判。所以在11g R2之前，这个方案是有问题的，在11g R2中，Oracle几乎所有的东西都可以放在ASM中，这个方案也许可行，我还没有测试过。
在我写完这篇博文后，发现这个方案存在一些问题，通过iscsi将online redo输出到另外一个主机后，log file sync的响应时间需要40-60ms，这个响应时间肯定是无法接受的。现在两台主机的互连是四块千兆网卡直连，通过Linux的Multipath来管理多路径，为什么响应时间这么久，我们还在进一步查找问题。

在面试时经常会问一个问题，请列举出hash在数据库内部的应用，hash的原理虽然简单，但是它在数据库中可以说是无处不在。其中hash partition是hash在数据库中一个简单的应用，虽然它没有range partition那么常用，但是我们在做数据库水平拆分时，其实就是利用了hash partition的原理，利用hash函数对某个key进行运算，然后将其分布到不同的主机上，原理很简单。
我们在设计时遇到了一个问题，当分区的数量需要变化时，基于hash的原理，数据可能会从一个分区移动到另外一个分区，因为某个key在4个分区时，可能被分布在分区3，而在8个分区时，可能被分布在分区5。这样每当分区数量变化时，就需要全部重新分布数据，代价很高。
那么Oracle是怎么做的？首先可以肯定的是Oracle的hash partition在分区增加时，不需要做全部数据的重新分布。有人告诉我Oracle的hash函数比较牛，可以保证分区数量增加时，这个hash函数可以让原来的数据还在旧的分区中，而新的数据可以分布在新的分区。Oracle的函数无非就是get_hash_value或ora_hash(10g)，从hash的原理上来说，这也是不可能做到的。
我们对hash partition都有一个常识，就是partition的数量最好是2的次方，也就是2，4，8，16……，否则分区会出现不分区均衡的现象，按照hash的原理，不管是几个分区，都可以做到完全均衡的，为什么会不均衡，其实答案已经出来了，Oracle为了能够增加分区，为你预留了几个看不到的分区。
假设我们有6个分区，一共8000条数据，数据的分布如下图：

hash partition不能直接增加分区，而是split当前分区，当需要增加到8个分区时，实际上是分区3和分区4分别split产生新的分区7和分区8，如下图：

Oracle如何做到分区数量增加后，其他分区的数据不受影响呢，其实很简单，Oracle在做hash运算时，预留了分区，比如6个分区，实际上是用8个分区的hash来运算的，只不过把缺少的分区的数据合并到其他分区，这样就会出现数据不均衡的情况。Oracle的公式是这样的，用等于或者大于当前分区数量的最小的一个2的N次方，比如6个分区做8个hash bucket。我们再来考虑一下2，4，8，16（2的N次方）的情况，比如要把4个分区加为5个分区，因为已经是2的N次方，所以数据会均匀分布，而且Oracle还是使用4个hash bucket。这时新增的分区5实际上把分区1 split后产生的，这时因为有5个分区了，所以会使用8个hash bucket。这时Oracle的hash函数就比较牛了，它可以保证2，4，8，16个分区时，同一个键值分布在相同的分区或者是对应可以合并的分区，看下面的SQL：
select ora_hash(‘hellodba’,1)+1 par2,ora_hash(‘hellodba’,3)+1 par4,ora_hash(‘hellodba’,7)+1 par8,ora_hash(‘hellodba’,15)+1 par16 from dual;
PAR2 PAR4 PAR8 PAR16
———- ———- ———- ———-
[...]

我们常用的HA方案有几种：一是用小型机和HA软件作双机热备，这种方案始终有一台设备处于空闲状态，设备利用率很低，而且必须用IBM，HP等厂商的硬件，代价昂贵。二是用Oracle的RAC来做HA，在Linux环境下，Oracle提供了全套的解决方案，是个不错的选择，不过最低也需要一套共享的存储设备。三是用Oracle DG，这种方案成本最低，但是无法做到故障时应用透明切换，我们也曾经尝试过用heartbeat配合DG failover来作一些尝试，但是在测试中发现，在极端情况下，可能存在丢失数据或者无法切换的可能性。
自从使用MySQL数据库以来，我们就一直探索MySQL的HA方案，目前应用最广泛的是用heartbeat作HA，利用MySQL双向复制技术，达到透明切换的目的。但是heartbeat并不是十分的稳定，而且切换的过程也比较长。
是否有更好的解决方案？首先要解决故障探测的问题，如果应用可以自己探测数据库状态，发现数据库出现问题时，可以切换到另外一台备机；其二主备库之间的数据同步问题，如果我们可以解析Oracle或者MySQL的日志，还原成SQL信息并应用到备机，这样就实现了logical standby或者MySQL复制的功能。利用这两个功能，我们可以实现一个更廉价更灵活的HA方案。
目前我们正在做三个工具，第一是日志解析工具，包括Oracle和MySQL，日志解析是将日志文件中的变化还原为SQL或者日志信息；第二是数据同步工具，主要负责将日志信息打包传输，并应用到目标数据库上；第三是数据库探测与路由工具，主要负责探测数据库状态，对应用做透明故障切换。
这个方案中，由于数据库不再有primary和standby之分，仅仅是应用端来作判断连接哪个数据库，所以故障切换的时间非常快，我们测试大概只需要10秒。但是数据同步可能存在一定的延时，也就是说数据库切换后，数据可能存在一定程度的丢失，但是我们可以在切换后再对数据进行补全，这个我们是可以接受的。利用这些工具，我们可以搭建出很多灵活的解决方案，并不一定要依赖IBM，Oracle的解决方案，毕竟适合我们的才是最好的方案。
目前这个方案还在开发与验证中，欢迎大家和我探讨HA这方面的问题。
–EOF–