这是一个创建于 1327 天前的主题，其中的信息可能已经有所发展或是发生改变。
手头上有个 java 后台应用，是服务于各个业主的微信小程序的。 每个业主在微信平台上申请各自的 appId,appSecret 这些交给我们。
我们数据库里有个用户表，其中字段就有这个 appId,一开始为了快速上线，也没怎么长远考虑，直接单表走起。 基本上用 appId + openId 就能唯一定位到具体哪个业主下面的哪个用户。
查表的频率还是挺多的。 特别是新用户一来，就会根据 appId+openId 去检查是否已经落库，根据结果引导到后续不同的处理逻辑。 目前这个用户表的数据已经有 200W 左右了，而且搞商务的同事还在努力去拉新的业务，有潜在入驻的业主。 现在服务运行情况还好，数据库这块还不是瓶颈。 但如果再发展一两年，假设数据达到单表千万级，估计就很有问题了。
我想这种情况应该是个普适性的问题吧，就是这种多个“主体”的数据在一个单表里如何进行插入和查询的优化问题。 而且还有个特点是数据的不均匀性， 像我这个应用，目前小的业主下面只有 2W 左右数据，最大的一个业主下面就 100W 占了一半。
我们数据库里有个用户表，其中字段就有这个 appId,一开始为了快速上线，也没怎么长远考虑，直接单表走起。 基本上用 appId + openId 就能唯一定位到具体哪个业主下面的哪个用户。
查表的频率还是挺多的。 特别是新用户一来，就会根据 appId+openId 去检查是否已经落库，根据结果引导到后续不同的处理逻辑。 目前这个用户表的数据已经有 200W 左右了，而且搞商务的同事还在努力去拉新的业务，有潜在入驻的业主。 现在服务运行情况还好，数据库这块还不是瓶颈。 但如果再发展一两年，假设数据达到单表千万级，估计就很有问题了。
我想这种情况应该是个普适性的问题吧，就是这种多个“主体”的数据在一个单表里如何进行插入和查询的优化问题。 而且还有个特点是数据的不均匀性， 像我这个应用，目前小的业主下面只有 2W 左右数据，最大的一个业主下面就 100W 占了一半。
 |
1
yumenawei 2020-08-28 12:27:28 +08:00
帮顶。期望其他大神给些方案。
我能想到的就是分表。 |
 |
2
springz 2020-08-28 12:36:02 +08:00
大客户单独部署，另外推荐 TiDB 这种数据库，以后双管齐下就行了。做大了再说，TiDB 搭建一个最小可用拓扑阿里云也得每月 5w+ 了。
|
 |
3
jorneyr 2020-08-28 17:16:07 +08:00
1. 不需要关联查询的大数据，可以放到 MongoDB
2. 需要关联查询，但是呢没啥复杂关系，可以拆开放到 MongoDB，从应用层获取后再到 MyQL 等关系型数据库查询 3. 难度大一些的可以考虑分库分表 |
 |
4
lithiumii 2020-08-28 21:29:20 +08:00 via Android
微信 openid 本来就是全局 unique 的吧，不同的 appid，即使是同一个人，腾讯会给不同的 openid
|
 |
5
dustinth 2020-08-29 17:01:41 +08:00
@lithiumii 不同商户 openid 不保证全局不重复的, 即使重复的概率很低.
很好奇 LZ 的业务场景, 应该不止一张用户表啊(除非是专门管客户信息的子系统), 其他业务表不用分表吗? 怎么分库分表不光是性能的需求, 还有业务的需求(比如要不要不同商户的数据隔离, 特别是大商户一般都会要求隔离). 保险的方法是按照商户分库分表(至少先做到按商户分表), spring JPA 对多商户其实支持挺好, 业务层的逻辑基本是透明的. 分析需求如果要合并表再备库到大数据平台做. |
 |
6
lance6716 2020-08-30 00:06:08 +08:00 via Android
|
Select Language