目的 在一台服务器上做主从复制，充分利用CPU资源。下面的文档首先说明如何在一台服务器开启多个MySQL

环境 MySQL 5.5

工具

mysql_install_db

mysqld_multi

配置过程

1. 利用mysql_install_db生成数据库

mysql_install_db --datadir=/var/lib/mysql2 --user=mysql

mysql_install_db --datadir=/var/lib/mysql3 --user=mysql

……

mysql_install_db命令会自动创建datadir目录。

2. 利用mysqld_multi工具生成配置文件

[root@ora01 ~]# mysqld_multi --example

# This is an example of a my.cnf file for mysqld_multi.

# Usually this file is located in home dir ~/.my.cnf or /etc/my.cnf

#

# SOME IMPORTANT NOTES FOLLOW:

#

# 1.COMMON USER

#

#   Make sure that the MySQL user, who is stopping the mysqld services, has

#   the same password to all MySQL servers being accessed by mysqld_multi.

#   This user needs to have the 'Shutdown_priv' -privilege, but for security

#   reasons should have no other privileges. It is advised that you create a

#   common 'multi_admin' user for all MySQL servers being controlled by

#   mysqld_multi. Here is an example how to do it:

#

#   GRANT SHUTDOWN ON *.* TO multi_admin@localhost IDENTIFIED BY 'password'

#

#   You will need to apply the above to all MySQL servers that are being

#   controlled by mysqld_multi. 'multi_admin' will shutdown the servers

#   using 'mysqladmin' -binary, when 'mysqld_multi stop' is being called.

#

# 2.PID-FILE

#

#   If you are using mysqld_safe to start mysqld, make sure that every

#   MySQL server has a separate pid-file. In order to use mysqld_safe

#   via mysqld_multi, you need to use two options:

#

#   mysqld=/path/to/mysqld_safe

#   ledir=/path/to/mysqld-binary/

#

#   ledir (library executable directory), is an option that only mysqld_safe

#   accepts, so you will get an error if you try to pass it to mysqld directly.

#   For this reason you might want to use the above options within [mysqld#]

#   group directly.

#

# 3.DATA DIRECTORY

#

#   It is NOT advised to run many MySQL servers within the same data directory.

#   You can do so, but please make sure to understand and deal with the

#   underlying caveats. In short they are:

#   - Speed penalty

#   - Risk of table/data corruption

#   - Data synchronising problems between the running servers

#   - Heavily media (disk) bound

#   - Relies on the system (external) file locking

#   - Is not applicable with all table types. (Such as InnoDB)

#     Trying so will end up with undesirable results.

#

# 4.TCP/IP Port

#

#   Every server requires one and it must be unique.

#

# 5.[mysqld#] Groups

#

#   In the example below the first and the fifth mysqld group was

#   intentionally left out. You may have 'gaps' in the config file. This

#   gives you more flexibility.

#

# 6.MySQL Server User

#

#   You can pass the user=... option inside [mysqld#] groups. This

#   can be very handy in some cases, but then you need to run mysqld_multi

#   as UNIX root.

#

# 7.A Start-up Manage Script for mysqld_multi

#

#   In the recent MySQL distributions you can find a file called

#   mysqld_multi.server.sh. It is a wrapper for mysqld_multi. This can

#   be used to start and stop multiple servers during boot and shutdown.

#

#   You can place the file in /etc/init.d/mysqld_multi.server.sh and

#   make the needed symbolic links to it from various run levels

#   (as per Linux/Unix standard). You may even replace the

#   /etc/init.d/mysql.server script with it.

#

#   Before using, you must create a my.cnf file either in /usr/my.cnf

#   or /root/.my.cnf and add the [mysqld_multi] and [mysqld#] groups.

#

#   The script can be found from support-files/mysqld_multi.server.sh

#   in MySQL distribution. (Verify the script before using)

#

上面是mysqld_multi工具的简单说明，下面是根据实际情况，修改的配置文件。为方便测试，将多实例的配置文件命名为

mysqld_multi.cnf。未指定的其他MySQL参数，将使用默认的。

[mysqld_multi]

mysqld     = /usr/bin/mysqld_safe

mysqladmin = /usr/bin/mysqladmin

#user       = multi_admin

#password   = my_password

[mysqld2]

socket     = /var/lib/mysql2/mysql2.sock

port       = 3307

#pid-file   = /var/lib/mysql2/hostname.pid2

datadir    = /var/lib/mysql2

#language   = /usr/share/mysql/mysql/english

user       = mysql

[mysqld3]

socket     = /var/lib/mysql3/mysql3.sock

port       = 3308

#pid-file   = /var/lib/mysql3/hostname.pid3

datadir    = /var/lib/mysql3

#language   = /usr/share/mysql/mysql/swedish

user       = mysql

注：我做测试的时候，把pid-file和language选项注释掉了。

3. 启动

# mysqld_multi --defaults-extra-file=/etc/mysqld_multi.cnf report

Reporting MySQL servers

MySQL server from group: mysqld2 is not running

MySQL server from group: mysqld3 is not running

# mysqld_multi --defaults-extra-file=/etc/mysqld_multi.cnf start

等一会儿…………，注意start后面跟具体的数字，比如start 2，则单独开启mysqld2这个实例。

# mysqld_multi --defaults-extra-file=/etc/mysqld_multi.cnf report

Reporting MySQL servers

MySQL server from group: mysqld2 is running

MySQL server from group: mysqld3 is running

[root@ora01 mysql2]# netstat -tunlp

Active Internet connections (only servers)

Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name  

tcp        0      0 192.168.122.1:53            0.0.0.0:*                   LISTEN      3808/dnsmasq       

tcp        0      0 :::3307                     :::*                        LISTEN      24335/mysqld       

tcp        0      0 :::3308                     :::*                        LISTEN      24241/mysqld       

tcp        0      0 :::22                       :::*                        LISTEN      3537/sshd          

udp        0      0 192.168.122.1:53            0.0.0.0:*                               3808/dnsmasq       

udp        0      0 0.0.0.0:67                  0.0.0.0:*                               3808/dnsmasq       

连接

mysql -uroot -p -h127.0.0.1 -P3307

4. 测试

如果--defaults-extra-file选项指定的配置文件中，未具体设置路径socket，则会用mysql默认的路径。

mysql> show variables like 'socket';

+---------------+---------------------------+

| Variable_name | Value                     |

+---------------+---------------------------+

| socket        | /var/lib/mysql/mysql.sock |

+---------------+---------------------------+

1 row in set (0.00 sec)

但是pid文件，会自动在数据目录内生成

mysql> show variables like '%pid%';

+---------------+---------------------------------+

| Variable_name | Value                           |

+---------------+---------------------------------+

| pid_file      | /var/lib/mysql2/ora01.dh.cn.pid |

+---------------+---------------------------------+

1 row in set (0.00 sec)

因此，一般来说都是通过 主从复制（Master-Slave）的方式来同步数据，再通过读写分离（MySQL-Proxy）来提升数据库的并发负载能力 这样的方案来进行部署与实施的。

如下图所示：

下面是我在实际工作过程中所整理的笔记，在此分享出来，以供大家参考。

一、MySQL的安装与配置
具体的安装过程，建议参考我的这一篇文章：http://heylinux.com/archives/993.html
值得一提的是，我的安装过程都是源码包编译安装的，并且所有的配置与数据等都统一规划到了/opt/mysql目录中，因此在一台服务器上安装完成以后，可以将整个mysql目录打包，然后传到其它服务器上解包，便可立即使用。

二、MySQL主从复制
场景描述：
主数据库服务器：192.168.10.130，MySQL已经安装，并且无应用数据。
从数据库服务器：192.168.10.131，MySQL已经安装，并且无应用数据。

2.1 主服务器上进行的操作
启动mysql服务
/opt/mysql/init.d/mysql start

通过命令行登录管理MySQL服务器
/opt/mysql/bin/mysql -uroot -p'new-password'

授权给从数据库服务器192.168.10.131
mysql> GRANT REPLICATION SLAVE ON *.* to 'rep1'@'192.168.10.131' identified by ‘password’;

查询主数据库状态
Mysql> show master status;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000005 | 261 | | |
+------------------+----------+--------------+------------------+

记录下 FILE 及 Position 的值，在后面进行从服务器操作的时候需要用到。

2.2 配置从服务器
修改从服务器的配置文件/opt/mysql/etc/my.cnf
将 server-id = 1修改为 server-id = 10，并确保这个ID没有被别的MySQL服务所使用。

启动mysql服务
/opt/mysql/init.d/mysql start

通过命令行登录管理MySQL服务器
/opt/mysql/bin/mysql -uroot -p'new-password'

执行同步SQL语句
mysql> change master to
master_host=’192.168.10.130’,
master_user=’rep1’,
master_password=’password’,
master_log_file=’mysql-bin.000005’,
master_log_pos=261;

正确执行后启动Slave同步进程
mysql> start slave;

主从同步检查
mysql> show slave status\G
==============================================
**************** 1. row *******************
Slave_IO_State:
Master_Host: 192.168.10.130
Master_User: rep1
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000005
Read_Master_Log_Pos: 415
Relay_Log_File: localhost-relay-bin.000008
Relay_Log_Pos: 561
Relay_Master_Log_File: mysql-bin.000005
Slave_IO_Running: YES
Slave_SQL_Running: YES
Replicate_Do_DB:
……………省略若干……………
Master_Server_Id: 1
1 row in set (0.01 sec)
==============================================

其中Slave_IO_Running 与 Slave_SQL_Running 的值都必须为YES，才表明状态正常。

如果主服务器已经存在应用数据，则在进行主从复制时，需要做以下处理：
(1)主数据库进行锁表操作，不让数据再进行写入动作
mysql> FLUSH TABLES WITH READ LOCK;

(2)查看主数据库状态
mysql> show master status;

(3)记录下 FILE 及 Position 的值。
将主服务器的数据文件（整个/opt/mysql/data目录）复制到从服务器，建议通过tar归档压缩后再传到从服务器解压。

(4)取消主数据库锁定
mysql> UNLOCK TABLES;

2.3 验证主从复制效果

主服务器上的操作
在主服务器上创建数据库first_db
mysql> create database first_db;
Query Ok, 1 row affected (0.01 sec)

在主服务器上创建表first_tb
mysql> create table first_tb(id int(3),name char(10));
Query Ok, 1 row affected (0.00 sec)

在主服务器上的表first_tb中插入记录
mysql> insert into first_tb values (001,’myself’);
Query Ok, 1 row affected (0.00 sec)

