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提交。