随业务扩展,数据库表记录越来越多的优化思路?

2020-08-28 11:15:39 +08:00
 chillingkitten
手头上有个 java 后台应用,是服务于各个业主的微信小程序的。 每个业主在微信平台上申请各自的 appId,appSecret 这些交给我们。

我们数据库里有个用户表,其中字段就有这个 appId,一开始为了快速上线,也没怎么长远考虑,直接单表走起。 基本上用 appId + openId 就能唯一定位到具体哪个业主下面的哪个用户。

查表的频率还是挺多的。 特别是新用户一来,就会根据 appId+openId 去检查是否已经落库,根据结果引导到后续不同的处理逻辑。 目前这个用户表的数据已经有 200W 左右了,而且搞商务的同事还在努力去拉新的业务,有潜在入驻的业主。 现在服务运行情况还好,数据库这块还不是瓶颈。 但如果再发展一两年,假设数据达到单表千万级,估计就很有问题了。

我想这种情况应该是个普适性的问题吧,就是这种多个“主体”的数据在一个单表里如何进行插入和查询的优化问题。 而且还有个特点是数据的不均匀性, 像我这个应用,目前小的业主下面只有 2W 左右数据,最大的一个业主下面就 100W 占了一半。
1715 次点击
所在节点    程序员
6 条回复
yumenawei
2020-08-28 12:27:28 +08:00
帮顶。期望其他大神给些方案。
我能想到的就是分表。
springz
2020-08-28 12:36:02 +08:00
大客户单独部署,另外推荐 TiDB 这种数据库,以后双管齐下就行了。做大了再说,TiDB 搭建一个最小可用拓扑阿里云也得每月 5w+ 了。
jorneyr
2020-08-28 17:16:07 +08:00
1. 不需要关联查询的大数据,可以放到 MongoDB
2. 需要关联查询,但是呢没啥复杂关系,可以拆开放到 MongoDB,从应用层获取后再到 MyQL 等关系型数据库查询
3. 难度大一些的可以考虑分库分表
lithiumii
2020-08-28 21:29:20 +08:00
微信 openid 本来就是全局 unique 的吧,不同的 appid,即使是同一个人,腾讯会给不同的 openid
dustinth
2020-08-29 17:01:41 +08:00
@lithiumii 不同商户 openid 不保证全局不重复的, 即使重复的概率很低.

很好奇 LZ 的业务场景, 应该不止一张用户表啊(除非是专门管客户信息的子系统), 其他业务表不用分表吗?

怎么分库分表不光是性能的需求, 还有业务的需求(比如要不要不同商户的数据隔离, 特别是大商户一般都会要求隔离).

保险的方法是按照商户分库分表(至少先做到按商户分表), spring JPA 对多商户其实支持挺好, 业务层的逻辑基本是透明的. 分析需求如果要合并表再备库到大数据平台做.
lance6716
2020-08-30 00:06:08 +08:00
@springz https://tidbcloud.com
欢迎免费试用 AWS/gcp 的 tidb 服务

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/702143

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX