翻译自 ： http://gihyo.jp/dev/serial/01/mongodb/0007

 

本文永久链接地址：https://www.askmac.cn/archives/mongodb-gridfs.html ‎

 

GridFS的概要

 

能在MongoDB中保存的Document尺寸一般有最大16Mbyte的限制。这对于保存一般的文本文件是非常足够的尺寸，但要保存一些巨大的文本文件以及视频等Binary data时，就会出现超出16Mbyte的情况。想在MongoDB中保存16Mbyte以上的文件时，通过使用GridFS这种接口，可以将数据进行多个分割来进行保存。这次，我将解说处理MongoDB中处理大尺寸文件的功能——GridFS。

 

GridFS的概要图

 

 

 

图：左青：大文件 左蓝：girdFS interface（mongofile或者是driver） 黄：1.将文件分割到chunk中，写入文件。 2.文件的元数据（文件名、尺寸等等）的写入

上图例：文件 collection

右Mongod以下：chunk用collection、Binary data、Binary data、Binary data、元数据用collection、元数据。

 

被分割的数据我们称之为chunk，作为Binary data保存在Document中。

 

用数据库来管理文件的优点

 

话说回来，用数据库管理文件有怎样的好处呢。

 

在大部分系统之中，图片/音频/视频等大尺寸Binary data使用OS的文件系统进行保存。使用文件系统的话，就能用用习惯的接口访问文件。但是根据情况不同，文件被保存在数据库中，管理起来就会更有效率。以下我试着整理了用数据库来管理文件的优点。

 元数据管理简便

 

不仅是文件，也能通过数据库对文件相关的元数据进行同时管理。比如，文件的尺寸与制成者，制成时间等。视频文件的话也可以管理播放次数。在数据库中与文件相关的元数据也非常简便，有扩张性。另外，包含元数据的备份也很容易。

[Read more…]

翻译自：　http://gihyo.jp/dev/serial/01/mongodb/0005

第5回 试试MongoDB的Sharding

 

前言

 

这次我将说明MongoDB的sharding。

 

Sharding是指将数据分散到多个服务器中的功能。这次我将先说明sharding，之后是sharding的概要，之后将解说在sharding中登场的几个关键词。第二章之后将解说sharding的架构顺序。

 

Sharding在MongoDB功能之中是很重要而复杂的。用手边的环境来架构的话，对sharding的理解有很大帮助，请一定好好参考本文再进行架构。

 

sharding的优点

 

Sharding通过将MongoDB进行水平Scaling的功能，有以下优点。

 

因为分散负荷所以可以提高性能

 

通过将数据分散到多个服务器中，可以减少CPU以及I/O的负荷。虽然是复述，但MongoDB可以用key的范围数据。通过设定合适的范围，可以将负荷进行水平Scaling。

 

由于资源分散导致性价比的提高。

 

近年因为内存以及磁盘的价格变得非常便宜了，尺寸越大内存模块价格越高，另外价格的上升幅度也会增多。要举内存的例子的话，共计需要64GB的内存时，比起与16个4GB内存Module的价格，4个16GModule的价格一般而言会更贵。内存以及磁盘在一个服务器中能够累计的Unit数是有极限的。在这样的背景下，在多个服务器中，使得数据分散，可以使得性价比提高。在MongoDB因为内存与性能直接相关，我推荐要保证有充足尺寸的内存。

 

MongoDB的sharding的概要

 

关于sharding，我将说明数据分散以及自动Balancing这两个特征。

 

 

根据Shard key的范围的数据分散

 

MongoDB的sharding采用范围分区（※1）。通过指定Shard key，可以决定个服务器中存储的数据的范围。服务器间不拥有重复数据，一个数据被存储的数据库是根据Shard key的范围来决定。

用图表示Sharding的image的话，就如图1所示。在图一中出现的术语我稍后说明。首先请随我对全体内容有个大致印象。

图1 sharding的概要图

图：右图例：mongos服务器 Shard Chunk 数据

 

※1）

 

仅仅观察数据分散这个点的话，几乎与MySQL的范围指定的分区几乎相同。

 

 自动balancing

 

Key范围的调整以及伴随调整的服务器间的数据的移动，MongoDB有将其全部自动进行balancing的功能。被设计不去在意由于自动balancing导致的服务器间的数据的偏差也行的形式。另外追加新的服务器时，自动调整会使得执行数据移动的偏差渐渐消失。

※2）

在设定中可关闭自动balancing

 

重要关键词的说明

 

现在我将说明在sharding中出现的关键词。

 

 shard

这是指数据被实际存储的mongod进程。1个文件存在一个shard中，无法在shard之间执行数据的复制。虽然不是必要的，但我推荐为每一个shard都要配置replication复制。

 

config服务器

这是指管理sharing的Metadata的mongod进程。因为会成为单一故障点，所以我推荐用复数的config服务器来构成。

 

mongos服务器

这是指在sharing中的路由进程Routing process。可以使shard以及客户端合作。必要的话，可以做多个mongos服务器。因为不是mongod进程，所以是无状态的，也不存放数据。

 

Shard key

这是指分散数据的key。可以进行复数指定。Key上哪个范围的数据被存储在那个shard中由MongoDB管理，根据数据的偏差进行自动调整。

 

chunk

 

