https://spricoder.github.io/2026-10-11T10:49:39.440ZSpriCoderhttps://spricoder.github.io/benchmarking/tsfile-dataset/00/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.440Z

一份时序数据集可能需要交付给其他团队、加载到数据库提供查询服务，也可能用于 AI 分析与预测。在这些场景中，使用者都需要知道数据来自哪里、各字段代表什么，以及如何读取和核验结果。 这些需求涉及三类边界：时序数据与文件系统之间；时序数据与数据库之间；时序数据集与 AI 之间。缺少共同的数据载体与访问约定时，结构说明、导入配置和分析代码往往分

https://spricoder.github.io/benchmarking/tsfile-dataset/01/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.445Z

一份 CSV 可以保存温度记录，却通常缺少说明 site 和 rack 如何标识设备、 temperature 应按什么类型读取。接收方往往还需要一份字段说明，或向提供数据的人确认。 本篇回到导读提出的“可发现、可理解”价值：把列定义和观测记录放在同一份可读取的文件中，接收方据此开始工作。 TsFile 将表名、列类别、数据类型和编码等信

https://spricoder.github.io/benchmarking/tsfile-dataset/02/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.446Z

接收一份设备测试数据或机房运行数据后，使用者需要先确认文件模型、对象、字段结构和数据规模，再决定如何分析。本文沿用第 01 篇创建的 sensors.tsfile，说明如何逐步检查一个本地时序数据集。 本篇回到导读提出的“可发现、可理解、可验证”价值：按对象、结构、统计和记录逐层检查数据。 检查时先查看有哪些表或设备，再核对字段和时间范围

https://spricoder.github.io/benchmarking/tsfile-dataset/03/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.450Z

同一份时序数据，在离线交付和在线查询时需要的工具不同。本文以 sensors.tsfile 为例，说明如何选择文件工具、数据库工具或 SDK。 本篇回到导读提出的“可流转”价值：根据任务在本地文件、在线数据库和程序接口之间选择合适的入口。 选择时先看任务：只是检查一个文件，还是需要持续写入、多人查询与统一管理？如果要把读写逻辑放进长期运行

https://spricoder.github.io/benchmarking/tsfile-dataset/04/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.456Z

各机房每天提交一份温湿度 TsFile，数据接收方希望自动生成检查报告：文件是否可以读取、表结构是否符合约定、温度超过阈值的记录有多少。Shell 可以负责目录遍历与任务编排，TsFile-Cli 负责单个文件的结构化访问，jq 负责筛选和汇总。原有的 Unix 自动化流程由此可以纳入二进制时序数据集。 本篇回到导读提出的“可组合”价值：

https://spricoder.github.io/benchmarking/tsfile-dataset/05/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.458Z

前几篇文章把一份 CSV 做成了可携带的 table-model TsFile，并用 TsFile-Cli 在本地完成了检查。现在把这份文件交给 IoTDB，看看它怎样从文件识别表结构、建立数据库中的对象，并让数据重新出现在 SQL 查询结果里。 本篇回到导读提出的“可流转”价值：将已检查的文件交给 IoTDB，形成在线查询对象。 设想一

https://spricoder.github.io/benchmarking/tsfile-dataset/06/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.462Z

已经加载到 IoTDB 的数据，还可以按表导出为 TsFile，供离线分析或交付使用。本篇承接第 05 篇，将 tsfile_cli_demo.sensors 导出并读回检查。 本篇回到导读提出的“可流转、可验证”价值：导出在线数据并检查文件中的结构和记录。 例如，机房异常排查结束后，团队可以把选定的观测记录交给设备供应商复核。导出由 I

https://spricoder.github.io/benchmarking/tsfile-dataset/07/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.465Z

文件加载到 IoTDB 后，怎样确认再次导出的数据缺少变化？本文使用同一个 TsFile-Cli 读取原始文件与导出文件，比较表结构、字段计数和明细记录。 本篇回到导读提出的“可验证”价值：比较加载前后的结构与明细，留下可复查依据。 机房联合排查结束后，团队需要确认交给设备供应商的数据与进入 IoTDB 前的记录相符。本文把前两篇文章串成

https://spricoder.github.io/benchmarking/tsfile-dataset/08/2026-10-10T16:00:00.000Z2026-10-11T10:49:39.469Z

