数据库表保证读快还是保证写快， 1000tps 写入， 60000tps 查询？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2311 天前的主题，其中的信息可能已经有所发展或是发生改变。

需求

数仓上的应用，1000tps 的写入事件，60000tps 的查询当事人，需要设计缓存表。

我的设计

以当事人 id 作为主键，做宽表，所有事件做成 list，塞到一个 cell，方便查询当事人所有信息，保证读得快。

结果

老大表示应该保证先写得快，以事件 id 作主键做宽表，再设一张当事人 id 作主键的关联表，把当事人 id 和事件 id 关联。

疑问

为什么读 tps 是写 tps 的 60 倍时还需要优先保证写快？
有没有数据库表设计的优秀经验、原则可以指教？
有没有表设计实践的书籍可以推荐？

设计被否了觉得心情低落，也发现需要学习、积累的经验很多，ball ball 大佬赐教！！！

tps

主键

当事人

Ball

7 条回复 • 2018-08-22 20:17:12 +08:00

kingcc

2018-08-21 14:35:54 +08:00 via Android

应用场景

ppyybb

2018-08-21 16:26:02 +08:00 via iPhone

我也不懂数据仓库，经验比较少，也不知道你们现在用的是主从还是集群，但是有这么几个猜测：
目的是设计为数据库能扛住这么大的压力，以及业务方便维护
从性能上
如果你们两的设计达到的效果是：
都能满足现有的需求，但是你的设计在不改变大的架构的情况下上限是 20 万 tps，写是 2000tps
你老大的读上限是 10 万，写是 5000qps，那么就需要看未来需求的变化哪个先到瓶颈。

如果在主从架构下，写肯定比较难扩展，读只需要加 slave。所以倾向于先保证写。但是如果这个设计马上就使得读到极限了，也不一定科学。

所以你可以问下老大有没有做过类似的评估以及性能测试，或者有没有类似的经验，或者说就是单纯的直觉（拍脑袋）

lucyatwex

2018-08-21 16:56:26 +08:00

@kingcc 谢谢您回复！！！
应用场景是抽奖活动，用当事人的所有事件信息判断抽奖次数和奖品
当事人的量约为 500w，事件的量约为 2000w，一次事件包括用户的申请、交易、交易成功等全流程信息，一个当事人会有多次事件
缓存表保存所有历史事件和当事人身份信息，同时活动期间的注册、实名、申请、交易事件通过 storm 实时写入缓存表
我做的是提供当事人信息查询接口，当事人 id 过来，返回缓存表中该 id 的所有事件信息

lucyatwex

2018-08-21 17:23:38 +08:00

@ppyybb 非常谢谢您的分析，对我超级有帮助！
数据库是集群，做过单机的读写性能测试，并且集群上有做过项目（因为业务逻辑比较复杂，写 tps<1000，读 tps 未定量地观察过），所以我觉得老大应该是评测+经验吧

CRVV

2018-08-21 19:02:32 +08:00

1. 读操作可以用缓存优化。如果需要保证数据库的 ACID，我觉得写操作上不能加缓存
2. 关系型数据库有设计表的范式，如果照着范式来做，那应该没多少选择的余地。
当然实际情况是连第一范式都几乎没人严格遵守
这种事情的主观成分非常大，我估计 MySQL 用户和 Oracle/PostgreSQL 用户应该会有很多相反的观点
我个人倾向于先设计一套尽量满足范式的表，然后如果确定某种修改方式能带来好处，再一点点改

lucyatwex

2018-08-21 20:12:43 +08:00

@CRVV 非常非常感谢您！
“我个人倾向于先设计一套尽量满足范式的表，然后如果确定某种修改方式能带来好处，再一点点改”，超级棒的建议，醍醐灌顶！
“写操作上不能加缓存”，可能我表达的不太正确，因为使用的是关系型内存数据库，针对当前营销活动建的表，所以我把它叫缓存表>_< 也算是直接读库和写库吧！

kingcc

2018-08-22 20:17:12 +08:00

谢谢你。
我对你的表述有几点不了解。
1. 首先你的业务场景下，有必要使用关联表吗？多个候选人可能关联一个事件吗
2. 保证读快还是写快还是要看具体的业务场景，业务规模，qps 等等。最好的方法是经验，最好做测试。
3. “为什么读 tps 是写 tps 的 60 倍时还需要优先保证写快”，让我感觉楼主是不是对`tps`有一些误解