NoSQL，就是反SQL，是一项全新的数据库革新运动，特别是在 2010 年得以迅猛发展。而各种开源的 NoSQL 软件突然间涌现在你面前。目前似乎没有对 NoSQL 给出一个标准的定义，也没有相应的规范，但从这些软件可以看出 NoSQL 软件的共同点：独立运行、K/V存储结构，这之前有人称之为集中式缓存服务，其实你可以把二者等同起来。

那么多的 NoSQL 软件，到底哪些更受欢迎呢？为此，开源中国社区为你评选出10款2010年最受关注的 NoSQL 软件。

1. Cassandra

Cassandra 在 2010 年出尽风头，但最终都以失败告终，包括 Twitter 以及 Digg 的案例使我们不得不对 NoSQL 技术是否成熟，是否能在大规模系统中应用产生了怀疑。但这并不影响 Cassandra 拔得头筹，因为还有 Facebook 的支持。

Apache Cassandra 是一套开源分布式Key-Value存储系统。它最初由Facebook开发，用于储存特别大的数据。Facebook目前在使用此系统。

主要特性：

分布式

基于column的结构化

高伸展性

Cassandra 采用 Java 开发，Apache 授权协议。

2. memcached

memcached 是老牌的独立缓存服务的领头羊，目前国内使用该系统的网站非常的多，在这基础上还有国内开发的 memcachedb 是 memcached 支持持久化存储。

memcached 是一套分布式的快取系统，当初是Danga Interactive为了LiveJournal所发展的，但目前被许多软件（如MediaWiki）所使用。不过，memcached 缺乏认证以及安全管制

memcached 采用 C 语言开发，可在 Linux 系统下使用，采用 BSD 授权。

3. Membase

Membase 是 NoSQL 家族的一个新的重量级的成员，其完全兼容 memcached 的方式，有望笼络 memcached 的用户群。Membase 的可伸缩性、集群、复制以及管理方便等特性又是 memcached 无法匹敌的。

Membase 同样采用 C 语言开发，支持 Windows 和 Linux 系统，使用 Apache 授权协议。

接下来介绍两款国产的 NoSQL 软件：

4. Tair

Tair 是由淘宝网自主开发的分布式Key/Value结构数据存储系统，在淘宝网有着大规模的应用。您在登录淘宝、查看商品详情页面或者在淘江湖和好友“捣浆糊”的时候，都在直接或间接地和Tair交互。

Tair 采用 C 语言开发，支持 Linux 系统，使用 GPLv2 授权协议。

5. BeansDB

BeansDB 是豆瓣网开发的一个主要针对大数据量、高可用性的分布式Key Value存储系统，采用HashTree和简化的版本号来快速同步保证最终一致性（弱），一个简化版的 Dynamo。

它采用类似memcached的去中心化结构，在客户端实现数据路由。目前只提供了 Python版本的客户端，其它语言的客户端可以由memcached的客户端稍加改造得到。

主要特性包括：

高可用：通过多个可读写的用于备份实现高可用；

最终一致性：通过哈希树实现快速完整数据同步（短时间内数据可能不一致）；

容易扩展：可以在不中断服务的情况下进行容量扩展；

高性能：异步IO和高性能的Key Value数据Tokyo Cabinet；

可配置的可用性和一致性：通过N,W,R进行配置；

简单协议：Memcached兼容协议，大量可用客户端。

BeansDB 采用 Python 语言开发，支持 Linux 系统，使用 BSD 授权协议。

6. Redis

Redis 是一个高性能的key-value数据库。 redis的 出现，很大程度补偿了memcached这类keyvalue存储的不足，在部分场合可以对关系数据库起到很好的补充作用。它提供了Python，Ruby，Erlang，PHP客户端，使用很方便。

Redis 的短板：

这个项目还很新，可能还不足够稳定，而且没有在实际的一些大型系统应用的实例。

缺乏mc中批量get也是比较大的问题，始终批量获取跟多次获取的网络开销是不一样的。

Redis 采用 C 语言开发，支持 Linux 系统，使用 BSD 授权协议。

7. CouchDB

Apache CouchDB 是一个面向文档的数据库管理系统。它提供以 JSON 作为数据格式的 REST 接口来对其进行操作，并可以通过视图来操纵文档的组织和呈现。 CouchDB 是 Apache 基金会的顶级开源项目。

CouchDB落实到最底层的数据结构就是两类B+Tree 。

不过最近有消息说 CouchDB 将走一条不同于 NoSQL 的路子，具体情况如何我们只能拭目以待。

CouchDB 是用 ErLang 开发的哦，跨平台支持，Apache 授权协议。

