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

[lucyatwex]

需求

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

我的设计

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

结果

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

疑问

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

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

[kingcc]

应用场景

[ppyybb]

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

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

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

[lucyatwex]

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

[lucyatwex]

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

[CRVV]

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

[lucyatwex]

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

[kingcc]

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