用户将一份机房温湿度 TsFile 交给 AI，希望比较北京与上海机房的最高温度，并说明计算依据。完成这项任务，需要确认文件模型、表结构和字段含义，读取两个站点的记录，再检查工具执行状态。自然语言问题由此转化为一组可以复查的数据操作。 本篇回到导读提出的“可委托”价值：让 Agent 依照 Skill 指引调用工具并说明依据。 仓库附带的

https://spricoder.github.io/benchmarking/tsfile-dataset/09/2026-10-10T16:00:00.000Z2026-10-11T10:48:00.086Z

前面的文章介绍了如何保存、查询和分析时序数据。本篇以发动机温度预测为场景，说明怎样准备历史序列，通过 TimechoAI / Timer 获得预测，并与后续观测对照。 本篇回到导读提出的“可流转、可验证”价值：整理历史序列，生成预测并用后续观测检查结果。 本文提供接入说明和命令模板，适合已了解 TsFile 或 IoTDB 的开发者。操作

https://spricoder.github.io/benchmarking/tsfile-dataset/series/2026-10-10T16:00:00.000Z2026-10-11T10:48:00.088Z

本专栏介绍时序数据的文件交付、数据库查询、脚本分析与模型预测。00 篇用飞机试飞说明应用场景；01–08 篇沿用同一份四行机房温湿度样例演示操作；09 篇介绍模型接入，需要另外准备连续的历史序列。 阅读顺序 序号 文章 内容 00 玩转 TsFile｜00-专栏导读：AI-Native 的时序数据集 理解数据格式、访问工具与业务说明的分工

https://spricoder.github.io/ai-work/ai-work-12-agent-friendly-database/2026-07-22T16:00:00.000Z2026-10-11T07:15:31.709Z

给 Agent 一个数据库连接、一份 schema 和执行 SQL 的工具，它就能可靠地回答数据问题了吗？ 很多失败并不是 Agent 不会写 SQL，而是它不知道某个字段的业务含义，不清楚单位和时区，无法判断两个系统里的客户编号是否指向同一实体，也不知道空结果来自“确实没有数据”还是“查询条件写错了”。即使最终数字正确，它也可能使用了过

https://spricoder.github.io/ai-work/ai-work-08-agent-trajectory/2026-07-22T16:00:00.000Z2026-10-11T07:50:16.475Z

假设你让一个 Agent 汇总一份表格中的销售额，它返回了正确数字。只看答案，这次任务应该得满分。 但如果查看执行记录，可能会发现另一幅图景：它读错了数据版本，几次查询都失败了，最后从一段旧对话里碰巧找到了同一个数字；或者它虽然生成了正确文件，却覆盖了另一列公式；又或者它在发送结果时重复提交了两次。 答案可以是对的，过程仍然可能不安全、不

https://spricoder.github.io/ai-work/ai-work-09-llm-judge/2026-07-22T16:00:00.000Z2026-10-11T07:50:16.486Z

让人评价一万条开放式回答，昂贵而缓慢；用关键词、字符串匹配或传统自动指标，又很难判断一段解释是否清楚、完整、切题。 于是，一个自然的办法出现了：让另一个大语言模型阅读任务、候选回答和评分标准，再输出分数、偏好或评语。这就是通常所说的 LLM-as-a-Judge ，也就是“让大模型担任评委”。 问题是：一个会犯错、会受提示影响的模型，能不

https://spricoder.github.io/ai-work/ai-work-11-ai-science/2026-07-22T16:00:00.000Z2026-10-11T07:15:31.709Z

让 AI 围绕一个研究问题提出十个假设，已经不难。 它可以迅速给出听起来新颖的机制、候选变量和实验方向，语言完整，逻辑顺滑，甚至像一份成熟的研究计划。但如果继续追问：这个想法是否早已发表？关键前提来自哪篇论文？怎样设计能够证伪它的实验？失败结果如何解释？分析代码能否复现？同一结论换一批样本是否仍然成立？ 任务会立刻变得困难。 原创配图：科

https://spricoder.github.io/ai-work/ai-work-06-context-memory/2026-07-21T16:00:00.000Z2026-10-11T07:50:16.454Z

