下面我们就来看看几个新的操作符：

$match

$match的作用是过滤数据，通过设置一个条件，将数据进行筛选过滤，例子：

db.runCommand({ aggregate : "article", pipeline : [
    { $match : { author : "dave" } }
]});

这相当于将article这个collection中的记录进行筛选，筛选条件是author属性值为dave，其作用其实相当于普通的find命令，如：

> db.article.find({ author : "dave" });

所以，那这个命令有什么用呢？与find不同，find的结果是直接作为最终数据返回，而$match只是pipeline中的一环，它筛选的结果数据可以再进行下一级的统计操作。

$project

$project命令用于设定数据的筛选字段，就像我们SQL中select需要的字段一样。例子：

db.runCommand({ aggregate : "article", pipeline : [
    { $match : { author : "dave" } },
    { $project : {
        _id : 0,
	author : 1,
        tags : 1
    }}
]});

上面就是将所有author为dave的记录的author和tags两个字段取出来。（_id:0 表示去掉默认会返回的_id字段）

其实上面这个功能也能用我们平时用的find命令来实现，如：

> db.article.find({ author : "dave" }, { _id : 0, author : 1, tags : 1);

$unwind

$unwind命令很神奇，他可以将某一个为array类型字段的数据拆分成多条，每一条包含array中的一个属性。
比如你使用下面命令添加一条记录：

db.article.save( {
    title : "this is your title" ,
    author : "dave" ,
    posted : new Date(4121381470000) ,
    pageViews : 7 ,
    tags : [ "fun" , "nasty" ] ,
    comments : [
        { author :"barbara" , text : "this is interesting" } ,
        { author :"jenny" , text : "i like to play pinball", votes: 10 }
    ],
    other : { bar : 14 }
});

这里面tags字段就是一个array。下面我们在这个字段上应用$unwind操作

db.runCommand({ aggregate : "article", pipeline : [
    { $unwind : "$tags" }
]});

上面命令的意思就是按tags字段来拆分，此命令执行的结果如下：

{
        "result" : [
                {
                        "_id" : ObjectId("4eeeb5fef09a7c9170df094b"),
                        "title" : "this is your title",
                        "author" : "dave",
                        "posted" : ISODate("2100-08-08T04:11:10Z"),
                        "pageViews" : 7,
                        "tags" : "fun",
                        "comments" : [
                                {
                                        "author" : "barbara",
                                        "text" : "this is interesting"
                                },
                                {
                                        "author" : "jenny",
                                        "text" : "i like to play pinball",
                                        "votes" : 10
                                }
                        ],
                        "other" : {
                                "bar" : 14
                        }
                },
                {
                        "_id" : ObjectId("4eeeb5fef09a7c9170df094b"),
                        "title" : "this is your title",
                        "author" : "dave",
                        "posted" : ISODate("2100-08-08T04:11:10Z"),
                        "pageViews" : 7,
                        "tags" : "nasty",
                        "comments" : [
                                {
                                        "author" : "barbara",
                                        "text" : "this is interesting"
                                },
                                {
                                        "author" : "jenny",
                                        "text" : "i like to play pinball",
                                        "votes" : 10
                                }
                        ],
                        "other" : {
                                "bar" : 14
                        }
                }
        ],
        "ok" : 1
}

我们可以看到，原来的tags字段是一个包含两个元素的数组，通过$unwind命令后，被拆分成两条记录，每一条记录的tags字段是原来数组中的一个元素。

$group

$group命令比较好理解，功能就是按某一个key将key值相同的多条数据组织成一条。
比如我们使用下面命令再往article这个collection中写入一条记录，这时候我们就有两条记录了：

db.article.save( {
    title : "this is some other title" ,
    author : "jane" ,
    posted : new Date(978239834000) ,
    pageViews : 6 ,
    tags : [ "nasty" , "filthy" ] ,
    comments : [
        { author :"will" , text : "i don't like the color" } ,
        { author :"jenny" , text : "can i get that in green?" }
    ],
    other : { bar : 14 }
});

我们可以先用上面的$unwind按tags将记录拆成多条，然后再将记录按tags字段重新组织，将同一个tag对应的所有author放在一个array中。只需要像下面这样写：

db.runCommand({ aggregate : "article", pipeline : [
    { $unwind : "$tags" },
    { $group : {
	_id : "$tags",
        count : { $sum : 1 },
	authors : { $addToSet : "$author" }
    }}
]});

这时候你就能得到如下结果了

{
        "result" : [
                {
                        "_id" : "filthy",
                        "count" : 1,
                        "authors" : [
                                "jane"
                        ]
                },
                {
                        "_id" : "fun",
                        "count" : 1,
                        "authors" : [
                                "dave"
                        ]
                },
                {
                        "_id" : "nasty",
                        "count" : 2,
                        "authors" : [
                                "jane",
                                "dave"
                        ]
                }
        ],
        "ok" : 1
}

上面是2.1版本将会推出的一些新的统计类命令的介绍，在易用性方面它们提供给我们很多便利，但是MongoDB MapReduce的最大硬伤，单个mongod中无法并行执行，貌似还是没有解决。虽然其命令中采用了pipeline 的组织模式，但是貌似还是完全串行且分降段完成的。

来源：blog.mongodb.org

相关文章：
从MySQL到MongoDB(添加MongoDB循环插入数据方法)	MongoDB数据文件内部结构	MongoDB 1.4.3 发布	MongoDB索引内部实现	【译】 MongoDB 入门教程
无觅

下载：https://github.com/steelThread/redmon

简单安装（目前还木有gem包）

$ bundle install
$ ruby sample/app.rb

你可以用它提供的这个脚本给Redis来点压力，以便你试用redmon

$ ruby sample/load_sim.rb

然后打开浏览器，访问 0.0.0.0:4567，就能看到下面的界面了

相关文章：
使用Cacti监控MongoDB和Redis	Redis Web界面管理工具	Radish：Redis监控与分析服务	Redis教程一篇	Redis Pipelining功能介绍
无觅

下面是来自其七夜的简介：

quickdb 是一款基于内存文件系统的 HashTable数据结构的Key-Value数据引擎，什么是内存文件系统了？就是操作系统把系统内存划出一部分当作硬盘使用。你可以像操作磁盘那样的操作内存。但效率远远比硬盘来的快多了。通俗叫做内存文件系统，只要服务器不重起数据将一直都在。

通俗的来讲 redis、memcached是自己申请内存管理数据。当进程重启或者挂了就会丢失数据。quickdb是把实体数据储存在内存文件系统里的。当quickdb进程挂了，  实体数据依然还在。 一个进程可能因为各种原因比如修改了配置文件或者要调试数据。要经常重启。但是一个服务器不可能三天两天的重启或者死机。 一般服务器都是半年，或者 好几年都不重起的。 如果你的服务器经常断电或者死机重启那就不叫服务器了。叫家用电脑了。嘿嘿  为了起见,quickdb可以定期的从内存文件系统的数据同步到磁盘中去。这样当服务器重启，也不会丢失数据。 简单的来讲，进程可能会经常因为各种原因要重启或者挂了，但是服务器不可能经常重启或者死机。这样很大程度上保证了数据持久性，也保证了读写效率。

quickdb性能很高，下面是其测试数据：

• 写入3145739条数据 花费4.38秒（qps： ~72w）
• 读取 3145739条数据花费3.88秒（qps： ~81w）

quickdb下载地址：code.google.com

更多详细介绍请参见作者博客的介绍：www.cellphp.com

相关文章：
redisfs – Redis＋FUSE 构建的文件系统	小文件存储的方案对比：nginx、Redis、Moosefs	MongoDB数据文件内部结构	虚拟内存实现原理	MongoDB部署与运维
无觅

另外个人认为这也是一个适合新手的Redis数据结构学习工具，通过将Redis几种数据结构dump成json，可以让我们更直观的认识Redis数据结构及其操作。

下面是使用简介：

$ redis-dump
$ redis-dump -u 127.0.0.1:6371 > db_full.json
$ redis-dump -u 127.0.0.1:6371 -d 15 > db_db15.json

$ < db_full.json redis-load
$ < db_db15.json redis-load -d 15
# OR
$ cat db_full | redis-load
$ cat db_db15.json | redis-load -d 15

# You can specify the redis URI via an environment variable
$ export REDIS_URI=127.0.0.1:6371
$ redis-dump

层出的json数据格式如下，包括了db，key，ttl，数据的type，以及相应的数据

{"db":0,"key":"hashkey","ttl":-1,"type":"hash","value":{"field_a":"value_a","field_b":"value_b","field_c":"value_c"},"size":42}
{"db":0,"key":"listkey","ttl":-1,"type":"list","value":["value_0","value_1","value_2","value_0","value_1","value_2"],"size":42}
{"db":0,"key":"setkey","ttl":-1,"type":"set","value":["value_2","value_0","value_1","value_3"],"size":28}
{"db":0,"key":"zsetkey","ttl":-1,"type":"zset","value":[["value_0","100"],["value_1","100"],["value_2","200"],["value_3","300"],["value_4","400"]],"size":50}
{"db":0,"key":"stringkey","ttl":79,"type":"string","value":"stringvalue","size":11}

而实际上Redis作者也在昨天开启了一个关于将Redis数据转换成json或csv的讨论(issues-288)。目前正广泛收集需求中。

项目地址：github.com

相关文章：
redis_warp、redis_graph、redis_queue － Python下的Redis二次开发	锋利的Redis	Redis教程一篇	REDIS TO GO：一个Redis存储服务	django-redis-cache：用Redis作django的缓存层
无觅

• Elections（选举）
• Creating a set（创建一个replica sets）
• Reconfiguring（重新配置）
• Syncing（同步）
• Initial Sync（初始化同步）
• Rollback（数据回滚）
• Authentication（权限控制）
• Debugging（故障排除）

本文就是其文章的第一篇，关于 replica sets 的选举机制。

本文假定你已经知道什么是 replica sets，并且你已经配置并使用过它，而且你已经了解 primary 和 secondary 的概念。

对 replica sets 来说，其最大的特点是能够自动选举出 primary，所以作为本系列的第一篇文章，我们先来讨论一下选举过程。

Replica Set 选举过程

心跳检测

假设我们有三个节点的replica sets：X，Y和Z节点。在replica sets结构中，这三个节点每2秒会各自向其它两个节点发送一个心跳检测请求。比如X节点向Y和Z节点各发送了一个心跳检测请求，在正常情况下，Y、Z会返回一个包含自身信息的回复包，回复包中主要包括了下面一些信息：它们现在是什么角色（primary 还是 secondary)，他们是否能够在必要的时候成为 primary，以及他们当前时钟时间等等。

