AppBoxFuture(三): 分而治之



  系統數據量達到必定程度後必將採用分庫分表的方式來提升系統性能，但傳統的分庫分表方式也必將帶來更高的開發複雜程度。新一代的NewSql及NoSql數據庫因爲天生的分佈式存儲基因，既保證了可以橫向擴展，又能夠避免較高的開發複雜程度。AppBoxFuture框架的存儲引擎借鑑了新一代分佈式數據庫分而治之的思想，在設計實體模型時能夠指定分區鍵，存儲引擎會根據分區鍵建立相應的RaftGroup(多個副本)。須要注意的是AppBoxFuture框架的分區策略與NewSql不一樣，NewSql通常採用自動分裂與合併的方式來管理分區，而框架採用的是一開始就指定分區鍵的方式，更相似於Cassandra的分區方式，但又不一樣於Cassandra的分區不能排序。

  在設計實體模型時先要估算數據量來肯定是否須要分區存儲，通常的基礎信息如客戶信息之類的不須要分區，但訂單之類的動態數據，能夠根據年或月份做爲分區鍵，若是是SaaS類的應用，能夠用租戶Id + 期間做爲分區鍵。

  做者錄了個演示視頻演示視頻連接, 簡單說明一下演示內容:

• 新建車輛狀態(VehicleState)實體模型，加入VehicleId, Lng, Lat成員, 設置分區鍵爲VehicleId;
• 新建測試服務併發插入8萬條記錄，計算每秒tps(演示視頻20行 i < loopCount 應爲 j < loopCount)。

  在做者的虛擬機內（4C8G）的進行單分區併發插入的測試結果以下圖, 虛擬機Cpu已經跑滿。實際單獨測試存儲引擎(C++)可達40000/秒，Clr層代碼還有優化的空間。

  做者下一步的開發重點是：

• 設計與實現索引掃描api;
• 設計與實現聚合掃描api，能夠並行聚合各分區;
• 實體間關係EntityRef, EntitySet實現。

  若是您以爲該項目未來能幫到您，請您掃如下二維碼打賞一下做者以購買測試VM；若是您有問題或Bug報告，請在Github提交。