在从服务器上查看
mysql> show databases;
=============================
+--------------------+
| Database |
+--------------------+
| information_schema |
| first_db |
| mysql |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.01 sec)
=============================
数据库first_db已经自动生成

mysql> use first_db
Database chaged

mysql> show tables;
=============================
+--------------------+
| Tables_in_first_db |
+--------------------+
| first_tb |
+--------------------+
1 row in set (0.02 sec)
=============================
数据库表first_tb也已经自动创建

mysql> select * from first_tb;
=============================
+------+------+
| id | name |
+------+------+
| 1 | myself |
+------+------+
1 rows in set (0.00 sec)
=============================
记录也已经存在

由此，整个MySQL主从复制的过程就完成了，接下来，我们进行MySQL读写分离的安装与配置。

三、MySQL读写分离
场景描述：
数据库Master主服务器：192.168.10.130
数据库Slave从服务器：192.168.10.131
MySQL-Proxy调度服务器：192.168.10.132

以下操作，均是在192.168.10.132即MySQL-Proxy调度服务器 上进行的。

3.1 MySQL的安装与配置
具体的安装过程与上文相同。

3.2 检查系统所需软件包
通过 rpm -qa | grep name 的方式验证以下软件包是否已全部安装。
gcc* gcc-c++* autoconf* automake* zlib* libxml* ncurses-devel* libmcrypt* libtool* flex* pkgconfig*
libevent* glib*

若缺少相关的软件包，可通过yum -y install方式在线安装，或直接从系统安装光盘中找到并通过rpm -ivh方式安装。

3.3 编译安装lua
MySQL-Proxy的读写分离主要是通过rw-splitting.lua脚本实现的，因此需要安装lua。

lua可通过以下方式获得
从http://www.lua.org/download.html下载源码包

从rpm.pbone.net搜索相关的rpm包
download.fedora.redhat.com/pub/fedora/epel/5/i386/lua-5.1.4-4.el5.i386.rpm
download.fedora.redhat.com/pub/fedora/epel/5/x86_64/lua-5.1.4-4.el5.x86_64.rpm

这里我们建议采用源码包进行安装
cd /opt/install
wget http://www.lua.org/ftp/lua-5.1.4.tar.gz
tar zvfx lua-5.1.4.tar.gz
cd lua-5.1.4

vi src/Makefile
在 CFLAGS= -O2 -Wall $(MYCFLAGS) 这一行记录里加上-fPIC，更改为 CFLAGS= -O2 -Wall -fPIC $(MYCFLAGS) 来避免编译过程中出现错误。

make linux
make install

cp etc/lua.pc /usr/lib/pkgconfig/
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/lib/pkgconfig

3.4 安装配置MySQL-Proxy
MySQL-Proxy可通过以下网址获得：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/

推荐采用已经编译好的二进制版本，因为采用源码包进行编译时，最新版的MySQL-Proxy对automake，glib以及libevent的版本都有很高的要求，而这些软件包都是系统的基础套件，不建议强行进行更新。
并且这些已经编译好的二进制版本在解压后都在统一的目录内，因此建议选择以下版本：
32位RHEL5平台：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.1-linux-rhel5-x86-32bit.tar.gz
64位RHEL5平台：
http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.1-linux-rhel5-x86-64bit.tar.gz

测试平台为RHEL5 32位，因此选择32位的软件包
wget http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.1-linux-rhel5-x86-32bit.tar.gz

tar xzvf mysql-proxy-0.8.1-linux-rhel5-x86-32bit.tar.gz
mv mysql-proxy-0.8.1-linux-rhel5-x86-32bit /opt/mysql-proxy

创建mysql-proxy服务管理脚本
mkdir /opt/mysql-proxy/init.d/

vim mysql-proxy

01    #!/bin/sh
02    #
03    # mysql-proxy This script starts and stops the mysql-proxy daemon
04    #
05    # chkconfig: - 78 30
06    # processname: mysql-proxy
07    # description: mysql-proxy is a proxy daemon to mysql
08     
09    # Source function library.
10    . /etc/rc.d/init.d/functions
11     
12    #PROXY_PATH=/usr/local/bin
13    PROXY_PATH=/opt/mysql-proxy/bin
14     
15    prog="mysql-proxy"
16     
17    # Source networking configuration.
18    . /etc/sysconfig/network
19     
20    # Check that networking is up.
21    [ ${NETWORKING} = "no" ] && exit 0
22     
23    # Set default mysql-proxy configuration.
24    #PROXY_OPTIONS="--daemon"
25    PROXY_OPTIONS="--admin-username=root --admin-password=password --proxy-read-only-backend-addresses=192.168.10.131:3306 --proxy-backend-addresses=192.168.10.130:3306  --admin-lua-script=/opt/mysql-proxy/lib/mysql-proxy/lua/admin.lua --proxy-lua-script=/opt/mysql-proxy/scripts/rw-splitting.lua"
26    PROXY_PID=/opt/mysql-proxy/run/mysql-proxy.pid
27     
28    # Source mysql-proxy configuration.
29    if [ -f /etc/sysconfig/mysql-proxy ]; then
30            . /etc/sysconfig/mysql-proxy
31    fi
32     
33    PATH=$PATH:/usr/bin:/usr/local/bin:$PROXY_PATH
34     
35    # By default it's all good
36    RETVAL=0
37     
38    # See how we were called.
39    case "$1" in
40      start)
41            # Start daemon.
42            echo -n $"Starting $prog: "
43            $NICELEVEL $PROXY_PATH/mysql-proxy $PROXY_OPTIONS --daemon --pid-file=$PROXY_PID --user=mysql --log-level=warning --log-file=/opt/mysql-proxy/log/mysql-proxy.log
44            RETVAL=$?
45            echo
46            if [ $RETVAL = 0 ]; then
47                    touch /var/lock/subsys/mysql-proxy
48            fi
49           ;;
50      stop)
51            # Stop daemons.
52            echo -n $"Stopping $prog: "
53            killproc $prog
54            RETVAL=$?
55            echo
56            if [ $RETVAL = 0 ]; then
57                    rm -f /var/lock/subsys/mysql-proxy
58                    rm -f $PROXY_PID
59            fi
60           ;;
61      restart)
62            $0 stop
63            sleep 3
64            $0 start
65           ;;
66      condrestart)
67           [ -e /var/lock/subsys/mysql-proxy ] && $0 restart
68          ;;
69      status)
70            status mysql-proxy
71            RETVAL=$?
72           ;;
73      *)
74            echo "Usage: $0 {start|stop|restart|status|condrestart}"
75            RETVAL=1
76           ;;
77    esac
78     
79    exit $RETVAL

==============================================
PROXY_PATH=/opt/mysql-proxy/bin //定义mysql-proxy服务二进制文件路径

PROXY_OPTIONS="--admin-username=root \ //定义内部管理服务器账号
--admin-password=password \ //定义内部管理服务器密码
--proxy-read-only-backend-addresses=192.168.10.131:3306 \ //定义后端只读从服务器地址
--proxy-backend-addresses=192.168.10.130:3306 \ //定义后端主服务器地址
--admin-lua-script=/opt/mysql-proxy/lib/mysql-proxy/lua/admin.lua \ //定义lua管理脚本路径
--proxy-lua-script=/opt/mysql-proxy/scripts/rw-splitting.lua" \ //定义lua读写分离脚本路径

PROXY_PID=/opt/mysql-proxy/run/mysql-proxy.pid //定义mysql-proxy PID文件路径

$NICELEVEL $PROXY_PATH/mysql-proxy $PROXY_OPTIONS \
--daemon \ //定义以守护进程模式启动
--keepalive \ //使进程在异常关闭后能够自动恢复
--pid-file=$PROXY_PID \ //定义mysql-proxy PID文件路径
--user=mysql \ //以mysql用户身份启动服务
--log-level=warning \ //定义log日志级别，由高到低分别有(error|warning|info|message|debug)
--log-file=/opt/mysql-proxy/log/mysql-proxy.log //定义log日志文件路径
==============================================

cp mysql-proxy /opt/mysql-proxy/init.d/
chmod +x /opt/mysql-proxy/init.d/mysql-proxy

mkdir /opt/mysql-proxy/run
mkdir /opt/mysql-proxy/log

mkdir /opt/mysql-proxy/scripts

配置并使用rw-splitting.lua读写分离脚本
最新的脚本我们可以从最新的mysql-proxy源码包中获取
cd /opt/install

wget http://mysql.cdpa.nsysu.edu.tw/Downloads/MySQL-Proxy/mysql-proxy-0.8.1.tar.gz

tar xzvf mysql-proxy-0.8.1.tar.gz
cd mysql-proxy-0.8.1
cp lib/rw-splitting.lua /opt/mysql-proxy/scripts

修改读写分离脚本rw-splitting.lua
修改默认连接，进行快速测试，不修改的话要达到连接数为4时才启用读写分离
vim /opt/mysql-proxy/scripts/rw-splitting.lua
=============================
-- connection pool
if not proxy.global.config.rwsplit then
proxy.global.config.rwsplit = {
min_idle_connections = 1, //默认为4
max_idle_connections = 1, //默认为8
is_debug = false
}
end
=============================

修改完成后，启动mysql-proxy
/opt/mysql-proxy/init.d/mysql-proxy start

3.5 测试读写分离效果
创建用于读写分离的数据库连接用户
登陆主数据库服务器192.168.10.130，通过命令行登录管理MySQL服务器
/opt/mysql/bin/mysql -uroot -p'new-password'
mysql> GRANT ALL ON *.* TO 'proxy1'@'192.168.10.132' IDENTIFIED BY 'password';
由于我们配置了主从复制功能，因此从数据库服务器192.168.10.131上已经同步了此操作。

为了清晰的看到读写分离的效果，需要暂时关闭MySQL主从复制功能
登陆从数据库服务器192.168.10.131，通过命令行登录管理MySQL服务器
/opt/mysql/bin/mysql -uroot -p'new-password'

关闭Slave同步进程
mysql> stop slave;
Query OK, 0 rows affected (0.00 sec)

连接MySQL-Proxy
/opt/mysql/bin/mysql -uproxy1 -p'password' -P4040 -h192.168.10.132

登陆成功后，在first_db数据的first_tb表中插入两条记录
mysql> use first_db;
Database changed
mysql> insert into first_tb values (007,’first’);
Query Ok, 1 row affected (0.00 sec)
mysql> insert into first_tb values (110,’second’);
Query Ok, 1 row affected (0.00 sec)

