V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 3 页 / 共 81 页
回复总数  1601
1  2  3  4  5  6  7  8  9  10 ... 81  
那些 PUA 的,其实是给你们送育儿福利,老实人还是太善良(法盲)了
这几个定义确实不怎么好,即使是英文原版,加上定义的细节,非常容易让人记混。反正如果有人面试问我这几个,我八成回答不准确。

我喜欢用自己的分类总结,比这三个定义更容易记忆而且更全面。如下:


这几个工程问题根本原因的共性:查询缓存的 key 不存在。主要有两类:
1. 传入的查询的 key 参数本来就不存在。例如传错参数、攻击时黑客随便弄的空 key 。
2. 业务上曾经存在该 key 、但是设置了有效期、查询时过期了。

造成工程问题时的另一个维度就是 key 的数量:
1. 少量 key
2. 大量 key

key 不存在的原因、key 的数量维度结合起来的四种情况。

完整详情,欢迎评论:
https://gist.github.com/lesismal/3640d2a74db3eaf303bb8d40ecd0de05
@sthwrong #6

> 海量数据这俩都不是银弹,都得拉队友支撑

对,我在主贴中就说过了。

> 现阶段,pg 的队友可能更多更强大

普通数据量级,pg 功能丰富很多业务非常好用,这个我在主贴里也说了



但是我见到的几次 V 站上 pger 们的现象,有点盲目相信 pg 了,不区分业务量级数据量级和场景,一味贬低 mysql 。
这样会造成很多错觉,中小项目做得风生水起,大项目直接拉垮,尤其是早期阶段的 OLAP 甚至业务逻辑重度依赖 pg ,导致大项目发展起来后的重构成本高太多。
所以我并不是说 pg 不好,也不是说 mysql 比 pg 好,而是应该懂得如何合理选型、不要盲目追捧和吹嘘。

对于这种海量数据场景,mysql 的劣势甚至成为项目发展生命周期中的优势,比如 OLAP 不友好、干脆早期就少用它搞 OLAP ,比如存储过程不行、干脆不使用它的存储过程,而是把这些都诉诸于拉队友的方式解决。这些不便利,在业务量级剧增需要重构时,反倒成为优势。

当然,多数人的工作内容并不涉及这种海量数据场景,用 pg 足够爽,挺好的,但是没必要盲目捧 pg 贬 mysql 。
@guiyumin #1 我是聊技术观点,您如果不聊技术、上来就 who care 不太合适吧?纯技术选型的观点,跟 uber 倒闭不倒闭也没关系的,请先理清自己逻辑


@sthwrong @kapr1k0rn pg 确实在进步,但海量数据场景 pg 不是银弹、甚至很多人依赖 pg 的 OLAP 导致数据量真的增长后很难迁移,uber 的 blog 主要是衬托海量业务场景传统关系数据库仍然不足、十年来 pg 的进步不假但是解决不了海量性能问题,所以不存在十年前就不合时宜的问题
102 天前
回复了 clacf 创建的主题 投资 清仓 A 股所有资产
49 年退 d
#71 回错贴,回隔壁退 A 股
1  2  3  4  5  6  7  8  9  10 ... 81  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   2951 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 24ms · UTC 13:28 · PVG 21:28 · LAX 05:28 · JFK 08:28
♥ Do have faith in what you're doing.