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

Question

在数据库设计的早期，我们为每个表创建任务字段，其中几个重要字段是:

created_by
created_time
created_by_ip
updated_by
updated_time
updated_by_ip

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

My question here is:

1. Is it a good practise to maintain logs in a separate database?

2. Do we need to create separate log table for each mysql tables considering mongodb or is it okay to have single mongodb audit table for all mysql tables?

3. What things need to be considered in querying the results from mongodb?

4. What should be the structure for mongodb table structure?

5. Any other alternatives to store logs?

考虑到如果在指定时间(最多 48 小时)内未通过身份验证，我们是否要删除注册用户的情况。

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

Answer 1

您通常希望此(审计？)数据位于真实数据旁边，并且绝对不位于不同的数据库引擎中，因为要支持的部分错误的数量变得相当噩梦(例如，有人注册了，但您无法插入审计数据 -这样可以吗？该帐户应该成为孤儿帐户吗？如果应用程序中途崩溃会发生什么？)。

具有这种分离的系统通常使用消息传递，并且有 2 个不同的监听器负责存储数据和存储审计(例如，一个在关系数据库中，另一个在事件存储中)。通过这种方式，您就有更高的机会实现最终一致性。

编辑

使用消息传递有几种选择，这里的假设是两个数据源必须同步(或尽可能接近)。请记住，我仍然认为将数据+审计存储在一起是迄今为止最简单、更明智的方法。

使用消息传递，您的应用可以针对某些事件(例如用户创建)发出消息。然后 2 个不同的监听器对此消息使用react。一个监听器将数据存储在一个数据库引擎中；另一个监听器存储审计数据。这种方法的问题是您可能需要确保消息的排序，这使得它非常很慢。

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

我需要强调的是，上述两种方法都很糟糕，不应该永远实现。

有更明智的方法，但可能需要不同的技术堆栈。例如，使用 EventSourcing+CQRS，您可以存储事件(带有审核数据)并存储最终的读取模型，而无需审核数据。