X节点在收到回复包后，会用这些信息更新自己的一个状态映射表，更新的内容包括：是否有新的节点加入或有老的节点宕掉，这个请求的网络传输时间等等。

而当X节点的映射表发生了变化，那X会进行下面的逻辑判断：如果X是 primary，而另外一个节点出现故障，那么它会那自己是否还能和集群中大多数节点进行通信，如果不能与大多数节点通信，那么他会把自己从 primary 降级为 secondary。（在replica sets中，primary 必须能够和集群中的大多数节点进行通信，以免发生网络断开形成两个或多个节点群各自为政的情况，这样会影响到数据的一致性）

关于降级

在节点从 primary 降级为 secondary 的过程中，会有一些问题出现。在 MongoDB 中，写操作默认是通过 fire-and-forget 的模式来进行的，也就是说写操作通常不关心是否成功，发完请求后客户端就认为成功了。但如果这时候 primary 进行降级操作，那么客户端并不知道这时候 primary 已经降级成为 secondary 了，客户端可能还会将后续的写操作发送给这个节点。这时候刚刚降级的这个 secondary 可以发送一个包说“我已经不是 primary 了”，但是我们上面说过了，客户端根本就无视你这个包。所以客户端根本不知道这次写入已经失败了。

对于这个问题，你可能会说”那我们每次都使用安全写入不就行了“（安全写入意思是说等待服务器返回成功后客户端才认为写成功了），但是很明显，这非常不靠谱。所以我们的做法是，在一个 primary 降级成为 secondary 后，它会将原来的所有连接关闭。这样客户端在下一次写入的时候就会出现 socket 错误。而客户端在发现这个错误之后，就会重新向集群获取新的 primary 的地址，并将后续的写操作都往新的服务器上写入。

