MongoDB的操作因素和数据模型

    MongoDB的建模应用程序数据取决于数据本身，也跟MongoDB的特性有关。比如，不同的数据模型可能提高应用程序的查询效率，提高插入和更新操作的吞吐量，让分片集群更有效的提高分发效率。

    这些处理或记录需求的因素，出现在应用程序以外，但是会影响以MongoDB为数据库的应用。当创建数据模型时，在下述场景下需要考虑应用程序的读操作和写操作。

    文档增长

    更新文档可能会导致文档大小的增加，这些更新包括添加元素到数组，添加新字段到文档中等等。如果文档增长的大小打到了文档允许的最大大小，MongoDB会重新分配磁盘上的文档。重新分配文档会占用比更新文档更长的时间，并且可能会导致文档碎片。尽管MongoDB自动填充文档分配来将重新分配的可能性最小化，但数据建模时应尽可能避免文档增长。

    例如，如果你的应用程序更新会增加文档大小，你应该重构数据模型，在不同文档之间使用引用而不是使用非规范化的数据模型（Embeded Data Model）。

    MongoDB的自适应调整有利于减少数据的迁移，你可能想要使用一种预分配的模式避免文档的增长。

    原子性

    

    在MongoDB中，文档级别的操作都是原子性的，没有一个写操作可以自动影响到多个文档或多个集合。在一个集合中修改多个文档时，需要在每个文档上都操作一次。为确保应用程序在一个文档中存储存储所有原子性需求的字段，如果应用程序能够容忍非原子性两块数据的更新，你可以这些数据存储在不同的文档中。

    使用嵌入式数据模型有利于在一个文档中完成这些原子操作。对于那些将相关数据通过引用模式存储的数据模型，应用程序必须通过不同的读和写操作来完成查询和修改这些相关的数据。

    分片

    MongoDB通过分片提供水平扩展。这些集群支持部署大数据集合和高通量操作。分片允许用户将数据库中的一个集合分割成多个Mongod实例或分片的多个文档集合。

    MongoDB使用分片关键字来分发数据和访问量。选择合适的分片关键字可以提高程序的性能，并且能够启动或关闭查询隔离来提高程序的写性能，所以，一定要仔细考虑好分片的字段。

    索引

    使用索引能够提高普通的查询性能。索引经常建立在频繁使用查询并且在所有的操作中返回排序的数据。MongoDB会在_id字段上建立索引。

    MongoDB使用索引时，需要考虑以下场景：

    （1）每个索引需要至少8kb的数据空间。

    （2）添加索引会影响写操作的性能。对于那些高速读写的操作，在每次插入或更新时索引的更新代价是高昂的。

    （3）高读写的集合通常受益于额外的索引，索引不会影响没加索引的读操作。

    （4）活动状态下，索引会占用磁盘的硬盘和内存。这种占用是很费资源的，应该监控系统的规划容量，尤其是工作集的大小。

    大数据集合

    在某些情况下，可能会考虑将相关的数据存储在几个不同的集合里，而不是在一个集合中存储。

    考虑一下logs集合用来存储不同的环境变量和应用程序的情形，logs集合由以下类型的表单组成：

{ log: "dev", ts: ..., info: ... } { log: "debug", ts: ..., info: ...}

    如果文档的数量太少的话，你可能会按照类型去为文档分组。对于logs来说，考虑维护不同的日志的集合，比如logs_dev和logs_debug。logs_dev集合只会包含开发环境有关的文档。

    一般来说，大量的数据集合不会有显著的性能影响，仍然是高性能的。不同的集合对于高通量的集合是非常重要的。

    当模型中有大量集合时，需要考虑以下场景：

    （1）每个集合都有最少的几kb的开销。

    （2）每个索引，包括_id上的索引，都需要至少8kb的数据空间。

    （3）对每个数据库而言，每个命名空间（.ns文件）存储了数据的所有元数据。并且每个索引和集合有自己条目的命名空间。MongoDB的命名空间文件的大小是有限制的（不能超过2047MB）。

    （4）MongoDB限制命名空间的数量（命名空间的大小除以628）。如果想要知道当前命名空间的序号以便于知道还有多少可以使用命名空间，在Mongo shell中运行以下命令即可：

db.system.namespaces.count()

    命名空间的大小取决于.ns文件的大小，默认的命名空间的大小是16MB。

    要改变命名空间文件的大小，在启动server时加入如下参数即可：

--nssize <new size MB>

    对于已经存在的数据库，使用-nssize参数启动server后，运行以下命令即可。

db.repairDatabase()

    数据生命周期管理

    

    数据建模也应该把数据生命周期管理考虑在内。

    所有的文档集合在使用一段时间后都会过期，如果应用程序需要存储一些数据在数据库中一段时间，考虑使用TTL（Time To Live）特性。

    另外，如果应用程序仅使用最近插入的文档。考虑使用限制的集合（Capped Collections）。Capped Collections使用先进先出的方式插入文档提高基于顺序插入数据的插入和读取文档的性能。

本文转自 genuinecx 51CTO博客，原文链接：http://blog.51cto.com/favccxx/1547487A ，如需转载请自行联系原作者