chunk是指分散的数据单位。具体来说，在某个collection的连续范围的数据中，会变成复数的文件。达到chunk的最大尺寸的话，就会被分割，shard对应拥有的chunk数，必要的话会移动到其他shard中。可以变更chunk的最大尺寸。

 

至此我们说明的的关键词，一下子记不住也没关系。我们将通过在下一章中通过实际构造sharding环境，来加深理解。

试试sharding（前半）

 

在这一章与下一章中，我们将实际制作sharding结构。

 

这次，我们将在一台机器中区分节点，做5个服务器。具体来说就是，config服务器、mongos服务器、以及3个shard（node0，node1，node2）。3个mongod分别变成其他shard（参考图2）

 

 

 

构筑系统的服务器准备

首先制成数据direct以及日志direct。顺序按MongoDB的解压direct执行。

$ cd (MongoDB相关目录)

$ mkdir -p data/config

$ mkdir data/node0

$ mkdir data/node1

$ mkdir data/node2

$ mkdir log

 

启动shard

$ bin/mongod --shardsvr --port 30000 --dbpath data/node0 --logpath log/node0.log --fork  
$ bin/mongod --shardsvr --port 30001 --dbpath data/node1 --logpath log/node1.log --fork  
$ bin/mongod --shardsvr --port 30002 --dbpath data/node2 --logpath log/node2.log --fork

 

Mongod命令中，由于指定shardsvr的option，这个mongod会变成shard。

 

启动config服务器

 

$ bin/mongod --configsvr --port 20001 --dbpath data/config --logpath log/config.log --fork

 

通过在mongod命令中，指定configsvr的选项，这个mongod会变成config。

mongos服务器启动

$ bin/mongos --configdb localhost:20001 --port 20000 --logpath log/mongos.log --chunkSize 1 --fork

 

通过mongos命令，可以启动mongos服务器（不是mongod）。——在configdb中指定config服务器。mongos服务器是仅仅在内存上存在的进程，所以没有必要指定dbpath。chunkSize是chunk的尺寸。默认是64M，但这次想确认chunk分割的东西，所以这次设定1MB。

确认

在ps命令中可以看见5个进程就没问题了。

$ ps -ef | grep mongoroot 
$ bin/mongod --shardsvr --port 30000 --dbpath data/node0 --logpath log/node0.logroot 1235 
$ bin/mongod --shardsvr --port 30001 --dbpath data/node1 --logpath log/node1.logroot 1236 
$ bin/mongod --shardsvr --port 30002 --dbpath data/node2 --logpath log/node2.logroot 1239 
$ bin/mongod --configsvr --port 20001 --dbpath data/config --logpath log/config.logroot 1241 
$ bin/mongos --configdb localhost:20001 --port 20000 --logpath log/mongos.log --chunkSize 1

 

在mongos服务器中追加shard

用mongo shell，连接到mongos服务器的admin数据库。

$ bin/mongo localhost:20000/admin

 

用sh.addShard方法追加shard。

 

mongos> sh.addShard("localhost:30000")    // 追加{ "shardAdded" : "shard0000", "ok" : 1 }   
mongos>  sh.addShard("localhost:30001")   // 追加{ "shardAdded" : "shard0001", "ok" : 1 }   
mongos> sh.addShard("localhost:30002")    // 追加{ "shardAdded" : "shard0002", "ok" : 1 }

 

因为在「sh」这个object中有简化sharding的设定的方法。

 

用sh.status方法确认追加的shard是否正确追加了。

mongos> sh.status()

--- Sharding Status --- 
 sharding version: { "_id" : 1, "version" : 3 } 
 shards:        {  "_id" : "shard0000",  "host" : "localhost:30000" }        
 {  "_id" : "shard0001",  "host" : "localhost:30001" }        
 {  "_id" : "shard0002",  "host" : "localhost:30002" }  
 databases:        {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }

 

投入数据

 

然后，将通过mongos服务器投入数据。

 

在连接mongos服务器的状态下，制作logdb这个数据库。

mongos> use logdb
switched to db logdb

 

然后，在logs这个collection中投入10万件数据。因为在mongoshell中可以使用javascript的语法。通过for循环插入数据。

 

mongos> for(var i=1; i<=100000; i++) 
db.logs.insert({"uid":i, "value":Math.floor(Math.random()*100000+1)})     
 mongos> db.logs.count()100000                   
 //插入了10万个document

 

 

最后在uid中展开index。理由是，在此后将collection进行sharding化的情况下，需要对应shard key制成index。

mongos> db.logs.ensureIndex( { uid : 1 } );

 

在这个时间点，sharding还没有变成有效的。仅仅是单纯地在最开始的节点中插入10万个document

 

图3 sharding有效前的image图

 

最右：mongos服务器 shard 数据

 

要确认这个状态，观察mongo shell中mongos服务器的config数据库就行了。让我们来试着对config数据库的chunks collection加入询问。

 

 

试着sharding吧

sharding的有效化

 

那么接下来，让我们对sharding就行有效化，试着分散数据吧。要将sharding有效的话，需要在sh object的enableSharding方法中指定数据名。

 

mongos> use admin
switched to db admin
mongos> sh.enableSharding("logdb"){ "ok" : 1 }

 

然后用sh.shardCollection方法指定shard化的collection。第一参数是（数据库名）.（collection名）的文字列，第二参数是作成index时的hash。

 