查询记录
mysql> select * from first_tb;
=============================
+------+------+
| id | name |
+------+------+
| 1 | myself |
+------+------+
1 rows in set (0.00 sec)
=============================
通过读操作并没有看到新记录

mysql> quit
退出MySQL-Proxy

下面，分别登陆到主从数据库服务器，对比记录信息
首先，检查主数据库服务器
mysql> select * from first_tb;
=============================
+------+------+
| id | name |
+------+------+
| 1 | myself |
+------+------+
| 007 | first |
+------+------+
| 110 | second |
+------+------+
3 rows in set (0.00 sec)
=============================
两条新记录都已经存在

然后，检查从数据库服务器
mysql> select * from first_tb;
=============================
+------+------+
| id | name |
+------+------+
| 1 | myself |
+------+------+
1 rows in set (0.00 sec)
=============================
没有新记录存在

由此验证，我们已经实现了MySQL读写分离，目前所有的写操作都全部在Master主服务器上，用来避免数据的不同步；
另外，所有的读操作都分摊给了其它各个Slave从服务器上，用来分担数据库压力。

经验分享：
1.当MySQL主从复制在 show slave status\G 时出现Slave_IO_Running或Slave_SQL_Running 的值不为YES时，需要首先通过 stop slave 来停止从服务器，然后再执行一次本文 2.1与2.2 章节中的步骤即可恢复，但如果想尽可能的同步更多的数据，可以在Slave上将master_log_pos节点的值在之前同步失效的值的基础上增大一 些，然后反复测试，直到同步OK。因为MySQL主从复制的原理其实就是从服务器读取主服务器的binlog，然后根据binlog的记录来更新数据库。

2.MySQL-Proxy的rw-splitting.lua脚本在网上有很多版本，但是最准确无误的版本仍然是源码包中所附带的lib/rw-splitting.lua脚本，如果有lua脚本编程基础的话，可以在这个脚本的基础上再进行优化；

3.MySQL-Proxy实际上非常不稳定，在高并发或有错误连接的情况下，进程很容易自动关闭，因此打开--keepalive参数让进程自动 恢复是个比较好的办法，但还是不能从根本上解决问题，因此通常最稳妥的做法是在每个从服务器上安装一个MySQL-Proxy供自身使用，虽然比较低效但 却能保证稳定性；

4.一主多从的架构并不是最好的架构，通常比较优的做法是通过程序代码和中间件等方面，来规划，比如设置对表数据的自增id值差异增长等方式来实现两个或多个主服务器，但一定要注意保证好这些主服务器数据的完整性，否则效果会比多个一主多从的架构还要差；

5.MySQL-Cluster 的稳定性也不是太好；

6.Amoeba for MySQL 是一款优秀的中间件软件，同样可以实现读写分离，负载均衡等功能，并且稳定性要大大超过MySQL-Proxy，建议大家用来替代MySQL-Proxy，甚至MySQL-Cluster。

原文出处：http://heylinux.com/archives/1004.html

为此，我们进行了一系列数据产品的研发，比如为大家所熟知的量子统计、数据魔方和淘宝指数等。尽管从业务层面来讲，数据产品的研发难度并不高；但在 “海量”的限定下，数据产品的计算、存储和检索难度陡然上升。本文将以数据魔方为例，向大家介绍淘宝在海量数据产品技术架构方面的探索。

淘宝海量数据产品技术架构

数据产品的一个最大特点是数据的非实时写入，正因为如此，我们可以认为，在一定的时间段内，整个系统的数据是只读的。这为我们设计缓存奠定了非常重要的基础。

按照数据的流向来划分，我们把淘宝数据产品的技术架构分为五层（如图1所示），分别是数据源、计算层、存储层、查询层和产品层。位于架构顶端的是我们的数据来源层，这里有淘宝主站的用户、店铺、商品和交易等数据库，还有用户的浏览、搜索等行为日志等。这一系列的数据是数据产品最原始的生命力所在。

在数据源层实时产生的数据，通过淘宝自主研发的数据传输组件DataX、DbSync和Timetunnel准实时地传输到一个有1500个节点的 Hadoop集群上，这个集群我们称之为“云梯”，是计算层的主要组成部分。在“云梯”上，我们每天有大约40000个作业对1.5PB的原始数据按照产品需求进行不同的MapReduce计算。这一计算过程通常都能在凌晨两点之前完成。相对于前端产品看到的数据，这里的计算结果很可能是一个处于中间状态的结果，这往往是在数据冗余与前端计算之间做了适当平衡的结果。

不得不提的是，一些对实效性要求很高的数据，例如针对搜索词的统计数据，我们希望能尽快推送到数据产品前端。这种需求再采用“云梯”来计算效率将是比较低的，为此我们做了流式数据的实时计算平台，称之为“银河”。“银河”也是一个分布式系统，它接收来自TimeTunnel的实时消息，在内存中做实时计算，并把计算结果在尽可能短的时间内刷新到NoSQL存储设备中，供前端产品调用。

容易理解，“云梯”或者“银河”并不适合直接向产品提供实时的数据查询服务。这是因为，对于“云梯”来说，它的定位只是做离线计算的，无法支持较高的性能和并发需求；而对于“银河”而言，尽管所有的代码都掌握在我们手中，但要完整地将数据接收、实时计算、存储和查询等功能集成在一个分布式系统中，避免不了分层，最终仍然落到了目前的架构上。

为此，我们针对前端产品设计了专门的存储层。在这一层，我们有基于MySQL的分布式关系型数据库集群MyFOX和基于HBase的NoSQL存储集群Prom，在后面的文字中，我将重点介绍这两个集群的实现原理。除此之外，其他第三方的模块也被我们纳入存储层的范畴。

存储层异构模块的增多，对前端产品的使用带来了挑战。为此，我们设计了通用的数据中间层——glider——来屏蔽这个影响。glider以HTTP协议对外提供restful方式的接口。数据产品可以通过一个唯一的URL获取到它想要的数据。

以上是淘宝海量数据产品在技术架构方面的一个概括性的介绍，接下来我将重点从四个方面阐述数据魔方设计上的特点。

关系型数据库仍然是王道

关系型数据库（RDBMS）自20世纪70年代提出以来，在工业生产中得到了广泛的使用。经过三十多年的长足发展，诞生了一批优秀的数据库软件，例如Oracle、MySQL、DB2、Sybase和SQL Server等。

尽管相对于非关系型数据库而言，关系型数据库在分区容忍性（Tolerance to Network Partitions）方面存在劣势，但由于它强大的语义表达能力以及数据之间的关系表达能力，在数据产品中仍然占据着不可替代的作用。

淘宝数据产品选择MySQL的MyISAM引擎作为底层的数据存储引擎。在此基础上，为了应对海量数据，我们设计了分布式MySQL集群的查询代理层——MyFOX，使得分区对前端应用透明。

目前，存储在MyFOX中的统计结果数据已经达到10TB，占据着数据魔方总数据量的95%以上，并且正在以每天超过6亿的增量增长着（如图2所示）。这些数据被我们近似均匀地分布到20个MySQL节点上，在查询时，经由MyFOX透明地对外服务（如图3所示）。

值得一提的是，在MyFOX现有的20个节点中，并不是所有节点都是“平等”的。一般而言，数据产品的用户更多地只关心“最近几天”的数据，越早的数据，越容易被冷落。为此，出于硬件成本考虑，我们在这20个节点中分出了“热节点”和“冷节点”（如图4所示）。

顾名思义，“热节点”存放最新的、被访问频率较高的数据。对于这部分数据，我们希望能给用户提供尽可能快的查询速度，所以在硬盘方面，我们选择了每分钟15000转的SAS硬盘，按照一个节点两台机器来计算，单位数据的存储成本约为4.5W/TB。相对应地，“冷数据”我们选择了每分钟7500转的 SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。

将冷热数据进行分离的另外一个好处是可以有效降低内存磁盘比。从图4可以看出，“热节点”上单机只有24GB内存，而磁盘装满大约有 1.8TB（300 * 12 * 0.5 / 1024），内存磁盘比约为4:300，远远低于MySQL服务器的一个合理值。内存磁盘比过低导致的后果是，总有一天，即使所有内存用完也存不下数据的索引了——这个时候，大量的查询请求都需要从磁盘中读取索引，效率大打折扣。
NoSQL是SQL的有益补充

在MyFOX出现之后，一切都看起来那么完美，开发人员甚至不会意识到MyFOX的存在，一条不用任何特殊修饰的SQL语句就可以满足需求。这个状态持续了很长一段时间，直到有一天，我们碰到了传统的关系型数据库无法解决的问题——全属性选择器（如图5所示）。

这是一个非常典型的例子。为了说明问题，我们仍然以关系型数据库的思路来描述。对于笔记本电脑这个类目，用户某一次查询所选择的过滤条件可能包括 “笔记本尺寸”、“笔记本定位”、“硬盘容量”等一系列属性（字段），并且在每个可能用在过滤条件的属性上，属性值的分布是极不均匀的。在图5中我们可以看到，笔记本电脑的尺寸这一属性有着10个枚举值，而“蓝牙功能”这个属性值是个布尔值，数据的筛选性非常差。

在用户所选择的过滤条件不确定的情况下，解决全属性问题的思路有两个：一个是穷举所有可能的过滤条件组合，在“云梯”上进行预先计算，存入数据库供查询；另一个是存储原始数据，在用户查询时根据过滤条件筛选出相应的记录进行现场计算。很明显，由于过滤条件的排列组合几乎是无法穷举的，第一种方案在现实中是不可取的；而第二种方案中，原始数据存储在什么地方？如果仍然用关系型数据库，那么你打算怎样为这个表建立索引？

这一系列问题把我们引到了“创建定制化的存储、现场计算并提供查询服务的引擎”的思路上来，这就是Prometheus（如图6所示）。

从图6可以看出，我们选择了HBase作为Prom的底层存储引擎。之所以选择HBase，主要是因为它是建立在HDFS之上的，并且对于 MapReduce有良好的编程接口。尽管Prom是一个通用的、解决共性问题的服务框架，但在这里，我们仍然以全属性选择为例，来说明Prom的工作原理。这里的原始数据是前一天在淘宝上的交易明细，在HBase集群中，我们以属性对（属性与属性值的组合）作为row-key进行存储。而row-key 对应的值，我们设计了两个column-family，即存放交易ID列表的index字段和原始交易明细的data字段。在存储的时候，我们有意识地让每个字段中的每一个元素都是定长的，这是为了支持通过偏移量快速地找到相应记录，避免复杂的查找算法和磁盘的大量随机读取请求。

