NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与 ACID 理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。

当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的 BigTable 与 Amazon 的 Dynamo 是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的 Cassandra， Apache 的 HBase，也得到了广泛认同。

如果您刚接触 NoSQL，那有必要学习一些背景知识。下列资料是Kas Thomas，一位国外的技术分析师认为非常有价值的 NoSQL 相关必读资料：

先看看这个吧 http://sebug.net/paper/databases/nosql/Nosql.html

Amazon Dynamo 论文。几乎所有懂 NoSQL 的人都阅读过它。

Google 的 Bigtable 论文。 也许您已经耳熟能详。

Werner Vogels 的 Eventually Consistent （发布于 ACM Queue）。如果您对最终一致性不是非常清晰，请阅读这篇文章。

Brewer 的 CAP 理论（可伸缩性的基础）在这里可以找到非常好的诠释。也可以看看 2000 7 月 PODC 上 Brewer的原始幻灯片。

在 2009 年 6 月在 SFO 的 NoSQL 见面会的幻灯片。这些资料可以用经典的、关键的、将影响巨大的、值得纪念的来形容。

SQL Databases Don’t Scale 是一篇简短、基础、直切问题的文章。除非您是一位在伸缩性问题上身经百战的数据库管理员，否则，这篇文章讲述的内容对于您可能是非常关键的。

Jonathan Ellis 的文章 NoSQL Ecosystem 以表格的方式对当今主流的分布式数据库做了比较。类似的比较还有 Quick Reference to Alternative data storages。Ellis 的文章除了表格对比外对于想了解 NoSQL 生态的人来说是非常值得一读的，该文章内涵丰富，短小精悍；而 Quick Reference to Alternative data storages 主要是表格，这些表格对比的内容又比 Ellis 的完整。

【相关国外资源】

http://nosql-databases.org/ 该站点的标语是：非关系型世界的终结向导！，该站点非常确信自己是：在互联网上拥有 NoSQL 相关链接最多的网站。总之，该网站值得关注。

另外，作为 NoSQL 极客（geeks），请 follow @nosqlupdate。另外，请 follow @al3xandru （MyNoSQL blog 与 NoSQL Week in Review 的创建者）。NoSQL Week in Review 比较新，希望能保持正常更新，因为它确实很棒！

当然，您还可以看看 Ricky Ho 最近的博文，他总结了一些分布式数据存储技术关键点。他的博文中有两篇非常值得一看的文章：Query Processing for NoSQL Databases，还有 NoSQL Design Patterns（《程序员》杂志有译文）。

--------------------------------------------------------------------------------------------------------------------------

http://adam.heroku.com/past/2009/7/6/sql_databases_dont_scale/

此文章非常有用,它对之前主流的分布式数据库的概念进行了批判。

a tornado of razorblades

by Adam Wiggins

SQL Databases Don't Scale

databases

Mon Jul 06 12:51:22 -0700 2009

A question I’m often asked about Heroku is: “How do you scale the SQL database?” There’s a lot of things I can say about using caching, sharding, and other techniques to take load off the database. But the actual answer is: we don’t. SQL databases are fundamentally non-scalable, and there is no magical pixie dust that we, or anyone, can sprinkle on them to suddenly make them scale.

What Is Scaling?

To qualify as true scaling, I believe a technique must fit the following criteria:

1. Horizontal scale: more servers creates more capacity. 水平扩展性(也称Scale out)
2. Transparent to the application: the business logic of the app should be separated from concerns of scaling server resources. 透明性
3. No single point of failure: there should be no one server which, if lost, causes downtime of the application. 没有单点故障

As an example from the hardware world, a RAID5 disk array offers true scaling:

1. Horizontal scale: you can run a RAID5 with 4 disks, or 12, or 20; more disks gives you more drive space and (generally) better performance.
2. Transparent to the application: applications using the RAID as a single device. My text editor doesn’t care that the file it is saving or loading is split across many disks.
3. No single point of failure: you can pop out a drive and the array will continue to function (albeit with a performance hit, known as “degraded mode”). Replace the drive and it will rebuild itself. All of this happens without the applications using the RAID being aware any interruption of the functioning of the disk storage.

So let’s take a look at some of the techniques used to “scale” SQL databases, and why they all fail to achieve the criteria above.

Vertical Scaling 垂直扩展性[关系数据库的扩展方式的问题，相对于水平扩展性，纵向扩展性（也称Scale up）]

One way to scale a SQL database is to buy a bigger box. This is usually called “vertical scaling.” I sometimes call it: Moore’s law scaling. What are the problems with this?

• It’s a complicated transaction that usually requires manual labor from ops people and substantial downtime.
• The old machine is useless afterward. This wastes resources and encourages you to overprovision, buying a big server before you know you’re really going to need it.
• There’s a cap on how big you can go.