mongos> sh.shardCollection("logdb.logs" , { uid : 1 }){ "collectionsharded" : "logdb.logs", "ok" : 1 }

 

 

sharding的状态确认

 

在此，用sh.status方法表示sharding的状态的话，我们可以知道在3个shard服务器中，分别可以作成chunk。

mongos> sh.status()
--- Sharding Status ---  
sharding version: { "_id" : 1, "version" : 3 }  
shards:    {  "_id" : "shard0000",  "host" : "localhost:30000" }    
{  "_id" : "shard0001",  "host" : "localhost:30001" }    
{  "_id" : "shard0002",  "host" : "localhost:30002" }  
databases:    {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }    
{  "_id" : "logdb",  "partitioned" : true,  "primary" : "shard0000" }      
logdb.logs chunks:          
shard0001       1    // ←shard0001的chunk数          
shard0002          

{ "uid" : { $minKey : 1 } } -->> { "uid" : 10083 } on : shard0001 Timestamp(2000, 0)        
{ "uid" : 10083 } -->> { "uid" : 20166 } on : shard0002 Timestamp(3000, 0)

 

在上述的输出中，shard0000的chunk数有8个，shard0001的chunk数是1个，然后shard0002的chunk数是1个

 

这样chunk数发生偏移的情况是因为数据还在移动中的原因。请稍等后，在此执行sh.status。

 

--- Sharding Status ---  
sharding version: 
{ "_id" : 1, "version" : 3 }  
shards:    {  "_id" : "shard0000",  "host" : "localhost:30000" }    
{  "_id" : "shard0001",  "host" : "localhost:30001" }    
{  "_id" : "shard0002",  "host" : "localhost:30002" }  
databases:    {  "_id" : "admin",  "partitioned" : false,  "primary" : "config" }   
{  "_id" : "logdb",  "partitioned" : true,  "primary" : "shard0000" }      
logdb.logs chunks:        
shard0001       3     // ←shard0001的chunk数 
shard0002       3     // ←shard0002的chunk数 
shard0000       4     // ←shard0000的chunk数 
{ "uid" : { $minKey : 1 } } -->> 
{ "uid" : 10083 } on : shard0001 Timestamp(2000, 0)          
{ "uid" : 10083 } -->> { "uid" : 20166 } on : shard0002 Timestamp(3000, 0)

 

 

稍等后，chunk数就均等地变成3.3.4了（参考图4）

 

 

Chunk数均分的image图

图：最右 mongos服务器、shard、chunk、数据

数据数和chunk数是image。

另外，各输出的后半中加入的各chunk中的shard key的范围被输出了，

{ “uid” : 10083 } –>> { “uid” : 20166 } on : shard0002 Timestamp(3000, 0)

在上述例子中，我们可以看出shard0002的chunk被储存在uid的范围是10083≦uid＜20166这个collection中。

$minKey被看做比所有值都小，$maxKey被看做比所有值都大。

另外也有别的确认方法——观察mongos服务器的config表的方法。

 

mongos> use config
switched to db config
mongos> db.chunks.count()
10
mongos> db.chunks.findOne()

 

各shard服务器的状态确认

 

在被sharding的状态下，确认各shard服务器会变成怎样。做法很简单，只要在各shard服务器中用mongoshell连接就性了，首先试着访问node1吧。

$ bin/mongo localhost:30000/logdb
> db.logs.count()
39503
> exit

 

 

这样，就可以参照在各shard服务器中加入的collection数。另外用find方法等也能参照collection数。其他的shard服务器也是相同的。

 

$ bin/mongo localhost:30001/logdb
> db.logs.count()
30248> exit 
$ bin/mongo localhost:30002/logdb
> db.logs.count()
30249
> exit

 

下次的主题

 

这次我介绍了mongoDB的数据分散功能，sharding。通过使用sharding功能，可以分散负荷以及资源从而实现减少成本。另外我也介绍了自动balancing这种MongoDB的特有的功能。

下次，我介绍上次介绍过的复制以及这次介绍的sharding来进行组合构成介绍。

 

本文地址：https://www.askmac.cn/archives/overview-mongodb.html

 

在本连载中我们会对mongodb有一个初步的认识，介绍在何种场景下mongodb是适用的。

 

NOSQL

在过去20年间，CPU的处理能力上升了几十倍，而同样空间的磁盘的成本也下降到了原来的千分之一。越来越多的开发工程针对web端和移动app而存在，而我们的计算机环境软硬件造就了我们今天所能处理的数据量和互联网的访问量都成倍增长了；由于对于数据存放和处理的数据库环境也在逐渐进化。

在传统的RDBMS关系型数据库中，对于担当极高流量的web系统的后台数据库而言，集中式非分片化的架构逐渐显现出了性能的极限。 所以目前正流行着通过在适当的位置以NOSQL来补充，以便补足原有系统在性能上的不足。

 

[Read more…]

Mongodb 配合node.js 是最佳搭档，但如果不经过必要的测试就上线的话肯定会出现这样那样的问题，包括：“无法发挥出预想的性能”、“不了解sharding和replication是如何工作的“、”不知道如何监控才好“，”要如何做备份和恢复呢“，”安全性方面要如何考量“。这系列的文章就是为了解答此问题。

 

前言

