Mongodb

之前数据存储方面接触最多还是Mysql,SQLserver, 用起来还不错, 也没有觉得很复杂, 或许人的思维习惯了复杂,后来慢慢听到了很多很热的词:NoSQL.开始觉得NoSQL == "No SQL", 是表示我们不需要SQL了,放弃关系数据库了吗? 当时觉得这会不会只是一个很热的词了,过阵子就不了了之,就木有花很多时间在这上面.这次有这样一个机会可以好好看看. 很基本的疑问是:关系数据库是70年代产生的,问题是在觉得如何存储和获取数据(通过SQL这样的一个DSL), 而面向对象是在80年代兴起的,也许关系数据库使用了很多的场景,但是到了现在随着WEB大潮的到来,数据量的爆咋,关系数据库已经很吃力了.你实际上在要求70年代设计关系数据库的作者超前设计这样一个"one size fits all"的数据存储系统,很明显这是不太可能的. 所以Not only SQL的数据存储方式就应运而生了. 主要包括4种:

• Key-Value store , 比如Memcached
• Big-Table , Cassandra
• Document-Oriented, MongoDB, CouchDB
• Graph Database , Neo4j

本篇文章只简要的介绍MongoDB.

MongoDB (from "humongous") is a scalable, high-performance, open source, document-oriented database.

MongoDB是面向文档的数据库, 这个可以跟关系数据库对比起来.关系数据库我们可以认为是面向表格的,每一个表格都第一行是schema,其他的是对应的数据.一个post-user的例子: 在关系数据库中我们这么表示:               而在mongoDB我们一个文档来表示:               看起来非常熟悉, 对,没错,key-value pair, 非常像JSON的格式.而实际上这个文档的存储方式就是以BSON来实现的.

MongoDB uses BSON as the data storage and network transfer format for "documents".

Schema设计: MongoDB的哲学是:如果它是一个Aggregation Root的model,那么它应该值得有自己的Collection(这里对应关系数据库中的table), 将其它的model尽量内嵌到这个aggregation root中去.                     传统的关系数据库很重要的一个概念是范式.我们强调在将Model映射到数据库设计时使用E-R图帮助设计,比如在上面的图中,我们传统是希望将post-user之间联系在设计数据库时划分为post表和user表,它们之间使用外键来创建这样的一个1对1的关系. 而在MongoDB中更强调去范式,尽量能内嵌的就内嵌,而不是去单独抽出来独立成为一个collection.内嵌的方式更加有效率. MongoDB经常要问得是:

"why would I not want to embed this object?"

更多的可以参考MongoDB的Schema Design. MongoDB的Query也是很方便的:             而比较复杂是Aggregation的操作,比如SQL中的group, avg,sum等等,这些操作在MongoDB中可以使用Map/Reduce来完成. MongoDB差不多对主流的编程语言都有很多的支持,在ruby中就有MongoMapper和Mongoid两个很不错的封装框架. Use Case: 我觉得很好的一个例子是日志.现在的方式是将debug的信息都写到文本文件中去.问题就是每当出现一个问题时我需要去那个日志文件中去搜查出错的地方,就非常痛苦.而这个时候使用MongoDB就是一个很好的候选人,它提供很强的查找查询功能,支持快速的读写. 更多参考: http://www.mongodb.org/