图7用一个典型的例子描述的Prom在提供查询服务时的工作原理，限于篇幅，这里不做详细描述。值得一提的是，Prom支持的计算并不仅限于求和 SUM运算，统计意义上的常用计算都是支持的。在现场计算方面，我们对Hbase进行了扩展，Prom要求每个节点返回的数据是已经经过“本地计算”的局部最优解，最终的全局最优解只是各个节点返回的局部最优解的一个简单汇总。很显然，这样的设计思路是要充分利用各个节点的并行计算能力，并且避免大量明细数据的网络传输开销。

用中间层隔离前后端

上文提到过，MyFOX和Prom为数据产品的不同需求提供了数据存储和底层查询的解决方案，但随之而来的问题是，各种异构的存储模块给前端产品的使用带来了很大的挑战。并且，前端产品的一个请求所需要的数据往往不可能只从一个模块获取。

举个例子，我们要在数据魔方中看昨天做热销的商品，首先从MyFOX中拿到一个热销排行榜的数据，但这里的“商品”只是一个ID，并没有ID所对应的商品描述、图片等数据。这个时候我们要从淘宝主站提供的接口中去获取这些数据，然后一一对应到热销排行榜中，最终呈现给用户。

有经验的读者一定可以想到，从本质上来讲，这就是广义上的异构“表”之间的JOIN操作。那么，谁来负责这个事情呢？很容易想到，在存储层与前端产品之间增加一个中间层，它负责各个异构“表”之间的数据JOIN和UNION等计算，并且隔离前端产品和后端存储，提供统一的数据查询服务。这个中间层就是glider（如图8所示）。

缓存是系统化的工程

除了起到隔离前后端以及异构“表”之间的数据整合的作用之外，glider的另外一个不容忽视的作用便是缓存管理。上文提到过，在特定的时间段内，我们认为数据产品中的数据是只读的，这是利用缓存来提高性能的理论基础。

在图8中我们看到，glider中存在两层缓存，分别是基于各个异构“表”（datasource）的二级缓存和整合之后基于独立请求的一级缓存。除此之外，各个异构“表”内部可能还存在自己的缓存机制。细心的读者一定注意到了图3中MyFOX的缓存设计，我们没有选择对汇总计算后的最终结果进行缓存，而是针对每个分片进行缓存，其目的在于提高缓存的命中率，并且降低数据的冗余度。

大量使用缓存的最大问题就是数据一致性问题。如何保证底层数据的变化在尽可能短的时间内体现给最终用户呢？这一定是一个系统化的工程，尤其对于分层较多的系统来说。

图9向我们展示了数据魔方在缓存控制方面的设计思路。用户的请求中一定是带了缓存控制的“命令”的，这包括URL中的query string，和 HTTP头中的“If-None-Match”信息。并且，这个缓存控制“命令”一定会经过层层传递，最终传递到底层存储的异构“表”模块。各异构“表” 除了返回各自的数据之外，还会返回各自的数据缓存过期时间（ttl），而glider最终输出的过期时间是各个异构“表”过期时间的最小值。这一过期时间也一定是从底层存储层层传递，最终通过HTTP头返回给用户浏览器的。

缓存系统不得不考虑的另一个问题是缓存穿透与失效时的雪崩效应。缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。在数据魔方里，我们采用了一个更为简单粗暴的方法，如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存失效时的雪崩效应对底层系统的冲击非常可怕。遗憾的是，这个问题目前并没有很完美的解决方案。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。在数据魔方中，我们设计的缓存过期机制理论上能够将各个客户端的数据失效时间均匀地分布在时间轴上，一定程度上能够避免缓存同时失效带来的雪崩效应。

结束语

正是基于本文所描述的架构特点，数据魔方目前已经能够提供压缩前80TB的数据存储空间，数据中间层glider支持每天4000万的查询请求，平均响应时间在28毫秒（6月1日数据），足以满足未来一段时间内的业务增长需求。

尽管如此，整个系统中仍然存在很多不完善的地方。一个典型的例子莫过于各个分层之间使用短连接模式的HTTP协议进行通信。这样的策略直接导致在流量高峰期单机的TCP连接数非常高。所以说，一个良好的架构固然能够在很大程度上降低开发和维护的成本，但它自身一定是随着数据量和流量的变化而不断变化的。我相信，过不了几年，淘宝数据产品的技术架构一定会是另外的样子。

MongoDB的源代码依赖了一些基础组件，如js引擎Spider Monkey，正则表达式引擎PCRE，安装构建工具Scons，以及C++的boost库等

1、准备

wget http://downloads.mongodb.org/src/mongodb-src-r1.8.2.tar.gz
wget http://sourceforge.net/projects/scons/files/scons/2.1.0.alpha.20101125/scons-2.1.0.alpha.20101125.tar.gz/download
wget http://ftp.mozilla.org/pub/mozilla.org/js/js-1.7.0.tar.gz
wget http://sourceforge.net/projects/pcre/files/pcre/7.4/pcre-7.4.tar.gz/download
wget http://downloads.sourceforge.net/project/boost/boost/1.42.0/boost_1_42_0.tar.gz?use_mirror=cdnetworks-kr-1

2、scons编译安装

tar zxvf scons-2.1.0.alpha.20101125.tar.gz
cd scons-2.1.0.alpha.20101125
python setup.py install

3、pcre编译安装

tar zxvf pcre-7.4.tar.gz
cd pcre-7.4
configure --enable-unicode-properties
make -j 2 && make install

configure中要加入--enable-unicode-properties支持，要不运行mongod会出现下面错误

Fri Dec 30 23:53:45 Assertion: 10342:pcre not compiled with utf8 support
0x53f16a 0x5cfda1 0x8945f3 0x338101d994 0x4c0e49
/usr/local/mongodb/bin/mongod(_ZN5mongo11msgassertedEiPKc+0x12a) [0x53f16a]
/usr/local/mongodb/bin/mongod(_ZN5mongo6RXTest3runEv+0x3b1) [0x5cfda1]
/usr/local/mongodb/bin/mongod(main+0x5c73) [0x8945f3]
/lib64/libc.so.6(__libc_start_main+0xf4) [0x338101d994]
/usr/local/mongodb/bin/mongod(__gxx_personality_v0+0x451) [0x4c0e49]

4、js编译安装

tar zxvf js-1.7.0.tar.gz
cd js/src
export CFLAGS="-DJS_C_STRINGS_ARE_UTF8"
make -f Makefile.ref
JS_DIST=/usr make -f Makefile.ref export

5、boost编译安装

tar -zxvf boost_1_42_0.tar.gz
cd boost_1_42_0/
#使用下面的命令创建boost自己的编译工具bjam（目的是保证Boost在任何平台上都能用bjam编译），类似于GNU Make。
./bootstrap.sh
#会安装头文件和库文件到相应指定目录，头文件安装到/usr/local/include下，库文件安装到/usr/local/lib下
install
#最后执行的创建命令：
./bjam –without-python –layout=tagged variant=debug,release link=static,shared runtime-link=shared threading=multi stage

6、mongodb编译安装

tar -xzvf mongodb-src-r1.8.2.tar.tar
cd mongodb-src-r1.8.2/
scons all
scons --prefix=/usr/local/mongodb --full install

安装成功后 安装到/usr/local/mongodb下

文件结果

bin
GNU-AGPL-3.0
include
lib64
README
THIRD-PARTY-NOTICES

7、加入环境变量

/etc/profile 加入

CLASSPATH=.:/usr/local/lib
export CLASSPATH

然后source /etc/profile

完成后就可以运行mongodb。

[root@test_192.168.4.95 mongodb]# bin/mongo
MongoDB shell version: 1.8.2
connecting to: test

运行可能会出现下面错误

/usr/local/mongodb/bin/mongod: error while loading shared libraries: libboost_system.so.1.42.0: cannot open shared object file: No such file or directory

解决方法

echo "/usr/local/lib" > /etc/ld.so.conf.d/usr_local_lib.conf
/sbin/ldconfig

mongodb的Replication是通过一个日志来存储写操作的，这个日志就叫做Oplog。

在默认情况下,对于64位的mongodb,oplogs都相当大-可能是5%的磁盘空间。通常而言,这是一种合理的设置。可以通过mongod --oplogSize来改变Oplog的日志大小。

Oplog的collectio为：

local.oplog.$main for master/slave replication;

local.oplog.rs for replica sets

如 master/slave replication：

> use local               
switched to db local
> db.oplog.$main.help()
DBCollection help
        db.oplog.$main.find().help() - show DBCursor help
        db.oplog.$main.count()
        db.oplog.$main.dataSize()
        db.oplog.$main.distinct( key ) - eg. db.oplog.$main.distinct( 'x' )
        db.oplog.$main.drop() drop the collection
        db.oplog.$main.dropIndex(name)
        db.oplog.$main.dropIndexes()
        db.oplog.$main.ensureIndex(keypattern,options) - options should be an object with these possible fields: name, unique, dropDups
        db.oplog.$main.reIndex()
        db.oplog.$main.find( [query] , [fields]) - first parameter is an optional query filter. second parameter is optional set of fields to return.
                                           e.g. db.oplog.$main.find( { x : 77 } , { name : 1 , x : 1 } )
        db.oplog.$main.find(...).count()
        db.oplog.$main.find(...).limit(n)
        db.oplog.$main.find(...).skip(n)
        db.oplog.$main.find(...).sort(...)
        db.oplog.$main.findOne([query])
        db.oplog.$main.findAndModify( { update : ... , remove : bool [, query: {}, sort: {}, 'new': false] } )
        db.oplog.$main.getDB() get DB object associated with collection
        db.oplog.$main.getIndexes()
        db.oplog.$main.group( { key : ..., initial: ..., reduce : ...[, cond: ...] } )
        db.oplog.$main.mapReduce( mapFunction , reduceFunction , <optional params> )
        db.oplog.$main.remove(query)
        db.oplog.$main.renameCollection( newName , <dropTarget> ) renames the collection.
        db.oplog.$main.runCommand( name , <options> ) runs a db command with the given name where the first param is the collection name
        db.oplog.$main.save(obj)
        db.oplog.$main.stats()
        db.oplog.$main.storageSize() - includes free space allocated to this collection
        db.oplog.$main.totalIndexSize() - size in bytes of all the indexes
        db.oplog.$main.totalSize() - storage allocated for all data and indexes
        db.oplog.$main.update(query, object[, upsert_bool, multi_bool])
        db.oplog.$main.validate() - SLOW
        db.oplog.$main.getShardVersion() - only for use with sharding
