源自于NEO的KeyValue 数据库面世啦

虽然想把标题取得大一点，但终究不是什么太大不了的工作，还是安分守己的开始介绍吧。

项目组成

这个项目叫做LightDB

由三个部分构成

Lightdb.lib 是对rocksdb做了一层封装，主要的修改是追加了保存的数据类型，和表的概念

https://github.com/lightszero/lightdb.lib

Lightdb.server 就是一个远程数据库啦，Lightdb的服务器版本

https://github.com/lightszero/lightdb.server

Lightdb.SDK 是方便客户端接入LightdbServer 提供的，目前只提供了C#版本实现，后续还会提供Typescript版本实现，通讯协议比较简单，任意支持websocket的方案都可以连接。

https://github.com/lightszero/lightdb.sdk

项目特点

要说项目特点的话，

一、追加了数据类型和表概念。

二、有服务器，采用websocket通讯，对js友好

三、数据的存储以taskblock为单位，方便数据库互相验证和同步

其实最重要的特点还有一个关于读的快照snapshot。快照的需求来源是数据处理的事务化，或者说一批操作的原子性要求。
传统数据库一定程度支持事务化，而KeyValue数据库这边支持事务化的程度就更差一些。
而NEO使用的嵌入式数据库，LevelDB因为采用LSM存储方式，提供读取的snapshot 非常容易，代价也小。
这也就造成了在NEO的实现中，存储部分对Snapshot的依赖非常强。

创立这个项目的初衷，有一部分是要改造NEO的存储部分为网络存储，并且可以用轻型节点直接找网络数据库去执行InvokeScript
也就是把Neo的一个节点一个进程的模式，改造为一个节点一个集群。
完成这个目标的基础，就是这个网络数据库需要一个类似的很低成本的读snapshot支持。
所以我选择了rocksdb作为这个基础，rocksdb是facebook 基于leveldb魔改的一个改进版本。

那么为什么要追加数据类型和表的概念？因为leveldb使用中存储的东西都是byte[],而很多时候我们使用neo中得到的byte[] 都不知道是什么东西，要靠相应的约定。
我觉得这个很不方便，所以我们存储的单位不是byte[] 而是一个结构体 DBValue,他可以描述自己是什么数据类型，整数，string，byte[],bigint,小数，等等。
这个结构体里面还预留了给每一个值附加信息的功能，也记录了这个值最终修改的时间戳（存储高度）
至于表就更好理解了，这是使用leveldb的一个自然需求，keyvalue数据库是一个字典，可是我们存进去的东西，从逻辑上是分为几个字典的，交易字典，utxo字典，等等等。
我们只是把这个分字典的自然需求，在数据库层面直接提供了。

然后是网络层，选择了websocket作为通讯方法，完全是基于将来是网页的天下的考虑。因为存储这个功能被独立出来，甚至可以写一条链，他完全是在网页中运行的。
当然目前还没有想那么多，但可以预见到越来越多的业务会在网络中运行，因为这个数据库的出现，nel目前的至少50%的查询需求可以不通过后台服务器，js直接完成。
比如nep5资产的blanceof，比如交易UTXO数据的确认。

其三，数据库的存储模仿了区块链的结构，以taskblock为单位，首尾相接。毕竟一开始这个项目的名字就叫lightchain.
后来一想，这个名字有点烂大街了，数据库还是老老实实的叫DB吧
为什么要以taskblock为单位呢，因为便于同步。数据库读写分离是性能扩展的必然走向，而把每一个操作记录下来，从数据库只要从主数据库取得每一个block，自己执行一遍，就同步完了。
对了还有一点也很像NEO区块链，我们的写入权限控制不是用密码，而是用私钥，而且还是和NEO完全兼容的私钥

最后，还有一个很重要的功能，checkpoint，这也是rocksdb提供的礼物，可以快速的在本地产生一个新的数据库副本。这样我们做链上数据快照的手段就更多了，传统手段是用爬虫爬取要快照的数据，爬到指定高度，停。现在又多了一个手段，约定时间快照，到时间了，啪，一个checkpoint，整个数据库都备份下来了。

不过当数据量达到G的级别，这个checkpoint性能是怎样的，还是需要测试确认的