mongodb对于新手是很友好的，安装简单，用户接口也因为JSON而显得很单纯。没有什么RDBMS相关知识的开发者也能开发出简单的应用。基于javascript开发，常常使用样本数据来指导开发，而一旦当真实数据开始大量产生后，就会出现”怎么不能发挥预想性能的问题“

”MongoDB由于是NOSQL所以速度很快“  ， 这样的见解是很危险的。以mongodb为例，NOSQL的特点是“善于水平数据分配(Sharding)，水平分片的话，请往往比单机要快！”  这虽然是事实，但单机的快慢仍和具体的调优/优化有关。另外，”因为是NOSQL所以就比RDBMS要快“ 这种想法是要不得的；如果不在实际的场景中去充分测试那么没有人能得出有价值的性能比较结论。

也可能会有人这么想：“那么为了提供整体性能，我们就一定要把sharding数据分片用起来啊！”

但实际大家可能会觉得意外的是，MongoDB的大原则其实是尽可能不要进行sharding。

MongoDB的sharding虽然看起来非常不错，似乎有必要为了提高性能而就sharding进行相关的应用设计，但使用起来其实并不简单。 特别是对已经sharding的数据进行备份的话，就较为困难了。

在MongoDB中如果不是特别复杂的查询，那么使用较为一般的硬件，不进行sharding，也可以达到每秒3000-10000个document的查询。    因此，如果不是太大规模的数据量，则没有必要进行sharding。实际使用mongodb的企业很大一部分并没有启用sharding。

因此在本讲座中关于MongoDB单体性能的阐述，我会试图仔细的说明。  第一回我们说明下 “到底是慢在哪里？”， 第二回则说明“为什么慢”。

 

要知道是什么原因引起了慢

 

要处理性能问题，第一要义是知道是什么原因引起了慢；我是为基础设施团队工作的，经常从应用团队哪里接到”数据库就是慢得不行，你快帮忙想想办法吧。“ 这要的拜托。  听到这样的问题，一个职业工程师的第一个反应应当是找出到底什么原因造成了慢。

具体而言，”是某一个特定的查询的响应速度满了吗？“ ”还是整体的数据库的处理能力低下？”  ， 以及到底是“查询慢了，还是“事务慢了”。  比如，写入的响应时间明显变长了，那么此时去扩大物理内存，往往也得不到什么改善。

那么MongoDB到底是哪里慢了，让我们了解一些诊断的技巧。

 

首先来看看慢的查询

 

首先我们来看看最基本的找出缓慢查询的方法。  在MongoDB中默认情况下，耗时超过100ms以上的查询，会现在在mongod进程的后台日志中。   以下展示的是mongodb 3.0.中的一个慢查询日志的例子（在MongoDB 2.x中也几乎一样):

 

2015-07-10T04:09:01.113+0900 I COMMAND  [conn1] command test.$cmd command: insert { insert: "hoge", documents: [ { _id: ObjectId('559ec6cd959e8f181ae68153'), a: "012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789..." } ], ordered: true } keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 2, w: 2 } }, Database: { acquireCount: { w: 2 } }, Collection: { acquireCount: { w: 2 } } } 120ms

[Read more…]

MongoDB3.0对WiredTiger存储引擎引入了压缩功能。在本文中，我们将观察不同选项，并举例说明这个功能如何运行。由于情况因人而异，所以我们鼓励你测试自己的数据和应用程序。

 

为什么需要压缩？

每个人都知道存储很便宜对吧？

但是，有可能你添加数据的速度比存储价格下降的速度来得更快，你花费在存储上的净支出实际上正在上升。你的内部成本也可能需要包括管理等因素，因此它们的价格可能会比商品市场价格高出很多。换句话说，你仍然需要寻求新的方式以减少您对存储的需求。

 

磁盘存储的大小是一个需要考虑的因素，当然还有其他需要考虑的。磁盘I/ O延迟是由在旋转存储上寻道时间为主导。通过降低数据的大小，用更少的磁盘寻道检索一定量的数据是必要的，这样磁盘I / O吞吐量将得到改善。对于RAM而言，一些压缩格式可以不用解压在内存中的数据。在这样的情况下，更多的数据可以放在RAM中，从而提高了性能。 

MongoDB的存储性能

还有两个关于存储的重要特性，影响空间在MongoDB中的使用：BSON和动态模式。

 

MongoDB存储数据在BSON，一种类似JSON文件的二进制编码（BSON支持其他数据类型，如日期，不同的数字类型，二进制类型）。 BSON能有效编码和解码，并且易于遍历。然而，BSON不压缩数据，所以有可能它的数据表示大于同等的JSON。

 

用户喜欢MongoDB的文档数据模型的一点是其动态schema。在大多数数据库中，模式(Schema)是在一个分类或系统表中集中进行描述和维护的。列名对所有行仅保存一次。这种方法对于空间是有效的，但它需要所有数据根据模式被构造。 MongoDB中目前还没有核心分类：每个文件是自述的。新字段可以被添加到一个文档，而不会影响其他文件，并且不用在核心分类中进行字段登记。

 

更大灵活性的代价是更大的应用空间。字段名在每个文档中被定义，在允许的情况下就使用较短的字段名。但是同样要注意不要太短 – 单字母字段名称或代码会使得字段名称很难理解和阅读，其数据也变得更难使用。

 

