这是一个创建于 1873 天前的主题，其中的信息可能已经有所发展或是发生改变。
手头上有个 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