数据量过大该如何分表比较合适

  • 最近业务数据量越来越大 趁还有机会看下能不能补救下
  • 存放人脸设备打卡数据 一般一个工地大概有1000人
  • 进出上下班 包括中午进出一天一个人打卡产生4条打卡记录 最少的1000*4产生的记录数
  • 一天一个工地产生的数据量最少就是4000条

目前想到的就是分表优化下先

要是分表的话是10个工地的打卡数据都一起存在一张表好

还是一个工地单独一张表这两种方案那种比较好

一个工地的数据到完工起码得1年时间才能完工 所以不能删除

《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
最佳答案

就是目前的话已有10个工地 卖打卡考勤设备装置的 理论上不是10个工地随着销售额会一直上涨

1周前 评论
讨论数量: 17

说实话 几百万的数据 压根用不到分表

1周前 评论
y1415181920 (楼主) 1周前
Smilephp (作者) 1周前
Smilephp (作者) 1周前

几百万数据确实不需要分表,特别是这种签到数据,存进去了基本不会用到

1周前 评论
22 (作者) 1周前
y1415181920 (楼主) 1周前
y1415181920 (楼主) 1周前
22 (作者) 1周前
22 (作者) 1周前

就是目前的话已有10个工地 卖打卡考勤设备装置的 理论上不是10个工地随着销售额会一直上涨

1周前 评论

一个工地一张表吧,省心一整年。

1周前 评论

如果打卡仅仅是插入而没有查询的话那瓶颈应该不在数据库上面,可以考虑从以下方面排查:

  • 网络带宽,打卡时间段是不是带宽一直处于满载状态,如果是可以考虑提升带宽。

  • 如果是运行在 PHP-FPM 下瞬时流量激增会因为文件 IO 次数过多从而严重影响性能 ,调整 PHP-FPM 参数不能解决问题,可以试试加入 Swoole 等组件来托管运行 Laravel,能够大大减少文件 IO,性能应该能提升一大个台阶;当然加服务器使用负载均衡是最简单的办法。

  • 典型的写多读少的场景,应该优先考虑使用缓存组件来实现功能。

1周前 评论

有很多种方案,例如上面有的老哥说的,一年一张表,省心好维护,也可以按照工人信息的id者求余,然后分到不同的表;还可以把打卡记录放在非关系型数据库mongodb、redis里,不走数据库,然后做好统计表,减少数据库读写,也能提升速度,然后再加上队列走异步,不要太爽!

1周前 评论

打卡没必要实时存数据库,可以将数据先存redis,再异步或者定时,将数据根据(用户ID或者工地ID--那个方便后续操作用哪个)取模存进对应的表。

1周前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!