前言：NEO节点是一个功能非常复杂的项目，它包含了P2P网络，RPC接口，数据库读写，执行智能合约等功能。不同的功能相互协作，才能确保节点及时同步数据，并且提供准确的数据给使用者。节点通过P2P网络，请求和获得块数据，并将之验证分析存入leveldb数据库。当此节点正确同步到链上最新高度时，就意味着节点保存了一份链上数据可以供用户使用。
作为开发者，对于节点的使用需求第一个是通过节点发送交易上链，第二个是通过RPC服务获取节点中的数据或者模拟执行合约。在实际使用场景中，获取数据或模拟执行合约的需求会更大一点，单个节点有时会扛不住请求的压力。因为RPC服务和数据库存在一个进程中，所以不存在开启多个数据库负载均衡提供数据给接口服务器的情况，也不存在启动多个接口服务器从同一个数据库中获取数据的情况。
我们在开发一些dapp时，会遇到节点RPC请求的瓶颈。部署多个节点负载均衡时，由于每个节点拿到最新的块数据并存入leveldb的时间不一样，很容易造成在某一个时间点，访问不同的节点拿最新的交易数据有不同的返回。基于此，我们做了一个设想，将数据库功能从节点中独立出来，将数据库做成网络数据库（如果需要部署多个数据库则从同一个源头同步，保证数据库内数据的统一）。并将RPC服务和执行智能合约的虚拟机构造成一个轻型节点提供接口服务。简单的来说就是将Neo节点的存储部分改为网络存储，并且可以通过轻型节点直接找网络数据库执行InvokeScript。
项目介绍
由于数据处理有事务化的要求，因此需要的数据库必须要有快照的功能。Neo节点使用的LevelDB因为采用LSM存储方式，提供读取的快照非常容易，代价也很小。而关系型数据库支持事物化的程度就差了一些，我们本来想使用的mongodb也因为读快照功能的限制被舍弃。最终，我们选择了以rocksdb（rocksdb是facebook基于leveldb改进的一个版本，读写性能都有明显的提升)为基础开发本地数据库，并加上网络层实现一个网络数据库。
节点在获取数据存入leveldb的时候，是有一个分类的。存储块数聚，utxo数据，合约数据等不同的数据时会追加不同的修正前缀，以示区分。这个是使用leveldb的一个自然需求，kv数据库是一个字典，我们存进去的东西，从逻辑上是分为诺干个字典的。现在我们将这个需求直接在数据库层面提供，增加了一个表的概念。用户在读写时，就可以更精准的读取某张表内某个key的值。此外，数据库的存储还模仿了区块链的结构，在每次写操作的时候都会加入一个高度，模拟块的概念，方便和区块链中的块高度对应。这样接口服务器就可以较容易的用块高度来做索引，获取对应的快照执行数据。
我们将节点分析存储每个块数据进入leveldb的操作都视为一个集合，可以确认的是不同的leveldb执行这个集合都必然能存储进相同的数据。基于此，我们将网络数据库的读写分离。将主节点每个块存储进leveldb的操作都记录下来，网络数据库只要获取这些块的操作集，自己执行一遍就同步到了数据。有了这些网络数据库之后，我们的轻型节点就可以从这些数据库中获取数据并返回给调用者。
目前这个项目还是属于一个探索研发阶段，这里附上这个项目的github地址：
https://github.com/NewEconoLab/NEL.LightDB
下图是项目中包含的所有的工程，NEL.Peer.*是网络层；SDK是为了方便客户端接入而包装的方法；SimpleDB是没有附加网络层的本地数据库；API是实现了简单RPC接口的轻型节点；Server是网络数据库。
流程演示 我们首先编译Server项目，打开config.json进行配置。
port是访问数据库的端口; bindAddress是允许访问的地址; server_storage_path是数据库数据存放于本地的路径;
Conn_Track,DataBase_Track,Coll_Track 这三个是mongodb的链接和库名，我们暂时将每个块应该怎么操作数据库的集合存放在了我们NEL的mongodb中进行管理，目前开放性不是很高。暂时这个样子，后续可能会将这些操作集用另一种方式提供出来，方便使用。
配置完成后，启动
网络数据库正在快速的恢复数据。
此时再编译API工程，配置config.json
port是访问api端口，bindAddress是Api允许访问的ip；dbServerPort是数据库访问的端口，dbServerAddress是数据库所在的ip；dbServerPath是数据库开启的actor的路径。（确保链接的数据库已经同步到最近的数据高度）
启动api服务
此时我们借助PostMan工具来通过api工程获取数据（分别附上获取块数据，和模拟执行合约的例子）
相关文章
头条焦点
精彩导读