> db.oplog.$main.find()
{ "ts" : { "t" : 1294582140000, "i" : 14 }, "op" : "d", "ns" : "mixi_top_city.building_90", "b" : true, "o" : { "_id" : "6380690_441_30_29" } }
{ "ts" : { "t" : 1294582140000, "i" : 15 }, "op" : "i", "ns" : "mixi_top_city.building_90", "o" : { "_id" : "6380690_441_24_24", "uid" : "6380690", "x" : 24, "y" : 24, "pos" : 1, "btime" : 1294154452, "ntime" : 1294154452, "bid" : 71, "extprop" : 0, "status" : 0, "ucid" : 441 } }
{ "ts" : { "t" : 1294582140000, "i" : 16 }, "op" : "u", "ns" : "mixi_top_city.building_64", "o2" : { "_id" : "16702364_459_14_14" }, "o" : { "$set" : { "status" : 1 } } }
{ "ts" : { "t" : 1294582140000, "i" : 17 }, "op" : "u", "ns" : "mixi_top_city.building_08", "o2" : { "_id" : "6223408_391_30_28" }, "o" : { "$set" : { "ntime" : 1294582321 } } }
{ "ts" : { "t" : 1294582140000, "i" : 18 }, "op" : "u", "ns" : "mixi_top_city.building_03", "o2" : { "_id" : "9882403_353_28_20" }, "o" : { "$set" : { "ntime" : 1294600141 } } }
{ "ts" : { "t" : 1294582140000, "i" : 19 }, "op" : "u", "ns" : "mixi_top_city.building_24", "o2" : { "_id" : "4162924_365_32_28" }, "o" : { "$set" : { "ntime" : 1294582321 } } }
{ "ts" : { "t" : 1294582141000, "i" : 1 }, "op" : "u", "ns" : "mixi_top_city.building_49", "o2" : { "_id" : "32797749_285_28_30" }, "o" : { "$set" : { "ntime" : 1294583341 } } }
{ "ts" : { "t" : 1294582141000, "i" : 2 }, "op" : "u", "ns" : "mixi_top_city.building_50", "o2" : { "_id" : "33768850_425_28_32" }, "o" : { "$set" : { "ntime" : 1294582561 } } }
{ "ts" : { "t" : 1294582141000, "i" : 3 }, "op" : "u", "ns" : "mixi_top_city.building_35", "o2" : { "_id" : "28235635_333_28_36" }, "o" : { "$set" : { "ntime" : 1294582741 } } }
{ "ts" : { "t" : 1294582141000, "i" : 4 }, "op" : "u", "ns" : "mixi_top_city.building_04", "o2" : { "_id" : "25178304_3_32_28" }, "o" : { "$set" : { "ntime" : 1294594141 } } }
{ "ts" : { "t" : 1294582141000, "i" : 5 }, "op" : "u", "ns" : "mixi_top_city.building_18", "o2" : { "_id" : "7304918_445_32_26" }, "o" : { "$set" : { "ntime" : 1294582321 } } }
{ "ts" : { "t" : 1294582141000, "i" : 6 }, "op" : "u", "ns" : "mixi_top_city.building_93", "o2" : { "_id" : "5003293_453_20_24" }, "o" : { "$set" : { "status" : 1 } } }
{ "ts" : { "t" : 1294582141000, "i" : 7 }, "op" : "u", "ns" : "mixi_top_city.building_59", "o2" : { "_id" : "19601459_485_28_30" }, "o" : { "$set" : { "ntime" : 1294582741 } } }
{ "ts" : { "t" : 1294582141000, "i" : 8 }, "op" : "u", "ns" : "mixi_top_city.building_47", "o2" : { "_id" : "23744647_273_22_46" }, "o" : { "$set" : { "ntime" : 1294582741 } } }
{ "ts" : { "t" : 1294582141000, "i" : 9 }, "op" : "u", "ns" : "mixi_top_city.building_50", "o2" : { "_id" : "3549050_451_20_30" }, "o" : { "$set" : { "ntime" : 1294583041 } } }
{ "ts" : { "t" : 1294582141000, "i" : 10 }, "op" : "d", "ns" : "mixi_top_city.building_77", "b" : true, "o" : { "_id" : "8577977_215_44_38" } }
{ "ts" : { "t" : 1294582141000, "i" : 11 }, "op" : "i", "ns" : "mixi_top_city.building_77", "o" : { "_id" : "8577977_215_44_38", "uid" : "8577977", "x" : 44, "y" : 38, "pos" : 1, "btime" : 1293955498, "ntime" : 1294486420, "bid" : 18, "extprop" : 0, "status" : 0, "ucid" : 215 } }
{ "ts" : { "t" : 1294582141000, "i" : 12 }, "op" : "u", "ns" : "mixi_top_city.building_89", "o2" : { "_id" : "21405489_541_20_24" }, "o" : { "$set" : { "status" : 1 } } }
{ "ts" : { "t" : 1294582141000, "i" : 13 }, "op" : "u", "ns" : "mixi_top_city.building_60", "o2" : { "_id" : "6479060_395_16_32" }, "o" : { "$set" : { "ntime" : 1294582321 } } }
{ "ts" : { "t" : 1294582141000, "i" : 14 }, "op" : "u", "ns" : "mixi_top_city.building_38", "o2" : { "_id" : "12696438_1037_28_40" }, "o" : { "$set" : { "ntime" : 1294583042 } } }
has more
>

Oplog日志中：

ts:Timestamp 这个操作的时间戳

op:operation 操作

i – insert
d – delete
u – update
c – command
n – no-op

ns:Namespace也就是操作的collection name

o:Document

查看master的Oplog信息：

[root@tc-03 cacti]# mongo
MongoDB shell version: 1.6.4
connecting to: test
> db.printReplicationInfo();
configured oplog size:   7503.049113600001MB
log length start to end: 3566227secs (990.62hrs)
oplog first event time:  Tue Jan 11 2011 12:17:03 GMT+0900 (KST)
oplog last event time:   Mon Feb 21 2011 18:54:10 GMT+0900 (KST)
now:                     Mon Feb 21 2011 18:54:10 GMT+0900 (KST)

查看slave的同步状态：

> db.printSlaveReplicationInfo()
source:   192.168.8.173
         syncedTo: Mon Feb 21 2011 18:55:19 GMT+0900 (KST)
                 = 31secs ago (0.01hrs)

一、安装PCRE库
PCRE(Perl Compatible Regular Expressions)，提供高速的正则表达式匹配api。

yum install pcre-devel

或者到ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/下载合适的pcre源码包，然后configure/make/make install

二、安装Spider Monkey库
SpiderMonkey是JavaScript的C实现，可以提供JavaScript的代码解释功能。
到ftp://ftp.mozilla.org/pub/mozilla.org/js/下载js压缩包，解压后进入src目录，并按照如下步骤进行编译安装：

export CFLAGS=”-DJS_C_STRINGS_ARE_UTF8″  make -f Makefile.ref JS_DIST=/usr make -f Makefile.ref export

三、安装SCons
Scons是一个Python写的自动化构建工具，比传统的GNU make更加简便、可靠以及高效。
到http://sourceforge.net/projects/scons/files/scons/下载源码压缩包，解压之后按照如下步骤进行安装：

python setup.py install

四、安装MongoDB
先到http://www.mongodb.org/downloads/下载想要的MongoDB版本。建议下载1.6以上，有很多架构和功能方面的改进。
解压缩之后按照如下步骤进行安装：

scons all scons –prefix=/usr/local/mongodb install

如果想要头文件和lib包，执行

scons –prefix=/usr/local/mongodb –full install

五，让MongoDB跑起来
虽然MongoDB支持在命令行里面添加所有参数，但是为了管理方便，还是应该添加一个配置文件的。然后在命令行里面指定配置文件的位置。
下面是一个简单的配置文件：

vim /usr/local/mongodb/config/mongodb

#Directory and relavent set dbpath = /usr/local/mongodb/data logpath = /usr/local/mongodb/log/mongodb.log repairpath = /usr/local/mongodb/repair pidfilepath = /usr/local/mongodb/mongodb.pid directoryperdb = true #sysinfo = true #verbose = true logappend = true #cpu = true #Network and security set noauth = true port = 8888 maxConns = 1024 fork = true #Management #nohttpinterface = true rest = true quota = true quotaFiles = 1024 nssize = 16 #syncdelay = 5

值得注意的是，类似 nohttpinterface = false 的配置是无效的。因为这些选项默认为false，不需要配置。

运行MongDB：

mongod –config /usr/local/mongodb/config/mongodb

启动脚本 mongodb-start.sh

#!/bin/sh /usr/local/mongodb/bin/mongod --config /usr/local/mongodb/config/mongodb ## --upgrade \ ##runs a database upgrade option if needed \

关闭脚本 mongodb-stop.sh

#!/bin/bash pid=`ps -o pid,command ax | grep mongod | awk '!/awk/ && !/grep/ {print $1}'`; if [ "${pid}" != "" ]; then kill -2 ${pid}; fi

六，做服务

启动脚本init-rpm.sh

#! /bin/sh # # mongodb – this script starts and stops the mongodb daemon # # chkconfig: - 85 15 # description: MongoDB is a non-relational database storage system. # processname: mongodb # config: /opt/config/mongodb # pidfile: /opt/mongodb/mongo.pid PATH=/opt/mongodb/bin:/sbin:/bin:/usr/sbin:/usr/bin NAME=mongodb test -x $DAEMON || exit 0 set -e case "$1" in start) echo -n "Starting MongoDB... " su - mongodb -c "/opt/bin/mongodb-start" ;; stop) echo -n "Stopping MongoDB" /opt/bin/mongodb-stop ;; *) N=/etc/init.d/$NAME echo "Usage: $N {start|stop}" >&2 exit 1 ;; esac exit 0

把以上启动脚本做成服务

#mv init-rpm.sh /etc/init.d/mongodb #chmod +x /etc/init.d/mongodb #chkconfig --add mongodb #chkconfig -–level 345 mongodb on

MongoDB与sql语句对照表

CREATE TABLE USERS (a Number, b Number)

implicit; can be done explicitly

INSERT INTO USERS VALUES(1,1)

db.users.insert({a:1,b:1})

SELECT a,b FROM users

db.users.find({}, {a:1,b:1})

SELECT * FROM users

db.users.find()

SELECT * FROM users WHERE age=33

db.users.find({age:33})

SELECT a,b FROM users WHERE age=33

db.users.find({age:33}, {a:1,b:1})

SELECT * FROM users WHERE age=33 ORDER BY name

