CrateDB 6.3.5 已正式发布。作为一个补丁版本，它延续了 CrateDB 的核心定位：用熟悉的 SQL 接口实时写入和分析大规模机器数据，同时提供通常由 NoSQL 系统承担的水平扩展能力。来源摘要提到该版本包含问题修复，但具体修复条目并未完整给出，因此生产升级仍应以完整发布说明和实际回归测试为准。
为什么机器数据需要分布式 SQL
日志、指标、设备遥测和工业传感器数据通常具有三个共同特征：写入持续发生、数据量快速增长、查询条件难以提前确定。传统事务数据库能够处理 SQL，但面对高吞吐时序写入时，分区和扩容成本可能迅速上升；一些 NoSQL 数据库擅长扩展，却会把关联、聚合和临时分析的复杂度推给应用层。
CrateDB 的思路是把两种能力放在一起：数据在集群中分片存储，查询由多个节点并行执行，同时对应用提供 SQL 接口。来源摘要指出，即使是最小规模的 CrateDB 集群，也可以轻松达到每秒数万条记录的摄取能力，并能在整个集群上实时执行临时并行查询。实际吞吐量仍会受到节点配置、分片数量、字段映射、复制策略和存储设备影响，不能直接把这一数字当作任何工作负载下的容量承诺。
用容器快速验证 6.3.5
可以这样实践：先在本地启动单节点 CrateDB 6.3.5，验证建表、写入和聚合查询。以下配置只适合开发或升级验证，不代表生产集群拓扑。
将下面内容保存为 compose.yaml：
services:
cratedb:
image: crate:6.3.5
command:
- crate
- -Cdiscovery.type=single-node
- -Ccluster.name=crate-local
ports:
- "4200:4200"
- "5432:5432"
volumes:
- crate-data:/data
volumes:
crate-data:
启动服务并检查健康状态：
docker compose up -d
docker compose ps
curl -fsS http://localhost:4200/
端口 4200 提供 HTTP 管理与 SQL API，5432 可供兼容 PostgreSQL 协议的客户端连接。下面通过 HTTP SQL API 创建一张机器遥测表。单节点示例将副本数设为 0；生产环境不应照搬这个设置。
curl -fsS -X POST http://localhost:4200/_sql \
-H 'Content-Type: application/json' \
-d '{
"stmt": "CREATE TABLE IF NOT EXISTS machine_metrics (device_id TEXT, ts TIMESTAMP WITH TIME ZONE, temperature DOUBLE PRECISION, status TEXT) CLUSTERED INTO 4 SHARDS WITH (number_of_replicas = 0)"
}'
使用批量参数一次写入多条记录：
curl -fsS -X POST http://localhost:4200/_sql \
-H 'Content-Type: application/json' \
-d '{
"stmt": "INSERT INTO machine_metrics (device_id, ts, temperature, status) VALUES (?, ?, ?, ?)",
"bulk_args": [
["press-01", "2025-01-15T10:00:00Z", 71.4, "ok"],
["press-01", "2025-01-15T10:01:00Z", 76.8, "warning"],
["press-02", "2025-01-15T10:01:00Z", 69.2, "ok"]
]
}'
随后执行临时聚合查询，找出设备的最高温度和样本数：
curl -fsS -X POST http://localhost:4200/_sql \
-H 'Content-Type: application/json' \
-d '{
"stmt": "SELECT device_id, COUNT(*) AS samples, MAX(temperature) AS max_temperature FROM machine_metrics WHERE ts >= ? GROUP BY device_id ORDER BY max_temperature DESC",
"args": ["2025-01-15T00:00:00Z"]
}'
这组命令验证的是最小闭环：应用批量写入机器数据，再用 SQL 按时间过滤并聚合。要做吞吐测试，应使用接近生产的数据宽度、批次大小和并发度，而不是循环执行单条 curl。
补丁版本也要按生产升级处理
6.3.5 的版本号看起来风险较低，但分布式数据库升级会同时影响节点通信、分片恢复、查询计划和客户端连接。来源摘要没有展示完整修复清单，因此不宜根据截断信息推断某个具体问题已经解决。
升级前可以按以下顺序执行：
- 阅读完整发布说明，确认修复内容是否涉及当前使用的写入方式、SQL 特性或客户端驱动。
- 检查当前版本到 6.3.5 的升级路径、支持的滚动升级方式以及可能存在的中间版本要求。
- 备份关键数据与集群配置，并实际验证恢复流程。
- 在预生产环境回放代表性写入流量和高成本查询，比较延迟、错误率与查询结果。
- 升级期间持续观察集群健康、未分配分片、节点重启次数和客户端重试。
- 保留明确的停止条件；若官方不支持直接降级，应通过快照恢复或替换集群完成回退。
采用建议
新环境可以直接用固定的 6.3.5 镜像标签开展功能验证，避免使用会随时间变化的 latest。现有集群则应把本次发布视为一次受控补丁升级：先确认修复项与自身工作负载的关系，再通过真实数据回放验证收益。
CrateDB 适合需要持续摄取机器数据、又希望保留 SQL 聚合和临时查询能力的团队。不过，分布式 SQL 并不会消除容量规划：分片过多会增加集群元数据和调度成本，分片过少则可能限制并行度；副本可以提高可用性，但也会增加存储与写入开销。上线前应围绕数据保留周期、节点故障容忍度、查询并发和恢复时间目标确定这些参数，而不是直接复制单节点示例。