随着用户量的增加,单表逐渐不足以支撑庞大的用户数据。所以需要进行数据切分。来解决数据增长的问题
- 水平切分
垂直切分用户当前表,已经是用户的最小存储单元,不适合垂直切分。所以应该选择水平切分,即把用户表横向切分为多个用户字表,这些字表和原有的users
表保持相同的数据结构和字段索引等
-
封装成单独的模块 -
做成服务 因为项目使用到了
php
,go
两个开发语言,如果封装成 单独的模块。则需要在php
和go
两个项目中封装两次,如果用户方面有需求变动。就需要改动 两个不同项目修改对应的模块,改动不方便,容易出错。所以建议是做成一个公共的服务。 做成一个服务的好处。如果发现错误,定位为题相对容易,需求变动。一次改动即可上线。代码接口风格和逻辑统一。缺点: 服务不能中断。一旦出现问题,影响整个系统
-
go rpcgo自带的rpc服务。 -
grpc google 开发的rpc服务
go自己的rpc服务。只能支持go自己的语言调用。无法使用php调用所以不考虑 grpc 性能高,社区活跃。支持当前流行的大部分开发语言
-
mongo
-
elasticsearch elasticsearch 是一个高效的数据搜索引擎。 mongo 是一个高效的k v存储数据库。 两者在使用方式和对数据的支持上有很大一部分是重叠的。 比如都是类似与json的序列化格式存储 都是只支持简单的事物.
用户表水平分割为 16个字表。`users`表中的数据 平均拆分到这对应的子表中。
使用grpc 服务启动对用户的单独处理。不论是 php的后台项目还是go的接口等对用户的查询,更新等操作。均应该调用 grpc服务提供的接口。
如果遇到数据统计和查询等问题。需要使用mongo或者es来配合处理
- 分表后的数据查询问题 (数据落表,搜索交给 es 或者mongo)
- 分表后数据库一致性和是否需要分布式锁的问题
- 安全问题( rpc服务应该是只在内网访问)
- 是否高效 - 待测试
- 数据扩展问(es 没有研究。mongo 是分片,分集合。应该是类似与es的集群机制)