mongodb简单介绍以及使用整理2

分片服务角色介绍

1，客户端访问路由节点mongos来进行数据读写。

config服务器保存了两个映射关系，一个是key值的区间对应哪一个chunk的映射关系，另一个是chunk存在哪一个分片节点的映射关系。

路由节点通过config服务器获取数据信息，通过这些信息，找到真正存放数据的分片节点进行对应操作。

2，路由节点还会在写操作时判断当前chunk是否超出限定大小，如果超出，就分列成两个chunk。

对于按分片key进行的查询和update操作来说，路由节点会查到具体的chunk然后再进行相关的工作。

对于不按分片key进行的查询和update操作来说，mongos会对所有下属节点发送请求然后再对返回结果进行合并。

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

数据文件内部结构

在文件系统中为每个数据库预分配逐渐增长大小的文件集，这样可以有效地避免潜在的文件系统碎片，使数据库操作更高效。

一个数据库的文件集从序号0开始分配，0，1...，大小依次是64M，128M，256M，512M，1G，2G，然后就是一直2G的创建下去（32位系统最大到512M）。

数据库文件在内部会被切分成多个数据域，数据域之间使用双向链表连接。

名字空间用于区分不同的存储类别，比如每个collection有一个独立的名字空间，每个索引也有自己的名字空间

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

字空间与数据域：

每个名字空间可以有不同的数据域，在磁盘上不必连续。

图中还有一个特殊的名字空间freelist，存放着不再使用的数据域，例如，删除集合或索引产生的数据域。

当名字空间分配新的数据域时，系统会先查找空闲列表，看看有没有适合大小的数据域可用。

在每一个数据域中，保存了具体一行行BSON格式的数据，这些数据也是通过双向链表连接。

每一行数据存储空间不仅包括数据占用空间，还可能包含一部分附加空间，这使得在数据update变大后可以不移动位置。

索引数据也保存在数据文件中，不过索引是被组织成B-tree结构，而不是双向链表。

对每个数据库，都有一个命名空间文件，用于保存每个名字空间对应的元数据。我们通过查询这些元数据来找到对应的名字空间的数据存储位置。

数据文件使用MMAP进行内存映射，会将所有数据文件映射到内存中，但只是虚拟内存，只有访问到这块数据时才会交换到物理内存

在命名空间文件中，保存的是一个哈希表，存储了每个名字空间对应的元数据，包括其大小，块数，第一块位置，最后一块位置，被删除的块的链表以及索引信息

这些位置通过DiskLoc数据结构进行存储，存储了数据文件编号和块在文件中的位置

MongoDB尽管在数据存储上与传统关系数据库很不一样，但是在索引构建上却几乎是与传统关系型数据库一致。

主要是使用了B-tree作为索引结构。

B-tree，多路搜索树，并不是二叉的，以下介绍其主要特点：

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

唯一索引

想像你要在一本没有目录的食谱上查找某一道菜的做法，唯一的办法可能就是从头到尾把这本几百页的书看一遍，直到找到你想找的菜。

而一个快速的方法就是给菜谱加上一个目录，目录中有每一道菜的名字及与其相对应的页数，并且菜名是按字母顺序排列，这样你就可以按首字母快速地找到你菜谱的页数了。

唯一索引

举例：

水饺

- 45

水煮肉片

- 4,011

水煮鱼

- 943

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

非唯一索引

但是如果我今天买了条鱼，想查一下所有跟鱼相关的做法，那么用上面的索引就没办法了。于是出现下面一种索引构建方法，即将所有菜的材料构建目录，这时候一个材料对应多道菜。

举例：

鱼

- 3, 20, 42, 88, 103, 1,215…

猪肉

- 2, 47, 88, 89, 90, 275…

白菜

- 7, 9, 80, 81, 82, 83, 84…

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

联合索引

还有另一种需求，如果我知道材料里有鱼，而我又知道这道菜的名字，就不用查找到材料后去翻看后面几个具体页的菜再来选择了。

举例：

鱼

- 水煮鱼

—- 1,215

- 红烧带鱼

—- 88

- 酸菜鱼

—- 103

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

mngodb api用法

1，DBCollection

DBCollection

insert与save的区别

若存在主键，insert()  不做操作，而save() 则更改原来的内容为新内容