我正在使用 ILP 协议与他们的官方客户之一将数据流式传输到 QuestDB。我希望在发送后立即看到可用的数据，但事实并非如此。
如果我转到 Web 界面，表已经创建，但如果我运行 SELECT count() FROM sensors 或 SELECT * FROM sensors，我没有得到任何结果。
日志也没有显示任何错误。
谢谢
更新: 如果我在几分钟后检查，数据就在那里，但我至少需要 5 分钟才能看到它
【问题讨论】：
标签： database time-series real-time-data questdb
这曾经是 QuestDB 新用户最常问的问题之一。在 QuestDB 6.6.1 版（2022 年 11 月发布）之前，QuestDB 将使用一种名为 "CommitLag" 的机制来权衡查询中新数据的摄取性能和准备情况。
这是专门为无序到达的数据（相对于指定的时间戳）而设计的，但在许多情况下，当数据按顺序摄取时它也会产生副作用。 CommitLag 默认为 5 分钟，但可以针对单个表进行更改（精确到毫秒）。
乱序数据（或 QuestDB 术语中的 o3）需要这样做的原因是因为 QuestDB 存储的数据是通过增加指定时间戳进行物理排序的，因此数据迟到意味着引擎需要重写这些数据所属的分区。
从 6.6.1 版本开始，QuestDB 改变了将数据持久化到表文件的方式，引入了"Dynamic Commits"。这种新机制自动决定物理写入表文件的频率。只要数据按顺序发送，写入就会立即进行，您的数据将能够立即出现在您的SELECT 语句中。
如果数据开始出现乱序（例如，由于源中的网络滞后，或者因为业务逻辑允许发送较旧的数据），QuestDB 将计算出数据到达的时间并因此调整写入频率.这种启发式算法每秒计算一次，因此可以非常快速地响应摄取模式的变化。
当您使用 QuestDB 6.6.1 或更高版本时，新功能无需配置并且开箱即用，因此我的建议是升级到最新版本。
【讨论】：