[Mongodb经典资料-MongoDB开发技巧50例.docVIP

应用设计技巧 1.技巧1：速度和完整性的折中 在多个文档中使用的数据既可以是采用内嵌（反范式化）的方式，也可以采用引用（范式化）的方式。 反范式化会产生不一致的数据。要是不能容忍哪怕一丁点不一致，则应该选用范化式。读取速度块，一致性削弱。商品信息的变更不会原子性地更新到多个文档。 范式化，应用则必须在每次确认的时候做额外的一次查找，若是无法承担这样的负载，又不强调一致性，则用反范化式。一次查询无法获得完整的订单，读取速度慢，但所有订单的一致性会有保证。多个文档会原子性的更新（因为仅仅引用的文档会更新）。 考虑因素： 是否要额外读取一次几乎不怎么改变的数据？ 更新越少，越适合反范式化，有些极少变化的数据几乎根本不值得引用，如姓名、生日股票代码、地址。 一致性很重要么？ 要不要尽快地读取？ 订单文档非常适合反范式化，因为其中的商品信息不经常变化，就算变化了也不必更新到所有的订单。 2.技巧2：适应未来的数据要范式化 范式化可使数据可用性更长久，将来可以在不同的应用中以不同的方式查询范式化的数据。大多数人的数据都会不断的演化，陈旧的数据要么被更新，要么被丢弃。大多数人都希望数据库能尽可能地对当前查询做出快速的响应，如果将来查询变了，它们会针对新的查询优化数据库。 3.技巧3：尽量单个查询获取数据 应用单元：对于web应用或者是移动应用，可以将对后端的一次请求视作一个应用单元。 对桌面应用，一次用户交互算作一个应用单元。 对分析系统，一个图表的加载算作一个应用单元。 3.1 示例：博客 若要设计博客系统，对一篇博客文章的请求或许就是一个应用单元。 很多情况下一个应用单元对应多个文档，但只通过单条查询来完成这种请求。 3.2 示例：相册 假设有一个相册，用户可以创建或回复含有照片和文字的帖子。有个应用单元就是查看线索中的20条回帖，每个人的回复都是posts集合中一个独立的文档。 “一次查询”的目标是个良好的起点，可以很好地衡量初始的设计，但现实并非完美世界。 4.技巧4：嵌入关联数据 当在嵌入和引用文档之间犹豫不决时，不妨想想查询的目的究竟是为了获得字段本身的信息，还是为了进一步获取更广泛的信息。 5.技巧5：嵌入时间点数据 当一个商品打折或者换了图片，并不需要更改原来订单的信息。类似这种特定于某一时间点的数据，都应该做嵌入处理。 6.技巧6：不要嵌入不断增加的数据 7.技巧7：预填充数据 如果已经知道未来要用到哪些字段，第一次插入时就带着这些字段会比用到时再创建效率更多。 8.技巧8：尽可能预先分配空间 只要知道文档开始比较小，后来会变为确定的大小，就可以使用这种优化技巧，一开始插入文档的时候就用和最终数据大小一样的垃圾数据填充，即添加一个garbage字段（其中包含一个字符串，串大小与文档最终大小相同），然后马上重置字段。 如果存储文档时变为其分配将来所需要的空间，之后就不用在移动它了。 9.技巧9：用数组存放要匿名访问的内嵌数据 一个常见的问题就是内嵌的信息到底是用数组存还是用子文档存。 如果确切知道要查询的内容，则要用子文档。 如果有时不清楚查询的具体内容，则要用数据。 当知道一些条目的查询条件时，通常该使用数组。 例子见P75。 10.技巧10：文档要自给自足 MongoDB是一种“无脑”的大型数据存储。即，MongoDB几乎不做任何数据处理，仅仅是存取数据。要尽量遵守这一点，避免让MongoDB做些能在客户端完成的计算。即便是“小任务”，像求平均值或求和，也要放在客户端去做。 如果要找的信息必须经过计算，且无法直接从文档中获得，有两种方式： 付出高昂的代价强制MongoDB使用JavaScript计算。 优化文档结构，使得这些信息能够从文档中直接获得。 11.技巧11：优先使$操作符 $操作符应付不来某些操作，但是对于绝大多数应用，让文档本身提供足够的内容可以极大地简化查询的复杂度。然而，还是有些情况下的查询不能用$操作符表达。这时候就借助JavaScript了，可以在查询中使用$where子句来执行JavaScript代码。 查询中的$where对应一个JavaScript函数，该函数的返回值是true或false（表示匹配与否）。 12.技巧12：随时聚合 13.技巧13：编写代码处理数据完整性问题 由于MongoDB无模式的特点和反范式的优势，需要注意应用数据的一致性问题。 一致性修复器 预分配器 聚合器（更新文档内部的聚合数据，使之为必威体育精装版数据） 结构校验器 备份任务 应用设计技巧 14.技巧14：使用正确的类型 用正确的数据类型存放数据大有裨益，数据类型影响数据多的查询方式、MongoDB的数据存放顺序，以及占用多少空间。 数字 日期 字符串 MongoDB中的字符串都是UTF-8编码的，所以其他