var mydoc = {
_id: ObjectId("5099803df3f4948bd2f98391"),
name: { first: "Alan", last: "Turing" },
birth: new Date('Jun 23, 1912'),
death: new Date('Jun 07, 1954'),
contribs: [ "Turing machine", "Turing test", "Turingery" ],
views : NumberLong(1250000)
字段名称是字符串,但是有以下限制
字段名“_id”被保留用作主键,它的值在集合中必须是唯一的,是不可变的,并且可以是数组以外的任何类型。 如果 _id 包含子字段,则子字段名称不能以 ($) 符号开头。
字段名称不能包含null字符
服务器允许存储包含点 (.) 和美元符号 ($) 的字段名称。
MongoDB 使用点(.)符号来访问数组的元素和访问嵌入文档的字段。
"<array>.<index>"
contribs: [ "Turing machine", "Turing test", "Turingery" ],
要指定 contribs 数组中的第三个元素,请使用点表示法“contribs.2”
"<embedded document>.<field>"
name: { first: "Alan", last: "Turing" },
contact: { phone: { type: "cell", number: "111-222-3333" } },
要指定“first”字段,可以使用“name.last”
要指定“number”字段,可以使用“contact.phone.number”
与 JavaScript 对象不同,BSON 文档中的字段是有序的。
对于查询操作,在比较文档时,字段排序非常重要。
例如,在文档查询中比较a和b两个字段时,{a: 1, b: 1} 与 {b: 1, a: 1} 是不同的。
对于写入操作,MongoDB 保留文档字段的顺序,但以下情况除外:
_id 字段始终是文档中的第一个字段
包含重命名字段名称的更新操作可能会导致文档中的字段重新排序
BJSON类型
https://docs.mongodb.com/manual/reference/bson-types/
ObjectId
ObjectId 很小,可能是唯一的,生成速度快,并且是有序的。 ObjectId 值的长度为 12 个字节,包括:
一个4字节的时间戳,表示ObjectId的创建时间
一个5字节的随机值,每个进程生成一次
一个3字节的递增计数器,初始化为一个随机值
在MongoDB中,存储在集合中的每个文档都需要一个唯一的_id字段作为主键。如果插入的文档省略了_id字段,MongoDB会自动为_id字段生成一个ObjectId。
MongoDB客户端应添加具有唯一 ObjectId 的 _id 字段。 将 ObjectIds 用于 _id 字段可提供以下额外好处:
在mongosh中,可以使用ObjectId.getTimestamp()方法来访问ObjectId的创建时间
对存储ObjectId值的_id字段进行排序大致相当于按创建时间进行排序
4. 配置文件选项
https://docs.mongodb.com/manual/reference/configuration-options/
Linux中,默认配置文件是 /etc/mongod.conf
启动时指定配置文件,可以使用 --config 或者 -f 选项
mongod --config /etc/mongod.conf
mongod -f /etc/mongod.conf
主要的一些配置参见 https://docs.mongodb.com/manual/reference/configuration-options/#core-options
5. MongoDB 包组件
5.1. mongod
mongod 是 MongoDB 系统的主要守护进程。 它处理数据请求,管理数据访问,并执行后台管理操作。
https://docs.mongodb.com/manual/reference/program/mongod/
6. CRUD
https://docs.mongodb.com/manual/crud/
https://docs.mongodb.com/manual/reference/command/
https://docs.mongodb.com/manual/reference/method/
7. 存储
存储引擎是数据库的组件,负责管理数据在内存和磁盘中的存储方式。MongoDB 支持多个存储引擎,因为不同的引擎对于特定的工作负载表现更好。选择合适的存储引擎会显着影响应用程序的性能。
7.1. WiredTiger Storage Engine (Default)
WiredTiger 是从 MongoDB 3.2 开始的默认存储引擎。 它非常适合大多数工作负载,建议用于新部署。 WiredTiger 提供文档级并发模型、检查点和压缩等功能。
从 MongoDB 3.2 开始,WiredTiger 存储引擎是默认存储引擎。对于现有部署,如果不指定 --storageEngine 或 storage.engine 设置,则 3.2+ 版本的 mongod 实例可以自动确定 --dbpath 或 storage.dbPath 中用于创建数据文件的存储引擎。
7.1.1. 文档级别的并发
WiredTiger 使用文档级并发控制进行写入操作。 因此,多个客户端可以同时修改一个集合的不同文档。
对于大多数读写操作,WiredTiger 使用乐观并发控制。 WiredTiger 仅在全局、数据库和集合级别使用意图锁。 当存储引擎检测到两个操作之间的冲突时,会引发写入冲突,导致 MongoDB 透明地重试该操作。
7.1.2. 快照和检查点
WiredTiger 使用多版本并发控制 (MVCC)。在操作开始时,WiredTiger 会为操作提供数据的时间点快照。快照呈现内存中数据的一致视图。
写入磁盘时,WiredTiger 将快照中的所有数据以一致的方式跨所有数据文件写入磁盘。现在持久的数据充当数据文件中的检查点。检查点确保数据文件在最后一个检查点之前是一致的,包括最后一个检查点;即检查点可以充当恢复点。
从 3.6 版开始,MongoDB 配置 WiredTiger 以每隔 60 秒创建检查点(即将快照数据写入磁盘)。在早期版本中,MongoDB 将检查点设置为在 WiredTiger 中以 60 秒的间隔或在写入 2 GB 的日志数据时发生在用户数据上,以先发生者为准。
在写入新的检查点期间,之前的检查点仍然有效。因此,即使 MongoDB 在写入新检查点时终止或遇到错误,在重新启动时,MongoDB 也可以从最后一个有效检查点恢复。
当 WiredTiger 的元数据表被原子更新以引用新的检查点时,新的检查点变得可访问和永久。一旦可以访问新的检查点,WiredTiger 就会从旧的检查点中释放页面。
7.1.3. 日志
WiredTiger 使用预写日志(即日志)结合检查点来确保数据的持久性。
WiredTiger 日志保留检查点之间的所有数据修改。 如果 MongoDB 在检查点之间退出,它会使用日志重放自上一个检查点以来修改的所有数据。
7.1.4. 压缩
使用 WiredTiger,MongoDB 支持所有集合和索引的压缩。压缩以增加 CPU 为代价最大限度地减少了存储使用。
默认情况下,WiredTiger 使用 snappy 压缩库对所有集合使用块压缩,对所有索引使用前缀压缩。
7.1.5. 内存使用
使用 WiredTiger,MongoDB 同时利用 WiredTiger 内部缓存和文件系统缓存。
从 MongoDB 3.4 开始,默认的 WiredTiger 内部缓存大小是以下两者中的较大者:
50% of (RAM - 1 GB)
256 MB
例如,在一个总共有 4GB RAM 的系统上,WiredTiger 缓存将使用 1.5GB 的 RAM (0.5 * (4 GB - 1 GB) = 1.5 GB)。 相反,总共有 1.25 GB RAM 的系统将分配 256 MB 给 WiredTiger 缓存,因为这是总 RAM 减去 1 GB 的一半以上 (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB) 。
7.2. 内存存储引擎
内存存储引擎在 MongoDB Enterprise 中可用。它不是将文档存储在磁盘上,而是将它们保留在内存中,以获得更可预测的数据延迟。
从MongoDB Enterprise版本3.2.6开始,内存存储引擎是64位版本中通用可用性(GA)的一部分。除了一些元数据和诊断数据,内存存储引擎不维护任何磁盘上的数据,包括配置数据、索引、用户凭据等。
通过避免磁盘I/O,内存存储引擎允许更多可预测的数据库操作延迟。
7.2.1. 指定内存存储引擎
为了选择使用内存存储引擎,可以这样操作:
命令行中使用 --storageEngine 选项指定 inMemory ,或者 在配置文件中通过设置 storage.engine 的值
--dbpath 或 storage.dbPath(如果使用配置文件)。尽管内存存储引擎不会将数据写入文件系统,但它会在 --dbpath 中维护小型元数据文件和诊断数据以及用于构建大型索引的临时文件。
mongod --storageEngine inMemory --dbpath <path>
storage:
engine: inMemory
dbPath: <path>
7.2.2. 并发
内存存储引擎对写入操作使用文档级并发控制。因此,多个客户端可以同时修改一个集合的不同文档。
7.2.3. 内存使用
内存存储引擎要求它的所有数据(包括索引,如果mongod实例是副本集的一部分,则包括oplog,等等)必须符合命令行选项 --inMemorySizeGB 或配置文件中 storage.inMemory.engineConfig.inMemorySizeGB 设置的内存大小。
默认情况下,内存存储引擎使用 50% 的物理 RAM 减去 1 GB。
例如,内存8G,那么使用内存存储引擎的话,默认使用的内存大小最多是 8 × 0.5 - 1 = 3 GB
如果写入操作会导致数据超过指定的内存大小,MongoDB 会返回错误:
"WT_CACHE_FULL: operation would overflow cache"
为了指定新的内存大小,在配置文件中设置 storage.inMemory.engineConfig.inMemorySizeGB
storage:
engine: inMemory
dbPath: <path>
inMemory:
engineConfig:
inMemorySizeGB: <newSize>
或者使用命令行参数 --inMemorySizeGB
mongod --storageEngine inMemory --dbpath <path> --inMemorySizeGB <newSize>
7.2.4. 持久化
内存存储引擎是非持久化的,不向持久化存储写入数据。非持久数据包括应用程序数据和系统数据,如用户、权限、索引、副本集配置、分片集群配置等。
因此,日志或等待数据变得持久的概念不适用于内存存储引擎。
7.2.5. 事务
从MongoDB 4.2开始,副本集和分片集群上都支持事务: 主节点使用 WiredTiger 存储引擎,并且次要成员使用 WiredTiger 存储引擎或内存存储引擎。