系統資料量達到一定程度後必將採用分庫分表的方式來提高系統性能，但傳統的分庫分表方式也必將帶來更高的開發複雜程度。新一代的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提交。