SQL or NoSQL

nosql

最近的 NOSQL meetup 又把SQL数据库的 scale 问题抛出来了。NoSQL guys 对 SQL 不满的主要原因是:SQL 数据库不能很好的 scale。我们可以通过 caching,用 master-slave 分担负载,给数据库横向/纵向分区等技术来减轻 SQL 数据库的负担,但是还不能真正做到 scale。目前最好的方法还是修改应用程序的代码把数据库分散存储在不同的数据库服务器上。随着 Web 应用的规模越来越庞大,这些方法始终没有解决 SQL 数据库 scale 的根本问题。Google/Amazon/Yahoo/Facebook 等都陆续自立门户,纷纷推出了自己超大规模 scale 的数据存储方案,这些方案用来处理海量数据,已经不能叫它们传统的数据库了,更像是分布式键值/文件存储系统。

什么是 scale

什么才算是真正的 scale?

How well a solution to some problem will work when the size of the problem increases, when the size decreases the solution must fit.

我对 scale 的理解是至少要满足下面三个条件:

1、扩展伸缩。加入一个新的数据库服务器后,原先的数据库的容量就扩大,性能也能增大。能立刻自动的把数据部署到新的数据库服务器上,不需要应用程序干预。拿掉一个服务器后,反过来也一样。

2、应用程序透明。对应用程序来说应该是透明的,应用程序不关心也不应该知道数据存储是怎么存储的,存储在哪个服务器上。

3、自动接管/自愈。一台服务器坏了或者 down 了不丢失数据,不影响其他数据库服务器和整个数据库的运行。

一个好例子就是RAID5:

1、增加一个硬盘就会增加整个 RAID 的容量和更好的性能。
2、应用程序不知道 RAID 在干什么,也不需要特殊编写程序。
3、一个硬盘坏了,只需要换一个,不影响数据,不影响服务器运行。

怎么scale

SQL 数据库离上面的 scale 要求还很远,来看一下现在一般怎么 scale 数据库的:

1、现在如果要增加 SQL 服务器的容量和性能就只能增加服务器硬件性能(更强大处理器,更多内存)做垂直的 scale。不能通过简单增加另外1台服务器的方法做水平的 scale,像 RAID5 那样。

2、需要更改程序满足分散访问数据库服务器的能力,数据表分区切片等。

3、用 MySQL 的 master-save 功能 scale,save 复制 master,然后 save 只能读取,master 可写可读,通过 proxy 来分散读取 master 和 save,可以很好提高读数据库性能,很多大一点的网站可以是这种方式减轻负载,这种方式不能很好解决写的问题,而且如果 master fail 掉了,没有其他的 save 能自动接管。

NO SQL, please

这就是为什么要 “NO SQL!”。每个人对 NoSQL 都有一套说法,但是至少有一个大家都同意的说法,就是:“他们不叫数据库”:)。Amazon 和 Facebook 称他们的系统为 “key-value store”,Google 称 “BigTable”,…… 下面是一些和 NoSQL 有关的 open source 数据存储系统(不要叫他们数据库哦,NoSQL guys 会生气的;))

Voldemort
Cassandra Facebook 正在用的系统。
Dynomite
HBase
Hypertable Zvents,百度在用的系统。
CouchDB
VPork
MongoDb

那么我们能修改 SQL 服务器让它变得 scale 吗?我看不大可能,如果 scale 现成的 SQL 很简单的话,那么现在早就有一些 scalable 的 SQL 数据库出现了,上面列出的 open source 项目也用不着这么费劲周折了,NoSQL 也没必要存在了。NoSQL 现在还在起步阶段,要替代 SQL 还有很长一段路要走,毕竟 SQL 历史太长,发展太成熟,和我们生活密切相关,去银行取钱/查账就要 SQL 一下吧。NoSQL 现在还没办法胜任 SQL 那些复杂/关键的应用,现在还只是应用在一些简单的键-值存储或者文件系统上。Notes from the NoSQL Meetup 提到了更多信息。

发表评论