db.users.find({age:33}).sort({name:1})

SELECT * FROM users WHERE age>33

db.users.find({'age':{$gt:33}})})

SELECT * FROM users WHERE age<33

db.users.find({'age':{$lt:33}})})

SELECT * FROM users WHERE name LIKE "%Joe%"

db.users.find({name:/Joe/})

SELECT * FROM users WHERE name LIKE "Joe%"

db.users.find({name:/^Joe/})

SELECT * FROM users WHERE age>33 AND age<=40

db.users.find({'age':{$gt:33,$lte:40}})})

SELECT * FROM users ORDER BY name DESC

db.users.find().sort({name:-1})

CREATE INDEX idx_name ON users(name)

db.users.ensureIndex({name:1})

CREATE INDEX idx_name ON users(name,ts DESC)

db.users.ensureIndex({name:1,ts:-1})

SELECT * FROM users WHERE a=1 and b='q'

db.users.find({a:1,b:'q'})

SELECT * FROM users LIMIT 10 SKIP 20

db.users.find().limit(10).skip(20)

SELECT * FROM users WHERE a=1 or b=2

db.users.find( { $or : [ { a : 1 } , { b : 2 } ] } )

SELECT * FROM users LIMIT 1

db.users.findOne()

EXPLAIN SELECT * FROM users WHERE z=3

db.users.find({z:3}).explain()

SELECT DISTINCT last_name FROM users

db.users.distinct('last_name')

SELECT COUNT(*y) FROM users

db.users.count()

SELECT COUNT(*y) FROM users where AGE > 30

db.users.find({age: {'$gt': 30}}).count()

SELECT COUNT(AGE) from users

db.users.find({age: {'$exists': true}}).count()

UPDATE users SET a=1 WHERE b='q'

db.users.update({b:'q'}, {$set:{a:1}}, false, true)

UPDATE users SET a=a+2 WHERE b='q'

db.users.update({b:'q'}, {$inc:{a:2}}, false, true)

DELETE FROM users WHERE z="abc"

db.users.remove({z:'abc'});

mongod每天要产生大量的日志，如果不去管它，我这边一周大约有10~20G的日志出来，可见日志轮询是必须的。

mongodb本身支持日志轮询的信号，所以我的日志轮询脚本如下：

#!/bin/sh

log_dir="/var/log/mongo/"
killall -SIGUSR1 mongod
/usr/bin/find ${log_dir} -name 'mongod.log.*' -mtime +5  -exec rm -f {} \;

然后每天零点零分跑一下。

我有6台mongodb,上面的脚本跑了一两个月一直挺正常。但是最近其中一台在做日志轮询的时候可能是产生了死锁，因为我首先收到了读写锁过多的报警，日志轮询没有成功，客户端也连不进去。收到报警后就连到服务器去看，查查日志，确定问题后重启mongodb就正常了。

这个脚本造成服务中断14分钟，mongodb用的是最新的稳定版本1.8.1，mongodb的稳定性还有待提高。

发生这个问题之后，上面的脚本就不敢再用了，对脚本进行了更改：

#!/bin/sh

log_dir="/var/log/mongo/"
date=`date +%Y-%m-%d`

cat ${log_dir}/mongod.log >> ${log_dir}/mongod.log.${date}
cat /dev/null > ${log_dir}/mongod.log

/usr/bin/find ${log_dir} -name 'mongod.log.*' -mtime +5  -exec rm -f {} \;

然后让他一小时跑一次，目前看还行，就是要多占一点磁盘IO，但是稳定第一，可以确保不会出现上面的问题了。

下面性能测试对比来自LevelDB官方，由 NoSQLFan 进行翻译整理。从结果上看，这不像某些田忌赛马式的性能对比，总体来说还是比较客观全面。通过多种场景下的不同性能测试结果的对比，我们也能对这三个数据库分别擅长和适用的场合有所了解。同时对其性能调优的方法理解也有一定的帮助。

原文链接：leveldb.googlecode.com

下面是对LevelDB、TreeDB、SQLite3 这几个数据库的性能对比测试，分别使用了LevelDB (revision 39) SQLite3 (version 3.7.6.3) 及 Kyoto Cabinet’s (version 1.2.67)这三个版本的数据库。

测试机器配置：six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288 KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz

文件系统：测试脚本分别跑在两台机器上，其文件系统一台为ext3（磁盘为 SATA Hitachi HDS721050CLA362），一台为ext4（配备磁盘 SATA Samsung HD502HJ）

性能测试源码：

• LevelDB: db/db_bench.cc.
• SQLite: doc/bench/db_bench_sqlite3.cc.
• Kyoto TreeDB: doc/bench/db_bench_tree_db.cc.

基本测试

基本测试的条件如下：

• 每个数据库使用4GB内存
• 数据库都处于异步写模式(LevelDB’s sync option, TreeDB’s OAUTOSYNC option, SQLite3’s synchronous options 都关闭)，也就是说写操作不用等数据真正写到磁盘上才返回。
• Key 的长度为16字节
• Value 的长度为100字节 (这个长度才能让数据库的压缩算法能够起作用，将数据压缩至50％大小左右)
• 顺序读写时Key值递增变化
• 随机读时生成随机的Key值

测试结果：

结果显示，在顺序读写和随机写上，LevelDB 在性能上都遥遥领先，在随机读上面 Kyoto Cabinet 引擎稍快一些。

在几种不同策略下进行写操作测试

A. Values 为长数据（数据长度为100,000字节）

LevelDB在Value较长时性能比较低，这是由于LevelDB对每一次写操作都会至少进行两次写动作，一次是写数据文件，另一次是写日志文件。这里慢的主要原因是LevelDB在进行这些操作时对值进行了过多的Copy。

B. 批量写操作

一次写操作写1000条100字节的数据，由于TreeDB不支持批量写入，故未对其进行对比测试

上面结果是由于LevelDB数据的组织方式，导致顺序写和随机写在性能上都变化不大。

C. 同步进行写操作

• 对 LevelDB, 设置 WriteOptions.sync = true.
• 对 TreeDB, 将 TreeDB’s OAUTOSYNC 选项开启.
• 对 SQLite3, 设置 “PRAGMA synchronous = FULL”.

如果你看一下ext4文件系统下的测试数据，你会发现ext3和ext4在表现上非常不同。

D. 无压缩的写操作

LevelDB 和 TreeDB 都支持相应的数据压缩算法(LevelDB 使用的是 Snappy , TreeDB 使用的是 LZO)，由于SQLite不支持压缩，所以这里的测试数据只是从上面的基本测试结果copy过来的。

LevelDB开启压缩比不开启压缩效率更高，而TreeDB则相反，这可能是由于TreeDB采用的压缩算法（LZO）与LevelDB采用的压缩算法（Snappy）相比计算代价更高。

E. 使用更大内存

将每个独立库的内存增大到128MB，对LevelDB来说，其中120MB用来做 write buffer，另外8MB用来做 cache（原来是2MB的 write buffer 和2MB的cache），对SQLite来说，我们不改变其page size，还是保持为1kb，但是我们增大其page数量从4k增加到128k，对TreeDB来说，我们同样不改变其page大小，也只是增大其cache，从4MB增大到128MB。

SQLite 在采用了大内存后性能变化并不大，而 LevelDB 和 TreeDB 的随机写性能却有显著提高。LevelDB 在增大内存后性能提升的原因是其write buffer 更大，从而减少了创建的sorted file的次数。减少了磁盘IO。而 TreeDB 的性能提升原因是由于其数据库的更大部分被映射到内存中了。

在几种不同策略下进行读操作测试

A. 大的Cache空间

我们分配128MB给每个数据库，对LevelDB来说，我们分配8MB给 write buffer，120MB给cache，对另外两个数据库，由于它们不支持区分 write buffer 和cache，所以统一将 cache size设置成128MB。

从结果可以看到，增大Cache在数据库读性能上都有所提升，其中最为显著的是TreeDB，其随机读性能大幅提升。主要是由于有足够的内存使得其所有读操作都几乎是在内存中进行。

B. 无压缩的读操作

下面结果是我们对预先无压缩状态写入的100万条key为16字节、value为100字节的数据后进行的读性能测试。同样的 SQLite 由于不支持压缩，所以下面数据是直接从其基本测试上copy过来的。

结果可以看到，取消压缩对读取性能提升不是特别大，当然，如果你的数据都在内存中的话，执行解压操作也不会对性能造成太大影响。

基于列存储的数据库的优点¶
a)对于聚集操作，比如求sum，明显基于列存储的要比基于行存储的快；
b)对于update操作，不须接触其他列值；
c)基于行存储的数据库在查询每行记录的多个列值更高效的条件是，row-size比较小，这样一次磁盘读取就可以获取整行；
d)基于行存储的数据库在insert一行的时候相对更高效，毕竟可一次写入一个连续空间，即一次single disk seek；

从实际情况上来看，基于行存储的数据库更适合OLTP（联机事务处理系统），基于列存储的数据库更适合OLAP（联机分析处理系统），比如数据仓库。除此之外，同一列必定是同一类型大小，基于列存储的数据库更容易使用高效的存储方式，与之相对，基于行存储的数据库则只能采用随机方式处理列值了。

Vertica 数据库的设计特点¶
a)它是基于列的存储结构，提高了连续的record处理的性能，但是在一般事务中增加了对单独record进行update和delete的开销；
b)“单独”更新（out-of-place updates）和混合存储结构，提高了查询、插入的性能，但增加了update和delete的开销；
c)压缩，减少存储开销和IO带宽开销；
d)完全无共享架构，降低对共享资源的系统竞争；

Vertica数据库运行在基于Linux的网格服务器上，目前应用于Amazon Elastic Compute Cloud的数据库管理系统。

The Vertica Analytic Databas¶
a)重申三大特点：压缩、基于列、表分解；
b)混合数据存储模式，当insert时候，按照写优先分配原则，实现insert与query的高并发操作；
c)自动化数据库结构设计工具，多节点集群系统，所有的数据都会保存在不止一个节点上，即所谓的k-safety，这样可防止单点故障造成的损失；
d)高性能，支持ACID，轻量级事务和并发控制更加适合load和query操作。Vertica的故障恢复模型是基于多节点拷贝，而不是传统的基于日志；
e)灵活部署；
f)监视和管理工具和API；

对于一个node上的vertica数据库，数据存储分为两个部分，一个是读优存储（read-optimized store，ROS），另一个是写优存储（write-optimized store，WOS），每次更新和插入的数据临时放在WOS部分，SQL查询会访问ROS部分，并且ROS存放已经经过压缩和排序的数据，这样就做到了读写并发两不误，通过tuple mover进程定期将WOS的数据压缩排序后拷贝到ROS区域。

