导读
NFTScan 是一家多链 NFT 数据基础设施服务商，为 Web3 用户提供高效简洁的 NFT 资产搜索查询服务，为 Web3 开发者和新一代金融科技公司提供专业的 NFT API 数据服务。
TiDB 作为一种分布式 HTAP 数据库，可以同时满足海量数据存储和高并发读写的需求， 在高可用性、分布式架构、ACID 事务支持和实时多维查询等方面，都具备优势，适配 Web3 行业的场景需求。
NFTScan 在快速发展中发现传统的 MySQL 数据库无法满足业务的快速增长，而 TiDB 能够提供毫秒级多维查询的能力，为 NFTScan 提供了更高效的服务，于是选择 TiDB 作为核心数据架构。本文介绍了 NFTScan 数据架构面临的挑战、选型的思考、迁移至 TiDB 的过程以及迁移后获得的收益。一体化的 HTAP 架构能够替代 MySQL Elasticsearch 的能力，成为支撑在线数据服务的最佳选择。
NFTScan 成立于 2021 年 4 月，是一个多链 NFT 数据基础设施服务商，截止到 2023 年 1 月份，我们已经支持了 11 条区块链网络，包括 Ethereum、Solana、BNBChain、Moonbeam、Polygon、Arbitrum、Optimism、Avalanche、Fantom、Cronos、PlatON 网络。
NFTScan 旗下有 2 个核心业务：NFTScan.COM 多链 NFT 数据浏览器平台和 NFTScan OpenAPI 开发者平台。NFTScan 主要为 Web3 用户提供高效简洁的 NFT 资产搜索查询服务，以及为 Web3 开发者和新一代金融科技公司提供专业的 NFT API 数据服务。
a.png目前，NFTScan 数据库收录了 100 万 个 NFT 合约地址，7 亿多枚 NFT 资产数据，17 亿多链 NFT 链上交互记录。并且这个数字还在以每日 3000 个 NFT 合约地址和 200 万个 NFT 资产的速度在递增。从上述数据可以看出，NFTScan 有着增量大，活跃度高两大特点。这样的业务特点决定了我们对数据库技术架构要求极高，需要具备全面、实时、高效等特性，并满足高并发、低延时等需求。选择一个合适的，能满足业务需求的数据存储体系对 NFTScan 来说至关重要。
b.png以前的 MySQL 解决方案的挑战
此前，NFTScan 使用 Amazon Web Services (AWS) 上的 MySQL 和 Elasticsearch 作为其核心数据库解决方案。MySQL 存储了所有业务数据，包括来自 B 端和 C 端用户的用于分析和处理的数据。其中，NFT 的交易记录和资产记录是核心的业务数据模型，B 端和 C 端的查询也大部分是围绕这两类核心数据展开的。由于 NFT 数据每天都在持续增长，多维度查询会存在一些分布不均匀的现象，NFTScan 将 NFT 交易和资产相关数据以全索引方式同步到 Elasticsearch，以近乎全字段索引的方式响应多维度 NFT 数据查询，从而解决 MySQL 在多维度检索海量数据方面的性能与效率瓶颈。
该解决方案在使用半年后， 我们逐渐发现其无法满足业务的快速增长，存在以下缺陷：
可扩展性差，存储和维护成本高。每天新的区块链数据量急剧增加，但 MySQL 无法自动横向扩展以应对不断增加的工作负载。我们不得不手动对表进行分片并新增 MySQL 的主备集群，来分摊和均衡 CPU 和内存资源的使用，这大大增加了存储和维护成本。 随着成本的增加，使用率下降。Elasticsearch 部署在 AWS 上，由于 AWS 原生集群配置的限制，我们不得不增加更多的 Elasticsearch 高配置数据节点来提供在线查询服务，这导致成本上升和使用率降低。 反复出现的精度错误。Elasticsearch 数据库更多的是为搜索而设计的，而不是为计算设计，所以在聚合计算中存在精度误差。
为什么选择 TiDB？
经过近一个月的调研和测试，我们最终选择了 TiDB 来作为核心数据架构，替代原有数据库系统。NFTScan 研发团队在调研中选择 TiDB 主要有以下几点考量因素：
高度兼容 MySQL：TiDB 在传输协议和 SQL 语法等方面与 MySQL 高度兼容，NFTScan 可以轻松地将数据迁移到 TiDB，MySQL 兼容性大大减少了研发团队使用新数据库的学习成本、时间和精力，同时也能加速数据库架构的迁移工作； 弹性伸缩：TiDB 采用计算和存储分离的分布式架构以及底层分布式存储数据的设计机制，NFTScan 可以根据读写流量的实时变化灵活伸缩计算存储资源，最大限度地提高了资源使用率，并大幅降低了成本； 一体化 HTAP 架构：TiDB 的 HTAP 能力可以同时处理事务和分析工作负载，一套数据库即可满足事务型数据库和分析型数据库的需求，不仅完美地满足了 NFTScan 不断增长的业务需求，还降低了整体运营成本； 高可用性：TiDB 本身的数据副本同步机制和内置的灾备方案，保证了整体数据库服务的高可用性。
迁移方案
经过两个月的时间，我们完成了将底层数据库系统全部切换到 TiDB 的工作，通过部署 2 台 TiDB 服务器、9 台 TiKV 服务器和 2 台 TiFlash 服务器，并在同一 region 下，跨三个可用区（AZ) 进行部署，保证了整体架构的高可用性。
截至 2022 年 11 月，NFTScan 的 TiDB 数据库存储了大约 6TB 的业务数据，QPS 达到 5000，平均查询时长 40ms，各种应用在 TiDB 上运行稳定。
流畅的迁移体验
在整个迁移过程中，我们对 TiDB 的性能与数据迁移的流畅性印象深刻。
TiDB 提供了 Dumpling、TiDB Data Migration (DM) 等一系列数据同步套件，帮助 NFTScan 将历史数据从 MySQL 迁移到 TiDB。比如 NFTScan 的一些业务数据是不能直接迁移到 TiDB 的，必须在迁移前先进行调整。在这种情况下，TiDB 的同步工具可以并发写入大量数据。在解析存储实时 NFT 数据时，执行效率较之前的存储方案提升了约 30%。
同时，TiDB 的 online schema update （在线 schema 更新）设计，使得 NFTScan 可以在迁移过程中进行异步更改字段和异步添加索引等数据定义语言 (DDL) 操作，而不会阻塞整个表的读写，这大大提高了业务逻辑调整时数据模式的灵活性。迁移完成后，NFTScan 对 B 端、C 端各类应用程序的数据查询进行了改造，经过充分调优和测试后，逐步将生产环境的应用全部切换到 TiDB。
使用收益
TiDB 支持多维实时查询，查询时间短。TiDB 完美地满足了 NFTScan 高吞吐量和低延迟的核心要求。以业务端的 API 服务为例，平均查询时间从 10-100 毫秒下降到 10 毫秒或更少。即使处理 1,000 QPS，这样的查询速度也能保持稳定。 TiDB 的列式存储引擎 TiFlash ，可以高效地处理分析工作负载。例如，在对某张具有数亿行的表执行复杂查询时，可以在几秒钟内获得结果。 TiDB 的智能 SQL 优化器可以根据数据的分布情况选择最具性价比的数据查询执行计划，让开发者可以灵活调整和优化 SQL 执行计划。
