最近听说了很多关于NoSQL的新闻，比如之前Sourceforge改用MongoDB，Digg改用Cassandra等等。再加上之前做数据库比较时有人推荐我mongodb，所以也搜索了一下NoSQL，觉得NoSQL可能真的是未来的趋势。

    `

NoSQL vs SQL

    传统SQL数据库为了实现ACID(atomicity, consistency, isolation, durability)，往往需要频繁应用文件锁，这使得其在现代的web2.0应用中越来越捉襟见肘。现在SNS网站每一个点击都是一条/多条查询，对数据库写的并发要求非常之高，而传统数据库无法很好地应对这种需求。而仔细想来SNS中大部分需求并不要求ACID，比如Like/Unlike投票等等。

    NoSQL吸取了教训，比如有些NoSQL采用了eventually consistency的概念，在没有Update操作一段时间后，数据库将最终是“consistency”的，显然这样的数据库将能更好的支持高并发读写。

    `

    SQL数据库是基于schema的，这对时时刻刻更新着的web2.0应用开发者来说是个噩梦：随时随地有新的应用出现，旧的数据库无法适应新的应用，只能不停地更新schema，或者做补丁表，如此一来要么schema越发混乱，要么就是数据库频繁升级而耗时耗力耗钱。

    `

    NoSQL一般就没有schema这种概念，大部分NoSQL都直接保存json类的Row，比如一个记录可以是

    { ‘id’ = 1, name = ‘Bob’, phone = 38492839 }，这样扩展升级非常方便，比如需要地址信息直接加入 address=’blahblah’ 即可。

    `

    传统SQL很难进行分布式应用，即使可以也往往代价高昂。而NoSQL则很好地解决了这个问题：他们一般都直接从分布式系统中吸取了Map/Reduce方法，从而很容易就可以处理规模急速增加的问题。

    `

    推荐robbin牛的NoSQL数据库探讨之一 － 为什么要用非关系数据库？一文，介绍了主流的一些NoSQL系统，还有这个站http://nosql-database.org/收集了基本上目前所有的NoSQL系统。

    `

    总结一下我对NoSQL的看法，NoSQL出现的目的就是为了解决高并发读写的问题，而高并发应用往往需要分布式的数据库来实现高性能和高可靠性，所以NoSQL的关键字就是concurrency和scalability。

    `

我的瓶颈

    我之前主要关注数据库的select性能也就是read性能，在读性能方面SQL数据库并没有明显的劣势，应该说纯粹高并发读的性能的话往往要优于NoSQL数据库，然而一旦涉及写，事情就不一样了。

    `

    我本来以为自己不会遇到大量写的问题，后来发现即使在simplecd这种简单的应用环境下也会产生大量的并发写：这就是爬VC用户评论的时候。事实上，sqlite3在处理这个问题上非常的力不从心，所以我产生了换个数据库的想法。

    `

    既然我是要求能高并发读写，干脆就不用SQL了，但是同时我也想测试一下其他SQL的写性能。

    我的数据有180万条，总共350M，测试用了10个线程，每个线程做若干次100个数据的bulk写入，然后记录总共耗时。结果如下。

    `

    innodb: 15.19

    myiasm: 14.34

    pgsql: 23.41

    sqlite3: 锁住了

    sqlite3(单线程): 300+

    mongodb: 3.82

    couchdb: 90

    couchdb(单线程）:66

    `

    作为一个MySQL黑，看到这组测试数据我表示压力很大。在SQL数据库中，mysql意外地取得了最佳的成绩，好于pgsql，远好于sqlite。更令人意外的是myisam居然优于号称insert比较快的innodb。不管如何，对我的应用来说，用mysql保存评论数据是一个更为明智的选择。我对mysql彻底改观了，我宣布我是mysql半黑。以后select-intensive的应用我还是会选择sqlite，但是insert/update-intensive的应用我就会改用mysql了。

    `

    MongoDB和CouchDB同为NoSQL，表现却截然相反，MongoDB性能很高，CouchDB的并发性能我只能ORZ，这种性能实在太抱歉了。

    `

NoSQL的碎碎念

    其实我本来还打算测试cassandra的，可是cassandra用的是java，这首先让我眉头一皱，内存大户我养不起啊，其次看了cassandra的文档，立刻崩溃，这简直就是没有文档么。（BTW，CouchDB也好不到哪里去，我都是用python-couchdb然后help(couchdb.client)看用法的）

    `

    至于CouchDB，可能是因为采用http方式发送请求，所以并发性能糟糕的一塌糊涂，很怀疑它是否有存在的理由。

    `

    MongoDB是我用下来最讨人喜欢的一个NoSQL。不但文档丰富，使用简单，性能也非常好，它的Map/Reduce查询(很多NoSQL都有)让我惊叹，数据库可以非常简单地就扩大规模，完全不用理会什么分区分表之类繁琐的问题，可惜这方面我暂时没有需求。但是MongoDB有两大致命问题。

    `

    第一是删除锁定问题，当批量删除记录时，数据库还是会锁定不让读写。这意味着进行数据清理时会让网站应用失去响应。见locking problems

    `

    第二是内存占用问题，MongoDB用了操作系统的内存文件映射，这导致操作系统会把所有空闲内存都分配给MongoDB，当MongoDB有这个需要时。更可怕的是，MongoDB从来不主动释放已经霸占的内存，它只会滚雪球一样越滚越大，除非重启数据库。这样的上下文环境下，MongoDB只适合一台主机就一个数据库，而没有其他应用的环境，否则一会儿功夫MongoDB就会吃光内存，然后你都fork不出新进程，彻底悲剧。见memory limit

    `

    总之NoSQL虽然让我眼前一亮，可是目前尝试的一些产品都让人望而生畏，现在的NoSQL都把目光放在了巨型网站上，而没有一个小型的，可以在VPS里面应用的高性能NoSQL，令我有点失望。NoSQL尚未成熟，很期待它的将来发展，目前来说MySQL还是更好的选择。

推荐一些相关文章

    详细介绍了为何从MySQL转移到MongoDB的一篇文章，还指出了迁移过程中遇到的问题和他们的解决方法： http://blog.boxedice.com/2009/07/25/choosing-a-non-relational-database-why-we-migrated-from-mysql-to-mongodb/

    MySQL,MongoDB,Tokyo Cabinet的性能测试对比，写得很好： http://jayant7k.blogspot.com/2009/08/document-oriented-data-stores.html

    从概念上比较了MongoDB和CouchDB实现的不同： http://www.mongodb.org/display/DOCS/Comparing+Mongo+DB+and+Couch+DB

建议继续学习：

1. Xvfb+YSlow+ShowSlow搭建前端性能测试框架    (阅读：54187)
2. hbase运维    (阅读：13671)
3. 30分钟3300%性能提升――python+memcached网页优化小记    (阅读：12110)
4. 我对技术方向的一些反思    (阅读：9853)
5. Key-Value小数据库tmdb发布：原理和实现    (阅读：7305)
6. Go Reflect 性能    (阅读：9724)
7. 长连接(KeepAlive)在 http 连接中的性能影响    (阅读：7029)
8. 服务器性能测试工具推荐    (阅读：6437)
9. 让Redis使用TCMalloc，实现高性能NOSql服务器    (阅读：6089)
10. SQL到NOSQL的思维转变    (阅读：5635)