Solana 数据索引的问题

在开始解决 Solana 数据索引的问题之前，我认为有必要讨论这些问题为何会存在。

为了理解这一点，让我们先了解 Solana。

Solana 因其低成本和快速交易而受到广泛关注 —— 现在其每秒平均交易量预计很快将达到 50,000–65,000。这意味着一旦 Solana 网络达到最大容量，它将能够生成高达 1GB/s 的数据，并在一年的时间内 -> 1GB/s * 365 天 = 31PB 的数据，每年！这些数据将分布在所有节点间，形成类似点对点的数据分发。

在云存储中，存储 1PB 数据的平均成本在 $75,000-$300,000 之间。因此，存储 31PB 数据，至少需要 $2.3M。这不仅是一个非常昂贵且低效的存储和维护方式，对于开发人员来说，遍历这些数据也是非常困难且耗时的。这就是数据索引存在的原因。

那么什么是数据索引？

想象一下，如果我告诉你我会藏一个紫色小石子，你必须在接下来的两个小时内找到它。现在想象一下，我把它藏在一栋有十层的公寓里，而每层楼有十几间房子，这个小石子可能藏在任何地方。尽管目标很简单：找到紫色小石子，实际上几乎是不可能的。这就是 Solana 开发人员在每次需要数据时所经历的。

解析原始 Solana 数据的复杂性给开发人员带来了重大挑战，尤其是考虑到网络的交易量已超过 1000 亿。在高峰期，Solana 每天处理约 5000 万笔交易，生成大量必须有效解码的数据。约 70% 的开发人员报告接口定义语言（IDLs）和实际链上数据之间存在差异，导致调试时间增加。此外，约 65% 的开发人员碰到解码二进制格式的问题，影响数据检索。这种低效会导致平均查询时间在拥堵时从 0.5 秒上升到多达 2 秒 —— 增加了 300% ，这显著降低了用户体验和应用性能。

但是，如果我给你一张地图，显示小石子藏在哪一层，你只需走过去找到它。这虽然大大简化了你的工作，但这仍然是最有效的方式吗？让我们讨论在 Solana 上数据索引所面临的问题。

数据索引的问题：

实时处理的数据量不仅造成了瓶颈，而且一个显著的问题是状态膨胀，整体状态大小由于持续的交易流入而可能大幅增长。尽管 Solana 擅长处理简单查询，但涉及多个账户或广泛历史数据的更复杂查询可能会变得臃肿。这通常导致开发人员依赖于链下解决方案，这可能会增加应用程序架构的复杂性。

为了单个查询聚合多个交易是低效的，这就是数据库显得重要的地方。许多在 Solana 上的应用程序经历高读写比率，有时超过 100:1。这种失衡给索引系统造成压力，特别是在高峰期，当许多用户同时查询数据时。因此，延迟可能成为一个重大问题。

Solana 的事件驱动架构使得实时更新索引的任务变得复杂。事件发生时，相应的数据需要立即进行索引，同时考虑到 Solana 提供的有限内置索引解决方案 —— 有效管理这些数据对于维护性能和最小化运营成本至关重要。

此外，维护完整且最新的所有状态转换记录变得日益复杂。尽管拥有原始区块数据，开发人员仍需不断监控并保持数据解析器、IDL 和区分符定义的最新状态 —— 如果没有这些，你可能会遇到数据的不一致或不准确的问题。

高数据存储需求

随着交易数量的指数增长，存储容量需要快速增加。当对存储空间的需求迅速增加时会发生什么？区块链生成的庞大数据量可能迅速填满磁盘空间，导致服务器达到最大容量或意外崩溃。

区块链数据变化非常动态。与静态数据不同，确保数据一致性并不容易。每当新增交易时，区块链数据提供者会对其进行索引。此外，由于数据量庞大，索引费用本身可能存在缺陷。

数据解析器或 IDL 中的任何错误都可能导致账户余额的错误表示、交易历史不正确，甚至智能合约交互失败。此外，历史数据中的空缺可能会导致验证先前状态变化的困难，因此也难以确保数据的完整性。

Google Big Query：

在 Solana 开发的早期，RPC 节点运行在 Google Cloud 上。云托管为专注于迭代新代码库的开发人员提供了便利和简洁。Solana 生成的账本数据比单个计算实例更难以轻松存储，因此开发人员选择了 Google BigTable 进行账本存储。它以每次查询处理多达 1PB 数据的能力而闻名，通常能在 10 秒以内为大数据集完成任务。它的无服务器架构能够无缝扩展，非常适合数据需求变化的企业。

然而，它的定价模型大约是每查询 1TB 要 $5。1PB 包含 1000TB，因此 41000 = 4000TB 的数据需要查询。这意味着 4000TB$5 = $20,000。想象一下，每次你需要运行一次查询时都要支付 2 万美元！

Triton 的 Old Faithful：

Old Faithful 的诞生是因为 Triton 的联合创始人 Linus Kendall 和来自 Fire Dancer 团队的知名工程师 Richard Patel 讨论了访问 Solana 数据历史的困难，并希望找到在规模上实现 Solana 归档历史的方法。

