什么是 MongoDB？

Scrapeless Web Unlocker 获取公共网页内容，使采集服务能够将其验证并存储为 MongoDB 文档。

MongoDB 是一种文档数据库，以字段和值的集合形式存储记录。文档可以包含嵌套对象和数组，因此其结构可以类似于应用程序代码中使用的对象。这使得当记录自然围绕某个实体（如产品、文章或来源观测）进行聚合时，MongoDB 成为一个有用的选择。

文档模型允许存在差异，但可靠的数据仍然需要契约。如果一个集合中，一条记录将价格存储为文本，而另一条记录将金额存储为不带货币的数值，那么它可能容易填充，却难以被正确查询。关于模式的决策会进入应用程序和数据库设计之中，而不是消失不见。

文档和集合组织数据

MongoDB 集合将文档分组，而不要求每个文档都包含相同的字段。 MongoDB 文档架构 支持嵌套值、查询和事务操作。当这与应用程序读取和更新数据的方式匹配时，该模型允许应用程序将相关信息放在一起。

MongoDB 对存储的文档使用 BSON。BSON 支持比普通 JSON 更广泛的类型，因此日期或标识符应当能在驱动程序与应用程序边界之间保持其预期类型。类似 JSON 的便捷展示形式并不能证明每个值都只是 JSON 字符串或数字。

这种 JSON 交换格式 在文档通过 API 或导出到达时仍然很重要。将文档转换为 JSON 可能需要就更丰富的数据库类型做出明确决策。让这些决策成为导出契约的一部分，以便其他使用方能够重建其预期含义。

集合名称也应描述其记录单元。产品、来源页面和观测是不同的单元，即使每个单元中都包含产品标题。如果在没有区分标记的情况下将它们合并，就会产生歧义，无法判断某个文档描述的是持久存在的实体，还是关于该实体的某一时刻证据。

灵活的模式需要稳定的含义

灵活的模式支持记录演化，而稳定的字段含义则保持这些记录的可用性。来源观测可以新增一个可选字段，而不要求每个历史文档都包含它。消费者仍然需要知道字段缺失时，表示不可用、未被采集还是不适用。

尽早定义必需的身份和时间字段。一个公共产品观测可能需要来源标识符、产品身份、观测时间和抽取版本。可选属性随后可以变化，而不会失去将记录追溯到创建它的来源事件的能力。

将原始输入与已接受字段分开。保留来源响应有助于解释抽取过程，但原始负载不应自动成为应用程序的可信记录。被接受的文档应当标明哪些字段通过了验证，哪些可选值仍然未知。

嵌入与引用遵循访问模式

嵌入将相关信息存储在文档内部，而引用则存储到其他位置信息的关系。应根据哪些数据会一起被读取、如何变化，以及嵌套集合能否在有意义的界限之外增长来做出选择。

产品记录可以嵌入一小组当前属性，而产品页面总是会一起显示这些属性。历史价格观测可以持续增长，并具有自己的保留策略，因此单独的观测集合可能使它们的生命周期更清晰。这是基于该应用程序的建模决策，而不是适用于每个产品数据库的普遍规则。

重复需要更新策略。如果一个分类标签被复制到许多文档中，更改该分类时可能会在集合中留下不同版本。有时这是有用的历史上下文；有时则是意外的不一致。要决定嵌入值是一个快照，还是当前关系。

避免机械地将关系型设计翻译为文档，或因为可以嵌套就把每个关系都嵌入进去。从实际查询和更新操作出发。一个写入方便却在每次读取时都需要在应用侧反复拼装的记录，可能并不像其初始形态看上去那样匹配工作负载。

索引支持查询并增加写入开销

索引帮助 MongoDB 在查询时无需扫描整个集合就能定位文档。索引应当匹配重要应用请求所使用的字段和排序方式。为每个可用字段建立索引不能替代对这些请求本身的理解。

考虑一个展示某一来源最近被接受观测的采集器。它的查询会将来源身份与观测时间以及有效性条件组合在一起。围绕该访问模式设计并检查相关查询计划，而不是仅因为这些字段出现在文档中就创建与之无关的索引。

索引会消耗存储，并且在写入期间必须维护。因此，一个记录每一次观测的集合，其索引预算可能会与一个大多只读的目录不同。在做出性能承诺之前，用真实的文档大小、更新频率和查询形态来衡量工作负载。

唯一性规则也表达业务含义。如果一个被接受的观测在某个来源和采集时间区间内是唯一的，就要有意识地定义这种身份。仅仅使用新生成的数据库标识符并不能阻止同一业务观测在不同标识符下被插入多次。

建模一个公共产品观测

产品观测文档应当区分来源实体本身与对其进行观测这一行为。产品身份连接连续的观测，而观测身份区分不同的采集事件。这样应用就可以比较变化，而不必假装每次下载都在描述一个新产品。

保持展示价格与规范化金额可区分。规范化金额应附带预期货币和相关解释规则。如果页面提供的是区间价格或会员价，要明确记录这种类别，而不是随便选个数字，却标成普通产品价格。

缺失价格应当仍然是一个可以由应用解释的观测结果。它可能反映字段不可用、响应被拒绝，或来源页面根本不公布价格。这些情况对历史趋势的含义不同，不应都变成数值 0。

更新、事务与并发写入者

MongoDB 支持对单个文档的原子操作，并为适当的工作负载提供多文档事务。应用仍然需要选择与自身一致性要求匹配的更新边界。某个特性可用，并不决定每个采集器都该如何使用它。

对于当前产品视图，多个工作进程可能在不同时间观测同一产品。如果没有排序规则，较早的观测若更晚完成，就可能覆盖较新的数值。使用观测上下文和明确的更新策略，使处理顺序不会悄然变成“新鲜度”的定义。

历史观测采集可以通过单独保留被接受的观测来避免某些覆盖歧义。当前视图随后可以根据被接受的历史记录并在有文档说明的规则下推导得出。这增加了建模责任，但更容易解释某个展示值是如何被选中的。

关于 分布式采集架构 的讨论，为在服务之间分配采集与存储提供了背景。保持交接可问责：工作进程只有在其目标的被接受文档已到达目标位置后，才应报告完成，而不只是页面下载或本地转换结束后。

副本集、分片和保留各司其职

副本集为可用性维护数据库状态副本，而分片则在部署中分布数据。两者都不能替代对文档身份、查询访问和保留策略的设计。在数据模型尚不清晰时增加更多基础设施，会让其不一致性更难排查。

分片键会影响数据如何被分布和访问。要依据实际查询和写入模式来评估，而不是因为某字段看起来唯一就选它。分布决策应包括集合如何增长，以及常见操作是否需要访问许多分区。

备份与恢复与在线复制是分开的。不想要的更新可以传播到副本，因此历史恢复需要单独的流程。定义必须保留多少被接受的历史、如何恢复，以及团队如何验证恢复结果能成为可用的应用记录。

原始内容与被接受观测可以有不同的保留周期。只保留应用所需的证据，适当保护，并有意识地删除过期诊断材料。在运维计划中纳入采集需求和 Scrapeless pricing ，这样在安排新工作之前，增加来源覆盖范围的成本就是可预期的。

结论

MongoDB 围绕具有灵活字段和显式访问模式的文档来组织应用数据。可靠的采集数据需要稳定的身份、校验机制，以及对来源实体与观测之间清晰的区分。从你的产品必须支持的查询和更新出发，再据此选择内嵌、引用与索引。保留足够的来源上下文，以便在原始页面发生变化后，仍能解释每个被接受的文档。