使用 AI 一段时间后，人很容易遇到三种看似矛盾的情况：刚刚说过的要求，它转眼就忘了；几天前形成的写作偏好，它有时又能继续遵守；资料明明已经放进知识库，回答时却仍然没有引用到。 这些现象常被笼统地归结为“AI 的记忆不好”。但这里其实混合了三个不同问题：模型当前看见了什么，系统为以后保留了什么，以及外部资料能否在需要时被找到。 它们分别对

https://spricoder.github.io/ai-work/ai-work-07-multi-agent/2026-07-21T16:00:00.000Z2026-10-11T07:50:16.464Z

当一个 AI 完成任务不够快或结果不够好时，最直觉的想法是：再启动几个 AI，让它们一起做。 于是，同一个问题被同时交给三个 Agent。过一会儿，我们得到三份结构相似、观点略有差异的答案，还需要自己重新核对事实、消除重复、处理冲突并拼成最终版本。计算量增加了，工作却没有真正减少。 这不是多 Agent 协作，只是把同一项工作重复了几遍。

https://spricoder.github.io/ai-work/ai-work-03-completion-evidence/2026-07-20T16:00:00.000Z2026-10-11T07:50:16.422Z

让 AI 修改一份文档、修复一个 Bug 或整理一组资料后，我们经常会收到一段令人安心的总结：已经完成修改，已经运行检查，没有发现问题。 这段话很像工作的终点。它结构清楚，语气肯定，还会列出改了什么、验证了什么。于是，人很容易看完总结就直接进入下一项任务。 问题在于， “AI 说完成了”只是一条状态声明，不是任务已经完成的证据。 AI 未

https://spricoder.github.io/ai-work/ai-work-04-permission-gates/2026-07-20T16:00:00.000Z2026-10-11T07:50:16.432Z

当 AI 只能在对话框里生成文字时，最常见的风险是答案不准确。即使它写错了一段代码或误解了一份材料，人仍然可以在复制、粘贴和执行之前停下来检查。 但当 AI 能够读取本地文件、修改代码、查询数据库、创建日程和发送消息后，情况发生了变化。它不再只是给出建议，而是可能直接改变现实状态。 这时真正的问题不再是“要不要给 AI 权限”，而是： 它

https://spricoder.github.io/ai-work/ai-work-series/2026-07-20T16:00:00.000Z2026-10-11T07:51:19.295Z

本系列不追逐“哪个模型又快了多少”，而是持续讨论一个更稳定的问题：当 AI 从生成答案走向调用工具、修改文件和参与决策，人应该怎样定义任务、授予权限、验证结果，并对最终选择负责？ 当前发布版本以 CSDN 专栏 为准；本地第 10–12 篇尚未上线。 主线是： 保留人的判断 → 说清任务边界 → 理解 Agent 系统 → 建立验证方法

https://spricoder.github.io/benchmarking/benchmarking-01/2026-07-19T16:00:00.000Z2026-10-11T07:53:33.101Z

1. 前沿 在现代信息技术的飞速发展中，数据库作为数据存储和管理的核心组成部分，其性能直接影响到应用程序的响应速度和用户体验。而我们经常会遇到以下情况： 在业务选型的过程中，我们往往需要从多款数据库产品中 选择一款 作为业务支撑产品。 在数据库研发的过程中，我们同样需要将自己 优化调整后 的数据库产品同 优化调整前 的数据库产品进行比较。

https://spricoder.github.io/benchmarking/benchmarking-11/2026-07-17T16:00:00.000Z2026-10-11T07:50:16.341Z

一轮基准测试结束后，我们通常最先看到的是吞吐量、平均延迟、P99 和失败数。如果吞吐足够高、失败数又是 0，能否直接说明测试通过？ 不能。性能测试回答的是“系统处理得多快”，正确性验证回答的是“系统处理的结果是否符合预期”。一次请求返回成功，只能说明客户端收到了一次成功响应，并不能自动证明所有数据都以正确的设备、时间戳、类型和值落入数据库

https://spricoder.github.io/benchmarking/benchmarking-12/2026-07-17T16:00:00.000Z2026-10-11T07:50:16.354Z

前面的文章中，我们已经讨论了怎样验证正确性、比较接口和寻找合理的并发区间。接下来把数据库从单机换成集群，是不是只要增加节点，再把客户端数乘几倍就可以了？ 并不是。单机测试主要观察一台服务器上的 CPU、内存、磁盘和数据库执行路径；集群测试还会引入网络、请求路由、数据分片、副本写入和节点间负载均衡。此时，测试结果不仅由数据库“单节点有多快”