I know plenty of folks who have bumped their head on the last point (usually somewhere around a 256-core Sun server) and now they are painted into a corner. They find themselves crossing their fingers and hoping that they’ll stop growing - not cool at all.

So yes, you can put a SQL database on a bigger box to buy yourself more headroom. But this fails point #1 on my checklist for true scaling.

之前的分布式也是主要使用水平扩展的，这里是说nosql更好的支持水平扩展。

Partitioning, aka Sharding 分区/分片破坏RDBS数据关系

Sharding divides your data along some kind of application-specific boundary. For example, you might store users whose names start with A-M on one database, and N-Z on another. Or use a modulo of the user id by the number of databases.

This requires deep integration into the application and careful planning of the partitioning scheme relative to the database schema and the kinds of queries you want to do. Summary: big pain in the ass.

So while sharding is a form of horizontal scaling, it fails point #2: it is not transparent to the business logic of the application.

The deeper problem with sharding is that SQL databases are relational databases, and most of the value in a relational database is that it stores relationships. Once you split records across multiple servers, you’re servering many of those relations; they now have to be reconstructed on the client side. Sharding kills most of the value of a relational database.

Read Slaves 主从模式的局限性

MySQL’s killer feature is easy configuration of master-slave replication, where you have a read-only slave database that replicates everything coming to the master database in realtime. You can then create a routing proxy between the clients and your database (or build smart routing into the client library) which sends any reads (SELECT) to one of the read slaves, while only sending writes (INSERT, UPDATE, DELETE) to the master.

Postgres has replication via Slony, though it’s much more cumbersome to set up than MySQL’s replication. Years ago I even did basic master-slave replication with a 50-line Perl script that read from the query log and mirrored all write queries over to the slave. So replication is possible just about anywhere, with differing degrees of setup and maintenance headaches.

The read slave technique is the best option for scaling SQL databases. It qualifies as horizontal scaling on the read side, and is transparent to the application. This is the technique that many of the largest MySQL installs use.

And yet, this is still ultimately a limited technique. The master server is a bottleneck, particularly on write-heavy applications. And it fails point #3 on the true scaling definition: there is a single point of failure. This is a problem not only when the database fails, but when you want to perform maintenance on the server. Promoting one of the read slaves to master allows you to recover relatively quickly, but this switcharoo requires hands-on attention from the sysadmins.

主数据库存在瓶颈，因此存在单点故障

And while it qualifies as horizontal scaling for read performance, it does not qualify for writes and capacity. Horizontal scaling should spread out both the load of executing queries and the data storage itself. This is how you can grow the total storage space of a RAID: add enough disks, and you can get a RAID which has a much greater capacity than any single hard drive on the market. Read slaves require complete copies of the database, so you still have a ceiling on how much data you can store.

读-从数据库需要数据的完整复制，因此任然存在存储天花板--硬盘能存多少东西？

A Long-Term Solution

So where do we go from here? Some might reply “keep trying to make SQL databases scale.” I disagree with that notion. When hundreds of companies and thousands of the brightest programmers and sysadmins have been trying to solve a problem for twenty years and still haven’t managed to come up with an obvious solution that everyone adopts, that says to me the problem is unsolvable. Like Kirk facing the Kobayashi Maru, we can only solve this problem by redefining the question.

---------------------------------------------------------------------------------------------------------------------------

文章 Query Processing for NoSQL Databases ：

大体意思是nosql有两个局限：

1. It calls for a more relaxed data consistency model

它是个简单关系的模型

1. It provides primitive querying and searching capability

他只提供原始的查询能力，例如键值对的键查询

----------------------------------------------------------------------------------------------------------------------------

孙立文章  不错

在 过去，我们只需要学习和使用一种数据库技术，就能做几乎所有的数据库应用开发。因为成熟稳定的关系数据库产品并不是很多，而供你选择的免费版本就更加少 了，所以互联网领域基本上都选择了免费的MySQL数据库。在高速发展的WEB2.0时代，我们发现关系数据库在性能、扩展性、数据的快速备份和恢复、满 足需求的易用性上并不总是能很好的满足我们的需要，我们越来越趋向于根据业务场景选择合适的数据库，以及进行多种数据库的融合运用。几年前的一篇文章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已经阐述了这个观点。

当我们在讨论是否要使用NoSQL的时候，你还需要理解NoSQL也是分很多种类的，在NoSQL百花齐放的今天，NoSQL的正确选择比选择关系数据库还具有挑战性。虽然NoSQL的使用很简单，但是选择却是个麻烦事，这也正是很多人在观望的一个原因。

NoSQL的分类

