设计指南¶
本篇详细描述了你在设计你的应用时应铭记于心的MongoDB的重要特性。
模式考量¶
动态模式¶
MongoDB中的数据拥有 动态模式。 Collections 没有强制 document 的结构。这有助于迭代开发和多态。不过，集合通保存着高度同质化的结构。更多信息请参见 数据建模理论 。
如下是一些实际操作中的参考，包括：
明确被使用的集合；
使用索引：除 _id 索引外，所有的索引都必须显示创建；
片键声明：选择好的片键非常重要，因为片键一旦被设定就不能更改。
不要直接从关系型数据库导入未更改的数据。通常，你想把某些数据导入更灵活的文档，以便于利用MongoDB支持子文档和内嵌数组。
字符串大小写敏感¶
MongoDB的字符串是大小写敏感的。所以对 "joe" 的查询不会找到 "Joe"。
考虑如下建议：
以规范化的大小写格式存储数据；
使用以 /i 结尾的正则表达式；
在 aggregation framework 中使用 $toLower 或 $toUpper。
字段类型敏感¶
MongoDB的数据被存储为 BSON 格式——类JSON文档的二进制编码序列。BSON编码进去了额外的类型信息。更多信息请参见 bsonspec.org 。
考虑如下文档，该文档的字段 x 的值为 字符串 值 "123"：
{ x : "123" }
那么，如下查找 数字 值 123 的查询不会返回上面的文档：
db.mycollection.find( { x : 123 } )
常规考量¶
默认情况下，更新操作只作用于一个文档。¶
为了能更新符合你的查询条件的多个文档，设置 update multi 选项为 true 或者 1。更多信息请参见 Update Multiple Documents。
对于MongoDB 2.2或之前的版本，你可以在 update 方法特定位置上的布尔型选项中指定 upsert 和 multi 选项。
BSON文档大小限制¶
目前， BSON Document Size 的限制为单个文档不大于16MB。如果你需要更大的文档，使用 GridFS。
没有完全的整体事务¶
MongoDB没有 fully generalized transactions。如果你用灵活的文档建立的数据模型与你应用中的对象十分贴近的话，任何一个逻辑上的对象都将在一个MongoDB 文档中。MongoDB允许你在单个的原子操作中修改文档。这种数据修改模式涉及了其他系统中事务最普遍的用法。
复制集考量¶
使用奇数个复制集成员¶
Replica sets 展示了一致性选举。为了保证该选举能成功进行，你要么使用奇数个成员，比如典型的3个，要么使用 arbiter 保证投票为奇数。
保持复制集成员最新¶
MongoDB复制集支持 automatic failover。这个特性对保持从节点为最新非常重要。有多种策略可以评估数据的一致性：
使用监视工具警告你延迟事件。
指定适当的安全写级别
如果你的应用需要 手动 故障切换，你可以将你的从节点配置为 priority 0。优先级为0的从节点需要手动进行故障切换。这对小型的复制集可能比较实用，但是大型部署应当自动进行故障切换。
分片考量¶
仔细地挑选你的片键。你不能为一个已经分片的集合选择新的片键。
片键值是不可改变的。
当对一个 已经存在的集合 开启分片时，MongoDB会使用分片后最大集合的大小以确保能创建数据段。关于这个限制的详细说明，请参见： <sharding-existing-collection-data-size>。
为了能对大量数据分片，创建一个空的已分片的新集合，并使用应用级别的导入操作从源集合获取数据。
除了片键自身，通过分片不能强制添加唯一索引。参见 确保分片集合中唯一字段的唯一性。
考虑在大规模批量导入前 pre-splitting 已分片集合。