我参加了丸之内 MongoDB 学习会＃22，所以做了内容记录。请原谅我根据个人兴趣的浓淡程度而改变了记录的详细程度。

勉强会详细 huì

关于Hands-On和最近举办的MongoDB World的摘要。尤其是关于MongoDB的特点和Hands-On方面，还有关于最新的v3.0的讨论。

第一部分：MongoDB 是什么 & MongoDB 实践课程

今天的研讨会由渡部徹太郎（@fetarodc）主持，他将对MongoDB进行概述，并通过各自带来的笔记本进行实践。

MongoDB 基础入门

根据以下的演示文稿，渡部先生进行演讲。

几乎都是依照幻灯片上的内容写的，但以下几点引起了我的注意：
* 尽管NoSQL有许多不同类型，例如键值对数据库(KVS)、列族数据库、图数据库等，但最近许多数据存储产品都开始采用了文档型的风格（例如DynamoDB、MySQL、PostgreSQL）。
* 在文档型数据库中，MongoDB可以动态地发出查询（就像SQL一样，可以即时编写并执行）。然而，CouchDB等只能进行静态的数据查询（需要预先准备好MapReduce逻辑，在启动之前需要进行部署的印象？）
* 文档型数据库与键值对数据库不同，它具有层次结构的表达能力，并且是无模式的。例如，在医院整合中，即使每个医院的病历模式不同，也可以共享相同的键，并保留每个整合源医院的特定列，类似于这样的操作是可以实现的。
* 由于其易于上手，近来在美国似乎出现了“虽然无法写SQL，但可以操作MongoDB”的年轻人。

MongoDB实操演练（包括常见问题和答疑）。

渡部先生在演讲时一边输入以下幻灯片命令，并进行讲解。之后进行约20分钟的问答环节。（据渡部先生说，这是问答环节首次如此火热）。

(Note: The translation may vary depending on the context and specific use)

有几个我关注的问题。

要使用WiredTiger，如何操作？

MongoDB 3.0 版本开始引入了 WiredTiger 存储引擎。要在 MongoDB 3.0 中使用 WiredTiger，只需在第一次启动 mongod 时添加相应选项即可。

WiredTiger和文档的重定位

到MongoDB 2.6为止，一旦插入的文档被更新导致数据量增大，超过了最初的分配空间，会发生数据重定位。使用WiredTiger引擎后，似乎不再发生这种数据重定位。（据渡部先生称，他也不太了解这个机制的详细情况）本次学习会的参与者中，有人在MongoDB 2.6之前使用db.myCollection.find()获取游标后发生了数据重定位，导致同一文档出现了两次，这很可能是2.6重定位的原因。

WiredTiger和压缩

WiredTiger在将数据写入磁盘时会进行压缩。
由于文档型数据库会保存每个文档的列信息，因此当保存传统的RDB的同样结构数据时，会消耗数倍的存储空间。因此，数据压缩在某种意义上是必需的。根据渡部先生的实验，1GB的数据据说压缩到了50MB。（详细信息请参考此处。）

MongoDB 的定期维护

在MongoDB 2.6之前，必須處理前述的重新定位造成的碎片化問題，需要在脱机時進行數據壓縮。這是著名的”MongodB典故”。如前所述，使用WiredTiger不會出現這個問題，但目前還不清楚是否需要作為定期維護操作。

虽然有各种各样的选择，但似乎WiredTiger是“强烈推荐”的。

由于篇幅过长，后续部分将另行书写。