AppBoxFuture(三): 分而治之

4928-20190112103938111-1806233514.png

  系统数据量达到一定程度后必将采用分库分表的方式来提高系统性能,但传统的分库分表方式也必将带来更高的开发复杂程度。新一代的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层代码还有优化的空间。
4928-20190112104205074-725897497.png
4928-20190112104208659-1202840132.png

  作者下一步的开发重点是:

  • 设计与实现索引扫描api;
  • 设计与实现聚合扫描api,可以并行聚合各分区;
  • 实体间关系EntityRef, EntitySet实现。

  如果您觉得该项目将来能帮到您,请您扫以下二维码打赏一下作者以购买测试VM;如果您有问题或Bug报告,请在Github提交。
4928-20190112120428249-1180246592.png

转载于:https://www.cnblogs.com/BaiCai/p/10258941.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值