Skip to main content
blockdb 负责存取。日常写索引管道大多数时候只需要 Pipeline,这一页给需要直接操作数据层、或者要绕开 Pipeline 做精细控制的场景。

Table —— 普通表

不带区块语义的读写接口,高吞吐。建表本身走控制台页面,SDK 不提供建表 API,只能引用已经存在的表:

条件写入(幂等)

upsert_rows 支持 condition,只在满足条件时才覆盖已有行——常用于”后到的旧数据不应该覆盖已有的新值”这类幂等写入:

BlockTable —— Block Event / Block State 表

按区块高度读写,读取自动限制在 height <= 目标高度,不会读到还没确认的数据。
平台会为每张 Block 表自动维护几张辅助表: 排查数据完整性、判断有没有写完,直接看 _height 就够了——不需要在代码里操作它。

TimeTable —— 按时间分桶

按固定时间桶(分钟级)组织的数据,写入时间自动向后取整到整分钟:
时间统一按 RFC3339 字符串处理:写入时可以传比较随意的格式(如 "2026-05-18 17:04:35",不带时区按 UTC 理解),读回来的字段固定是 ...Z 形态。

Subscribe —— 订阅新块

如果你用的是 Pipelineupdate(),订阅已经被包好了,通常不需要直接用 Subscribe
每次一张表成功写入一个新块,平台会产出一个写入事件。Subscribe.listen() 是无限生成器,逐个 yield (表名, Block),断线自动重连:
只有逐块写入(upsert_block)才会发订阅事件,批量写入(bundle / 回填)按设计不发事件。 上游用回填补的数据,下游订阅是收不到通知的,需要下游也主动发起一次回填。
Subscribe 只能订阅 Block Event / Block State 表,Normal 表没有订阅能力。

Aligned —— 多表高度对齐

转换逻辑经常需要点查另一张表的当前状态。如果那张表还没处理到当前高度,查到的就是过期数据——Aligned 是用来解决这个问题的状态机。
两种角色: 只有全部 trigger 表在该高度 ready、且全部 depends 表的共识高度都 ≥ 该高度,这个高度才会被放行,且每个高度只放行一次。一张表可以同时是 trigger 又是 depends——两个位置都要写,写一边不会顶替另一边(需要 blockdb-py >= v0.1.23)。
共识高度 = 表的 _height 子表里第一个连续区间的右边界(不要求从 0 开始);一行都还没有时取 start_height - 1。这也是为什么驱动逻辑不能跳过高度——跳过的高度会在 _height 里留下一个洞,后面所有更高的高度都会被卡住。
如果用的是 Pipeline,把依赖表传给 depends 参数即可,对齐由它自动处理,不需要手写 Aligned

scan vs filter_rows