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