选举

我们回头再来看心跳监测请求：如果X是一个 secondary，那么X会定时检测是否需要选举自己成为 primary。其检测内容包括：是否集群中有其它节点认为自己是 primary？X节点自己是否已经是 primary？X节点自己是否有资格成为 primary？如果这三个问题中的任何一个回答是否定的，那么X节点就不会试图把自己变成primary。（也就是说，只有当X节点是一个能够当 primary 的secondary，并且其它节点都不是primary时，X才会发起选举并选自己为primary）

而当X发现现在需要一个 primary 并且自己又正好可以充当时，它就会发起一轮选举：X节点会向Y、Z节点各发起一个请求包，告知他们”我认为我可以接管 primary 的角色，你们觉得怎么样？“

当Y和Z收到上面的请求包时，他们会进行下面几项检测：他们是否已经知识集群中有一个 primary了？他们自己的数据是否比X节点更新？是否有其它节点的数据比X节点更新？如果上面条件有任何一个满足，那么他们都会认为X不够资格成为 primary，他们会发送一个返回包告知X说”停止选举！“。而如果三个条件都不成立，也就是说他们认为目前集群中确实没有 primary，并且X的数据又是最新的，那么他们会发送返回包告知X说”没问题“。

如果X收到”停止选举！“的返回，那么他会马上停止选举并保持自己为 sencondary 状态。

