nosql优化教程,nosql数据库使用更加方便

简述什么是nosql数据库，并列举两种常见的nosql数据库名称及其特点

NoSQL太火，冒出太多产品了，保守估计也成百上千了。

10年积累的网站制作、成都做网站经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站设计后付款的网站建设流程，更有昌吉免费网站建设让你可以放心的选择与我们合作。

互联网公司常用的基本集中在以下几种，每种只举一个比较常见或者应用比较成功的例子吧。

1. In-Memory KV Store : Redis

in memory key-value store，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代memcached，通过checkpoint和commit log提供了快速的宕机恢复，同时支持replication提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的key-value storage, 模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google的几位大神出品的精品，LSM模型天然写优化，顺序写盘的方式对于新硬件ssd再适合不过了，不足是仅提供了一个库，需要自己封装server端。

3. Document Store: Mongodb

分布式nosql，具备了区别mysql的最大亮点：可扩展性。mongodb 最新引人的莫过于提供了sql接口，是目前nosql里最像mysql的，只是没有ACID的特性，发展很快，支持了索引等特性，上手容易，对于数据量远超内存限制的场景来说，还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了，最大的优势是开源，对于普通的scan和基于行的get等基本查询，性能完全不是问题，只是只提供裸的api,易用性上是短板，可扩展性方面是最强的，其次坐上了Hadoop的快车，社区发展很快，各种基于其上的开源产品不少，来解决诸如join、聚集运算等复杂查询。

企业应用系统架构优化方法

企业应用系统架构优化方法

系统优化是一个全面而复杂的工作，很难通过某一方面的提升而获得很好的效果，也很难在一朝一夕完成系统的全面优化，每个系统都有其特性，需要综合分析综合考虑才能获得比较好的效果。 我下面为大家整理了一些企业应用系统架构优化的方法，欢迎阅读参考：

1 实现动静分离

所谓“动静”分离，就是将静态资源如图片、CSS、Js等和动态资源如JSP、Servlet等进行分开的处理，通过使用不同的服务器，从而加快页面的响应速度，这是目前互联网应用最常用的方式之一，但是在企业应用端相对应用较少。

动静分离至少有两个方面的好处，一是提高了静态资源的处理速度，因为应用服务器处理静态资源的速度—般都不如专业的web服务器，第二个好处就是减少了应用服务器的负担，应用服务器专注于处理动态请求，这对系统的稳定运行是有很大的帮助的。

要实现动静分离，有两种方式，一种是在加载静态资源的HTML语言中，将地址指定到不同的IP/域名上，实现彻底的分离。这种方式需要在设计之初进行考虑，并不适合优化项目，因为这种修改会产生很大的工作量。第二种方式是通过分发器，拦截对静态资源的访问，将动态资源转发给后端的应用服务器，实现动静分离。这种方式的好处是不需要改动现有的代码，仅需要做部署方式故调整，增加web服务器进行静态资源的处理。示意图如下：

目前转发器比较多，既有老牌的Apache Web Server、有性能卓越的Zeus，也有目前如日中天的Nainx，不同的项目可以按照各自的需求进行选择。

2 使用缓存技术

缓存技术是巨型项目、超大型项目中最重要的技术，范围也比较广，从前端的页面、应用中的数据、数据库本身等均可以进行缓存，每个方面使用的技术也千差万别。使用缓存可以带来两个方面的好处，一是缓存的数据可以被高速加载，从内存中读取数据比通过数据库或磁盘读取具有更好的效率;二是最重要的，减少了数据库服务器的压力，有利于数据库的稳定，数据库可以使用更多的资源进行查询、统计等工作，有利于提高系统的整体运行速度。对于大中型应用而言，应用中的数据缓存和数据库端的缓存是应该被考虑的。数据库端的缓存在本文数据库章节中进行描述，本节描述应用中数据的缓存。

要使用缓存，首先需要明确缓存的'内容。一般优化项目不建议做全部数据缓存，或者使用内存数据库之类的技术，这种修改工作量巨大，由此带来的安全性、稳定性、数据的一致性都可能存在较大的隐患。所以，缓存的内容需要有所选择，一般的说，应该根据数据的数据量、被读取的次数、增加/更新频率进行选择。如果数据较少、增加/更新频率非常低，那么应该考虑直接缓存在应用服务器端，只有对于重要性较高、读取次数较多、增加/更新频率相对适中的数据，才适合使用独立缓存。 确定缓存的内容之后，就应该确定缓存的方式。对于缓存于应用服务器端的资源，一般选择KEY-ALUE(OBJECT)进行缓存。对于独立缓存，其内容也KEY-VALUE的格式进行存储(如果使用内存数据库实现缓存，那么存储的就是与数据库相同的信息)，VALUE可以选择SON或者Java Object，其中JSON占用空间较少，读取的网络流量较少，读取之后需要进行转换为Java对象;JavaXCN占用空间较大，读取的网络流量会较多，读取之后无需进行转化(前提是要求该对象已经系列化)，不同系统可以各自特点进行选择。

