AppBoxFuture(二): Say goodbye to sql!

  信息管理類應用系統離不開關係數據存儲，目前你們基本都使用的是傳統的數據庫如MySql、Postgres等。做者從事信息化建設十多年，我的認爲傳統的數據庫存在如下的問題：

擴展問題：

  系統數據的不斷增加是個繞不過去的坎，傳統數據庫的存儲結構一般都基於B+tree，單表數據在必定範圍內沒有問題，但數據量增大到必定程度後性能便會不斷降低，只能經過分庫分表的方式或升級硬件來解決，隨之而來的是提升了應用軟件的開發難度及相應的硬件成本。做者曾建設過一個北斗監控平臺，其中單表記錄10多億，通過優化雖能實行秒級查詢一天軌跡，但備份及按期刪除歷史數據很是慢且影響在線操做，後來只能手工實現了一套文件存儲來解決（那個時代尚未NoSql)。

可用性問題：

  傳統數據庫只能使用主從的方式來保障可用性，運維較複雜。做者曾經碰到過一次閃電致使機房（等保三級）內一臺數據庫用SAN存儲的電源背板燒壞，雖這臺存儲冗餘電源，RAID10通通沒用，致使系統停用兩天。

開發人員問題：

  因爲開發人員對sql的熟悉程度不一樣，常常能碰到寫的很爛的sql語句。另外若是使用ORM，則ORM->Sql字符串->網絡傳輸->Sql引擎分析->執行->網絡傳輸->ORM存在較大性能損耗。做者的一個朋友在一家公司作運維，他說他公司的開發只管程序可否跑通，從無論sql優化問題，致使系統很慢，出了問題全丟給運維處理。

  因爲存在上述問題，做者一直在尋找新的適合於信息管理類系統的存儲技術，既能簡單的隨需擴展，又能保障高可用高性能，還能兼顧大數據存儲與分析，最好建設與運維的成本儘量的低（做者接觸的都是中小微企業）。所以前後學習了互聯網企業經常使用的NewSql（TiDB, Cockroach）、NoSql(Cassandra, Kudu, ES等）技術，但願能將這些技術應用於傳統的信息管理系統的建設。但隨着進一步的深刻了解，這些技術都存在這樣或那樣的問題，好比或架構複雜問題，或事務一致性問題，或性能問題（如併發扣減庫存）。

  在學習了上述技術的原理後，做者就想可否從新實現一套適合於上述要求的分佈式數據庫，直接集成至應用框架內，從而能夠：

簡化應用系統架構

整個應用系統由一個或多個節點組成，每一個節點負責處理用戶請求及存儲，隨需擴展節點。

表分區

大表支持定義爲按分區鍵分區存儲（相似於Cassandra的PartionKey），同時支持分區索引及全局索引，以避免熱點問題，另外刪除整個分區對性能的影響較小。

強一致性事務

基於Raft及2PC支持分佈式事務（相似於TiDB, Cockroach)。

簡單的Api

支持框架的實體模型與存儲結構的直接映射，避免sql字符串轉換與分析損耗，另因爲直接進程內訪問存儲引擎，可減小網絡通訊開銷。
舉個簡單的保存例子：

var pos = new Entities.VehiclePosition(vehicleId); //車輛位置，根據id分區
pos.LAT = 32.22223;
pos.LNG = 100.2123;
await EntityStore.SaveAsync(pos);

再舉個簡單的表掃描查詢例子，支持其餘查詢方式如索引掃描，聚合掃描等：

var q = new TableScan<Entities.VehiclePosition>();
q.Partions(p => p.VehicleId == vehicleId); //指定分區條件
q.Filter(t => t.CreateTime >= startday && t.CreateTime < endday); //指定分區內記錄過濾條件
var list = await q.ToListAsync(t => new {t.Id, t.LAT, t.LNG}); //選擇指定列

小Tip:

1. 在實現表掃描及聚合掃描時，做者利用C#的Emit直接生成條件過濾代碼，類似於PG10 llvm生成代碼。
2. 關於Join將只支持LeftJoin，複雜Join只能在服務代碼內利用C#的Linq處理。
3. 目前事務隔離級別只支持ReadCommitted及Seializable，但純讀支持本地讀、線性一致性讀、事務讀。

  目前做者還在不斷踩坑與嘗試實現上述目標，固然首先要感謝上述所提的那些技術先驅們，在此但願有志同道合者來共同完成它。已實現的技術原型參考前篇
AppBoxFuture(一): Hello Future!，下篇「分而治之」將介紹框架如何在較低的硬件下保障高性能。