关系数据库是否适用于软实时系统？

Question

我正在研究一种实时视频分析系统，它逐帧处理视频流。在每一帧，它可以生成几个应该记录的事件，一些事件通过网络传送到另一个系统。该系统是实时软的，即消息延迟高于25ms是非常不受欢迎的，但不是致命的。

关系数据库（特别是MySQL和Postgres）是否适合作为此类系统的数据存储？

如果数据库安装在自己的服务器上并且有大约50个25fps的单行SQL插件流进入网络，我能指望它能正常工作吗？

编辑：我认为总的来说性能不会有问题，但我担心延迟差异。如果它偶尔会延迟1000毫秒，那将是非常糟糕的。

哦，系统全天候运行，因此数据库可以随意增长。这会降低插入延迟吗？

Answer 1

在选择关系数据库而不是其他类型的数据存储时，我不会过分担心性能，选择最符合您以后访问该数据的要求的解决方案。但是，如果您不仅选择RDBMS而是通过网络选择一个RDBMS，那么您可能需要考虑将事件缓冲到本地磁盘，然后再转发到数据库。使用单独的线程或进程或其他东西将事件推送到数据库中，以保持实时系统不受影响。

Answer 2

最大的问题是延迟是多么不可预测，以及它永远不会下降，总是向上。但现代硬件救援，指定一台具有足够cpu核心的机器。你可以指望至少两个，让四个很容易。因此，您可以启动一个线程并将一个核心专用于dbase更新，将其与软实时代码隔离开来。现在你不关心延迟的可变性，至少只要dbase更新不需要太长时间就可以比生成数据更快地生成数据。

设置dbase服务器并使用虚假数据加载它，将您认为需要存储的数量加倍。在开发过程中持续测试，添加您需要的仪器代码，以便在项目的早期阶段测量它的运行情况。

Answer 3

正如我所写，如果你排队需要保存的行并以异步方式保存它们（所以不要停止“主”线程）应该没有任何问题......但是！ ！

您希望将它们保存在数据库中......所以其他人会在相同的时间读取这些行。可悲的是，通常很难告诉数据库“这项工作是非常优先的，其他一切都可以停滞但不是这个”。所以，如果有人这样做：

BEGIN TRANSACTION
    SELECT COUNT(*) FROM TABLE
    WAITFOR DELAY '01:00:00'

（我在这里使用的是T-Sql ...但我认为很清楚。请求表的COUNT（*），以便锁定表，然后WAITFOR一小时）

然后写入可能会停止并进入超时状态。通常，如果您将除应用程序之外的所有人配置为只能执行读取操作，则不应出现这些问题。