解决方案以 IPFS（InterPlanetary File System）和 Filecoin 的方式出现。他们一致认为，内容可寻址归档（"CAR"）文件将提供一种可扩展的文件格式，可以长期存储在各种存储平台上。这是因为你可以将 100GB 的数据存储在 CAR 文件中，但在检索时可以选择仅检索其中的某些部分，而不必检索完整的 100GB，而且 CAR 文件与 S3 兼容。因此，Old Faithful 项目的目标是将整个 Solana 归档复制到社区可访问的 CAR 文件中。

状态存储问题

Solana 的账户基模型提出了一个关键的数据存储挑战。每个程序状态通常分布在多个账户中，每年生成约 5-7PB（来源：Dexter Labs）的状态数据。光是账本每年就增长 100TB。这使得全面的状态索引在技术上复杂且在经济上不可持续 —— 即使在规模上，成本也超过潜在回报。

挑战还不仅仅在原始存储。历史状态重建需要在每个插槽处理账户更新，处理可能达到 MB 规模的压缩 ZK 账户，并管理截断的 RPC 日志。传统度量数据库难以应对 Solana 的高基数（数百万个独特的钱包标签），而分析数据库的实时查询速度又过慢。即使是跟踪历史代币余额这样的简单操作，也需要复杂的基础设施以实现低于 20ms 的响应时间，同时在程序边界之间保持状态准确性。

使用基于 WASM 的索引器的问题

使用 WASM 的另一个显著缺点是它缺乏对实时数据同步和流媒体的内在支持。例如，如果你正在构建一个索引器，用于跟踪或评估过去一年的交易表现，单靠 WASM 可能会严重限制你高效处理实时数据流的能力。

WASM 主要在静态执行模型中运行，这意味着任何更新都需要明确重执行编译的代码。这本质上引入了延迟，使得难以对实时事件（例如价格变化或成交量激增）做出反应。在高频交易应用中，微秒至关重要，这种延迟可能导致错失机会和次优的决策。

再加上 Triton 发现，在 Epoch 208 中，约有 500 个插槽的仓库账本备份文件丢失。BigTable 数据库包含所有插槽的交易，但仓库文件缺失。这进一步坚定了他们对需要更好索引解决方案和构建 Old Faithful 的信念。让我们讨论在 Solana 上进行区块链数据仓储的挑战。

由于 ZK 压缩导致的索引挑战

虽然 ZK 压缩大幅降低了 Solana 的状态存储成本（高达 5000 倍），但它引入了显著的索引复杂性。压缩的账户更新可以超过数 MB，但 RPC 节点在 1KB 后截断日志，这使得索引器的状态重建变得困难。当解析历史数据时，压缩账户需要特殊参数以进行完全日志捕获，而这些信息并不广泛提供给索引服务。

这种情况创造了一个悖论：压缩解决了存储成本问题，但使数据访问复杂化。索引器必须处理可变大小的状态更新，管理部分日志数据，并为压缩账户实施特殊的解析逻辑。传统的索引方法在这里失败了——如果没有访问完整的 ZK 证明和验证参数，无法重建准确的状态历史。这需要新的索引架构能够高效处理并验证压缩的状态转移，同时保持历史数据的完整性。

数据流媒体方面的问题

通过 Geyser gRPC 管理数十万并发账户订阅，就像试图驯服一场飓风。尽管 gRPC 层相当稳健，但在如此大规模下却显得吃力。当订阅数量增加时，系统开始崩溃 —— 延迟飙升，同步错误增多，用户不得不面对零散或滞后的数据。这一挑战在处理跨不断变化的程序账户的实时流时变得尤为艰巨。尽管 Solana Geyser 插件本质上可以进一步优化以处理大量分布式负载进行账户更新，但目前提供这种高性能需求的定制功能的提供商并不多。谈谈以低于 1 秒的延迟流媒体 1M 个账户更新。

重新思考 Solana 数据基础设施以支持高性能操作

无论你是在构建需要微秒级状态访问的 AI 交易代理，维护需要实时程序账户状态数据的高频交易系统，还是开发需求高效历史数据遍历的分析平台，当前解决方案都迫使我们在速度、成本和可靠性之间做出不舒适的权衡。

进入 Astralane。我们构建了一种新型数据基础设施，让你可以手动定制所需的管道：

• 在几秒钟内遍历 PB 级历史数据（与多种提供商如 Triton Old Faithful 文件、Dexter Labs Hadoop 集成等）
• 以毫秒级精确度流媒体传输实时数据（与各种数据解析引擎如 Top Ledger 集成）
• 为你的索引管道手动构建 SDK，实现外部数据增强（例如：价格数据、交易量等）
• 根据实际使用线性扩展存储成本（热使用：Postgres，冷使用：Clickhouse）

我们的系统结合了经过实战检验的技术（Kafka、Clickhouse、gRPC）与专门为区块链数据挑战量身定制的组件。结果？数据管道感觉像是来自未来。

但这仅仅是个开始。想看看我们如何重塑 Solana 数据基础设施？寻求为你在 Solana 上的 AI 代理获取更多更好的数据？想知道我们如何对其他 SVM 链进行索引？请继续关注我们下周的技术深度探讨。

准备好为你的数据管道提速了吗？联系我：hi@astralane.io

• 原文链接： medium.com/@astralaneio/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～