对于独立缓存，接下来的工作是选择缓存服务器，缓存服务器选择需要具有一定的原则：是否满足已经确定的缓存方式、对操作系统要求如何、稳定性如何、是否支持分布式、是否支持多节点热备、客户端(即JAVA调用接口)接口是否支持漂移(一个节点崩溃是否能转移到另外的节点)、客户端是否高效等等。从目前业界来看，memcached、redis都是应用比较广泛的缓存服务器。

选择完缓存服务器之后，就需要对系统的代码进行一定的改造。改造的内容就是将通过数据库读取的信息改为从缓存服务器获得，而对数据的保存、修改、删除操作，既要操作数据库上的数据，也需要对缓存服务器的信息进行更新，如下图所示：

由于是对系统的优化，那么系统中已经具有很多数据且并未进入缓存，因此还需要将缓存服务器中的数据进行初始化。有两种方式来进行，一种方式是直接将数据库中的数据一次性加载到缓存服务器，另外一种方式是在修改Load数据的方式，先从缓存服务器获取，如果没有，则从数据库获取，然后同步到缓存服务器上。对于优化项目，建议使用第二种方式。第二种方式一个额外的好处就是当缓存服务器全部不可用时，系统也能提供完整的服务。

3 使用异步日志记录

对于企业应用而言，对用户的操作的记录是很重要的，在系统出现某些问题的时候，可以通过日志进行数据恢复。一般系统要么没有进行记录，要么使用数据库进行同步记录。这部分数据会比较庞大，少则百万级，多则数亿，并且随着使用量的增加而逐渐增加。这些表属于使用率最高的表之一，在这些表上进行经常性数据插入，有可能会变成系统的噩梦。

为了解决这个问题，引入异步日志记录，是较为理想的选择。通过在web容器中增加过滤器，拦截用户的请求，然后将用户的请求和表单数据封装为JSON格式的数据，采用异步方式发送到NoSQL数据库，需要恢复的时候，通过对JSON数据进行还原。这种方式有如下好处：

1)不需要改动现有代码而进行了用户操作记录;

2)由于采用异步模式，几乎不会增加用户操作的时间;

3)采用NoSQL+JSON存储，不用为每一类操作特别设置特定的表结构，修改简单。

目前的NoSQL数据库也逐渐显露头角，根据DB Engines在今年10月发布的数据库排名中，MongoDB的NoSQL服务器已经跃居第七位，因此NoSQL服务器目前推荐使用MongoDB。

;

如何选择NoSQL数据库

NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的

SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

NoSQL(NoSQL

= Not Only SQL

)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数

据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

从这一新兴技术中选择一款正确的NoSQL数据库是非常具有挑战性的。比一下网建议在选择时考虑以下因素：

并发控制

并

发控制指的是当多个用户同时更新运行时，用于保护数据库完整性的各种技术。并发机制不正确可能导致脏读、幻读和不可重复读等此类问题。并发控制的目的是保

证一个用户的工作不会对另一个用户的工作产生不合理的影响。在某些情况下，这些措施保证了当用户和其他用户一起操作时，所得的结果和她单独操作时的结果是

一样的。在另一些情况下，这表示用户的工作按预定的方式受其他用户的影响。

封锁

就是事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。加锁后事务T就对该数据对象有了一定的控制，在事务T释放它的锁之前，其它的事务不能更新此数据对象。

封锁是一次只允许一个用户读取或修改的一种机制，是实现并发控制的一个非常重要的技术。

MVCC

Multi-Version Concurrency Control多版本并发控制，维持一个数据的多个版本使读写操作没有冲突。MVCC优化了数据库并发系统，使系统在有大量并发用户时得到最高的性能，并且可以不用关闭服务器就直接进行热备份。

ACID

指