8. Tokyo Cabinet

Tokyo Cabinet 是一个DBM的实现。这里的数据库由一系列key-value对的记录构成。key和value都可以是任意长度的字节序列，既可以是二进制也可以是字符串。这里没有数据类型和数据表的概念。

当做为Hash表数据库使用时，每个key必须是不同的，因此无法存储两个key相同的值。提供了以下访问方法:提供key，value参数来存储，按 key删除记录，按key来读取记录，另外，遍历key也被支持，虽然顺序是任意的不能被保证。这些方法跟Unix标准的DBM,例如GDBM,NDBM 等等是相同的，但是比它们的性能要好得多（因此可以替代它们)

当按B+树来存储时，拥用相同key的记录也能被存储。像hash表一 样的读取，存储，删除函数也都有提供。记录按照用户提供的比较函数来存储。可以采用顺序或倒序的游标来读取每一条记录。依照这个原理，向前的字符串匹配搜 索和整数区间搜索也实现了。另外，B＋树的事务也是可用的。

Tokyo Cabinet 采用 C 语言开发，支持 Linux 系统，使用 LGPL 授权协议。

9. OrientDB

Orient DB 是一个可伸缩的文档数据库，支持 ACID 事务处理。使用 Java 5 实现。OrientDB 最强的一个地方是可以使用 类 SQL 的查询语句进行数据查询。

OrientDB 采用 Java 语言开发，跨平台支持，使用 Apache 授权协议。

10. Hibari

Hibari （在日语中意思为“云雀”）是一个专为高可靠性和大数据存储的数据库引擎，可用于云计算环境中，例如 webmail、SNS 和其他要求T/P级数据存储的环境中。Hibari 支持 Java, C/C++， Python, Ruby， 和 Erlang 语言的客户端。

Hibari 并不是一个关系数据库，主要是通过 key-value 的方法进行数据存储。

Hibari 使用 ErLang 语言开发，支持 Linux/BSD 系统，Apache 授权协议

本文转载自：http://www.oschina.net/news/14209/2010-top-10-nosql-projects

非聚集索引 , 不影响表中的数据存储顺序 , 检索效率比聚集索引低 , 对数据新增 / 修改 / 删除的影响很小

如何让你的 SQL 运行得更快
---- 人们在使用 SQL 时往往会陷入一个误区，即太关注于所得的结果是否正确，而忽略
了不同的实现方法之间可能存在的性能差异，这种性能差异在大型的或是复杂的数据库
环境中（如联机事务处理 OLTP 或决策支持系统 DSS ）中表现得尤为明显。笔者在工作实践
中发现，不良的 SQL 往往来自于不恰当的索引设计、不充份的连接条件和不可优化的 whe
re 子句。在对它们进行适当的优化后，其运行速度有了明显地提高！下面我将从这三个
方面分别进行总结：
---- 为了更直观地说明问题，所有实例中的 SQL 运行时间均经过测试，不超过１秒的均
表示为（ < 1 秒）。
---- 测试环境 --
---- 主机： HP LH II
---- 主频： 330MHZ
---- 内存： 128 兆
---- 操作系统： Operserver5.0.4
---- 数据库： Sybase11.0.3
一、不合理的索引设计
---- 例：表 record 有 620000 行，试看在不同的索引下，下面几个 SQL 的运行情况：
---- 1. 在 date 上建有一非个群集索引
select count(*) from record where date >
'19991201' and date < '19991214'and amount >
2000 (25 秒 )
select date,sum(amount) from record group by date
(55 秒 )
select count(*) from record where date >
'19990901' and place in ('BJ','SH') (27 秒 )
---- 分析：
----date 上有大量的重复值，在非群集索引下，数据在物理上随机存放在数据页上，在
范围查找时，必须执行一次表扫描才能找到这一范围内的全部行。
---- 2. 在 date 上的一个群集索引
select count(*) from record where date >
'19991201' and date < '19991214' and amount >
2000 （ 14 秒）
select date,sum(amount) from record group by date
（ 28 秒）
select count(*) from record where date >
'19990901' and place in ('BJ','SH') （ 14 秒）
---- 分析：
---- 在群集索引下，数据在物理上按顺序在数据页上，重复值也排列在一起，因而在范
围查找时，可以先找到这个范围的起末点，且只在这个范围内扫描数据页，避免了大范
围扫描，提高了查询速度。
---- 3. 在 place ， date ， amount 上的组合索引
select count(*) from record where date >
'19991201' and date < '19991214' and amount >
2000 （ 26 秒）
select date,sum(amount) from record group by date
（ 27 秒）
select count(*) from record where date >
'19990901' and place in ('BJ', 'SH') （ < 1 秒）
---- 分析：
---- 这是一个不很合理的组合索引，因为它的前导列是 place ，第一和第二条 SQL 没有引
用 place ，因此也没有利用上索引；第三个 SQL 使用了 place ，且引用的所有列都包含在组
合索引中，形成了索引覆盖，所以它的速度是非常快的。
---- 4. 在 date ， place ， amount 上的组合索引
select count(*) from record where date >
'19991201' and date < '19991214' and amount >
2000(< 1 秒 )
select date,sum(amount) from record group by date
（ 11 秒）
select count(*) from record where date >
'19990901' and place in ('BJ','SH') （ < 1 秒）
---- 分析：
---- 这是一个合理的组合索引。它将 date 作为前导列，使每个 SQL 都可以利用索引，并
且在第一和第三个 SQL 中形成了索引覆盖，因而性能达到了最优。
---- 5. 总结：
---- 缺省情况下建立的索引是非群集索引，但有时它并不是最佳的；合理的索引设计要
建立在对各种查询的分析和预测上。一般来说：
---- ① . 有大量重复值、且经常有范围查询
（ between, >,< ， >=,< = ）和 order by
、 group by 发生的列，可考虑建立群集索引；
---- ② . 经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
---- ③ . 组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。

