c - 基于队列文件的持久性 - WebSphere MQ 与 SQLite 队列 (WAL)

Question

我使用 Websphere MQ，它默认带有“基于文件的队列”。因此每个队列通常在磁盘上有一个物理文件。

所以假设对于这个 Websphere MQ 队列，我们​​有多个读取器和写入器....我假设读取和写入之间会有一些“毫秒锁定”开销，但我保证它仍然比使用完整数据库更快像 DB2 等

现在我已经使用 SQLite 实现了一个队列，它可以在 WAL 模式下愉快地工作在生产环境中。

我的问题是，您真的认为 WebSphere MQ 等产品使用的基于文件的队列与基于 SQLite 的队列在速度方面存在巨大差异吗？毕竟两者都是基于文件的，而且 SQLIte 是纯 ANSI C 的事实在速度方面做得很好。

SQLIte 确实提供了一些额外的功能，例如“更新 Hook ”等......以及许多其他功能。

我想我想知道的是，如果您要在 C 中实现高速持久队列，您会以与 WebSphere MQ 类似的方式来实现，并在单个文件中以不同的偏移量等方式处理消息，还是会你在 WAL 模式下使用 SQLIte 吗？

感谢您的帮助;-)

Answer 1

您对示例施加的限制越多，您就越有可能使数字看起来像您想要的那样。一个应用程序的单个队列？如果这是您的唯一要求，那么您有很多选择。

但是看看WAL模式的一些限制。检查点等待读者完成。因此，您拥有的读者越多，检查点就越难，检查点的破坏性就越大。如果 WAL 文件变大，那么读取性能会下降，因此您无法在繁忙的系统上执行惰性检查点并保持性能。

所以问题“如果您要在 C 中实现高速持久队列，您会以与 Websphere MQ 类似的方式来实现，并在单个文件中使用不同的偏移量等消息，还是您会使用SQLIte 在 WAL 模式下？”并没有包含所有的要求或注意事项。随着并发用户数量的增加，流程架构开始掩盖您所询问的存储方法的差异。 WMQ 可以处理数以千计的并发读写器，具有非常大的日志文件和相当平坦的性能曲线，而 WAL 文档指出性能与 WAL 文件的大小成正比，即随着 WAL 变大，性能曲线呈下降趋势。

如果我要在 C 中实现高速队列？如果你的意思是我应该选择哪种现有产品，我会选择经过 20 年调整和优化，每年投入数百万美元研发并且专注于排队的产品。如果通过“实现”你的意思是如果我要从头开始编写一个新的排队引擎我会怎么做，那么我会受到很长一段时间专注于排队并尝试重用他们的解决方案的产品的严重影响到非平凡的问题。数据库和队列引擎并不是偶然地达到了它们各自的存储架构。一种针对队列进行了优化，一种针对数据库语义进行了优化，如果您将范围扩大到包括 WMQ 和 SQLite 以外的数据库和队列引擎，这通常适用于所有类别。

全面披露:在 WMQ 存在的 20 年的大部分时间里，我一直在与它合作，最近加入了它在 IBM 的产品管理团队。我可能有点偏颇，但我试图专注于这里的技术，而不是下意识的“我的产品比你的产品好”的 react 。随意表示赞成票，反对票表示同意。如果得到太多反对票，我将撤回答案。