天天看點

AppBoxFuture(三): 分而治之

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層代碼還有優化的空間。

AppBoxFuture(三): 分而治之
AppBoxFuture(三): 分而治之

  作者下一步的開發重點是:

  • 設計與實作索引掃描api;
  • 設計與實作聚合掃描api,可以并行聚合各分區;
  • 實體間關系EntityRef, EntitySet實作。

  如果您覺得該項目将來能幫到您,請您掃以下二維碼打賞一下作者以購買測試VM;如果您有問題或Bug報告,請在Github送出。

AppBoxFuture(三): 分而治之