如果X收到所有其它节点都返回说”没问题“，那么他会进入选举过程的第二阶段。

在第二阶段中，X会向其它节点发送一个包，说”我宣布我已经是 primary 了“。这时候，Y和Z节点再进行一些最终的确认：上面的判断过的所有条件是否依然表明X可以做 primary，如果确实如此，那么他们会在本轮 primary 选举中向X出赞成票。并且他们投完赞成票后，30秒内不会再做其它投票决定。

上面是说如果第二次确认还是通过的情况，那么如果最终确认没有通过呢。他们会投一个反对票，反对X成为 primary，如果有反对票产生，那么这一轮选举就失败了。X还是保持 secondary 的身份。

下面我们假设一种情况，如果Y给X投了赞成票，而Z给X投了反对票。那这时候Y由于投了赞成票，它在30秒内不能再进行投票。所以如果这时候Z发起选举想让自己成为 primary，那么Z这时候必须要获得X的赞成票。因为这时候Y不能投票，为了获取多数票，Z必须获得X的赞成票。

所以投票的规则是这样的：如果没有人投反对票，并且赞成票的比例过半，那么本轮选举对象就能够成为 primary。

来源：www.snailinaturtleneck.com

相关文章：
Warning:MongoDB Replica Sets配置注意事项	MongoDB Replica Sets 简明搭建教程	MongoDB Replica Sets-让你的数据荡然无存？	MongoDB 1.7.x版本中的5个Replica Sets新特性	Riak与MongoDB的对比
无觅

英文大型演讲

