什么模式用于存储和检索 Mongo 中的记录审计跟踪？

Question

我正在研究使用 Mongo 来存储我的数据。我想为记录的每次更改存储一个文档。例如，一条记录代表一个日历事件。每次更新此事件（通过 Web 表单）时，我都想将新版本存储在新文档中。这将允许根据请求检索此事件的历史详细信息。

如果我要使用关系数据库存储这些数据，我将有一个“events”表和一个“events_history”表：

'events' table:
event_id
last_event_history_id

'events_history' table:
event_history_id
event_id
event_date

所以，当我想检索事件列表（显示每个事件的最新历史记录）时，我会这样做：

SELECT * FROM events_history eh, events e 
WHERE 
eh.events_history_id = e.last_event_history_id

但是，如果使用 Mongo，我不确定如何存储数据并生成此列表？

Answer 1

乔，

对于从 RDBMS 背景到 MongoDB 的人来说，您的问题是一个常见的问题（顺便说一句，这正是我个人来到 MongoDB 的方式）

我可以回答你的问题。

如果我要笼统地重申你的问题，我会说：

如何在 MongoDB 中建模一对多关系？

基本上有两种方法：

1. 嵌入式文档

您可以拥有一个“事件”集合。此集合中的文档可以包含一个名为“Event_history”的“键”，其中每个条目都是事件本身的“旧版本”。

The discussion on embedded documents for MongoDB is here.

1. 文档参考

这与您在关系数据库中所做的非常相似。您可以有两个集合，每个集合都有自己的文档。一个集合用于“活动”事件，一个集合用于历史事件

The discussion for Document references in MongoDB is here.

现在回到你的问题：这两种方法中哪一种更好。

有几个因素需要考虑

1 - MongoDB 目前没有基于数据库的连接 - 如果您的工作负载主要是读取，并且您的文档/事件不经常更改，则嵌入文档的方法会更容易并且性能更好。

2 - 避免增加文档。如果您的事件频繁更改导致 MongoDB 文档增长，那么您应该选择带有引用的设计 #2。使用 MongoDB 大规模“文档增长”通常不是最佳性能选择。 An in-depth discussion of why document growth should be avoided is here.

在不了解您的应用程序的详细信息的情况下，我倾向于“猜测”文档引用对于历史是一项重要功能的事件管理系统来说会更好。有 2 个单独的集合，并在您的应用内执行连接。