数据库事务正确执行的四个基本要素的缩写。包含：原子性(Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久

性（Durability）。一个支持事务（Transaction）的数据库系统，必需要具有这四种特性，否则在事务过程（Transaction

processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

None

一些系统不提供原子性。

镜像

数据库镜像是DBMS根据DBA的要求，自动把整个数据库或其中的关键数据复制到另一个磁盘上，每当主数据库更新时，DBMS会自动把更新后的数据复制过去，即DBMS自动保证镜像数据与主数据的一致性。

镜像分为同步和异步。

数据存储

指的是数据的物理特性怎样被存储在数据库中。

磁盘 数据被存储在硬盘驱动器里；

GFS或谷歌文件系统是一个由谷歌开发的专有的分布式文件系统；

Hadoop是Apache软件框架，免费许可下支持数据密集型分布式应用程序；

RAM随机存储器；

插件 可以添加外部插件；

Amazon S3通过Web服务接口提供存储；

BDB：BDB

全称是 “Berkeley DB”，它是MySQL具有事务能力的表类型，由Sleepycat

Software开发。BDB表类型提供了MySQL用户长久期盼的功能，即事务控制能力。在任何RDBMS中，事务控制能力都是一种极其重要和宝贵的功

能。事务控制能力使得我们能够确保一组命令确实已经全部执行成功，或者确保当任何一个命令出现错误时所有命令的执行结果均被退回。

实现语言

实现语言会影响数据库的发展速度。典型的NoSQL数据库是用低级语言如C / C + +编写的。另一方面，那些更高层次的语言如Java，使自定义更容易。

实现语言有：C, C++, Erlang, Java, Python

特性

考虑下列哪一个特点对你的数据库是最重要的：

持久性

可用性

一致性

分区容忍性

证书类型

下面这些许可证是一个不同的开放源码许可的形式：

GPL：通用公共许可证

BSD：伯克利软件分发

MPL：Mozilla公共许可证

EPL：Eclipse公共许可证

IDPL：最初的开发者的公共许可证

LGPL：较宽松通用公共许可证

存储类型

存储类型是NoSQL数据库最大的不同，是决定使用哪款数据库的一个首要指标。

关键字：支持get、put和删除操作

按列存储：相对于传统的按行存储，数据集成容易多了

面向文件系统：存储像是JSON或XML这样的结构化文件，很容易就能从面向对象软件中获取数据。

MySQL数据库性能优化之分区分表分库

分表是分散数据库压力的好方法。

分表，最直白的意思，就是将一个表结构分为多个表，然后，可以再同一个库里，也可以放到不同的库。

当然，首先要知道什么情况下，才需要分表。个人觉得单表记录条数达到百万到千万级别时就要使用分表了。

分表的分类

**1、纵向分表**

将本来可以在同一个表的内容，人为划分为多个表。（所谓的本来，是指按照关系型数据库的第三范式要求，是应该在同一个表的。）

分表理由：根据数据的活跃度进行分离，（因为不同活跃的数据，处理方式是不同的）

案例：

对于一个博客系统，文章标题，作者，分类，创建时间等，是变化频率慢，查询次数多，而且最好有很好的实时性的数据，我们把它叫做冷数据。而博客的浏览量，回复数等，类似的统计信息，或者别的变化频率比较高的数据，我们把它叫做活跃数据。所以，在进行数据库结构设计的时候，就应该考虑分表，首先是纵向分表的处理。

这样纵向分表后：

首先存储引擎的使用不同，冷数据使用MyIsam 可以有更好的查询数据。活跃数据，可以使用Innodb ,可以有更好的更新速度。

其次，对冷数据进行更多的从库配置，因为更多的操作时查询，这样来加快查询速度。对热数据，可以相对有更多的主库的横向分表处理。

其实，对于一些特殊的活跃数据，也可以考虑使用memcache ,redis之类的缓存，等累计到一定量再去更新数据库。或者mongodb 一类的nosql 数据库，这里只是举例，就先不说这个。

**2、横向分表**

字面意思，就可以看出来，是把大的表结构，横向切割为同样结构的不同表，如，用户信息表，user_1,user_2等。表结构是完全一样，但是，根据某些特定的规则来划分的表，如根据用户ID来取模划分。

分表理由：根据数据量的规模来划分，保证单表的容量不会太大，从而来保证单表的查询等处理能力。

案例：同上面的例子，博客系统。当博客的量达到很大时候，就应该采取横向分割来降低每个单表的压力，来提升性能。例如博客的冷数据表，假如分为100个表，当同时有100万个用户在浏览时，如果是单表的话，会进行100万次请求，而现在分表后，就可能是每个表进行1万个数据的请求（因为，不可能绝对的平均，只是假设），这样压力就降低了很多很多。

延伸：为什么要分表和分区？

日常开发中我们经常会遇到大表的情况，所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大，导致数据库在查询和插入的时候耗时太长，性能低下，如果涉及联合查询的情况，性能会更加糟糕。分表和表分区的目的就是减少数据库的负担，提高数据库的效率，通常点来讲就是提高表的增删改查效率。

什么是分表？

分表是将一个大表按照一定的规则分解成多张具有独立存储空间的实体表，我们可以称为子表，每个表都对应三个文件，MYD数据文件，.MYI索引文件，.frm表结构文件。这些子表可以分布在同一块磁盘上，也可以在不同的机器上。app读写的时候根据事先定义好的规则得到对应的子表名，然后去操作它。

什么是分区？

分区和分表相似，都是按照规则分解表。不同在于分表将大表分解为若干个独立的实体表，而分区是将数据分段划分在多个位置存放，可以是同一块磁盘也可以在不同的机器。分区后，表面上还是一张表，但数据散列到多个位置了。app读写的时候操作的还是大表名字，db自动去组织分区的数据。

**MySQL分表和分区有什么联系呢？**

1、都能提高mysql的性高，在高并发状态下都有一个良好的表现。

2、分表和分区不矛盾，可以相互配合的，对于那些大访问量，并且表数据比较多的表，我们可以采取分表和分区结合的方式（如果merge这种分表方式，不能和分区配合的话，可以用其他的分表试），访问量不大，但是表数据很多的表，我们可以采取分区的方式等。

3、分表技术是比较麻烦的，需要手动去创建子表，app服务端读写时候需要计算子表名。采用merge好一些，但也要创建子表和配置子表间的union关系。

4、表分区相对于分表，操作方便，不需要创建子表。

我们知道对于大型的互联网应用，数据库单表的数据量可能达到千万甚至上亿级别，同时面临这高并发的压力。Master-Slave结构只能对数据库的读能力进行扩展，写操作还是集中在Master中，Master并不能无限制的挂接Slave库，如果需要对数据库的吞吐能力进行进一步的扩展，可以考虑采用分库分表的策略。

**1、分表**

在分表之前，首先要选中合适的分表策略（以哪个字典为分表字段，需要将数据分为多少张表），使数据能够均衡的分布在多张表中，并且不影响正常的查询。在企业级应用中，往往使用org_id(组织主键)做为分表字段，在互联网应用中往往是userid。在确定分表策略后，当数据进行存储及查询时，需要确定到哪张表里去查找数据，

数据存放的数据表 = 分表字段的内容 % 分表数量

**2、分库**

分表能够解决单表数据量过大带来的查询效率下降的问题，但是不能给数据库的并发访问带来质的提升，面对高并发的写访问，当Master无法承担高并发的写入请求时，不管如何扩展Slave服务器，都没有意义了。我们通过对数据库进行拆分，来提高数据库的写入能力，即所谓的分库。分库采用对关键字取模的方式，对数据库进行路由。

数据存放的数据库=分库字段的内容%数据库的数量

**3、即分表又分库**

数据库分表可以解决单表海量数据的查询性能问题，分库可以解决单台数据库的并发访问压力问题。

当数据库同时面临海量数据存储和高并发访问的时候，需要同时采取分表和分库策略。一般分表分库策略如下：

中间变量 = 关键字%（数据库数量*单库数据表数量）

库 = 取整（中间变量/单库数据表数量）

表 = （中间变量%单库数据表数量）

实例：

1、分库分表

很明显，一个主表（也就是很重要的表，例如用户表）无限制的增长势必严重影响性能，分库与分表是一个很不错的解决途径，也就是性能优化途径，现在的案例是我们有一个1000多万条记录的用户表members,查询起来非常之慢，同事的做法是将其散列到100个表中，分别从members0到members99，然后根据mid分发记录到这些表中，牛逼的代码大概是这样子：

复制代码 代码如下:

?php

for($i=0;$i 100; $i++ ){

//echo "CREATE TABLE db2.members{$i} LIKE db1.members

";

echo "INSERT INTO members{$i} SELECT * FROM members WHERE mid%100={$i}

";

}

?

2、不停机修改mysql表结构

同样还是members表，前期设计的表结构不尽合理，随着数据库不断运行，其冗余数据也是增长巨大，同事使用了下面的方法来处理：

先创建一个临时表：

/*创建临时表*/

CREATE TABLE members_tmp LIKE members

然后修改members_tmp的表结构为新结构，接着使用上面那个for循环来导出数据，因为1000万的数据一次性导出是不对的，mid是主键，一个区间一个区间的导，基本是一次导出5万条吧，这里略去了

接着重命名将新表替换上去：

/*这是个颇为经典的语句哈*/

RENAME TABLE members TO members_bak,members_tmp TO members;

就是这样，基本可以做到无损失，无需停机更新表结构，但实际上RENAME期间表是被锁死的，所以选择在线少的时候操作是一个技巧。经过这个操作，使得原先8G多的表，一下子变成了2G多。

你觉得数据库这个课怎么样？

普通。就是学习数据库的操作而已。读取,编辑,删除这三种操作逻辑。只要记忆力好,把那几种命令语句背下来,基本的操作就没问题。这对今后的其他课程尤其是编程是有帮助的,因为有些软件会设计到数据库的读写操作。尤其是一些网站,肯定会连接数据库。不会数据库操作,就没办法制作动态网站。

为什么要使用NoSQL？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的数据库发展带来新的思路。