Posts Tagged ‘ NoSQL

一段小脚本,将 MongoDB 中所有 DB 的 Collection 按大小排序。

最近接到的一个遗留项目,数据库用的是 MongoDB,年久(?)失修,磁盘满了运维报怨。

实例里面有多个库,每个库中又有很多 collection
于是想要看看哪个 collection 占用的空间比较大,想 remove 掉一些过期数据。

发现 pymongo 取出 collection 之后,无法像 mongo 客户端一样可以直接用 collection.stats() 的方式获取状态。
于是很郁闷。

登上 mongo 查看了一下:

?View Code JAVASCRIPT
// db.col.stats
function ( scale ){
return this._db.runCommand( { collstats : this._shortName , scale : scale } )
}
 
// db.stats
function (scale){
return this.runCommand( { dbstats : 1 , scale : scale } );
}

这才发现,原来 db.state 和 collection.state 都是通过 mongodb 的内部命令实现的。

所以就有了如下代码:

?View Code PYTHON
from pymongo import Connection
db = Connection(HOST, PORT)</code>
 
print sorted(
    [(
        "%s -&gt; %s" % (dbn, coln),
        db[dbn].command('collstats', coln)['storageSize']
    )
    for dbn in db.database_names()
    for coln in db[dbn].collection_names()
    ],
    key=lambda x:x[1])

PS:这篇日志是 惰性的 Blade 大大两年之后头一次在这个布珞阁更新,大家鼓励他一下吧。

MongoDB的备份和恢复

话说怎么备份本身就是一个非常值得深入探讨的问题。能把数据放置到别的地方,而后再拿回来使用,看似很简单,但实际应用中却是非常令人恼火的一件事儿。因为实际运行中,所有的数据都是流动的,以刻舟求剑的方式来作数据的备份和恢复就很不靠谱了。但同时,任何应用于生产环境的数据存储方案首先要考虑的就是备份融灾问题。可能你的机房里不会有大象,但是说不定会有老鼠呢。可能你的操作人员不小心拉错了闸。这些事情貌似都不太可能发生。但是以我的实际经验来看,如果你没有备份的话,倒霉的事儿发生的几率就会成几何级数增长。也就是说备份了就备份了,要是不备份,倒霉的事儿总会发生在你头上。所以还是小心一些。另外说一句,备份是非常不符合精益思想的,起码原生态的简单备份有着明显的浪费,而且若是做不好监控的话,出故障的几率并不低,所以千万不要觉得备份就万事大吉,仅仅是运维的第一步而已。

有两种比较简单的备份方法(直接copy数据库文件,mongodump),不太能单独在生产环境中使用。比较建议的做法是构建Master-Slave,在Slave上做些备份,slavedelay是个非常有用参数,要是不想搞得很麻烦,就可以设置几个不同的slavedelay值的slave,这样就可以应对很多情况了。有人问了,如果有些延时,那么岂不是会丢失一些数据。说对了。首先备份并不能保证完全不丢失数据,任何地球上已知的方法都不能保障这一点。其次,备份数据也要考虑备份的目的。其实并不是所有情况都是要回复到最新的数据的,想一想有人用大量垃圾数据填充你的数据库你怎么办。应对这样的情况就不能简单地恢复到最新的备份了是吧。

在slave上,可以定期地加锁,备份,然后解锁。总之了,要在slave展开热备份的一切操作,甚至为备份建立专门的slave。比如视觉中国的图片存储方案中的备份就是这么做的。

MongoDB 东扯西

话说,传统的关系型数据库已经不那么吃香了。近来其他类型的数据库如雨后的春笋一般层出不穷,令人目不暇接,但也肯能非常令人恼火。究其原因,大多是觉得关系型数据库的性能不行,很多情况下也不适合互联网的应用。有针对性的,各路神侠构造了各种兵器,其中很大一类是基于key/value机制的数据库,典型的代表呢,就是Tokyo Cabinetmemcachedb。Tony Bain的一篇文章Is the Relational Database Doomed?对一些数据库发展的现状做了一个客观的评说。另外,还有ibm提出的xml的东西,不知道是个啥,半死不活的样子。很多年以前还有人搞了面向对象的数据库,后来也不怎么着,算是无疾而终(这么说很对不起还活着的兄弟,那能怎么样呢,不过是行尸走肉)。

无疑,数据库战场上的波澜会将每一个互联网开发者卷入其中。一波又一波的“去SQL化”浪潮(详见这里)在改变我们观念的同时,也在改变互联网的构建方式。

Document-Oriented database应运而生,典型代表

CouchDB 有篇不错的英文介绍

不过今天的主角是MongoDB注意啊不是MangoDB,让我们开开心心的开始吧。