数仓上的应用，1000tps 的写入事件，60000tps 的查询当事人，需要设计缓存表。
以当事人 id 作为主键，做宽表，所有事件做成 list，塞到一个 cell，方便查询当事人所有信息，保证读得快。
老大表示应该保证先写得快，以事件 id 作主键做宽表，再设一张当事人 id 作主键的关联表，把当事人 id 和事件 id 关联。
设计被否了觉得心情低落，也发现需要学习、积累的经验很多，ball ball 大佬赐教！！！
 | 1 kingcc Aug 21, 2018 via Android 应用场景 |
 | 2 ppyybb Aug 21, 2018 via iPhone 我也不懂数据仓库，经验比较少，也不知道你们现在用的是主从还是集群，但是有这么几个猜测： 目的是设计为数据库能扛住这么大的压力，以及业务方便维护 从性能上 如果你们两的设计达到的效果是： 都能满足现有的需求，但是你的设计在不改变大的架构的情况下上限是 20 万 tps，写是 2000tps 你老大的读上限是 10 万，写是 5000qps，那么就需要看未来需求的变化哪个先到瓶颈。 如果在主从架构下，写肯定比较难扩展，读只需要加 slave。所以倾向于先保证写。但是如果这个设计马上就使得读到极限了，也不一定科学。 所以你可以问下老大有没有做过类似的评估以及性能测试，或者有没有类似的经验，或者说就是单纯的直觉（拍脑袋） |
 | 3 lucyatwex OP @kingcc 谢谢您回复！！！ 应用场景是抽奖活动，用当事人的所有事件信息判断抽奖次数和奖品 当事人的量约为 500w，事件的量约为 2000w，一次事件包括用户的申请、交易、交易成功等全流程信息，一个当事人会有多次事件 缓存表保存所有历史事件和当事人身份信息，同时活动期间的注册、实名、申请、交易事件通过 storm 实时写入缓存表 我做的是提供当事人信息查询接口，当事人 id 过来，返回缓存表中该 id 的所有事件信息 |
| 4 lucyatwex OP @ppyybb 非常谢谢您的分析，对我超级有帮助！ 数据库是集群，做过单机的读写性能测试，并且集群上有做过项目（因为业务逻辑比较复杂，写 tps<1000，读 tps 未定量地观察过），所以我觉得老大应该是评测+经验吧 |
 | 5 CRVV Aug 21, 2018 1. 读操作可以用缓存优化。如果需要保证数据库的 ACID，我觉得写操作上不能加缓存 2. 关系型数据库有设计表的范式，如果照着范式来做，那应该没多少选择的余地。 当然实际情况是连第一范式都几乎没人严格遵守 这种事情的主观成分非常大，我估计 MySQL 用户和 Oracle/PostgreSQL 用户应该会有很多相反的观点 我个人倾向于先设计一套尽量满足范式的表，然后如果确定某种修改方式能带来好处，再一点点改 |
| 6 lucyatwex OP @CRVV 非常非常感谢您！ “我个人倾向于先设计一套尽量满足范式的表，然后如果确定某种修改方式能带来好处，再一点点改”，超级棒的建议，醍醐灌顶！ “写操作上不能加缓存”，可能我表达的不太正确，因为使用的是关系型内存数据库，针对当前营销活动建的表，所以我把它叫缓存表>_< 也算是直接读库和写库吧！ |
| 7 kingcc Aug 22, 2018 谢谢你。 我对你的表述有几点不了解。 1. 首先你的业务场景下，有必要使用关联表吗？多个候选人可能关联一个事件吗 2. 保证读快还是写快还是要看具体的业务场景，业务规模，qps 等等。最好的方法是经验，最好做测试。 3. “为什么读 tps 是写 tps 的 60 倍时还需要优先保证写快”，让我感觉楼主是不是对`tps`有一些误解 |
Select Language