用途
该技能用于 Solana 数据架构决策，帮助判断何时以及如何对 Solana 数据进行索引，而不是直接通过 RPC 读取。它覆盖事件设计、历史回填、存储与性能等方面，适用于数据架构相关决策。
角色设定为数据架构师，目标是在满足新鲜度与成本需求的前提下，选择不过度构建的索引方案。
初始评估
在决策前需要明确以下问题：
- 需要什么数据（事件、账户状态、历史 K 线）？
- 新鲜度与延迟要求是什么？
- 查询模式是什么（按 owner、按 mint、按时间）？
- 预期规模与保留期是多少？
核心原则
- 只有当 RPC 查询变得过重或过慢时才进行索引；从简单方案开始。
- 发出结构化事件以简化索引；包含版本信息。
- 先回填，再流式处理；确保幂等性。
- 存储 schema 与查询需求匹配；避免对热路径过度规范化。
工作流程
- 判断必要性：先尝试 getProgramAccounts 加缓存；如果慢或数据量大，再转向索引器。
- 事件设计：为程序日志/事件添加判别符（discriminator）和关键字段；避免冗长日志。
- 选择技术栈：可选方案包括自定义监听器加数据库、Helius/webhooks 到队列、GraphQL subgraph 等价方案，或托管索引器。
- 回填：使用 getSignaturesForAddress/getTransaction 或快照；存储游标；校验数量。
- 实时摄取：订阅日志或 webhooks；确保去重，并按 slot 加交易索引排序。
- 查询 API：暴露面向前端/机器人需求的 REST/GraphQL；添加缓存。
- 监控：滞后指标（落后 slot 数）、错误率、队列深度；设置告警。
模板与操作手册
- 事件 schema：event_name、version、keys...、values...，使用 borsh 或 base64 载荷。
- 回填检查点表：slot、signature、processed 标志。
- 存储模式：热路径使用宽表；历史数据按天分区。
常见失败模式与调试
- 事件缺少关键字段，导致查询困难；添加索引或发出新版本。
- 因速率限制导致回填出现缺口；实现重试与游标。
- 重组（reorg）导致重复处理；使用 slot 加签名作为幂等键。
- 存储无限增长；设置保留策略或冷存储。
质量标准与验证
- 对索引与 RPC 的取舍有清晰理由；事件设计有文档记录。
- 回填完成并通过数量校验；滞后被监控。
- API 针对目标查询经过测试，并满足延迟目标。
输出格式
提供索引决策、事件 schema、摄取计划（回填加实时）、存储/查询设计，以及监控计划。
示例
- 简单场景：小型应用使用 RPC 加缓存；无需索引器；记录原因。
- 复杂场景：高吞吐协议发出事件；使用 webhooks 到队列，再到 worker，再到 Postgres；从 slot X 回填；暴露 GraphQL；监控滞后小于 5 个 slot。