好在传统的模式不是有效利用空间的唯一方式。对于处理重复值比如字段名称，以及在文件中存储的大量数据，压缩也是很有效的方式。

 

没有万能的压缩方法

压缩很常见：图像（JPEG，GIF），音频（MP3），视频（MPEG），以及大多数Web服务器在使用gzip发送到浏览器之前，也会压缩网页。压缩算法已经存在了几十年，也有一些奖励创新的比赛。

 

压缩库依靠CPU和RAM来压缩和解压缩数据，而且每个都在压缩率，速度和资源利用率​​方面有不同的权衡。例如，一个当今最好的压缩库在文本方面可以压缩1GB的维基百科数据到124MB，相对于gzip的323MB，但它需要大约近3000倍的时间和30000倍的内存来这样做。根据您的数据和应用程序，某个库的使用可能会对于你的需求比别人更有效。

 

MongoDB3.0引入WiredTiger，支持压缩一个新的存储引擎。 WiredTiger使用页面管理磁盘I / O。每个页面都包含很多BSON文件。页面被写入磁盘时就被默认压缩，当在磁盘中被读入高速缓存时它们就被解压。

 

压缩的基本概念之一是重复值 – 确切的值以及形式 – 可以一次以压缩的格式被存储，减少了空间的总量。较大的数据单元倾向于更有效地压缩，因为有更多重复值。通过在页面级别压缩 – 通常称为数据块压缩 – WiredTiger可以更有效地压缩数据。

 

WiredTiger支持多种压缩库。你可以决定哪个选项是最适合你的集合水平。这是一个重要的选择，你的访问模式和数据可能在集合间大不相同。例如，如果你使用GridFS的存储较大的文件，如图片和视频，MongoDB自动把大文件分成许多较小的“块”，当需要的时候再重新组合。 GridFS的实施维护两个集合：fs.files，包含大文件的元数据和其相关的块；以及fs.chunks，包含大数据分成的255KB的块。对于图像和视频，压缩可能会有益于fs.files集合，但在fs.chunks的数据可能已经被压缩，因此它对于这个集合可能需要禁用压缩。

 

MongoDB3.0中的压缩选项

在MongoDB 3.0中，WiredTiger为集合提供三个压缩选项：

1. 无压缩
2. Snappy（默认启用） – 很不错的压缩，有效利用资源
3. zlib（类似gzip） – 出色的压缩，但需要占用更多资源

 

有索引的两个压缩选项：

1. 无压缩
2. 前缀（默认启用） – 良好的压缩，资源的有效利用

 

你也许会好奇，为什么对索引压缩选项与集合的不同。前缀压缩是相当简单的 – 值的“前缀”是将数据集中重复数据删除。这对于某些数据集特别有效，如那些低基数的（例如，国家），或那些具有重复值的，如电话号码，社会安全码和地理坐标。它对复合索引特别有效，如第一列与第二列的所有唯一值重复。前缀索引还提供了一个非常重要的优势优于Snappy或zlib – 可以直接使用压缩索引进行查询操作。

 

当从磁盘中访问被压缩的集合数据，数据在高速缓存中被解压。通过前缀压缩，索引可以在RAM中保持被压缩的形式。我们往往看到使用前缀压缩得到的非常好的带索引的压缩，这意味着在大多数情况下，你可以容纳更多的索引在内存中而不牺牲读取的性能，并且对写的影响很小。压缩率会有因您的数据的基数以及是否使用复合索引而有显著的不同。

 

请记住哪些适用于MongoDB的3.0所有压缩选项：

1. 随机数据不能压缩
2. 二进制数据不能压缩（它可能已经被压缩）
3. 文本压缩效果特别好
4. 对于文件中的字段名压缩效果特别好（尤其对短字段名来说）

 

默认情况下，对WiredTiger存储引擎存储的集合和索引启用压缩。 为了在启动时明确设置副本的压缩，需要在YAML配置文件中的进行相应设置。使用命令行选项 –wiredTigerCollectionBlockCompressor。由于WiredTiger不是在MongoDB中3.0的默认存储引擎，你还需要指定 –storageEngine选择使用WiredTiger再利用这些压缩功能。 

 

要指定压缩特定的集合，你需要使用db.createCollection() 命令中的并传入相应参数项来覆盖默认值。例如，使用zlib压缩库创建一个名为email的集合：

如何测量压缩

测量压缩的最好方法是使用和不使用启用压缩来分别装载数据，然后比较两个大小。db.stats()命令返回许多不同的存储数据，但两个与比较有关的测量点是存储大小和索引大小。值以字节为单位返回，但你可以通过传入1024*1024参数转换成MB：

这是我们在使用下面压缩方法时进行的测量方法。

 

在不同的数据集上测试压缩

让我们来看一些不同的数据集，看看一些压缩选项的执行。我们有四个数据库：

 

Enron

这是臭名昭著的Enron email corpus。它包括约50万的电子邮件。在邮件正文字段有大量的文本，一些元数据的基数很低，这意味着他们都可能会被压缩得很好。下面是一个例子（这里截断了电子邮件正文）：

不同选项在Enron数据库的运行状态：

Flights

美国联邦航空管理局（FAA）提供了关于按时的航空公司服务的数据。每个航班被表示为一个文件。许多字段有低基数，所以我们觉得这个数据集会得到很好的压缩：

不同选项在Flights数据库的运行状态：

MongoDB的配置数据库

