Ejabberd将应用程序逻辑与后端结合在一起(Ejabberd couples application logic with backends)

我们正在构建一个XMPP应用程序，我们已经选择ejabberd作为我们的服务器。 我们在协议层次上做了很多改变，以匹配我们的用例。 然而，我们并不满意ejabberd如何将应用逻辑与mnesia后端结合在一起。 我们希望将所有mnesia表（除了持有会话的mnesia表移动到其他节点）移动，以使系统易于维护和调试，并避免资源与ejabberd控制逻辑竞争。 如果是这样的话，我们知道会有延迟。 我们的问题是，这种方法是否更好？ 我们会面临更多分销问题吗？ 还有什么？ 请给出您的选择的详细原因。

We're building an XMPP application where we have chosen ejabberd as our server. We have done lots of changes on protocol level to match our use case. However, we not satisfied with how ejabberd couples application logic with its mnesia backends. We want to move all mnesia tables except the ones holding sessi to other nodes in order to decouple our system for easy maintainance and debugging and to avoid resource competion with the ejabberd controlling logic. We know that will suffer from latency if that is the case. Our question are, is it a better design with that approach? Are we gonna face more problems with distribution? Or what else? Please give a detail reason for your option.

最满意答案

实际上，存储数据的模块是围绕后端的概念设计的。 他们对Mnesia并不紧张。 您可以检查现有代码中每个模块后端的API。 您将会看到，通常存在可用于存储关系数据库，Riak，Redis等的模块。

您可以使用完全相同的API来实现您自己的自定义后端。

Actually, module that store data are designed around the concept of backend. They are not tight to Mnesia. You can check the API for each module backends in existing code. You will see that there is usually modules available to store in relational DB, Riak, Redis, etc.

You can use that exact same API to implement your own custom backends.