在MongoDB中存储mysql事件日志好吗？

Question

在我们的数据库设计的早期，我们使用为每个表创建任务字段，很少有重要字段是：

created_by
created_time
created_by_ip
updated_by
updated_time
updated_by_ip

现在，这是一个无模式设计的时代。我们更喜欢mongodb或其他只是编写数据库的东西。

我的问题是：

1. 在单独的数据库中维护日志是一个很好的实践吗？
2. 我们是否需要为每个考虑mongodb的mysql表创建单独的日志表，还是可以为所有mysql表创建一个mongodb审计表？
3. 在查询mongodb的结果时需要考虑哪些因素？
4. mongodb表结构应该是什么结构？
5. 还有其他替代存储日志的方法吗？

考虑到这样的情况，如果我们想删除注册用户，如果没有在指定的时间认证(最长48小时)。

如果所有时间日志都在mongodb中处理。我们如何从mysql中查询相同的内容？

Answer 1

你通常想要这个(审计？)数据旁边的真实数据，绝对不是在一个不同的DB引擎中，因为支持的部分错误的数量变成了一场噩梦(例如，有人注册了，但您没有插入审计数据-这可以吗？)这个账户应该变成孤儿吗？如果应用程序半途而废会发生什么？)

具有这种分离的系统通常使用消息传递，两个不同的侦听器负责存储数据和审计(例如，一个在关系DB中，另一个在事件存储中)。通过这种方式，您获得最终一致性的可能性更高。

编辑

关于使用消息传递有几个选项，这里的假设是两个数据源必须同步(或尽可能接近)。请记住，到目前为止，我仍然认为将data+audit存储在一起是最简单和更明智的方法。

使用消息传递，您的应用程序可以在特定事件(例如用户创建)上发出消息。然后，两个不同的侦听器对此消息作出反应。一个侦听器将数据存储在一个DB引擎中；另一个侦听器存储审计数据。这种方法的问题是，您可能需要确保消息的顺序，这使得它真正的慢。

另一种(可怕的)方法是在MySQL和消息传递系统之间使用分布式(XA)事务(因为mongo不支持事务)。然后将数据提交到MySQL和消息，侦听器可以接收审计数据并将其存储在mongo中。

我需要强调的是，上面的两种方法是可怕的，如果永远不会实现的话。

有更明智的方法，但可能需要一个不同的技术栈。例如，使用EventSourcing+CQRS，您可以存储事件(与审计数据一起)，并在没有审计数据的情况下存储最终读取模型。