NEL發佈NEO Key-Value數據庫LightDB 轉

項目組成

這個項目叫做LightDB

由三個部分構成

Lightdb.lib 是對rocksdb做了一層封裝，主要的修改是追加了保存的數據類型，和表的概念

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

Lightdb.server 就是一個遠程數據庫啦，Lightdb的服務器版本

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

Lightdb.SDK 是方便客戶端接入LightdbServer 提供的，目前只提供了C#版本實現，後續還會提供Typescript版本實現，通訊協議比較簡單，任意支持websocket的方案都可以連接。

https://github.com/NewEconoLab/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性能是怎樣的，還是需要測試確認的

項目使用方法