这是MongoDB存储在配置数据库进行分片集群的元数据。该手册描述了该数据库的各种集合。下面是来自块集合的一个例子，它把每个块的文件存储于集群中：

不同选项在配置数据库的运行状态：

TPC-H

TPC-H是一款经典的用于测试关系分析的数据库管理系统的标杆。该模式已被修正为使用MongoDB的文档模型。下面是订单表中的例子，只有很多行项目的第一个在此订单显示：

不同选项在TPC-H数据库的运行状态：

Twitter

这是200K的数据库。这里有一个模拟使用了Java3.0驱动的Tweets：

不同选项在Twitter数据库的运行状态：

比较压缩率

这些数据库大小不等, 这使得他们难以进行比较绝对的大小比较。我们可以通过比较每个选项所节省的存储空间来看他们的好处。要做到这一点，我们通过使用Sanppy和zlib在WiredTiger中的未压缩大小来比较每个数据库的大小。如上所述，我们增加storageSize和indexSize的值。 

另一种描述压缩的好处的方式是未压缩尺寸与压缩后的大小的比例计算。这里是Snappy和zlib在五个databases.v的执行。

如何测试自己的数据

有两种简单的方法可用于测试你在MongoDB 3.0中的数据的压缩。

 

如果你已经升级到MongoDB 3.0，你可以简单地用在副本中增加一个新成员并在启动时指定使用WiredTiger存储引擎。当你在运行时，通过设置为0 votes来隐藏这个副本，这样就不会影响到你的部署。 这个副本集新成员将和已存的成员进行初始同步。初始同步完成后，你可以从你的副本集中删除这个WiredTiger副本，然后连接到之前单独副本来比较你的数据库大小。对于你要测试的每个压缩选项，您可以重复这一过程。

 

另一种选择是使用mongodump导出你的数据并用它将其还原到一个独立的MongoDB 3.0实例。默认情况下您的集合将使用Snappy的压缩选项，但你在运行mongorestore之前，先创建具有相应设置的集合来指定不同选项，或者用不同的压缩选项启动mongod。这种方法能够导出/恢复特定的数据库，集合，或集合的子集来执行测试。

 

对于语法设置压缩选项的例子，请参见“如何使用压缩”部分。

 

固定集合（capped collection）须知

固定集合在MMAP存储引擎的实现与WiredTiger（和RocksDB）非常不同。在MMAP，空间在创建时被分配用于固定集合，而对于WiredTiger和RocksDB，只有当数据被添加到固定集合时，空间才被分配。如果你有很多空的或大部分空的固定集合，在不同的存储引擎之间的比较可能会因为这个原因出现误导。

 

本文地址：https://www.askmac.cn/archives/archiving-and-compression-in-mongodb-tools.html

 

介绍

 

我在MongoDB World 2015做的演讲“Putting the Go in MongoDB”，重点是关于MongoDB工具的重写，从C ++到Go，这在可用性以及性能方面得到了一些改进，但是这里我只简要的说两个方面的新功能，(planned for the 3.2 release) – 归档和压缩。

 

在本文中，我将对mongodump和mongorestore提供更详细的归档和压缩特性说明，并探索使用这些特性的可行用例。

 

概述

 

一个通常目的的归档一般由一个或多个文件组成。这样例子如磁带归档格式(tar)，其中包含按顺序组成的一个或多个文件。归档在执行进程间通信的应用程序中尤其有用，例如，你可以通过远程服务器进行目录的tarball压缩，然后通过SSH，传送到到本机上进行解压：

由于归档以顺序的方式创建，接收端将能按顺序接收到发送端按顺序发来的数据。

 

在3.0中，我们增加了在MongoDB中并发执行备份和恢复多个集合的能力，这可以让你执行备份时，更加充分地利用磁盘I / O。 结果，写入mongodump的备份并不一定以顺序的方式接收。 同样，mongorestore同时读取还原操作集合，它的读取指令也并非是序列性的。

通用归档格式，如tar，只支持连续的文件归档打包。mongodump和mongorestore利用这些备份格式，将得到一个不可接受的性能退化， 由于所有集合的数据将不得不被按顺序写入和读出。为了支持这些工具的并发行为，我们研发了一个特殊的通用备份格式，支持非并发文件的写入。 这个新的归档特性极大了提高了备份和还原操作的效率。 

 

背景

 

为了按上下文情况进行备份，我们考虑一下你们通常是如何创建备份的。比如，假设你有一个“country”的数据库，其中含有两个集合-“nigeria” and “austria”， 你可能会这样操作：

上面的指令读取“country”数据库的所有集合， 然后将其写入“dump”目录。 上面的指令就会产生以下的目录列表：

你也可以备份整个服务器-这里的服务器包含两个数据库(country 和product)。

或选择备份单个集合到标准输出，而不是一个目录：

 

归档支持

 

在3.2中，我们引入了创建备份的一个附加模式 – “归档”模式，写入所有转储数据，甚至从不同的数据库和集合到单一的输出文件。 使用mongodump创建归档是极为简单的 – 只需要一个附加选项：

上面的指令将在“country.archive”文件中创建“country”的数据库归档。默认情况下，归档被写入到标准输出。不同于目录模式的执行备份，创建目录树，默认归档模式下备份结果就是一个单一的文件， 包含“country”数据库的所有数据-所有集合，索引等。 

 

