我最近一直在研究MongoDB,有些小心得。恰好发现原来博客园支持Live writer啊

兴奋异常,终于多年以后重回这里。以前一直用liver writer写 myspace和 wordpress

但是前者完了,后者FQ很烦。

====================================================

首先推荐一个MongoDB的查询分析器

image

MongoVUE

这个工具是非常好用,虽然超过试用期,但是仍然可以使用

只是只能开三个查询窗口而已。

 

 

以前一直使用db4o, protobuf.net  ,所以对mongoDB还是很适应的。

因为相似性太大。尤其是对象持久化的方式,细节略微不同而已。

 

=============================================

1.需求

我的一个新写的算法需要读取一个完整的collection,而这需要几十秒钟。

而一开始都是使用特性标注的自动序列化和反序列化,无论用任何方式调整,InsertBatch和

FindAll() 的性能都得不到提高。

 

2.思考

我一开始以为读取速度和保存奇慢无比,是因为mongoDB自己的问题。今天仔细想了想。问题关键在于写入硬盘的数据太多。

mongoDB的数据持久化是以BSON格式的。而这种格式的冗余还是相当大的。尤其是默认序列化和反序列化。

 

"_id" : ObjectId("4f4e2a02c992571e54c30465"),
"value" : "xxxxx",
"chars" : [{
"words" : [{
"index" : 0,
"length" : 2,
"wordTypes" : 0
}]
}, {
"words" : [{
"index" : 0,
"length" : 2,
"wordTypes" : 0
}, {
"index" : 1,
"length" : 2,
"wordTypes" : 0
}]
},

 

用mongoVUE查看最终数据格式,发觉主要存储空间消耗在意义不大的属性name上。计算一下就可以知道,名称几乎是值的5-10倍空间大小。

相比 protobuf,采用数字作为属性的名称,就十分节省空间了。

但是mongodb可以检索字段,而protobuf不可以,所以mongo没有采用protobuf的方式。

 

我有一个collection有50000个document,平均一个document  4000byte,这真是令人吃惊的低效持久化啊。怪不得读取都需要几十秒钟。整个数据存储消耗了200m空间。

 

由于看过mongoDB的官方文档

http://www.mongodb.org/display/DOCS/CSharp+Language+Center

所以对Customizing serialization有点印象。

 

官方文档描述十分简略,只说了应该将类继承IBsonSerializable 接口,然后实现四个方法。但是没有示例,完全不知道如何具体操作。

public class MyClass : IBsonSerializable { // implement Deserialize method // implement Serialize method }

 

好吧有google大神在。

stackoverflow是个好网站

http://stackoverflow.com/questions/7105274/storing-composite-nested-object-graph

 

3.解决

 

第一部分:将对象变换成数字,节省名称和空间消耗

 

        public UInt32 IntValue
        {
            get
            {
                var v1 = ((UInt32)WordTypes) << 24;
                var v2 = ((UInt32)Index) << 16;
                var v3 = ((UInt32)Length) << 8;                
                var v4 = (UInt32)0;//预留

                return v1 | v2 | v3 | v4;
            }
        }

        public void FromInt32(UInt32 value)
        {
            this.WordTypes = (WordTypes)(value >> 24);
            this.Index = (Int32)(value<<8 >> 24);
            this.Length = (Int32)(value << 16 >> 24);
        }

     

 
以上没什么好讲的,无非左移右移,当然可能会出现数据类型溢出可能,如果有这种情况,换成Int64,或者适当修改。
说明一下,这个三级对象我不准备在mongoDB中检索字段,而是只用于存储,至于检索是变换成另外字符串keyword的方式来检索。
所以既然不需要检索,属性也就根本不需要有name,所以多个属性可以位或成一个数值,存放到数组中。对象都省了。
 
第二部分
 
public partial class Sentence : IBsonSerializable
    {

        public static int idSum;
        public bool GetDocumentId(out object id, out Type idNominalType, out IIdGenerator idGenerator)
        {
            id = this.Id = idSum++;
            idNominalType = typeof(int);
            idGenerator = null;
            return true;
        }

        public void Serialize(MongoDB.Bson.IO.BsonWriter bsonWriter, Type nominalType, IBsonSerializationOptions options)
        {
            bsonWriter.WriteStartDocument();
            bsonWriter.WriteInt32("_id"this.Id);  //10多个个字节,如果用objectId
            bsonWriter.WriteString("value"this.Value);//名称如果都改用几个字母可以节省十几个个字节
            bsonWriter.WriteString("words"this.WordStr);
            bsonWriter.WriteBoolean("isConf"this.IsConflict);
            bsonWriter.WriteStartArray("c");

            foreach (var item in Chars)
            {
                BsonSerializer.Serialize(bsonWriter, item.Words.Select(v=>v.IntValue).ToList());  
            }        


            bsonWriter.WriteEndArray();            
            bsonWriter.WriteEndDocument();
        }

        public void SetDocumentId(object id)
        {
            throw new NotImplementedException();
        }

        public object Deserialize(MongoDB.Bson.IO.BsonReader bsonReader, Type nominalType, IBsonSerializationOptions options)
        {
            //bsonReader.ReadStartDocument();
            
//this.Id = bsonReader.ReadInt32(); 
            
//var value=bsonReader.ReadString("v");
            
//var wordStr=bsonReader.ReadString("w");
            
//bsonReader.ReadStartArray();

            
//var list = new List<List<Int32>>();
            
//while (bsonReader.ReadBsonType() != BsonType.EndOfDocument) 
            
//
            
//    var element = BsonSerializer.Deserialize<List<Int32>>(bsonReader); 
            
//    list.Add(element);             
            
//}

            
//bsonReader.ReadEndArray();
            
//var isConflict=bsonReader.ReadBoolean("i");
            
//bsonReader.ReadEndDocument();


            if (nominalType != typeof(Sentence))
                throw new ArgumentException("不能序列化,因为类型定义不一致");
            var doc = BsonDocument.ReadFrom(bsonReader);

            this.Id = (Int32)doc["_id"];
            this.Value = (string)doc["value"];
            this.WordStr = (string)doc["words"];
            this.IsConflict = (bool)doc["isConf"];
            var list = (BsonArray)doc["c"];

            this.Chars = new List<CharObj>();
            for (int i = 0; i < list.Count; i++)
            {
                var ch = new CharObj { Index = i, Sen = this, Words=new List<WordObj>() };
                this.Chars.Add(ch);

                var words = (BsonArray)list[i];

                foreach (Int32 item in words)
                {
                    var wordObj = new WordObj((UInt32)item);
                    wordObj.Sen = this;
                    ch.Words.Add(wordObj);
                }              
            }


            return this;
            //return new Sentence { Id=1,  IsConflict= true, Value="1", WordStr= "1"};
        }

    }
   

 

主要有几个注意地方:

一个是Id的生成。我有点不明白为什么id赋值函数要弄的那么复杂的参数,但是这样可以绕过ObjectID的 guid式的id,使用int可以节省一些空间。

当然,如果整体对象比较大,还是用objectID吧。完全没必要用int,int也有很多问题,需要保存最大值在另外的collection,没法像ObjectId一样跨多个Collection。所以mongoDB设计Id 用ObjectId而不是int,是非常有道理的。如果对象整体比较大,还是没必要节省这十几个字节的消耗。

 

二是Serialize 方法的实现中,必须要以bsonWriter.WriteStartDocument()开始 bsonWriter.WriteEndDocument() 结束,切记,否则会报出一个没法write的错误。

 

三是如何对二层的集合进行写入,我原来是这样写的

 
            foreach (var item in Chars)
            {
                bsonWriter.WriteStartArray("words");
                foreach (var w in item.Words)
                    bsonWriter.WriteInt32((Int32)w.IntValue);
                bsonWriter.WriteEndArray();
            }
          

 

但是mongoDB不支持这种嵌套式的持久化。

 

必须改成

 
            foreach (var item in Chars)
            {
                BsonSerializer.Serialize(bsonWriter, item.Words.Select(v=>v.IntValue).ToList());  
            }
         
 
那个注意虽然 BsonSerializer.Serialize的参数是一个IEnumerable<T> 但是必须要ToList,否则不会保存成功数据
 
第四,反序列化的时候不能直接用start end方式,必然会报错,只能先一次读取,再取字典值
 
4.对比

 

image

 

新的bson格式的存储比较紧凑了。

"_id" : ObjectId("4f4e2a02c992571e54c30465"),
"value" : "xxxxx",
"chars" : [{
"words" : [{
"index" : 0,
"length" : 2,
"wordTypes" : 0
}]
}, {
"words" : [{
"index" : 0,
"length" : 2,
"wordTypes" : 0
}, {
"index" : 1,
"length" : 2,
"wordTypes" : 0
}]
},

 

对比原来的,差距非常明显。

image

 

用mongoVUE 查看平均 document大小,平均只有364byte了。原来可是吓死人的4000

而合计Size也从200m下降到17m

 

而耗时image  用我笔记本,耗时大概9秒钟。原来40秒以上。而用台式机硬盘快,可以快几倍,几秒钟内搞定。

 

 

5.其他

其实为什么要实现自定义的持久化方法,一当然是性能十分的让人忧虑。第二个则是对象关联指针的重新绑定问题。

原来从数据库读取的数据,需要手工恢复相互关联的指针,现在可以在反序列化函数中直接完成这个操作。

也就是说,一旦查询出来的对象,都已经和内存对像一摸一样了。

好处是大大降低了程序的复杂度。

 

使用mongoDB数据对象,犹如内存对象一样进行指针操作。然后自动永久化数据。

呃。我发觉爱上mongoDB了。虽然它还有不少缺点。