火热的2015 MongoDB Days深圳行

虽然无法体验《南山南》中的“艳阳天大雪纷飞”,不过深圳这里火热的太阳和四处妹子的短裤大腿确实把我们这些从上海来的一行人给热到了。一下飞机,在”艳阳天”下,开始换装运动。。。脱脱脱!!

话说本次2015 MongoDB Days活动就在深圳举行,因此公司里的哥们姐们对来深圳“考察”一番很是积极踊跃。无奈名额有限,兼文笔不行(^-^),因此矮子里拔高个。。。本人再次脱引而出了~~

这不,开完会当天,吃饱喝足后就开始我的战地报道啦~~~

 

MongoDB作为最流行的NoSQL数据库,无疑正受到越来越多人的关注。其dynamic schema特性,水平分片扩展,以及内存处理快速响应能力是其在快速发展的大数据应用及互联网技术升级中能获得成功的关键所在。

为了时刻紧跟技术前沿,也为和更多MongoDB专家交流,这次的活动还是非常有必要来参加的。除了下午能听到大牛们的精彩演讲,对于小白来说,还能选择在上午参加入门培训,真是一举两得哈~~【dbDao.com 数据岛

(更多…)

Read More

Mongodb 为复制集新增节点

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

概览

 

本文描述了如何为已有的 replica set 新增节点。有关复制集部署的模式的信息,参见复制集部署架构文档。

最多可参与投票的节点数

一个复制集最多可以拥有7个 参与投票的节点 。如果要为已经拥有7个参与投票节点的复制集新增节点,我们需要将新增的节点设置为 不参与投票的节点 或者将 已有的投票节点 的票数清除。

初始化脚本

在生产环节中,我们可以修改 init script 来管理节点。

 

已有节点

我们可以使用这些命令来为现有复制集新增节点。我们还可以使用命令 “re-add” 来添加一个已经被移除了的节点。如果这个被移除的节点中的数据较新,它能很快恢复并赶上主节点的数据。

数据文件

如果我们有已有节点的备份或者快照,我们可以可以将数据文件( dbPath 文件夹中) 复制到新的机器并使用它们快速的建立一个新的节点。这些数据文件必须是:

  • 同个复制集中可用节点的数据备份。参见 用文件系统快照备份并恢复 以获得更多信息。

    重要

    推荐使用文件快照的方式而不是来 mongodumpmongorestore 来为复制集新成员做数据备份。

  • 比在主节点oplog最旧的操作更近。新成员必须能通过从主节点的oplog应用操作获取当前数据。

需求

  1. 一个可用的复制集。

  2. 一个拥有数据集的MongoDB节点,且可以与现有复制集通讯。

否则,请参考 安装教程 和 部署复制集

 

(更多…)

Read More

MongoDB NOSQL数据库连载 第11回 MongoDB的备份

 

本文永久链接地址:http://t.dbdao.com/archives/mongodb-backup.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

 

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

第10回 MongoDB中的聚集aggregation 处理

本文永久链接地址:http://t.dbdao.com/archives/mongodb-aggregation.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

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进行处理。

 

  1. MongoDB的Map/Reduce功能

 

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

 

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

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

 

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

(更多…)

Read More

第7回 GridFS——在MongoDB中保存大容量文件的方法

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

 

本文永久链接地址:http://t.dbdao.com/archives/mongodb-gridfs.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

 

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

第5回 试试MongoDB的Sharding

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

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

第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因为内存与性能直接相关,我推荐要保证有充足尺寸的内存。

 

MongoDBsharding的概要

 

关于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执行。

 

启动shard

 

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

 

启动config服务器

 

 

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

mongos服务器启动

 

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

确认

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

 

在mongos服务器中追加shard

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

$ bin/mongo localhost:20000/admin

 

用sh.addShard方法追加shard。

 

 

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

 

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

 

投入数据

 

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

 

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

 

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

 

 

 

最后在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方法中指定数据名。

 

 

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

 

 

 

sharding的状态确认

 

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

 

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

 

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

 

 

 

稍等后,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表的方法。

 

 

各shard服务器的状态确认

 

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

 

 

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

 

 

下次的主题

 

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

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

 

Read More

mongoDB-logo-website-Feature

mongodb 技术连载(一) 了解MongoDB

本文地址:http://t.dbdao.com/?p=709

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

 

 

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

 

NOSQL

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

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

(更多…)

Read More

MongoDB单机性能 第一回

本文原始地址:http://t.dbdao.com/archives/mongodb单机性能.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

 

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中也几乎一样):

 

(更多…)

Read More

MongoDB的十字路口:增长还是开放?

本文地址:http://t.dbdao.com/archives/mongodb-at-the-crossroads-growth-or-openness.html

dbDao 百度贴吧:http://tieba.baidu.com/dbdao

MongoDB技术学习QQ群: 421431253

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

  1. Mongo Scout schema可视化工具。这是MongoDB管理服务(MMS)中的独立的工具。

(更多…)

Read More