二、不充份的连接条件：
---- 例：表 card 有 7896 行，在 card_no 上有一个非聚集索引，表 account 有 191122 行，在
account_no 上有一个非聚集索引，试看在不同的表连接条件下，两个 SQL 的执行情况：

select sum(a.amount) from account a,
card b where a.card_no = b.card_no （ 20 秒）
---- 将 SQL 改为：
select sum(a.amount) from account a,
card b where a.card_no = b.card_no and a.
account_no=b.account_no （ < 1 秒）
---- 分析：
---- 在第一个连接条件下，最佳查询方案是将 account 作外层表， card 作内层表，利用
card 上的索引，其 I/O 次数可由以下公式估算为：
---- 外层表 account 上的 22541 页 + （外层表 account 的 191122 行 * 内层表 card 上对应外层
表第一行所要查找的 3 页） =595907 次 I/O
---- 在第二个连接条件下，最佳查询方案是将 card 作外层表， account 作内层表，利用
account 上的索引，其 I/O 次数可由以下公式估算为：
---- 外层表 card 上的 1944 页 + （外层表 card 的 7896 行 * 内层表 account 上对应外层表每一
行所要查找的 4 页） = 33528 次 I/O
---- 可见，只有充份的连接条件，真正的最佳方案才会被执行。
---- 总结：
---- 1. 多表操作在被实际执行前，查询优化器会根据连接条件，列出几组可能的连接方
案并从中找出系统开销最小的最佳方案。连接条件要充份考虑带有索引的表、行数多的
表；内外表的选择可由公式：外层表中的匹配行数 * 内层表中每一次查找的次数确定，乘
积最小为最佳方案。
---- 2. 查看执行方案的方法 -- 用 set showplanon ，打开 showplan 选项，就可以看到连
接顺序、使用何种索引的信息；想看更详细的信息，需用 sa 角色执行 dbcc(3604,310,30
2) 。
三、不可优化的 where 子句
---- 1. 例：下列 SQL 条件语句中的列都建有恰当的索引，但执行速度却非常慢：
select * from record where
substring(card_no,1,4)='5378'(13 秒 )
select * from record where
amount/30< 1000 （ 11 秒）
select * from record where
convert(char(10),date,112)='19991201' （ 10 秒）
---- 分析：
---- where 子句中对列的任何操作结果都是在 SQL 运行时逐列计算得到的，因此它不得不
进行表搜索，而没有使用该列上面的索引；如果这些结果在查询编译时就能得到，那么
就可以被 SQL 优化器优化，使用索引，避免表搜索，因此将 SQL 重写成下面这样：
select * from record where card_no like
'5378%' （ < 1 秒）
select * from record where amount
< 1000*30 （ < 1 秒）
select * from record where date= '1999/12/01'
（ < 1 秒）
---- 你会发现 SQL 明显快起来！
---- 2. 例：表 stuff 有 200000 行， id_no 上有非群集索引，请看下面这个 SQL ：
select count(*) from stuff where id_no in('0','1')
（ 23 秒）
---- 分析：
---- where 条件中的 'in' 在逻辑上相当于 'or' ，所以语法分析器会将 in ('0','1') 转化
为 id_no ='0' or id_no='1' 来执行。我们期望它会根据每个 or 子句分别查找，再将结果
相加，这样可以利用 id_no 上的索引；但实际上（根据 showplan ） , 它却采用了 "OR 策略 "
，即先取出满足每个 or 子句的行，存入临时数据库的工作表中，再建立唯一索引以去掉
重复行，最后从这个临时表中计算结果。因此，实际过程没有利用 id_no 上索引，并且完
成时间还要受 tempdb 数据库性能的影响。
---- 实践证明，表的行数越多，工作表的性能就越差，当 stuff 有 620000 行时，执行时
间竟达到 220 秒！还不如将 or 子句分开：
select count(*) from stuff where id_no='0'
select count(*) from stuff where id_no='1'
---- 得到两个结果，再作一次加法合算。因为每句都使用了索引，执行时间只有 3 秒，
在 620000 行下，时间也只有 4 秒。或者，用更好的方法，写一个简单的存储过程：
create proc count_stuff as
declare @a int
declare @b int
declare @c int
declare @d char(10)
begin
select @a=count(*) from stuff where id_no='0'
select @b=count(*) from stuff where id_no='1'
end
select @c=@a+@b
select @d=convert(char(10),@c)
print @d
---- 直接算出结果，执行时间同上面一样快！
---- 总结：
---- 可见，所谓优化即 where 子句利用了索引，不可优化即发生了表扫描或额外开销。

