CAP定理（CAP theorem）

在计算机科学中, CAP定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer's theorem）, 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)
• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)
• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

• CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
• CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。
• AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。NoSQL的优点/缺点

优点:

• - 高可扩展性
• - 分布式计算
• - 低成本
• - 架构的灵活性，半结构化数据
• - 没有复杂的关系

缺点:

• - 没有标准化
• - 有限的查询功能（到目前为止）
• - 最终一致是不直观的程序BASE

BASE：Basically Available, Soft-state, Eventually Consistent。 由 Eric Brewer 定义。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。

BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

• Basically Availble --基本可用
• Soft-state --软状态/柔性事务。 "Soft state" 可以理解为"无连接"的, 而 "Hard state" 是"面向连接"的
• Eventual Consistency -- 最终一致性， 也是是 ACID 的最终目的。

ACID vs BASE

NoSQL 数据库分类

MongoDb 是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它是可扩展的高性能数据存储解决方案，经常被用于非关系型数据的存储，能存储海量的数据。常见的非关系型数据库还有：Redis，但 MongoDb 比 redis 更具有数据库的特性。

MongoDb的基本数据结构

与 MySQL 等关系型数据库一样，MongoDb 也有类似的概念，但是其称呼不同。下表列出了 MongoDb 的基本数据结构以及与 MySQL 的对比。

可以看到 MongoDb 与 SQL 的数据库概念都是一致的，而 MongoDb 中数据库表（Table）则称之为集合（Collection），行（Row）则称为文档（Document），列（Column）则称为字段（Field）。

文档相当于关系型数据库中的行。它一组键值对，具有动态的模式，所以文档不需要设置相同的字段，并且相同的字段不需要相同的数据类型，这一点，跟关系型数据库有很大的不同。注：

1. 文档中的键/值对是有序的。
2. MongoDB区分类型和大小写。
3. MongoDB的文档不能有重复的键。
4. 键不能含有\0 (空字符)。
5. .和$有特别的意义，只有在特定环境下才能使用。

集合即表格，即表
集合存在于数据库中，集合没有固定的结构。
这意味着可以往集合里插入任何的格式。
通常情况下，插入的数据具有关联性
合法的集合名：集合名不能是空字符串
集合名不能含有\0
集合名不能以system开头
创建的集合名不能有保留字，因为系统生成的集合包含有$

元数据

数据库的信息存储在集合中，使用了系统命名的空间

命令

insert方法向目标集合插入一个文档，这个操作会给文档自动增加一个"_id"键（要是原来没有的话），然后将其保存到MongoDB中；在shell中，可以使用batchInsert函数实现批量插入，它与insert函数非常像，只是它接受的是一个文档数组作为参数：db.foo.batchInsert([{"_id" : 0}, {"_id":1},{"_id":2}])

find和findOne方法可以用于查询集合里的文档，若只想查看一个文档，可以用findOne；

find和findOne可以接受一个查询文档作为限定条件，因此可以查询符合一定条件的文档，使用find时，shell会自动显示最多20个匹配的文档，也可获取更多文档。

update接受（至少）两个参数：一个是查询文档（限定条件），用于定位需要更新的目标文档；另一个是修改器（modifier）文档，用于说明要对找到的文档进行哪些修改。最简单的更新就是用一个新文档完全替换匹配的文档。这适用于进行大规模模式迁移的情况。

remove方法可将文档从数据库中永久删除。如果没有使用任何参数，它会将集合内的所有文档全部删除。它可以接受一个作为限定条件的文档作为参数。删除数据是永久性的，不能撤销，也不能恢复。删除文档通常很快，但是如果要清空整个集合，那么使用drop直接删除集合会更快（然后在这个空集合上重建各项索引）。

数据类型

null 用于表示空值或者不存在的字段；

布尔型有两个值true和false；

数值：shell默认使用64位浮点型数值。对于整型值，可使用NumberInt类（表示4字节带符号整数）或NumberLong类（表示8字符带符号整数）；

字符串：UTF-8字符串都可表示为字符串类型的数据；

日期，被存储为自新纪元以来经过的毫秒数，不存储时区；

正则表达式：查询时，使用正则表达式作为限定条件，语法也与JavaScript的正则表达式语法相同；

数组：数据列表或数据集可以表示为数组

内嵌文档：文档可嵌套其他文档，被嵌套的文档作为父文档的值；

对象id：是一个12字节的ID，是文档的唯一标识，ObjectId的12字节按照如下方式生成：

ObjectId的前4个字节是从标准纪元开始的时间戳，单位为秒。这会带来一些有用的属性。

• 时间戳，与随后的5字节（稍后介绍）组合起来，提供了秒级别的唯一性。
• 由于时间戳在前，这意味着ObjectId大致会按照插入的顺序排列。这对于某些方面很有用，比如可以将其作为索引提高效率，但是这个是没有保证的，仅仅是“大致”。
• 这4字节也隐含了文档创建的时间。绝大多数驱动程序都会提供一个方法，用于从ObjectId获取这些信息。

因为使用的是当前时间，很多用户担心要对服务器进行时钟同步。虽然在某些情况下，在服务器间进行时间同步确实是个好主意，但是这里其实没有必要，因为时间戳的实际值并不重要，只要它总是不停增加就好了（每秒一次）。

接下来的3字节是所在主机的唯一标识符。通常是机器主机名的散列值（hash）。这样就可以确保不同主机生成不同的 ObjectId，不产生冲突。

为了确保在同一台机器上并发的多个进程产生的ObjectId是唯一的，接下来的两字节来自产生ObjectId的进程的进程标识符（PID）。

前9字节保证了同一秒钟不同机器不同进程产生的ObjectId是唯一的。最后3字节是一个自动增加的计数器，确保相同进程同一秒产生的ObjectId也是不一样的。一秒钟最多允许每个进程拥有256 3 （16 777 216）个不同的ObjectId。