工程实践QuestDB Engineering
文章介绍 Port Context Engine 用免费 AIS 流构建港口拥堵监测：Go 采集器接收船舶位置，经 NATS JetStream 分发并写入 QuestDB，五个服务分别负责采集、挂靠检测、增强、API 和归档。系统利用 LATEST ON、ASOF JOIN、SAMPLE BY、去重和 TTL/分区，在 2 CPU/1 GB 容器内完成实时查询、降采样及原始数据归档到 Parquet。作者复盘了分区删除需双重校验、ILP 重连、去重键和类型转换等工程教训。该方案适合低吞吐、强时间语义的物联网分析，但受免费 AIS 覆盖范围和港口数据边界限制。
推荐收录：文章给出了可运行系统的完整证据，包括五服务架构、QuestDB 表结构与保留策略、ILP 写入、LATEST ON/ASOF JOIN/SAMPLE BY 查询、Parquet 归档校验和真实运维踩坑。适合数据工程、时间序列数据库和物联网后端读者参考，其“先独立校验再删除分区”和资源受限下的数据生命周期设计可直接迁移。注意其负载仅约 860 消息/分钟，不能代表高吞吐场景。
工程实践QuestDB Engineering
文章以 Databento EQUS.MINI 中 2026-10-27 美股全市场 3.54 亿条盘口事件和 754 万笔成交为样本，演示如何从 QuestDB 按时间顺序回放一天数据用于回测。作者用 Python 客户端经 QWP/WebSocket 以 Arrow 批次流式读取，按查询超时把全天切成连续区间并校验时间戳顺序。严格顺序模式约 119–130 秒、3.5–3.8 Gb/s；8 连接并行约 32.5 秒、14.2 Gb/s，受 12.5 Gbps 网络上限约束，客户端峰值内存约 194 MiB。单标的 NVDA 约 6 秒，本地回放可达 27 Gb/s。作者也说明 page cache、空消费者、top-of-book 深度等边界，代码和硬件公开可复现，但仍是厂商自测基准。
推荐收录为工程案例：文章公开了完整代码、查询切分、硬件与网络配置，并给出严格顺序与并行回放的吞吐、内存和网络瓶颈数据，还主动列出 page cache、消费者为空、仅盘口一档等限制。对做时序数据库、行情回放、回测基础设施或 Arrow 流式读取的读者，其基准方法和边界分析可直接迁移；主要风险是厂商自测，需用自己的负载复核。
技术文章QuestDB Engineering
文章围绕一张按天分区的 FX trades 表，演示 QuestDB 将旧分区转为 Parquet 后，QuestDB SQL、Polars 与 DuckDB 三种读取方式能对每日 VWAP、成交笔数、成交量和高低价得出一致结果。作者给出完整步骤：通过 QWP 写入 150 万行数据、建立物化视图、执行 CONVERT PARTITION TO PARQUET、直接读取 data.parquet，并用 SQL 与两种 Python/分析引擎交叉验证。文章重点说明 Parquet 分区仍是活表的一部分：迟到写入会被接受并触发 row group 重写，去重 upsert 生效，但 UPDATE 会被拒绝，后台 compaction 会回收空间。Enterprise 部分进一步展示同一批 Parquet 文件迁移到对象存储、采用 Hive 分区供 Trino/Spark/BigQuery/Snowflake/DuckDB 读取的路径，并强调 QuestDB 是唯一写入者、seal 后迟到写会被跳过、远程读取延迟更高。适用边界是时间分区表、以顺序写入为主且能接受对象存储查询延迟的场景；文中数据为合成数据，文件大小和性能结论不应直接外推。
推荐收录，因为它不是单纯的产品介绍，而是用可运行示例和交叉验证展示 Parquet 分区在数据库、Polars、DuckDB 之间的互操作细节，并明确写出迟到写入、UPDATE 限制、文件重写、compaction 和冷存储 seal 等边界。适合正在评估时间序列数据库冷存储、Parquet 湖仓互操作或 DuckDB/Polars 分析工作流的数据工程师参考。主要风险是厂商立场和合成数据，性能与容量数字只能作为示意，不应视为中立基准。
工程实践QuestDB Engineering
QuestDB 10.1 发布说明围绕时序数据库的乱序写入与分析能力展开。核心 merge-append 分区将迟到行合并进分区切片并追加，由后台 compaction 回收死空间，以临时磁盘空间换取更低写放大和更快可见性；demo 观测到每写入一行的磁盘写入从约 440 降到约 8，WAL apply 中位耗时从 1.7ms 降到 0.6ms。文章还介绍 SUBSAMPLE 抽稀、精确 percentile_disc/cont、sys.metrics 单实例指标历史，以及 HORIZON JOIN 语义调整和 join 上 GROUP BY 的并行执行。文末列出较多破坏性变更与回滚限制，内容偏 QuestDB 特定实现，但存储取舍、性能验证和升级风险梳理有迁移价值。
推荐收录，因为它不是单纯版本公告：文章具体解释了 merge-append 用分区切片和后台 compaction 降低迟到数据重写，并给出磁盘写放大约 440→8、WAL apply 中位延迟 1.7→0.6ms 的前后观测，也说明了 SUBSAMPLE、精确百分位和并行 join 聚合的语义与限制。适合时序数据库用户、数据库内核与存储工程师参考，可迁移的是以临时空间换低写放大、后台整理和升级兼容性评估；风险是发布方视角且实现高度 QuestDB 特定，基准需结合实际负载复核。
工程实践QuestDB Engineering
文章介绍如何用 QuestDB Enterprise 4.0 的 Databento connector 将 EQUS.MINI 美股实时行情接入 QuestDB。作者通过单一 TOML 配置订阅 mbp-1 与 trades，连接器自动建表，以 ts_recv 作为纳秒时间戳，并将买卖盘存为二维数组；随后用 LATEST ON、SAMPLE BY、ASOF JOIN 和 Web Console 仪表板进行查询与可视化。文章重点验证连接器重启后借助 Databento intraday replay 回补数据、用 replay_dedup 去重，以及 QuestDB 停机时连接器在内存中缓冲、恢复后按原始时间戳补写和副本 failover。文中还讨论分区、冷存储与保留策略，并指出该方案依赖企业版连接器和实时订阅，长停机及常规交易时段的高压路径尚未完整实测。
推荐收录：文章基于真实运行数据，完整展示了从配置、建表、SQL 查询到重启回补、去重、QuestDB 停机缓冲和副本 failover 的链路，并比较了 replay_dedup 与 DEDUP UPSERT KEYS 的取舍。适合做时序数据库、行情数据管道和高可用接入的工程师参考，其中按确认位点重放、计数式去重和缓冲边界具有可迁移价值；但需注意其企业版连接器与 Databento 实时订阅的特定依赖，长停机路径仍属设计而非实测。
技术文章QuestDB Engineering
文章深入解析 QuestDB 二进制传输协议 QWP 中用于时间戳的 Gorilla 编码。它从每行时间戳占满 64 位的问题出发，先讲增量编码，再引入 Facebook Gorilla（VLDB 2015）论文的 delta-of-delta（DoD）方案：稳定节奏下 DoD 为零，仅需 1 位。文章详细说明可变长桶标签（1/9/12/16/36 位）如何让解码器逐位确定边界，并用 OKX 真实成交数据实测压缩效果（突发行情约 4.9x，规律采样单列最高约 57x）。同时给出边界：DoD 超过 32 位有符号范围时整列回退为 64 位，该上限随单位变化（微秒约 35 分钟，纳秒约 2.1 秒），并附可复现脚本。适用于时间序列存储、数据库与协议设计读者。
推荐收录：文章以真实 OKX 成交与外汇行情数据逐位演算 Gorilla 时间戳编码，明确给出各桶的位宽与取值范围、不同数据形态下的压缩比（突发 4.9x、规律 15x、千行 57x）以及回退条件（微秒约 35 分钟、纳秒约 2.1 秒），并提供可复现脚本。对时间序列数据库、存储引擎和网络协议设计者具有直接可迁移价值。
技术文章QuestDB Engineering
文章系统比较 QuestDB 的五种时序 JOIN：ASOF、WINDOW、HORIZON、LT、SPLICE，并说明 LATERAL JOIN 如何按行复用它们。作者以 FX 交易与行情表为例，在公开 demo 上给出可运行 SQL，解释每种连接的时间匹配方式、返回行数、聚合行为和典型用途：ASOF 取事件时刻的最新值，WINDOW 聚合时间窗口内多行，HORIZON 在多个固定偏移上重复 ASOF，LT 取严格早于当前时间戳的前值，SPLICE 实现双向全外 ASOF。文章还讨论 TOLERANCE、EXCLUDE PREVAILING、CTE 组合限制、WINDOW 与 HORIZON 的混淆、LT 避免前视偏差等边界。最后提醒 demo 数据为合成数据，应关注查询语义而非市场结论。
推荐收录：文章不是泛泛介绍，而是用一组可运行 SQL 和返回行数直接证明五种时序 JOIN 的语义差异，并给出选择依据与组合限制。它适合数据库、时序数据分析、量化/监控系统开发者作为查询设计与选型参考，ASOF/WINDOW/HORIZON 的区别和 LT 防前视偏差等方法可迁移到其他时序系统；主要风险是语法和部分行为绑定 QuestDB。
工程实践QuestDB Engineering
文章对比两种开放表格式在元数据存放位置上的根本差异：Iceberg 把元数据写成对象存储中的 metadata JSON、manifest list 和 Avro manifest 文件，目录只保存指向当前元数据文件的指针；DuckLake 则把全部元数据（文件列表、schema 历史、快照、统计信息）存放在 SQLite、Postgres 或 DuckDB 这类 SQL 数据库中，目录即元数据本身。作者由此推导出三点后果：查询规划退化为对索引表的 SQL 查询、不存在元数据小文件堆积因而无需 compaction、但读取方必须能连接该数据库导致生态覆盖较窄。文章随后给出把 QuestDB 冷存储的 Hive 分区 Parquet 通过 ducklake_add_data_files 零拷贝注册进 DuckLake 的具体脚本，并讨论增量同步、删除单文件时需重新注册存活集合、关闭 auto_compact 保护原始文件，以及纳秒时间戳在 DuckDB 视图中降为微秒的边界。
推荐收录。文章不是产品宣传，而是把“表格式即 Parquet 之上的元数据层”这一抽象讲清楚，并用 Iceberg 与 DuckLake 元数据存放位置的差异推导出查询规划、运维成本和生态覆盖上的具体取舍。附带的注册与同步脚本、零拷贝约束和版本相关注意事项，对做数据湖、冷存储分层或 lakehouse 选型的工程师有直接可迁移价值；需注意示例仓库明确非生产工具，且结论带有 QuestDB 自身存储的视角。
技术文章QuestDB Engineering
文章系统解释 Parquet 文件格式与 Iceberg 表格式的分层关系。先讲 Parquet 的列式布局、统计信息与谓词下推优势，再指出以目录管理多个 Parquet 会在原子提交、并发写、快照、schema 演进和小文件上出问题，而 Iceberg 正是为了解决这些问题。Iceberg 不替代 Parquet，而是在文件之上增加元数据层，通过快照实现原子提交、时间旅行与多引擎互操作，且可直接注册已有 Parquet 而无需重写。文章以 QuestDB 冷存储为例，展示将历史分区转为 Parquet 放入对象存储、再用 PyIceberg 的 add_files 注册为 Iceberg 表的流程，并说明分区同步、纳秒时间戳和 UUID 兼容等运维边界。作者明确演示脚本是 demo，生产需自建带认证目录。
本文清晰区分了文件格式与表格式的职责边界，并用 QuestDB 冷存储配合 Iceberg 注册的完整示例证明 Parquet 可以无需重写即被 Iceberg 采用，概念解释与工程实践并重，属于长期可参考的数据工程内容。适合数据平台工程师、数据架构师及希望理解 Lakehouse 底层原理的读者。文中也提醒了分区同步和类型映射等落地风险，但厂商背景和 demo 代码需结合生产环境谨慎对待。
工程实践QuestDB Engineering
QuestDB 10.0引入新的二进制列式线协议QWP，用于替代ILP（文本摄取）和PGWire（行式查询）的组合。文章介绍了QWP的设计动机：性能差距（QWP摄取19M行/秒，ILP仅5.3M；查询结果回传220M行/秒）以及单一客户端同时支持读写、DataFrame和Arrow双向传输、内置故障转移的需求。QWP在线上传输类型化列而非行，SYMBOL列字典编码，客户端将批量数据零拷贝映射到Arrow缓冲，但可空列、位压缩时间戳和zstd压缩仍需额外处理。文章还详细说明了多主机故障转移机制（服务器通告角色和区域，客户端路由至主或副本）、存储转发队列（支持磁盘持久化和重放）以及至少一次语义，建议在表上声明DEDUP UPSERT KEYS。作者对比了ILP/PGWire/REST的使用场景，并指出QWP适合新项目和自己编写的客户端，第三方工具仍应使用既有兼容协议。
这是一篇来自QuestDB官方工程博客的技术文章，提供了QWP协议的完整设计细节和基准数据，包括性能对比、柱式格式、Arrow集成、故障转移和存储转发机制，内容有实质深度而非单纯宣传。适合数据库内核开发者、时序数据库用户以及需要设计高性能数据摄入/查询协议的系统工程师阅读。文章中的协议取舍、迁移路径和客户端行为规范具有可迁移价值，但需注意官方立场可能对性能数字偏乐观，读者应结合自身场景验证。
工程实践QuestDB Engineering
文章测试 QuestDB 新 QWP 协议将查询结果流式传输到 Apache Arrow 的性能，并与 ClickHouse、TimescaleDB 对比。作者用简单查询和并行读取器基准，测量 500M 行数据的导出速度。最初几轮结果受磁盘 I/O、Python GIL 等因素影响，修正后 QuestDB 达到 220M 行/秒，首批数据仅 32ms，比 ClickHouse 最快流式路径快 2.35 倍。文章还分析了每行字节数、存储占用、扩展性和协调成本，并指出测试的局限（单一 schema、低基数字符串等）。该文提供了可复现的测试方法和详实的过程反思。
推荐收录，因为它不是简单的产品宣传，而是深入的工程基准测试，展示了如何识别并消除磁盘、GIL、协调成本等测试伪影，并提供了可复现的仓库和明确的局限声明。适合数据库选型、性能评估或数据管道设计的读者，可迁移价值在于严谨的流式数据导出基准测试方法和工程分析框架。