---- 1. 任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时
要尽可能将操作移至等号右边。
---- 2.in 、 or 子句常会使用工作表，使索引失效；如果不产生大量重复值，可以考虑把
子句拆开；拆开的子句中应该包含索引。
---- 3. 要善于使用存储过程，它使 SQL 变得更加灵活和高效。
---- 从以上这些例子可以看出， SQL 优化的实质就是在结果正确的前提下，用优化器可
以识别的语句，充份利用索引，减少表扫描的 I/O 次数，尽量避免表搜索的发生。其实 S
QL 的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会
涉及数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计

例如：

CREATE TABLE tbl_Test
(
   Home nchar(100)  --對於字元使用nchar/nvarchar/ntext類型
)

--若沒有 N 前置詞，字串會被轉換為資料庫預設的字碼頁，這樣可能無法辨識某些字符
insert into Person.Info(home)
values(N'中華人民共和國')

insert into Person.Info(home)
values(N'中華人民共和國')   --Notes裡顯示不了簡體的(這裡為簡體字)

另外，在Web Page上，傳送到伺服器的 Unicode 字元字串常數必須先加上大寫 N。在HTML 畫面的 META 屬性中指定CHARSET字碼。例如，如果 Unicode 編碼配置是 UTF-8，就指定 CHARSET = utf-8。在伺服器端上，請使用 Session.CodePage 屬性或 @Codepage 指示詞來指定用戶端的編碼配置。例如，codepage=65001 會指定 UTF-8 編碼配置。這樣Internet InformationServices (IIS) 5.0 或更新版本將順利的處理 UTF-8 和 UCS-2 之間的轉換，而不需要採取其他動作。

一、数据库设计方面
1、字段类型。
varchar(max)\nvarchar(max)类型的引入大大的提高了编程的效率，可以使用字符串函数对CLOB类型进行操作，这是一个亮点。但是这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？是否碎片会引发效率问题？这都是需要进一步探讨的东西。

varbinary(max)代替image也让SQL Server的字段类型更加简洁统一。

XML字段类型更好的解决了XML数据的操作。XQuery确实不错，但是个人对其没好感。（CSDN的开发者应该是相当的熟了！）

2、外键的级联更能扩展
可能大部分的同行在设计OLTP系统的时候都不愿意建立外键，都是通过程序来控制父子数据的完整性。但是再开发调试阶段和OLAP环境中，外键是可以建立的。新版本中加入了SET NULL 和 SET DEFAULT 属性，能够提供能好的级联设置。

3、索引附加字段
这是一个不错的新特性。虽然索引的附加字段没有索引键值效率高，但是相对映射到数据表中效率还是提高了很多。我做过试验，在我的实验环境中会比映射到表中提高30%左右的效率。

4、计算字段的持久化
原来的计算字段其实和虚拟字段很像。只是管理方面好了而已，性能方面提高不多。但是SQL2005提供了计算字段的持久化，这就提高了查询的性能，但是会加重insert和update的负担。OLTP慎用。OLAP可以大规模使用。