对于多个node，一个表的schema首先会按列拆分为多个映射，将每个列排序保存在不同磁盘上。

Vertica数据库设计本身就适合基于列的查询，虽然一些基于行的数据库经过预处理和内部关系视图等操作也可以优化常见查询的速度，但仍和vertica能应付更多不同查询的高性能无法相比，尤其是vertica的的列主动压缩（aggressive compression）。主动压缩，简单的说就是将一个列不同的值的一维存储转换为二维元组（tuple），格式为<个数，列值>，这样的话，即使是date类型的百万条数据，一年最多也只有365个数对，好处不言而喻，节省空间、提高查询速度、方便聚集函数操作。另外，对应浮点数和时间这样的连续数值，也采用了某些处理方式实现了一些排序和压缩（具体没看懂）。

在读优存储（ROS）区域，除了排序压缩外，还有些别的优化处理。比如数据是致密填充（dense packed）的，即占用的磁盘分页内没有空闲，不用考虑后来insert的数据放哪的问题，因为那是tuple mover做的事情。另一个优化是，vertica会提前取出一大块数据用以减少多次磁盘扫描。 Vertica对于各节点上冗余存储的列数据可采用不同排序顺序存储，这样不但利用多拷贝实现了故障恢复，还利用多种排序顺序提高了查询速度，对于每一个给定的sql操作，vertica都会选择一个最合适的排序顺序。

DB designer 根据数据样本和查询样本将逻辑schema映射为多个物理schema，说白了就是将一个行映射拆分为多个行映射，同时保证每个查询的from部分都只来自一个映射。 k-safety，简单的说就是，对于数据库中的每一列，都会在k+1个节点上存储，这样即使k个节点坏掉了也没事。

Vertica开发，支持标准SQL语句，支持JDBC和ODBC，支持perl和python编程，支持PostgreSQL等数据库的应用代码向其平滑移植。但是vertica对于update这样的操作实在是笨拙。

1、High performance – 对数据库高并发读写的需求
web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求，例如像JavaEye网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

2、Huge Storage – 对海量数据的高效率存储和访问的需求
类似Facebook，twitter，Friendfeed这样的SNS网站，每天用户产生海量的用户动态，以Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求
在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

1、数据库事务一致性需求
很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

2、数据库的写实时性和读实时性需求
对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性，比方说我（JavaEye的robbin）发一条消息之后，过几秒乃至十几秒之后，我的订阅者才看到这条动态是完全可以接受的。

3、对复杂的SQL查询，特别是多表关联查询的需求
任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生，现在这两年，各种各样非关系数据库，特别是键值数据库(Key-Value Store DB)风起云涌，多得让人眼花缭乱。前不久国外刚刚举办了NoSQL Conference，各路NoSQL数据库纷纷亮相，加上未亮相但是名声在外的，起码有超过10个开源的NoSQLDB，例如：

Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB，  ……

这些NoSQL数据库，有的是用C/C++编写的，有的是用Java编写的，还有的是用Erlang编写的，每个都有自己的独到之处，看都看不过来了，我(robbin)也只能从中挑选一些比较有特色，看起来更有前景的产品学习和了解一下。这些NoSQL数据库大致可以分为以下的三类：

一、满足极高读写性能需求的Kye-Value数据库：Redis，Tokyo Cabinet， Flare

高性能Key-Value数据库的主要特点就是具有极高的并发读写性能，Redis，Tokyo Cabinet， Flare，这3个Key-Value DB都是用C编写的，他们的性能都相当出色，但出了出色的性能，他们还有自己独特的功能：

1、Redis
Redis是一个很新的项目，刚刚发布了1.0版本。Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过10万次读写操作，是我知道的性能最快的Key-Value DB。

Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存List链表和Set集合的数据结构，而且还支持对List进行各种操作，例如从List两端push和pop数据，取List区间，排序等等，对Set支持各种集合的并集交集操作，此外单个value的最大限制是1GB，不像memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一个功能加强版的memcached来用。

Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，并且它没有原生的可扩展机制，不具有scale（可扩展）能力，要依赖客户端来实现分布式读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。目前使用Redis的网站有github，Engine Yard。

2、Tokyo Cabinet和Tokoy Tyrant
TC和TT的开发者是日本人Mikio Hirabayashi，主要被用在日本最大的SNS网站mixi.jp上，TC发展的时间最早，现在已经是一个非常成熟的项目，也是Kye-Value数据库领域最大的热点，现在被广泛的应用在很多很多网站上。TC是一个高性能的存储引擎，而TT提供了多线程高并发服务器，性能也非常出色，每秒可以处理4-5万次读写操作。

TC除了支持Key-Value存储之外，还支持保存Hashtable数据类型，因此很像一个简单的数据库表，并且还支持基于column的条件查询，分页查询和排序功能，基本上相当于支持单表的基础查询功能了，所以可以简单的替代关系数据库的很多操作，这也是TC受到大家欢迎的主要原因之一，有一个Ruby的项目miyazakiresistance将TT的hashtable的操作封装成和ActiveRecord一样的操作，用起来非常爽。

TC/TT在mixi的实际应用当中，存储了2000万条以上的数据，同时支撑了上万个并发连接，是一个久经考验的项目。TC在保证了极高的并发读写性能的同时，具有可靠的数据持久化机制，同时还支持类似关系数据库表结构的hashtable以及简单的条件，分页和排序操作，是一个很棒的NoSQL数据库。

TC的主要缺点是在数据量达到上亿级别以后，并发写数据性能会大幅度下降，NoSQL: If Only It Was That Easy提到，他们发现在TC里面插入1.6亿条2-20KB数据的时候，写入性能开始急剧下降。看来是当数据量上亿条的时候，TC性能开始大幅度下降，从TC作者自己提供的mixi数据来看，至少上千万条数据量的时候还没有遇到这么明显的写入性能瓶颈。

这个是Tim Yang做的一个Memcached，Redis和Tokyo Tyrant的简单的性能评测，仅供参考

3、Flare
TC是日本第一大SNS网站mixi开发的，而Flare是日本第二大SNS网站green.jp开发的，有意思吧。Flare简单的说就是给TC添加了scale功能。他替换掉了TT部分，自己另外给TC写了网络服务器，Flare的主要特点就是支持scale能力，他在网络服务端之前添加了一个node server，来管理后端的多个服务器节点，因此可以动态添加数据库服务节点，删除服务器节点，也支持failover。如果你的使用场景必须要让TC可以scale，那么可以考虑flare。

flare唯一的缺点就是他只支持memcached协议，因此当你使用flare的时候，就不能使用TC的table数据结构了，只能使用TC的key-value数据结构存储。

二、满足海量存储需求和访问的面向文档的数据库：MongoDB，CouchDB

面向文档的非关系数据库主要解决的问题不是高性能的并发读写，而是保证海量数据存储的同时，具有良好的查询性能。MongoDB是用C++开发的，而CouchDB则是Erlang开发的：

1、MongoDB
MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。他支持的数据结构非常松散，是类似json的bjson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是他支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

Mongo主要解决的是海量数据的访问效率问题，根据官方的文档，当数据量达到50GB以上的时候，Mongo的数据库访问速度是MySQL的10倍以上。Mongo的并发读写效率不是特别出色，根据官方提供的性能测试表明，大约每秒可以处理0.5万－1.5次读写请求。对于Mongo的并发读写性能，我（robbin）也打算有空的时候好好测试一下。

因为Mongo主要是支持海量数据存储的，所以Mongo还自带了一个出色的分布式文件系统GridFS，可以支持海量的数据存储，但我也看到有些评论认为GridFS性能不佳，这一点还是有待亲自做点测试来验证了。

最后由于Mongo可以支持复杂的数据结构，而且带有强大的数据查询功能，因此非常受到欢迎，很多项目都考虑用MongoDB来替代MySQL来实现不是特别复杂的Web应用，比方说why we migrated from MySQL to MongoDB就是一个真实的从MySQL迁移到MongoDB的案例，由于数据量实在太大，所以迁移到了Mongo上面，数据查询的速度得到了非常显著的提升。

MongoDB也有一个ruby的项目MongoMapper，是模仿Merb的DataMapper编写的MongoDB的接口，使用起来非常简单，几乎和DataMapper一模一样，功能非常强大易用。

2、CouchDB
CouchDB现在是一个非常有名气的项目，似乎不用多介绍了。但是我却对CouchDB没有什么兴趣，主要是因为CouchDB仅仅提供了基于HTTP REST的接口，因此CouchDB单纯从并发读写性能来说，是非常糟糕的，这让我立刻抛弃了对CouchDB的兴趣。

三、满足高可扩展性和可用性的面向分布式计算的数据库：Cassandra，Voldemort

面向scale能力的数据库其实主要解决的问题领域和上述两类数据库还不太一样，它首先必须是一个分布式的数据库系统，由分布在不同节点上面的数据库共同构成一个数据库服务系统，并且根据这种分布式架构来提供online的，具有弹性的可扩展能力，例如可以不停机的添加更多数据节点，删除数据节点等等。因此像Cassandra常常被看成是一个开源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java开发的：

1、Cassandra
Cassandra项目是Facebook在2008年开源出来的，随后Facebook自己使用Cassandra的另外一个不开源的分支，而开源出来的Cassandra主要被Amazon的Dynamite团队来维护，并且Cassandra被认为是Dynamite2.0版本。目前除了Facebook之外，twitter和digg.com都在使用Cassandra。

Cassandra的主要特点就是它不是一个数据库，而是由一堆数据库节点共同构成的一个分布式网络服务，对Cassandra的一个写操作，会被复制到其他节点上去，对Cassandra的读操作，也会被路由到某个节点上面去读取。对于一个Cassandra群集来说，扩展性能是比较简单的事情，只管在群集里面添加节点就可以了。我看到有文章说Facebook的Cassandra群集有超过100台服务器构成的数据库群集。

Cassandra也支持比较丰富的数据结构和功能强大的查询语言，和MongoDB比较类似，查询功能比MongoDB稍弱一些，twitter的平台架构部门领导Evan Weaver写了一篇文章介绍Cassandra：http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/，有非常详细的介绍。

Cassandra以单个节点来衡量，其节点的并发读写性能不是特别好，有文章说评测下来Cassandra每秒大约不到1万次读写请求，我也看到一些对这个问题进行质疑的评论，但是评价Cassandra单个节点的性能是没有意义的，真实的分布式数据库访问系统必然是n多个节点构成的系统，其并发性能取决于整个系统的节点数量，路由效率，而不仅仅是单节点的并发负载能力。

