大致看了一点 MongoDB. 回忆一下，这个数据库有这样一些特征：
- Schema-less: 不需要预先定义 schema. 数据以 document 的方式存储，document 大致上相当于关系数据库中的一行记录。document 存放在 collection 中间（相当于关系数据库的 table）。document 里的每个 field 都可以建索引。
- MongoDB 的特性使得它和面向对象编程语言之间的 gap 比较小。不像关系数据库那样需要 OR Mapping 来减轻编程的困难程度。比如，在C#中将对象序列化，即可调用 MongoDB 保存之。
- Schema-less 的特性并非鼓励将所有不想干的对象都放到一个大垃圾堆里（同一个collection）。而是为了提供灵活性。在大多数情况下，存储模型/结构的设计方法和关系数据库没有太大的不同，只是在少数地方有所区别，如多对多关系。
- document 可以内嵌 document. 就像 JSON 对象可以嵌套一样。
- 一般的设计场景鼓励通过适当的冗余字段来定义 document 的存储结构，而非 normalized 的 ER 关系。不支持 join 的语法。
- 多对多关系可以通过内嵌 document 来存储多个关联 id 的数组来实现。系统能对数组进行高效率的查找。
- 和数据库的所有操作接口基本都通过 JavaScript / JSON 的语法来调用。
- 查找记录通过指定 selector 来实现。查询返回的结果只是游标(cursor)，而非直接返回结果。可以附加 order(), count() 等串接调用（估计内部也是通过 MapReduce 实现的）。
- update 命令默认是覆盖整个记录的模式，就是说并非仅更新指定的字段，而是将其他老的字段信息也抹掉。如果需要实现 sql 类似的按需更新字段的行为需要指定多余的参数。
- 支持 upsert 操作，含义是：存在则更新，否则插入。
- document 可以有任意的属性集合。同一个 collections 里面可以存放具有不同 field 的 document. 在运行时刻可以向已有的 document 附加属性。
- 对事务的支持不如传统的关系数据库。有2个办法：(1) 利用一些本身支持的原子操作来实现简单的事务。比如 $inc, $set. (2) 将事务对数据记录的影响结果预先计算出来，通过二段式的提交(2-phase commit)来实现。比较麻烦。
- 全文索引：支持简单的方案。复杂的方案需要通过和 Lucene/Solr 配合来实现。
- MapReduce 基本原理及支持：
- 至少需要提供一个 map function, 一个 reduce function.
- map 用于产生键值对；reduce 用于对键值对进行聚合操作。
- 键值对可以被并行处理（多个CPU，多个机器，。。。），所以 reduce 函数的特征是返回值也必须符合输入的键值对格式，这样才便于任务的拆分和调度。