你也可以备份一个单一的集合或整个服务器的内容：

单一集合：

整个服务器：

在mongodump的这种情况下，归档模式允许多个集合以非连续的方式打包在归档文件内。在mongorestore中，它允许多个集合进行并行恢复。这样，你可以在网络上执行数据迁移，降低磁盘I/O所占空间，享受到充分利用工具和底层存储引擎的并发所带来的好处。

 

数据迁移

 

一个新的备份改善的例子， 是mongodump和mongorestore之间的进程间通信 – 特别是能够将数据从一个传到另一个。在以前的版本中，这种支持有限 – 一个时间只能传输一个集合。现在，使用归档就没有这样的限制。这种方式对于数据库服务器出于安全考虑而安装有防火墙的情况下很有用。在这种情况下，一个通常的设计是允许一个或多个服务器方访问数据库。使用归档功能，在SSH上进行数据转移数据，就轻而易举了：

上面的指令使用SSH方式连接到代理主机（proxy.server.com），访问源服务器（source.server.com），在代理服务器上运行mongodump，为了最终的恢复，将源服务器的发送内容（通过SSH）到目标服务器（target.server.com）。

 

如果没有归档，通过mongodump完成这些操作的唯一办法就是，先执行备份到磁盘，在将文件复制到目标服务器，然后运行mongorestore。通过备份，一个指令就可以完成- 无需任何附加磁盘I/ O的开销。 

 

压缩支持

 

除了备份，我们还使用gzip进行压缩。这是通过在mongodump和mongorestore中引入一个新的指令行选项“- -gzip”实现的。 压缩可用于目录以及归档模型下创建的备份，压缩还可以减少磁盘空间使用。

生成：

注意,目录模型的归档备份大小-568KB-比没有压缩的备份要小很多-4.3MB.

 

压缩归档：

对于归档来说，数据在写入归档之前需要先压缩。 

恢复压缩目录模式备份，你应该运行：

类似用来恢复归档模式下的压缩备份的命令：

数据迁移不会产生任何磁盘I / O开销，由于压缩，将会使用更少的网络带宽。

 

总结

 

归档和压缩特性产生了许多用于进行备份和恢复操作的例子。如果你们正在使用MongoDB工具和其它类型的应用程序，我们也乐于倾听你们的经验及用例。 尽管目前最新版本工具还不文档，不过希望大家先对这些特性体验起来。

 

注：作为提供共享集群的集群范围快照的唯一备份解决方案，MongoDB Ops Manager和MongoDB Cloud Mannager被推荐用于较大的MongoDB部署。

From Mongo University,

下次开考时间：
Start: 2015年4月2日17:00
End: 2015年4月28日17:00

关于此考试

MongoDB认证DBA Associate级考试是为了具有MongoDB管理知识和技术的相关人员设立的。我们那些了解MongoDB相关基础知识并且具有一定专业管理经验的操作专家来进行认证。下面我们会详细说明对于此认证所需要具备的知识和技能：

考试细节

• 考试将基于MongoDB 2.6版本进行。
• 考试没有前提条件。任何人可以参与此认证考试，不过我们仍推荐大家进行一下自我学习或者参加M102和M202课程。考生也可以使用其他推荐学习准备材料。
• MongoDB认证考试提供在线网页监考解决方案。
• 完成计算机设备检查以保证你的系统满足必要的硬件软件需要以完成考试。
• 为了完成考试，你必须和你的监考方预约考试期。当然，一旦你注册了此考试，你就会收到相关的时间安排指导信息。
• 你可以在考试期内的任何时间完成考试，早晚都行。
• 一旦开考，考生将有90分钟来完成考试。
• 对于不正确的回答不会倒扣分数。
• 考试成绩将基于回答正确的题目的数量以及有专业评估作出的整体考试难度评判决定。
• 考题类型为多选题，请将你认为正确的答案进行选择即可。
• 在考试结束后，考试结果会在之后3周内得出。我们需要时间回顾考试时给出的问题并计算考试成绩。
• 请注意考试费用中不会包括免费重考费用。

MongoDB所需知识：

• 原理及特性：性能，JSON, BSON, 容错(fault tolerance)，灾难恢复，水平缩放(horizontal scaling)以及Mongo shell
• CRUD: 新建，读，更新和删除操作
• 索引: 单键, 复合, 多键索引, 构成及性能
• 聚合(Aggregation): 管道符, 操作符, 内存使用，排序(sort)、跳过(skip)和限制(limit)
• 复制(Replication): 相关设置，oplog概念，写相关，枚举，故障转移及多个数据中心的部署
• 分片(sharding)：组件，何时分片，平衡，分片key，和哈希分片key
• 应用管理： 数据文件，日志，认证及授权
• 服务器管理：性能分析，诊断调试，运维，备份和恢复

所需通用IT知识
数据库概念基础
系统编程基础
基本的JavaScript编程能力

考试规则

• 为了通过考试认证，测试者必须了解一下规则。视频，语音和计算机屏幕活动将会在考试时被记录获取并被考官回放检查。
• 在认证过程中，测试者必须按提示提供以下信息：

1. 一个清晰的头像照
2. 一个官方出具并认可的照片，如驾照或护照
3. 一份测试环境的视屏扫描