• How do I Cassandra? Rick Branson在Memphis Python User Group大会的的演讲，是本年度介绍Cassandra介绍相关的演讲中最好的一个，可能也是最具独创性的一个。
• Cassandra 1.0 and the future of big data, Jonathan Ellis在Cassandra Tokyo上的演讲，主要内容包括了NoSQL与Big Data的关系，内容围绕在Cassandra和Hadoop之间，包括了对 DataStax Enterprise的介绍。Q&A环节包含了英语 和 日语 版本.
• Replacing Datacenter Oracle with Global Apache Cassandra on AWS, Adrian Cockroft 在 Cassandra SF 上的一个演讲。内容包括了Netflix在尝试Amazon的SimpleDB后将数据迁移到Cassandra的过程，这里是视频内容。 Adrian 的一篇相关博客 scaling Cassandra to over one million writes per second。
• From 100s to 100s of Millions, Erik Onnen 在 Cassandra SF 大会的一个演讲。Erik 介绍了 Urban Airship 在 PostgreSQL，MongoDB，以及 Cassandra 方面的一些经验，这里是视频内容。
• Cassandra 101 for system administrators, Nathan Milford 在 Cassandra NYC 的演讲。他从系统工程师的角度对Cassandra进行了介绍。这里是视频内容.
• CQL: SQL for Cassandra, Eric Evans 在 Cassandra NYC 的一个演讲. Eric 向大家介绍了CQL（Cassandra Query Language）的现状和发现。如果你在使用Cassandra，并且在使用其ThriftAPI的使用上有问题，那强烈建议看看本视频。

闪电演讲

Cassandra SF 包括了一个 闪电演讲环节，五分钟的演讲通常会很有新意，Matt Dennis 的演讲 Cassandra antipatterns (视频) 就是这样。

非英语演讲

除了上面一些以外，在其它一些国家也都有一些不错的会议发言，像法国，葡萄牙 和 日本的。

来源：www.datastax.com

相关文章：
Digg使用Cassandra的惨痛经验	cassandra观止	Cassandra运维之道	Cassandra SF 会议精华集锦	Cassandra 发布 0.6.2 版本 修复bug 20个
无觅

在2.0版本以前，这一问题一直没有得到解决，于是有人提出，在可预见某个update操作的记录可能在磁盘上时，为了减少写锁占用的时间，可以采用先读后写的方式，通过先读一次，将要操作的记录加载到内存中，再进行内存中的update，这样写锁就不包括将数据从磁盘加载到内存的时间了。

在可预见数据冷热的情况下，这种操作能够有一定的效果，但是很明显，这种变态的方法不应该是一个终极解决方案。

值得庆幸的是，在2.0版本中，MongoDB宣称有很大程度的并发性能提升，而这一提升的基础正是解决了这个全局锁的问题。

解决的方法并不是通过减少锁粒度来解决，虽然collection级别的锁机制也正在开发中。（SERVER-1240）

解决方法是通过对一些可能造成长时间锁占用的操作进行锁抑制。比如和我们上面的方法类似，在进行update操作时，如果发现需要更新的记录在磁盘上，那么这个锁就不会一直占用，而是等到将数据从磁盘加载到内存后再添加写锁进行update。

而同理，对于其它一些可能耗时比较长的操作也可以采用类似的方法，通过将长时间占用的全局锁拆分成多个细粒度的小锁来使需要获取锁来进行的操作能够交错的执行，从而避免一夫当关万夫莫开的情况，主要包括下面一些操作：

• 查询操作
• 批量更新操作
• 批量删除操作
• 批量insert写入操作

如果你还在使用2.0以前的版本，并且在并发性能上出现问题，可以考虑在2.0.x版本上进行一些性能测试并对你的MongoDB进行升级。

2.0版本中的改进听起来是可行的，然而他的实际效果如何呢，这里有两张性能测试图片，来自blog.pythonisito.com的测试。

第一张是在不触发page faulting的情况下1.8版本和2.0版本在加了写锁后的性能对比，可以看出，在写操作能够直接在内存中完成的情况下，二者的性能几乎没有差别。

第二张图是在写操作会触发page faulting的情况，也就是在1.8中，加写锁的时间会包括将数据从磁盘讲到内存的时间，而在2.0中不包括这段时间。可以看出2.0版本中情况好了很多，因为采用了锁抑制策略，使得产生page faulting后还能有较好并发性能。

参考：www.mongodb.org

相关文章：
MongoDB系列教程	mongodb GridFS 介绍	简单的MongoDB	MongoDB1.5.2发布	MongoDB:下一代MySQL？
无觅

10GT是什么？

10GT是一个发现分享的小社区，我希望你可以在上面发布你觉得好玩或者有用的信息，同时在上面你也能看到其它人分享的信息。而这一切，都基于NoSQL存储。

内容存储

