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:
- 在實現表掃描及聚合掃描時，作者利用C#的Emit直接生成條件過濾程式碼，類似於PG10 llvm生成程式碼。
- 關於Join將只支援LeftJoin，複雜Join只能在服務程式碼內利用C#的Linq處理。
- 目前事務隔離級別只支援ReadCommitted及Seializable，但純讀支援本地讀、線性一致性讀、事務讀。
目前作者還在不斷踩坑與嘗試實現上述目標，當然首先要感謝上述所提的那些技術先驅們，在此希望有志同道合者來共同完成它。已實現的技術原型參考前篇
ofollow,noindex" target="_blank">AppBoxFuture(一): Hello Future! ，下篇“分而治之”將介紹框架如何在較低的硬體下保障高效能。