• 考生必须独立在一个安静环境中进行考试。不允许和任何其他人进行交谈。
• 在考试时，不会用到耳机，录音机，电视或其他计算机屏幕。
• 考生仅被允许阅览考题，如果必要，可以使用如Google Translate这样的一个简单翻译工具。 其他的参考资料或软件都不可使用。

考试系统需求

• Mac OS 10.6或以上，或Windows 7以上版本操作系统。Linux现在还不受支持。
• 你需要一个摄像头和一个麦克风。

完成考试设备检查以保证你的系统满足考试的软硬件需要。

MongoDB世界2015在MongoDB 3.2版推出有趣的新功能，而对于其公司和社区的未来人们感到更加好奇

 

这周我在MongoDB的年度用户大会，MongoDB世界。在三月MongoDB 3.0的发布及其WiredTiger存储引擎轰动一时。现在，我们只剩下相对较小的新闻公告，以及对于公司未来及其周围的开源数据库的社区关系的更大问题。

 

但首先我们看这个消息。今年的头条定下了基准，说MongoDB的数据库比Couchbase和Cassandra更好（大概他们也能根据自己的基准说他们是更好的），而BI集成的东西已经可以从第三方供应商获取。

 

这个“大新闻”毫不奇怪是一个snoozer。毕竟，WiredTiger在四个月前刚出现。此外，MongoDB中已经有一个近乎完整的营业额管理，如果没有产品开发的牵引这是很难做到的。这就是说，有趣的新功能即将在MongoDB 3.2中出现：

 

1. 数据静止加密。类似Hadoop，MongoDB是将数据加密到核心产品。据Kelly Stirman，MongoDB产品营销和战略部的副总裁，这将基于WiredTiger配置为MongoDB一个独立的存储引擎。这是一种常见的代码库，但将被配置为一个独立的存储引擎。

 

2. 文档验证。这基本上像在RDBMS中的限制或表结构，之前我介绍MongoDB的0版本时曾预测过。现在，你可以确保您的文档匹配他们写入时的模式。如果你在一个复杂的MongoDB项目工作过，用这个不错，虽然这有点可笑，因为不久之前无模式（schemalessness）被誉为NoSQL的一个主要优势。据Stirman，这将是开源的。

 

3. 在聚合框架动态查找。这基本上是左外连接。 Stirman表示，该公司并不想用“连接”一词，因为人们可能会认为它支持其他类型的连接。这将在聚合框架是开源的。

 

4. Tableau，BusinessObjects，Qlik和Cognos的BI连接器。我看到它具有潜力，它可能使你能避免一些ETL并分析你的运营商店的副本，但我有点怀疑，像Tableau的SQL工具能有效分析MongoDB中数据吗。技术上，我认为这是一个snoozer直到我跟Stirman说起。他解释说，非常不同的功能是，MongoDB的新的连接器将更多的处理移到数据库中，而大部分现有的连接器在客户端上做很多过滤和聚合。看到这再看看相当蹩脚的Hadoop连接器，我可以说这是一个真正重要的东西。更有意思的是它放置MongoDB的方式。

 

5. Mongo Scout schema可视化工具。这是MongoDB管理服务（MMS）中的独立的工具。

[Read more…]

本文地址：https://www.askmac.cn/archives/mongodb-how-big-data-explodes-old-databases.html

 

 

在这个新的世界，当我们需要做一些事情时，如在（相对）较短的时间内快速地建立新的大数据分析引擎，我们可以—因为有一种与生俱来的开放性和‘关注点分离’正改变着我们的技术拓扑.

 

有了MongoDB非模式化设计，用户能够带来多个新的大数据源，而不需要像以前一样去“准备它”。 这是关于创建一个环境，“数以千计的引擎”能够同时运用并行处理技术访问数据库…，当我们拥有正确的数据库拆分架构时，这已经成为可能。

 

 

对于这里的完整性，数据库拆分要将一个数据库分成更小的组件块， 我们称之为‘分片’（如破碎的玻璃）， 以至于我们能够将工作负荷通过一系列的分布式式服务器传播出去。你只需要知道什么时间开始分片是真确的。

[Read more…]

 

介绍

 

我在MongoDB World 2015做的演讲“Putting the Go in MongoDB”，重点是关于MongoDB工具的重写，从C ++到Go，这在可用性以及性能方面得到了一些改进，但是这里我只简要的说两个方面的新功能，(planned for the 3.2 release) – 归档和压缩。

 

在本文中，我将对mongodump和mongorestore提供更详细的归档和压缩特性说明，并探索使用这些特性的可行用例。

 

概述

 

一个通常目的的归档一般由一个或多个文件组成。这样例子如磁带归档格式(tar)，其中包含按顺序组成的一个或多个文件。归档在执行进程间通信的应用程序中尤其有用，例如，你可以通过远程服务器进行目录的tarball压缩，然后通过SSH，传送到到本机上进行解压：

ssh source.server.com tar c sourceDirectory | tar x

由于归档以顺序的方式创建，接收端将能按顺序接收到发送端按顺序发来的数据。

 

在3.0中，我们增加了在MongoDB中并发执行备份和恢复多个集合的能力，这可以让你执行备份时，更加充分地利用磁盘I / O。 结果，写入mongodump的备份并不一定以顺序的方式接收。 同样，mongorestore同时读取还原操作集合，它的读取指令也并非是序列性的。

[Read more…]