mongo简介——mongo的主要特性

gyts62

　　从今天开始每天一篇关于mongo的小文章。
　　开始之前首先介绍一些规范。
　　1）除函数名和关键字以外，所有数据库名、集合名、字段名等一律用加粗的大写字母和下划线表示，以示醒目；所有名称不以下划线开头，下划线只用来分割单词。
　　2）所有需要在代码中以字面值或变量出现的，在文章中一律以下划线开头且以下划线分割的的大写英文单词表示，绝不出现字面值或变量定义。比如，要定义一个集合的初始大小，则需要在指定初始值的地方使用INIT_SIZE表示。
　　3）为方便表达，文档、数据库、集合统称为实体（在我看过的相关书籍和文档中没有记的有实体这个名词，此处只是为了个人表达方便）。
　　4）数据SCHEMA在这一系列文章中称做模式
　　开始之前的一些废话：这一系列文章只为介绍mongo并鼓吹宣扬mongo的特性和优点，行文偏颇处，诸位看官请莫较真。
　　mongo的特性
　　1）mongo是一个面向文档的数据库，它集合了nosql和sql数据库两方面的特性。
　　2）所有实体都是在首次使用时创建。
　　3）没有严格的事务特性，但是它保证任何一次数据变更都是原子性的。
　　4）也没有固定的数据模型，同一个数据库内可以保存不同业务类型的数据，同一个集合可以保存拥有不同字段名、字段类型，甚至不同字段数量的文档；这一特性在某些情况下特别方便，减少了设计数据模型方面的困难，当然也需要更加谨慎的设计数据模型，否则将会为将来的维护和开发带来难以预料的灾难。
　　5）mongo以javascript作为命令行执行引擎，它自带一个javascript解释器，支持全部javascript语法特性，当然这个解释器与其它javascript解释器一样，也是单线程的，所以利用shell进行复杂的计算和查询时会相当的慢。
　　6）mongo本身支持集群和数据分片，如果想要把mongo作为主要数据存储和管理工具，只需要在数据库集群服务器上安装mongo即可实现数据库集群、负载均衡和数据分片。
　　7）mongo是c++实现的，支持windows mac linux等主流操作系统
　　8）性能远超mysql，国外已经有很多公司把数据完全从mysql迁移到mongo，并把mongo作为主要数据存储和管理工具。这些公司涉足互联网应用的各种不同领域。甚至有些公司舍弃了缓存服务器直接通过mongo为前端提供数据支持，仍然取得了良好的性能和可用性。个人认为目前凡是用mysql实现的应用都可以迁移到mongo上面，并能取得优秀的性能。当然，不得不提的是，尽管mongo不是模式严格的数据库，但是却需要更加谨慎的设计数据模型，否则会在将来的开发和维护工作中带来难以预料的混乱。换句话说，越自由灵活的工具，越需要谨慎的使用。
　　9）许可证协议：MONGO遵守GNU-AGPL许可。该许可要求，任何对源友的修改必须公布出来。维护MONGO的公司也为那些想保护核心服务器增强特性的公司提供了特殊的商业许可。
　　===================================================================================
　　基本概念：数据库、集合、文档
　　数据库:可以类比为关系数据库里的数据库的概念，也是惟一一个二者之间最接近的概念。
　　集合：可以类比为关系数据库里的表，但二者差异是巨大的。首先集合没固定的数据模式，可以向集合内插入完全不同的数据。这里集合的概念更像是数学意义上的集合，它完全符合数学的集合定义。
　　文档：mongo的基本数据存储单元
　　mongo以类似json的二进制数据格式BSON保存数据。JSON是文本数据格式，BSON是二进制的。
　　mongo又在json的基础上进行了扩展，增加了更多数据类型，更详细的内容请参考以下链接：mongo简介——BSON
　　mongo把保存到数据文件里的每一个BSON看作一个文档，可以把文档视作关系数据库表里的一条记录。
　　每一个文档储存在一个集合里面。
　　索引：mongo的索引以集合单位建立的BTREE索引。所以创建索引时，应当充分考虑到BTREE的优势和限制。
　　===================================================================================
　　SCHEMA设计原则与注意事项
　　1）mongo支持即时、任意字段查询。任意的数据变更立即可查，可查询文档中任意字段的数据，而不必返回整个文档。
　　2）不支持文档间的联合查询
　　3）没有事务
　　4）比RDBMS更多原子操作，而且每次增、删、改都是原子性的
　　5）支持复杂的文档，BSON支持文档嵌套和数组，数组元素可以是基本数据也可以是文档
　　设计SCHEMA时需要考虑的几方面：
　　具体需求、读写比、需要何种查询、数据如何更新、各种并发问题、数据结构化程度。（关于这个问题，在mongo特性全部介绍完以后再详细讨论）
　　1.不要创建无法分片的集合。总是希望业务量越来越大的，随着业务量的增长，数据分片迟早会到来。所以应创建易于分片的集合。
　　2. 文档嵌套不要过多。嵌套层次太多会降低查询效率
　　3. 除了二进制数据，最好文档尺寸都小于100k。小文档更新的开销更少，查询也更快。
　　3. 不要把不同的业务类型的数据放到一个集合里。集合的代价很低，不必吝啬。比如把用户数据跟博客数据放到一个集合里就不好。
　　4. 不要一个用户一个集合，集合太多会超过mongo命名空间的阈值。
　　5. 相同的文档键名应保证是相同的数据类型。这样易于管理，不易产生混乱。
　　6. 创建有效索引。