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

Question

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

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

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

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

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

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

感谢您的帮助；-)

Answer 1

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

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

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

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

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

Answer 2

使用一个消息生成器，具有默认日志记录参数（双循环或三循环日志记录）的 WMQ 7 将使用 mqjms api 在我的笔记本电脑 7200 hd 驱动器上每秒存储大约 300-400 条持久消息，同时尽可能快地使用 jms 代码。期望（一个会话，一个消息生产者，在通道上缓冲）和小消息大小（有效负载大小

通过在 QM 端使用较少的登录，您将获得更快的速度。这非常线性地扩展。使用非持久消息也有帮助。

其他常见问题是网络层。消息传递通常是关于发送大小不超过几 kb 的小消息。使用来自一个用户的通用网络代码（打开连接/打开会话/打开生产者/返回），您将在 HDD 启动之前遇到 TCP 限制。为了避免这个问题，WMQ 允许在通道上进行消息批处理。

我怀疑使用默认日志在 WMQ 中存储持久消息是否比在 DB2 中插入 blob 更快。底层机制基本相同（事务日志、rec/ack、...）。

我从未尝试将它与 SQLLite 进行比较。

WMQ 不是比子弹更快的消息传递解决方案。它也不是最容易管理的解决方案。如此说来，它有光明的一面，在我看来，它是最好的产品之一。