3. 长安链数据管理
3.1. 数据库的选型与配置
3.1.1. 数据库选型
长安链数据库划分是按照存储数据的功能和特性分为以下几种数据库：
BlockDB 存储区块与交易
StateDB 存储最新的世界状态
HistoryDB 存储状态变更历史，账户交易历史和合约调用历史，是可选的
ResultDB 存储合约执行的读写集，是可选的
ContractEventDB 存储合约事件日志数据库，是可选的
在数据持久化存储上，长安链支持常用的数据库来存储账本数据，如LevelDB、BadgerDB、TikvDB、MySQL等数据库，业务可选择其中任意一种数据库来部署区块链，每种数据库的简介如下：
LevelDB，默认采用的数据库引擎，LevelDB作为一款嵌入式KV数据库，默认集成在长安链节点中，无需部署，性能也相对关系型数据要更好。
BadgerDB，作为另一种形式的KV单机数据库的实现，也是嵌入式KV数据库，性能在写入value比较大时比LevelDB更高,但是读性能可能差于LevelDB
TikvDB，作为KVDB的横向扩容版本，需要单独启动tikv服务，底层使用rocksdb,性能更高。tikv部署流程
MySQL， (provider为：chainmaker.yml -> storage -> blockdb_config/statedb_config/resultdb/… -> provider)
采用关系型数据库的方式(provider: sql)，支持schema和富查询，性能较KV数据库低，目前关系型数据库与区块链的状态数据并不能很好的结合，导致很少有区块链采用关系型数据库作为状态数据库。原因主要有两点：1.区块链需要对智能合约所读写的状态数据做严格的控制和校验，而SQL语句相对区块链来说过于灵活，难以控制；2.需要提前创建库表和索引，需要针对不同的智能合约创建不同的数据库表结构，不够灵活。目前长安链支持MySQL存储引擎，在系统数据如Block DB上支持区块元信息、交易信息的关系型语义，状态数据库支持kv的方式和智能合约编写SQL语句方式读写状态数据(world state)。
采用模拟非关系型数据库的方式(provider: sqlkv)，类似KV数据库的方式组织数据存储到mysql中，适合搭配BFDB存储模式使用(用户数据量偏大时可将mysql数据库替换成TDSQL等分布式存储数据库)(推荐使用)。
长安链的存储分为RawDB(非文件存储)和BFDB(文件存储)两种方式 （详见: 9.6.1.1 数据库存储模式）
RawDB：RawDB是指将数据完全存储在关系或非关系型数据库中RawDB的优点是数据存储在数据库中
BFDB：BFDB是指将区块数据存放在”区块文件存储”中，然后将”区块文件存储”的数据索引信息存放在区块数据库、结果据库，其他业务数据库(状态数据库、历史数据库、事件数据库)与RawDB的数据一样
存储方式选型:
| 节点数据存储类型 | 别称 | 配置方式 | chainmaker-go支持版本 | blockdb/resultdb/statedb/historydb等的provider | 是否推荐 |
|---|---|---|---|---|---|
| RawDB | 非文件存储 | disable_block_file_db:true | >= v1.2.4 | leveldb/badgerdb/tikvdb/sql | 否 |
| BFDB | 文件存储 | disable_block_file_db:false | >= v2.2.0 | leveldb/badgerdb/tikvdb/sqlkv | 是 |
注:
“长安链节点” BFDB归档方案不支持采用sql方式（provider: sql）存储的节点数据，用户可以使用sqlkv（provider: sqlkv）方式替代
采用sql方式（provider: sql）存储的节点额外支持在链上部署支持sql的合约，但该sql合约性能偏低，不推荐使用
表格中的provider为：chainmaker.yml -> storage -> blockdb_config/statedb_config/… -> provider
3.1.2. 数据库配置
长安链的数据库配置在chainmaker.yml中，具体详见: 9.6.2 配置说明）
3.1.3. 数据库选择建议
在数据库选择时，需要根据自身业务类型和数据量以及运营模式而定
在区块链数据不到1T的情况下，建议使用LevelDB作为默认的数据库；(provider:leveldb)
如果状态数据中存储了大量上KB级别的Value，可以将BadgerDB作为状态数据库的底层；(provider:badgerdb)
如果预期数据量上T甚至更多且具备数据库自行运维能力，则建议采用TiKV作为数据库底层；(provider:tikvdb)
如果预期数据量上T甚至更多但是不具备数据库自行运维能力，则建议采用TDSQL等常见的分布式云关系数据库作为数据库底层；(provider:sqlkv)
如果支持的业务复杂，合约需要大量富查询和各个字段的索引查询，汇总等，建议采用MySQL作为状态数据库底层，并且使用SQL语句来编写智能合约。(但该合约性能偏低，不建议使用)(provider:sql)
在选择了不同的数据库作为provider后，其后续的子配置项就是这个数据库的参数配置，比如provider: leveldb，那么后续子配置项就是leveldb_config，其中store_path是最重要的配置参数，其他选型可以采用默认值即可，除非您非常明确这个选项对数据库的影响。
如果出于性能的考虑，可以关闭HistoryDB、ResultDB和ContractEventDB，这些数据库可以帮忙开发者查询更详细的记录，用于区块链浏览器或者数据分析的情况。
3.2. 数据归档&恢复功能
节点在长时间运行后，会积累大量数据，这些数据不常访问，但不能丢弃，因此需要长安链需要提供数据归档功能。具体详见: 9.7 链上数据归档）
3.3. 数据重建(rebuild_dbs)
当因为操作不当，恶意篡改等原因，导致状态数据库的数据与区块链历史数据或其他节点不一致，那么就意味着状态数据库损坏，需要利用账本数据进行数据重建。具体详见: 9.8 数据恢复）