使用模式构建：总结

现在到了我们总结使用模式构建系列的时候，这是一个很好的机会回顾一下这个系列涵盖的模式所解决的问题，并着重复习每个模式所具有的一些好处以及做出的权衡。关于模式设计，最常见的问题是“我正在设计一个要做某某事情的应用程序，如何对数据建模？”正如我们希望你在学习本系列过程中可以体会到的那样，要回答这个问题，需要考虑很多事情。不过我们提供了一个应用场景示例图，这至少有助于为通用的数据建模提供一些初级的指导。

应用场景示例

下图是我们在与客户合作多年后发现的用于各种应用程序中设计模式的指导原则。对于哪种设计模式可以用于某类特定的应用程序不是“一成不变”的。你需要仔细查看用例中经常使用的那些，但是不要忽略其它的，它们可能仍然适用。如何设计应用程序的数据模式非常依赖于数据访问的方式。

设计模式总结

近似值

近似值模式适用于当昂贵的计算很频繁，而这些计算的精度要求通常不是首要考虑的时候。 优点 • 对数据库更少的写入 • 保持在统计学上有效的数字 缺点 • 无法展示精确的数字 • 需要在应用层实现

属性

属性模式适用于解决这样一类问题：我们有一些大文档，它们有很多相似的字段，而这些字段的一个子集具有共同的特征，我们希望对该子集字段进行排序或查询。当需要排序的字段只能在一小部分文档中找到。或者在文档中同时满足这两个条件时。 优点 • 需要更少的索引 • 查询变得更容易编写，而且通常更快

分桶

当需要管理流式数据，如时间序列、实时分析或物联网（IOT）应用程序时，分桶模式是一个很好的解决方案。 优点 • 减少了集合中的文档总数 • 提高了索引性能 • 可以通过预聚合简化数据的访问

计算

当数据访问模式为读取密集型并且应用程序需要重复计算这些数据时，计算模式是一个很好的选项。 优点 • 对于频繁的计算可以减少CPU的工作负载 • 查询变得更容易编写，而且通常更快 缺点 • 识别出需要使用此模式的的场景可能比较困难 • 除非必要，请勿过度使用此模式

文档版本控制

当你需要在MongoDB中维护以前版本的文档时，文档版本控制模式是一种可行的解决方案。 优点 • 容易实现，即使是在现存的系统中 • 在最新版本上进行请求时，没有性能上的影响 缺点 • 写操作的数量会翻倍 • 请求需要被定位到正确的集合

扩展引用

当你的应用程序使用了大量的JOIN操作来将频繁访问的数据集中在一起时，你会发现扩展引用模式非常有用。 优点 • 当有大量的JOIN操作时可以提升性能 • 读操作会更快，并且可以减少JOIN操作的数量 缺点 • 会有重复数据

异常值

你是否发现有一些查询或文档和其它典型数据的模式不一样？这些例外情况是否驱动了你应用程序的解决方案？如果是这样，那么异常值模式就是解决这种情况的一个很好的方法。 优点 • 防止整个应用的解决方案被某些个别的文档或请求所左右 • 请求会针对那些典型的用例进行优化，而异常值仍将得到处理 缺点 • 通常会为特定的查询而进行定制，因此一些临时产生的查询可能性能不太理想 • 此模式的大部分工作是在应用程序代码中完成的

预分配

当你事先知道文档的结构，而应用程序只需要用数据填充它时，预分配模式是正确的选择。 优点 • 当预先知道文档结构时，可以简化设计 缺点 • 简单和性能之间的权衡

多态

当有多种文档它们的相似性比差异更多，并且需要将这些文档保存在同一个集合中时，多态模式是一种解决方案。 优点 • 实现简单 • 查询可以在单个集合中运行

模式版本控制

几乎每个应用程序都可以从模式版本控制模式中获益，因为数据模式的更改经常发生在应用程序的生命周期中。此模式允许历史版本和当前版本的文档在集合中同时存在。 优点 • 不需要停机时间 • 模式迁移可控 • 减少未来的技术债务 缺点 • 在迁移过程中，对相同的字段可能需要两个索引

子集

子集模式解决了有大量数据的大文档没有被应用程序使用而导致的工作集超过RAM容量的问题。 优点 • 在总体上减小了工作集的大小 • 缩短了最常用数据的磁盘访问时间 缺点 • 必须管理子集 • 请求附加的数据需要额外的数据库访问

树形

当数据是分层结构并且经常被查询时，树形模式就是你要使用的。 优点 • 通过避免多次JOIN操作提高了性能 缺点 • 需要在应用层管理图的更新

结论

正如我们希望你在本系列文章中看到的，MongoDB文档模型在如何建模数据方面提供了很大的灵活性。这种灵活性是非常强大的，但是这种能力需要根据应用程序的数据访问模式去驾驭利用。MongoDB中的模式设计对应用程序的性能有着巨大的影响。我们发现性能问题常常可以追溯到糟糕的模式设计。

请记住，为了进一步增强文档模型的能力，这些设计模式在合理的情况下可以一起使用。例如，随着应用程序的发展，模式版本控制可以与任何其它模式一起使用。学习完已经介绍的十二种设计模式，你已经拥有了利用文档模型强大的灵活性所需的工具和知识。

本文译自：Building with Patterns: A Summary