共计 2802 个字符，预计需要花费 8 分钟才能阅读完成。
导读
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 数据服务。
目前，NFTScan 数据库收录了 100 万 + 个 NFT 合约地址，7 亿多枚 NFT 资产数据，17 亿多链 NFT 链上交互记录。并且这个数字还在以每日 3000 个 NFT 合约地址和 200 万个 NFT 资产的速度在递增。从上述数据能够看出，NFTScan 有着增量大，活跃度高两大特点。这样的业务特点决定了咱们对数据库技术架构要求极高，须要具备全面、实时、高效等个性，并满足高并发、低延时等需要。抉择一个适合的，能满足业务需要的数据存储体系对 NFTScan 来说至关重要。
以前的 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 执行打算。