5、分区表
分区表是个亮点！从分区表也能看出微软要做大作强SQL Server的信心。资料很多，这里不详细说。但是重点了解的是：现在的SQL Server2005的表，都是默认为分区表的。因为它要支持滑动窗口的这个特性。这种特性对历史数据和实时数据的处理是很有帮助的。
但是需要注意的一点，也是我使用过程中发现的一个问题。在建立function->schema->table后，如果在现有的分区表上建立没有显式声明的聚集索引时，分区表会自动变为非分区表。这一点很让我纳闷。如果你觉得我的非分区索引无法对起子分区，
你可以提醒我一下呀！没有任何的提醒，直接就变成了非分区表。不知道这算不算一个bug。大家也可以试试。

分区表效率问题肯定是大家关心的问题。在我的试验中，如果按照分区字段进行的查询（过滤）效率会高于未分区表的相同语句。但是如果按照非分区字段进行查询，效率会低于未分区表的相同语句。但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

6、CLR类型

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。但是作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！还不是性能有问题！否则面向对象的数据库早就实现了！

建议使用CLR的地方一般是和应用的复杂程度或操作系统环境有很高的耦合度的场景。如你想构建复杂的算法，并且用到了大量的指针和高级数据模型。或者是要和操作系统进行Socket通讯的场景。否则建议慎重！

7、索引视图

索引视图2k就有。但是2005对其效率作了一些改进但是schema.viewname的作用域真是太限制了它的应用面。还有一大堆的环境参数和种种限制都让人对它有点却步。

8、语句和事务快照

语句级快照和事务级快照终于为SQL Server的并发性能带来了突破。个人感觉语句级快照大家应该应用。事务级快照，如果是高并发系统还要慎用。如果一个用户总是被提示修改不成功要求重试时，会杀人的！

9、数据库快照

原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！

10、Mirror
Mirror可以算是SQL Server的Data guard了。但是能不能被大伙用起来就不知道了。

二、开发方面

1、Ranking函数集
其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQL Server2005的row_number比Oracle的更先进。因为它把Order by集成到了一起，不用像Oracle那样还要用子查询进行封装。但是大家注意一点。如下面的例子：

select ROW_NUMBER() OVER (order by aa)
from tbl
order by bb

会先执行aa的排序，然后再进行bb的排序。

可能有的朋友会抱怨集成的order by，其实如果使用ranking函数,Order by是少不了的。如果担心Order by会影响效率，可以为order by的字段建立聚集索引，查询计划会忽略order by 操作（因为本来就是排序的嘛）。

2、top
可以动态传入参数，省却了动态SQL的拼写。

3、Apply
对递归类的树遍历很有帮助。

4、CTE
个人感觉这个真是太棒了！阅读清晰，非常有时代感。

5、try/catch
代替了原来VB式的错误判断。比Oracle高级不少。

6、pivot/unpivot
个人感觉没有case直观。而且默认的第三字段（还可能更多）作为group by字段很容易造成新手的错误。

三、DBA管理方面

1、数据库级触发器
记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。

2、多加的系统视图和实时系统信息

这些东西对DBA挑优非常有帮助，但是感觉粒度还是不太细。

3、优化器的改进
一直以来个人感觉SQL Server的优化器要比Oracle的聪明。SQL2005的更是比2k聪明了不少。（有次作试验发现有的语句在200万级时还比50万级的相同语句要快show_text的一些提示没有找到解释。一直在奇怪。）
论坛例子：
http://community.csdn.net/Expert/topic/4543/4543718.xml?temp=.405987

4、profiler的新事件观察
这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

5、sqlcmd

习惯敲命令行的朋友可能会爽一些。但是功能有限。适合机器跑不动SQL Server Management Studio的朋友使用。

四、遗憾

1、登陆的控制
始终遗憾SQL Server的登陆无法分配CPU/内存占用等指标数。如果你的SQL Server给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。而SQL Server如果能像Oracle一样可以为登陆分配如：5%的cpu，10%的内存。就可以解决这个漏洞。

2、数据库物理框架没有变动
undo和redo都放在数据库得transaction中，个人感觉是个败笔。如果说我们在设计数据库的时候考虑分多个数据库，可能能在一定程度上避免I/O效率问题。但是同样会为索引视图等应用带来麻烦。看看行级和事务级的快照数据放在tempdb中，就能感觉到目前架构的尴尬。

3、还是没有逻辑备份
备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。

4、SSIS(DTS)太复杂了

SQL Server的异构移植功能个人感觉最好了。（如果对比过SQL Server的链接服务器和Oracle的透明网关的朋友会发现SQL Server的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）
以前的DTS轻盈简单。但是现在的SSIS虽然功能强大了很多，但是总是让人感觉太麻烦。看看论坛中询问SSIS的贴子就知道。做的功能太强大了，往往会有很多用户不会用了。