在本期《使用模式构建》中，我们将介绍桶模式。这种模式在处理物联网（IOT）、实时分析或通用时间序列数据时特别有效。通过将数据放在一起，我们可以更容易地将数据组织成特定的组，提高发现历史趋势或提供未来预测的能力，同时还能对存储进行优化。

桶模式

随着数据在一段时间内持续流入（时间序列数据），我们可能倾向于将每个测量值存储在自己的文档中。然而，这种倾向是一种非常偏向于关系型数据处理的方式。如果我们[......]

阅读全文

欢迎回到MongoDB模式设计系列。上一次我们研究了多态模式，它涵盖了集合中所有文档具有相似但不相同结构的情况。在本文中，我们将了解一下属性模式。属性模式特别适用于以下情况：

• 我们有一些大文档，它们有很多相似的字段，而这些字段的一个子集具有共同的特征，我们希望对该子集字段进行排序或查询，或
• 我们需要排序的字段只能在一小部分文档中找到，或
• 上述两个条件均满足。

出于性能原因考虑，为了优化搜索[......]

阅读全文

当涉及MongoDB时，一个经常被问到的问题是“我如何在MongoDB中为我的应用程序构造模式（schema）？”老实说，这要看情况而定。你的应用程序读操作比写操作多吗？从数据库中读取时需要将哪些数据放在一起？有哪些性能因素需要考虑？文档有多大？它们今后会变成多大？你预计数据会如何增长和扩展？

所有这些以及更多的问题，都涉及到如何在MongoDB中设计数据库模式（schema）。有人说Mongo[......]

阅读全文

MongoDB 4.0增加了一个能力，在副本处理写操作的同时可以由从节点（secondary）读取数据。为了理解这个的重要性，让我们看看4.0版本之前从节点是如何处理的。

背景

从一开始，MongoDB就是这样设计的：当主节点上有一系列的写入操作时，每个从节点必须以相同的顺序体现出这些操作。如果你在一个文档中更改了字段“A”，然后更改了字段“B”，则不可能看到此文档字段“B”被更改而字段“A”[......]

阅读全文

本文的上篇探讨了WiredTiger中WAL的原始算法，该算法用于合并写操作以达到最小化I/O的目的。它没有使用耗时的锁，而是分两个阶段使用CAS原子操作来实现。只要每个核运行的线程不太多，这个算法就可以非常好地工作。但当线程数超过该限制时，它为了避免锁而依赖于忙等待的机制会导致logjam——鉴于许多MongoDB的任务都会导致每个核有大量线程，这个问题相当严重。它阻碍了MongoDB将Wire[......]

阅读全文

你无法优化代码；优化是针对特定的条件来实现的。当条件改变时，你的优化反而可能会变为瓶颈。这时仔细审查你对这些条件的假设，其中也许就蕴藏着解决方案的关键。

WiredTiger的WAL（write-ahead log）正说明了这一原则。它是高性能存储引擎中的一个关键代码路径，我曾经对其进行了大量优化以避免I/O和锁。但当WiredTiger成为MongoDB的存储引擎时，我最初所针对的一些条件变得[......]

阅读全文