2、Voldemort
Voldemort是个和Cassandra类似的面向解决scale问题的分布式数据库系统，Cassandra来自于Facebook这个SNS网站，而Voldemort则来自于Linkedin这个SNS网站。说起来SNS网站为我们贡献了n多的NoSQL数据库，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的资料不是很多，因此我没有特别仔细去钻研，Voldemort官方给出Voldemort的并发读写性能也很不错，每秒超过了1.5万次读写。

从Facebook开发Cassandra，Linkedin开发Voldemort，我们也可以大致看出国外大型SNS网站对于分布式数据库，特别是对数据库的scale能力方面的需求是多么殷切。前面我（robbin）提到，web应用的架构当中，web层和app层相对来说都很容易横向扩展，唯有数据库是单点的，极难scale，现在Facebook和Linkedin在非关系型数据库的分布式方面探索了一条很好的方向，这也是为什么现在Cassandra这么热门的主要原因。

如今，NoSQL数据库是个令人很兴奋的领域，总是不断有新的技术新的产品冒出来，改变我们已经形成的固有的技术观念，我自己（robbin）稍微了解了一些，就感觉自己深深的沉迷进去了，可以说NoSQL数据库领域也是博大精深的，我（robbin）也只能浅尝辄止，我（robbin）写这篇文章既是自己一点点钻研心得，也是抛砖引玉，希望吸引对这个领域有经验的朋友来讨论和交流。

从我（robbin）个人的兴趣来说，分布式数据库系统不是我能实际用到的技术，因此不打算花时间深入，而其他两个数据领域（高性能NoSQLDB和海量存储NoSQLDB）都是我很感兴趣的，特别是Redis，TT/TC和MongoDB这3个NoSQL数据库，因此我接下来将写三篇文章分别详细介绍这3个数据库

查看索引：
db.user_info.getIndexes();

建立索引：
db.user_info.ensureIndex({"name":1});

一、MongoDB集群包括一定数量的mongod（分片存储数据）、mongos（路由处理）、config server、clients。以下会一一介绍。

1、shards：一个shard为一组mongod，通常一组为两台，主从或互为主从，这一组mongod中的数据时相同的，具体可见《mongodb分布式之数据复制》。数据分割按有序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询，这同google的BigTable 类似。数据块有指定的最大容量，一旦某个数据块的容量增长到最大容量时，这个数据块会切分成为两块；当分片的数据过多时，数据块将被迁移到系统的其他分片中。另外，新的分片加入时，数据块也会迁移。

2、mongos：可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统。mongos可以运行在任何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后接受client端的请求，路由到shards服务器上，然后整理返回的结果发回给client服务器。

3、config server：存储集群的信息，包括分片和块数据信息。主要存储块数据信息，每个config server上都有一份所有块数据信息的拷贝，以保证每台config server上的数据的一致性。

4、shard key：为了分割数据集，需要制定分片key的格式，类似于用于索引的key格式，通常由一个或多个字段组成以分发数据，比如：

{ name : 1 }
{ _id : 1 }
{ lastname : 1, firstname : 1 }
{ tag : 1, timestamp : -1 }

      mongoDB的分片为有序存储(1为升序，-1为降序)，shard key相邻的数据通常会存在同一台服务器（数据块）上。config server的db中存储的信息如下：

CouchDB 特性介绍：

• CouchDB is a JSON document-oriented database written in Erlang.CouchDB是一个用Erlang 写的文档型数据库。
• It is a highly concurrent database designed to be easily replicable, horizontally, across numerous devices and be fault tolerant.支持高并发访问，支持数据同步，高容错性的分布式存储
• It is part of the NoSQL generation of databases.它是NoSQL 体系中的一员
• It is an open source Apache foundation project. 它是一个Apache 基金下的开源项目
• It allows applications to store JSON documents via its RESTful interface. 它支持JSON 数据的存储，支持RESTful方式的接口。
• It makes use of map/reduce to index and query the database.他使用map/reduce 来构建索引及进行数据查询操作

CouchDB的优势：

• JSON Documents – 文档在CouchDB中以JSON格式存储.
• RESTful Interface – 对CouchDB的所有操作，包括数据CRUD，数据库管理及数据同步，都可能通过HTTP方式进行。
• N-Master Replication – 你可以使用无限多个 master 机器，这样可能会让你能够构建很有意思的数据网络拓扑。
• Built for Offline – CouchDB 能够运行在移动设备上（Android 系统），他可以让你的移动设备在离线时存储数据，在接入网络时再同步到云端存储。
• Replication Filters – 可以在同步复制操作中加上一个过滤器，让你有选择性的同步数据。

CouchDB：为Internet而生：

使用CouchDB，你不仅可以把它当作一个存储，更推荐的方式是完全使用它来构建应用程序，你可以把工作代码直接写在CouchDB 中，完全不需要另外的WEB Server，可以减少开销。这也是CouchDB将自己称为是为Internet而生的原因。

CouchDB的数据查询：

与其他很多存储设备不同的是，CouchDB并不支持动态查询，相反的，它需要事先换需要查询的条件构建view，view通常是一个map函数，在已有数据基础上生成一个数据子集，在查询这个view时，如果数据有变更，会触发map函数增量更新view的内容并返回。这种方式也被称作惰性索引机制。

使用教程：

文章接下来的部分还列出了一个详细的CouchDB 使用教程：

1. 安装CouchDB
2. 使用CouchDB 强大的 WEB 管理工具：FUTON
3. CouchDB 用户管理
4. 创建一个数据文档
5. 更新数据文档
6. 通过CURL创建文档
7. 查询所有文档
8. 创建一个map函数
9. 运行一个reduce函数

原文链接：http://goo.gl/WK7q0

原文链接：Comparing Mongo DB and Couch DB

1.MVCC（Multiversion concurrency control）

MongoDB 与 CouchDB 的一大区别就是CouchDB 是一个MVCC的系统，而MongoDB是一个update-in-place 的系统。这二者的区别就是，MongoDB 进行写操作时都是即时完成写操作，写操作成功则数据就写成功了，而CouchDB 一个支持多版本控制的系统，此类系统通常支持多个结点写，而系统会检测到多个系统的写操作之间的冲突并以一定的算法规则予以解决。

2.水平扩展性

在扩展性方面，CouchDB 使用replication 去做，而MongoDB 的replication 仅仅用来增强数据的可靠性，MongoDB 在实现水平扩展性方面使用的是Sharding。（据说CouchDB 也有开发分片功能的计划）

3.数据查询操作

这个区别在用户接口上了，MongoDB 与传统的数据库系统类似，支持动态查询，即使在没有建立索引的行上，也能进行任意的查询。而 CouchDB 不同，CouchDB 不支持动态查询，你必须为你的每一个查询模式建立相应的view，并在此view的基础上进行查询。

4.原子性

这一点上两者比较一致，都支持针对行的原子性修改（concurrent modifications of single documents），但不支持更多的复杂事务操作。

5.数据可靠性

CouchDB 是一个”crash-only” 的系统，你可以在任何时候停掉CouchDB 并能保证数据的一致性。而MongoDB 在不正常的停掉后需要运行 repairDatabase() 命令来修复数据文件，在1.7.5 版本后支持单机可靠的 –dur命令。

6.Map/Reduce

MongoDB 和 CouchDB 都支持Map/Reduce ，不同的是MongoDB 只有在数据统计操作中会用到，而CouchDB 在变通查询时也是使用 Map/Reduce。

7.使用 javascript

MongoDB 和CouchDB 都支持javascript，CouchDb 用javascript来创建view。MongoDB 使用JSON作为普通数据库操作的表达式。当然你也可以在操作中包含javascript语句。MongoDB还支持服务端的javascript脚本（running arbitrary javascript functions server-side），当然，MongoDB 的Map/Reduce 函数也是javascript 格式的。

8.REST

CouchDB 是一个RESTFul 的数据库，其操作完全走HTTP协议，而MongoDB是走的自己的二进制协议。MongoDB Server在启动时可以开放一个HTTP 的接口供状态监控。

9.性能

• 此处主要列举了MongoDB 自己具有高性能的原因
• 采用二进制协议，而非CouchDB REST的HTTP 协议
• 使用Momary Map 内存映射的做法
• collection-oriented，面向集合的存储，同一个collection的数据是连续存储的
• update-in-place 直接修改，而非使用MVCC的机制
• 使用C＋＋ 编写

10.适用场景

• 如果你在构建一个 Lotus Notes 型的应用，我们推荐使用CouchDB，主要是由于它的MVCC机制。另外如果我们需要master-master 的架构，需要基于地理位置的数据分布，或者在数据结点可能不在线的情况下，我们推荐使用CouchDB。
• 如果你需要高性能的存储服务，那我们推荐 MongoDB，比如用于存储大型网站的用户个人信息，比如用于构建在其它存储层之上的Cache层。
• 如果你的需求中有大量 update 操作，那么使用MongoDB吧。就像我们在例子updating real time analytics counters 中的一样，对于那种经常变化的数据，比如浏览量，访问数之类的数据存储。

原文链接：Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase comparison

相比来看，CouchDB 的长处正是Redis的短处：存储大量的不易变但会被经常查询的数据。Redis的长处正是CouchDB的短处：存储小量的常变数据。

以一个博客系统为例，CouchDB作为一个文档型数据库，可以用来存储文章，评论，模板及附件等，而Redis以其丰富的数据类型的数据结构，更适合用来存储评论列表，网站实时状态，过滤spam，用户session信息以及页面缓存。

作为一个内存数据库，Redis提供了快速对其数据结构进行复杂操作的功能，另外通过一份顺序的日志来保证其数据可靠性。

CouchDB使用了一种append-only的数据模型，不仅在数据库数据存储上，包括其B-tree和R-tree索引都是append-only的，所以如果你的数据修改操作太多（比如计数器应用），那么CouchDB的数据文件会飞速膨胀。

Redis采用定时将内存数据Flush成RDB文件的方法来实现数据的持久化，而CouchDB的数据需要定时做数据压缩以缩减数据文件的大小，这一过程会把数据文件读入，压缩后再写成新的文件。是一个非常耗时的过程。

Redis提供了简单的索引机制和复杂的数据结构，而CouchDB提供的是复杂的索引和简单的数据结构。Redis适合用来存储实时数据，而CouchDB适合用来存储大量的文档型数据。

下面是一个更详细的各方面对比表格：

来源：ai.mee.nu