10GT的内容分为主题和回复两大块，这两大块都在MongoDB中进行存储。MongoDB的schema-free特性非常适合主题中tag的存储和检索。

10GT中对用户，主题和回复都会生成一个唯一的自增ID，这是通过MongoDB的findAndModify命令实现的。

消息队列

10GT中的站点日志，搜索，消息提醒，都是通过消息队列在后台完成，而这个消息队列是通过Redis的list结构实现的。

搜索提示

10GT提供搜索提示功能，这里包含了两块内容。

一块是对tag的搜索提示，比如你输入m，搜索提示会提示你mongodb，mongohub这些标签，而输入r，搜索提示会提示你redis，redis cluster这些标签。这一功能的实现也主要采用了Redis，通过将标签进行前缀切分，比如redis会被切分成r，re，red，redi，redis等几部分，以这些前缀作为key，我们用一个zsets结构来存放所有包含这些前缀的tag，这样当你输入一个r的时候，我们就能从zsets里取出相关的tag了。

类似的，主题检索的提示也是类似的，不同的是并非采用前缀切分的方法，而是做了标题分词，比如“NoSQLFan是个好网站” 这句话，可能会被分出“NoSQLFan”，“网站”两个词，通过这两个词作为key构建zsets，我们就能够将所有包含某一关键词的主题放到同一个zsets中。这样当你输入NoSQLFan时，所有标题中包含NoSQLFan的文章就被检索出来了，其实也就是用Redis存储倒排索引信息。目前我们暂时不考虑做正文的全文索引。

可能你会问，上面两个为什么要用zsets，用set不行吗？原因是我们会对检索内容添加权重，并将这个权重作为zsets的score值，权重主要由下面两部分构成，一是对应的tag被添加的次数，或者对应的主题被回复的次数，二是对应的tag或主题在搜索提示中被点击的次数。因为我们认为搜索提示出现后，用户点击越频繁的，越是其需要的结果，所以每个用户的点击，都会计入对应tag或主题的权重，这样通过zsets的自动排序，我们就能给出更合理的提示。

关于10GT与NoSQL和NoSQLFan的关系，就先讲到这里。10GT今天正式开放，欢迎大家来10GT分享有意思的主题。猛击这里！

相关文章：
Cinderella 提供对MongoDB、Redis的支持	使用Cacti监控MongoDB和Redis	Bump的Redis应用经验	10gen发布MongoDB监控系统MMS	Cassandra、MongoDB、CouchDB、Redis、Riak、HBase比较
无觅

Riaknostic不仅能够对Riak在运行时的各项参数进行诊断，还能够在Riak没有运行时对操作系统进行一些监测。如果发现有问题，就会提出相应的建议以供参考。

Riaknostic的诊断参数有很多，比如下面这三个比较常规且重要的：

• Riak目前使用了多大的内存？
• Riak的数据文件所在目录权限设置是否正确？
• Riak的Server之前是否崩溃了，是否有dump文件可供分析？

下面是一个简单的案例，使用Riaknostic检测到Riak之前的崩溃问题。

$ riak-admin diag
15:34:52.736 [warning] Riak crashed at Wed, 07 Dec 2011 21:47:50 GMT, leaving crash dump in /srv/riak/log/erl_crash.dump. Please inspect or remove the file.
15:34:52.736 [notice] Data directory /srv/riak/data/bitcask is not mounted with 'noatime'. Please remount its disk with the 'noatime' flag to improve performance.

你可以在这里找到Riaknostic的安装和更详细的使用方法。

相关文章：
Riak系统介绍	Riak源码阅读手记系列文章	Riak的最终一致性实现原理	Riak全方位介绍	Riak与MongoDB的对比
无觅

问题1：字符串与数字

注：本问题的之前的讨论本人描述有误，忽略了字符串前面标识长度的4个字节。多谢Zang MingJie在评论中指出。下面内容已经更正。

{a:12}

{a:'12'}

哪个更占空间？

{a:1234}

{a:'1256'}

又是哪个更占空间？