https://spricoder.github.io/benchmarking/benchmarking-13/2026-07-17T16:00:00.000Z2026-10-11T07:50:16.369Z

基准测试最令人遗憾的结果，不是吞吐量低，而是几天后再看那张截图，已经说不清它来自哪个版本、哪份配置和哪台机器。 性能结果天然依赖上下文。同样的吞吐量，可能来自不同设备数、批大小、接口、数据库参数和硬件状态；同一个 P99 峰值，也可能对应客户端 GC、网络抖动、服务端合并或磁盘写满。没有原始证据，复盘只能变成猜测。 这一篇讨论怎样把一次

https://spricoder.github.io/benchmarking/benchmarking-14/2026-07-17T16:00:00.000Z2026-10-11T07:50:16.394Z

走到这里，我们已经讨论了写入、读写混合、乱序、接口、正确性、单机与集群，也知道一轮结果应该怎样保存。真正开始测试时，仍然可能面对一个现实问题：这些原则怎样组织成一份可以执行的方案？ 一份好的测试方案不是参数清单，而是一份实验契约。它提前规定要回答的问题、唯一变量、固定条件、正确性门禁、运行矩阵和结论边界。这样，无论执行者是谁，最后得到的结

https://spricoder.github.io/benchmarking/benchmarking-15/2026-07-17T16:00:00.000Z2026-10-11T07:15:31.722Z

前十四篇文章分别解决了一个局部问题：怎样构造负载、读懂波动、进行公平比较、验证正确性、测试集群并保存结果。到了真正的数据库选型现场，这些方法必须被组织成一条决策链。 选型不是寻找一个脱离场景的“最快数据库”，而是判断哪个候选在当前业务约束下更合适。最高吞吐量可能伴随不可接受的 P99、资源成本或正确性问题；功能最丰富的产品也可能让部署和运

https://spricoder.github.io/benchmarking/benchmarking-09/2026-07-17T16:00:00.000Z2026-10-11T07:50:16.313Z

顺序写入通常是时序数据库最容易处理的路径：同一条序列持续写入递增的时间戳。网络抖动、异步链路或边缘缓存则可能让较早的时间戳晚于新数据抵达。 IoT Benchmark 的“乱序”并不是把一批记录随机打散后直接发送。阅读它的实现会发现：工具先根据一个 stepOffset 生成记录，再在生成 时间戳 时按模式改写这个 offset。理解这条

https://spricoder.github.io/benchmarking/benchmarking-10/2026-07-16T16:00:00.000Z2026-10-11T07:50:16.326Z

同一套数据库，可能同时提供 JDBC、REST、Session 等多种写入接口。它们看起来只是“换一条调用路径”，实际却可能经过不同的序列化方式、连接管理策略和批处理实现。 因此，比较接口并不是为了给它们排一个绝对名次，而是回答一个更具体的问题： 在同一份数据、同一种写入语义和同一套资源条件下，哪种接口更适合当前业务的目标？ 这一篇以 I

https://spricoder.github.io/benchmarking/benchmarking-07/2026-07-15T16:00:00.000Z2026-10-11T07:50:16.287Z

前面的文章 中，我们已经能够构造纯写和读写混合负载，也知道单次结果不能轻易代表系统能力。接下来就到了基准测试最容易产生误解、也最有实际价值的一步：比较。 比较两个数据库版本、两种写入接口，甚至两款数据库时，真正的问题不是“谁的吞吐量更大”，而是“这两个结果是否真的在回答同一个问题”。如果工作负载、硬件、配置或运行过程不同，数字再漂亮也无法

https://spricoder.github.io/benchmarking/benchmarking-08/2026-07-15T16:00:00.000Z2026-10-11T07:50:16.300Z

上一篇文章做完公平的性能对比后，很多人会立刻追问：把客户端并发和批大小调到多大，才能得到最好的性能？ 这个问题没有脱离场景的固定答案。并发过低，机器可能没有被充分利用；并发过高，客户端、网络或服务端会开始排队。批次太小，请求开销占比变大；批次太大，单次等待、内存占用和尾部延迟又可能升高。真正要找的不是一个“最大数字”，而是在当前业务约束下