NoSQL仅仅是一个概念，NoSQL数据库根据数据的存储模型和特点分为很多种类。

以上NoSQL数据库类型的划分并不是绝对，只是从存储模型上来进行的大体划分。它们之间没有绝对的分界，也有交差的情况，比如Tokyo Cabinet / Tyrant的Table类型存储，就可以理解为是文档型存储，Berkeley DB XML数据库是基于Berkeley DB之上开发的。

NoSQL还是关系数据库

虽然09年出现了比较激进的文章《关系数据库已死》，但是我们心里都清楚，关系数据库其实还活得好好的，你还不能不用关系数据库。但是也说明了一个事实，关系数据库在处理WEB2.0数据的时候，的确已经出现了瓶颈。

那么我们到底是用NoSQL还是关系数据库呢？我想我们没有必要来进行一个绝对的回答。我们需要根据我们的应用场景来决定我们到底用什么。

如 果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面，除非你是 个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也别贸然尝 试NoSQL。

然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分 表分库 （database sharding）、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝 试一下NoSQL了。

选择合适的NoSQL

如此多类型的NoSQL，而每种类型的NoSQL又有很多，到底选择什么类型的NoSQL来作为我们的存储呢？这并不是一个很好回答的问题，影 响我们选择 的因素有很多，而选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。我们常常需要根据如下情况考虑：

数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。

写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。

查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。

NoSQL和关系数据库结合

其实NoSQL数据库仅仅是关系数据库在某些方面（性能，扩展）的一个弥补，单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足，所以选择NoSQL的原因并不在功能上。

所以，我们一般会把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。

举 个简单的例子吧，比如用户评论的存储，评论大概有主键id、评论的对象aid、评论内容content、用户uid等字段。我们能确定的是评论内容 content肯定不会在数据库中用where content=’’查询，评论内容也是一个大文本字段。那么我们可以把 主键id、评论对象aid、用户id存储在数据库，评论内容存储在NoSQL，这样数据库就节省了存储content占用的磁盘空间，从而节省大量IO， 对content也更容易做Cache。

//从MySQL中查询出评论主键id列表

commentIds=DB.query("SELECT id FROM comments where aid=’评论对象id’ LIMIT 0,20");

//根据主键id列表，从NoSQL取回评论实体数据

CommentsList=NoSQL.get(commentIds);

NoSQL代替MySQL

在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等，用NoSQL完全可以替代MySQL存储。不但具有更高的性能，而且开发也更加方便。

NoSQL作为缓存服务器

MySQL+Memcached的架构中，我们处处都要精心设计我们的缓存，包括过期时间的设计、缓存的实时性设计、缓存内存大小评估、缓存命中率等等。

NoSQL数据库一般都具有非常高的性能，在大多数场景下面，你不必再考虑在代码层为NoSQL构建一层Memcached缓存。NoSQL数据本身在Cache上已经做了相当多的优化工作。

Memcached这类内存缓存服务器缓存的数据大小受限于内存大小，如果用NoSQL来代替Memcached来缓存数据库的话，就可以不再受限于内存大小。虽然可能有少量的磁盘IO读写，可能比Memcached慢一点，但是完全可以用来缓存数据库的查询操作。

规避风险

由于NoSQL是一个比较新的东西，特别是我们选择的NoSQL数据库还不是非常成熟的产品，所以我们可能会遇到未知的风险。为了得到NoSQL的好处，又要考虑规避风险，鱼与熊掌如何兼得？

现 在业内很多公司的做法就是数据的备份。在往NoSQL里面存储数据的时候还会往MySQL里面存储一份。NoSQL数据库本身也需要进行备份（冷备和热 备）。或者可以考虑使用两种NoSQL数据库，出现问题后可以进行切换（避免出现digg使用Cassandra的悲剧[全盘使用nosql出现问题]）。

总结

本文只是简单的从MySQL和NoSQL的角度分析如何选择，以及进行融合使用。其实在选择NoSQL的时候，你可能还会碰到关于CAP原则，最终一致性，BASE思想的考虑。因为使用MySQL架构的时候，你也会碰到上面的问题，所以这里没有阐述。

----------------------------------------------------------------------------------------------------------------------------

nosql 介绍[孙立]--文章泛泛而谈,nosql--mysql比较

非 常荣幸能受邀在InfoQ开辟这样一个关于NoSQL的专栏，InfoQ是我非常尊重的一家技术媒体，同时我也希望借助InfoQ，在国内推动 NoSQL的发展，希望跟我一样有兴趣的朋友加入进来。这次的NoSQL专栏系列将先整体介绍NoSQL，然后介绍如何把NoSQL运用到自己的项目中合 适的场景中，还会适当地分析一些成功案例，希望有成功使用NoSQL经验的朋友给我提供一些线索和信息。

