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

 

第11回  MongoDB的备份

在本连载中，至此我们一直注目MongoDB的功能方面的内容，这次开始我们将分几回介绍MongoDB的非功能方面的内容。这次我们将说明非功能特点中不可或缺的备份功能。另外，我们将使用MongoDB的最新版本v2.4。

 

  关于命令标记

$ ： 用命令行来实行的命令

> ： 用mongo shell执行的命令

MongoDB的备份的概要

 

要对MongoDB进行备份，需要对数据进行备份以及对配置选项进行备份。

 

配置选项用mongod的启动命令或者配置文件来进行指定。无论那种情况，因为只要复制mongod启动shell以及配置文件等文件就可以进行备份了，所以在这次的文章中将省略说明。

 

在数据的备份之中，可以将全备份与部分备份来进行组合使用，但在MongoDB v2.4中没有提供增量备份的功能。因此，这次我们介绍全量备份以及restore的方法。

［参考］

增量备份是为了恢复因为人为错误损害的数据而被实现的功能，其功能目的对应MongoDB的延迟复制功能。关于延迟复制功能，请参考官方网站。

 

 

要用MongoDB进行全量备份时，有以下两种方法。

1. 复制数据文件的方法
2. 利用mongodump

[Read more…]

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

第10回  MongoDB中的aggregation 聚集处理

MongoDB中的aggregation 聚集处理的概要

 

一般而言，在NoSQL的程序中，没有RDB的SQL这种Group以及Sum函数等聚集功能。要执行聚集的话，需要在应用上独立地写代码。

但是，MongoDB的开发方针是是一边维持NoSQL的性能，一边实装类似于RDB的功能，关于聚集功能早就实装了。在MongoDB中执行聚集处理的方法有三种。

1. Aggregation Framework

 

SQL中提供Group By语句以及Sum函数。可以从Mongo Shell中与查询一样实施。一部分的处理（$group与$sort）就对应sharding，用各shard进行处理。

 

2. MongoDB的Map/Reduce功能

 

独立定义Map函数/Reduce函数，执行聚集处理。在Aggregation Framework中无法做到的复杂的聚集处理，使用这种方法。因为对应sharding，所以可以执行分散处理。

 

3. 与其他聚集处理软件/框架的合作

为了执行大规模的聚集处理，也可以与其他聚集处理软件/框架合作。在这次的文章中，我将介绍与Hadoop的合作。

 

那么马上让我们来使用Aggregation Framework，来试着实际操作处理吧。

[Read more…]

翻译自 ： 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来进行组合构成介绍。