对于第二个例子，应该是后一个更占空间，而对于第一个例子呢，实际还是后一个更占空间。具体原因是：MongoDB对数字的存储分两个级别，一个32位的，一是64位的，如我们上面的例子，都是在32位能表达的范围内，所以数字型的占用4个字节，而字符串型的占用空间为其长度加上最后一位\0结束符，还要加上字符串前面用来标识字符串长度的4个字节，一共是五个字节。所以第一个例子中字符串占用8个字节，第二个例子中字符串占用10个字节。

同样的，在索引里也是一样，不过值得注意的是，字符串与数字在排序方式上不一样，所以在索引时，数字是按数字的方式比对大小，字符串是按字符串的方式比对大小，比如在字符串中，’12′是小于’2′的。

问题2：对象与数组

{a:1,b:2,c:3}

{d:[1,2,3]}

哪个更占空间？

可能你会觉得是第一个，因为它看起来长度更长，或者你还会觉得是因为它包含了每个字段的key值。而实际上呢？

答案是第二个会占用更多空间，因为BSON数据结构在存储数组类型时，是与对象类似的方法，比如第二条的存储实际上相当于这样：

{'d':{'0':1,'1':2,'2':3}}

问题3：_id与$natural的排序

MongoDB中有一个特殊的排序方法，叫$natural，当你指定按$natural排序的时候，相当于是按数据在磁盘上的组织顺序排序。而当你按自动生成的_id字段排序时，相当于是按插入时间排序。当不指定排序顺序的时候，MongoDB是按$natural排序的。这两个有什么差别吗？插入顺序与数据组织顺序不应该一样吗？答案是：有可能。

当MongoDB中的数据有变更时，可能会导致数据的移动，比如你先用下面的方式写入1000条数据：

for(var i=0;i<1000;i++)db.test.insert({_id:i,a:'1'})

然后你分别使用下面命令按_id和$natural排序取出前一条结果：

db.test.find().sort({_id:1}).limit(1)

db.test.find().sort({$natural:1}).limit(1)

你得到的结果会是一样的。

这时候你进行一次update操作，将第一条记录的长度变长：

db.test.update({},{a:'12'})

再通过上面两种不同的排序方式取第一条，你会发现取到的结果还是一样的。

然后你再将第一条记录变长：

db.test.update({},{a:'123'})

再通过上面两种不同的排序方式取第一条，这时候你会看到，通过_id排序查到的还是原来那一条，而通过$natural查到的已经变成了第二条。这是什么原因呢？

当我们执行insert操作的时候，每条记录的长度为31，你可以通过下面命令查看到。

Object.bsonsize(db.test.findOne());

而当我们通过一次update，将a值变为’12′时，其长度变长了1字节，变成了32。当我们又一次将a值变为’123′时，其长度变成了33。那为什么记录长度从31到32的时候，按$natural查到的第一条还是原来的，但是长度从32变到33的时候，通过$natural查到的就变了呢？

先说为什么变了，因为MongoDB在记录长度变化后，发现当前记录所在空间后面没有空余的空间可供其变长。那么这条记录就会被删除然后移动到数据集的最后。这是为什么第二次我们通过$natural查到的第一条不是原来那条的原因。因为原来那条已经跑到最尾巴上去了。

但是为什么第一次增长长度时记录没有移动呢？可能你从数字31，32，33上已经看出点端倪来了。对，就是内存对齐，MongoDB每一条记录都会做4字节的内存对齐。所以在你刚插入的时候，记录长度虽然只有31字节，但是MongoDB会为它分配32字节（8*4）的空间。这时候在其末尾就有一字节的空闲，当你增长一字节的时候，这一字节的空闲正好可以用上。所以就不需要移动位置了。而第二次从32字节变成33字节，原有的空间已经不能装下了，所以会造成数据的移动。实际上4字节对齐，也同时造成一些空间的浪费。同时引起数据变长后移动上的不确定性。

相关文章：
BSON：易于数据交换的格式	MongoDB Auto-Sharding 的问题	Riak与MongoDB的对比	Mongodb Mapreduce 初窥	MongoDB1.5.2发布
无觅