NoSQL概念

随着web2.0的快速发展，非关系型、分布式数据存储得到了快速的发展，它们不保证关系数据的ACID特性。NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受。（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字。）

NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。在NoSQL概念提出之前，这些数据库就被用于各种系统当中，但是却很少用于web互联网应用。比如cdb、qdbm、bdb数据库。

传统关系数据库的瓶颈

传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。

在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。

到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。

Memcached+MySQL

后 来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性 能。程序员们开始大量的使用缓存技术来缓解数据库的压力，优化数据库的结构和索引。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大 的时候，多台web机器通过文件缓存不能共享，大量的小文件缓存也带了了比较高的IO压力。在这个时候，Memcached就自然的成为一个非常时尚的技 术产品。

Memcached 作为一个独立的分布式的缓存服务器，为多个web服务器提供了一个共享的高性能缓存服务，在Memcached服务器上，又发展 了根据hash算法来进行多台Memcached缓存服务的扩展，然后又出现了一致性hash来解决增加或减少缓存服务器导致重新hash带来的大量缓存 失效的弊端。当时，如果你去面试，你说你有Memcached经验，肯定会加分的。

Mysql主从读写分离

由于数据库的写入压力增加，Memcached只能缓解数据库的读取压力。读写集中在一个数据库上让数据库不堪重负，大部分网站开始使用主从复制技术来达到读写分离，以提高读写性能和读库的可扩展性。Mysql的master-slave模式成为这个时候的网站标配了。

分表分库

随 着web2.0的继续高速发展，在Memcached的高速缓存，MySQL的主从复制，读写分离的基础之上，这时MySQL主库的写压力开始出 现瓶颈，而数据量的持续猛增，由于MyISAM使用表锁，在高并发下会出现严重的锁问题，大量的高并发MySQL应用开始使用InnoDB引擎代替 MyISAM。同时，开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候，分表分库成了一个热门技术，是面试的热门问题也是业界讨论的热门 技术问题。也就在这个时候，MySQL推出了还不太稳定的表分区，这也给技术实力一般的公司带来了希望。虽然MySQL推出了MySQL Cluster集群，但是由于在互联网几乎没有成功案例，性能也不能满足互联网的要求，只是在高可靠性上提供了非常大的保证。

MySQL的扩展性瓶颈

在 互联网，大部分的MySQL都应该是IO密集型的，事实上，如果你的MySQL是个CPU密集型的话，那么很可能你的MySQL设计得有性能问 题，需要优化了。大数据量高并发环境下的MySQL应用开发越来越复杂，也越来越具有技术挑战性。分表分库的规则把握都是需要经验的。虽然有像淘宝这样技 术实力强大的公司开发了透明的中间件层来屏蔽开发者的复杂性，但是避免不了整个架构的复杂性。分库分表的子库到一定阶段又面临扩展问题。还有就是需求的变 更，可能又需要一种新的分库方式。

MySQL数据库也经常存储一些大文本字段，导致数据库表非常的大，在做数据库恢复的时候就导致非常的慢，不容易快速恢复数据库。比如1000万4KB大小的文本就接近40GB的大小，如果能把这些数据从MySQL省去，MySQL将变得非常的小。

关系数据库很强大，但是它并不能很好的应付所有的应用场景。MySQL的扩展性差（需要复杂的技术来实现），大数据下IO压力大，表结构更改困难，正是当前使用MySQL的开发人员面临的问题。

NOSQL的优势[总结的好]

易扩展

NoSQL数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。数据之间无关系，这样就非常容易扩展。也无形之间，在架构的层面上带来了可扩展的能力。

大数据量，高性能

NoSQL 数据库都具有非常高的读写性能，尤其在大数据量下，同样表现优秀。这得益于它的无关系性，数据库的结构简单。一般MySQL使用 Query Cache，每次表的更新Cache就失效，是一种大粒度的Cache，在针对web2.0的交互频繁的应用，Cache性能不高。而NoSQL的 Cache是记录级的，是一种细粒度的Cache，所以NoSQL在这个层面上来说就要性能高很多了。

灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是一个噩梦。这点在大数据量的web2.0时代尤其明显。

高可用

NoSQL在不太影响性能的情况，就可以方便的实现高可用的架构。比如Cassandra，HBase模型，通过复制模型也能实现高可用。

总结

NoSQL数据库的出现，弥补了关系数据（比如MySQL）在某些方面的不足，在某些方面能极大的节省开发成本和维护成本。

MySQL和NoSQL都有各自的特点和使用的应用场景，两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上，NoSQL关注在存储上

-----------------------------------------------------------------------------------------------------------------------