萝卜丝全套挂经

Ericson1995 发表于 2024-12-3 15:27
想请问下楼主他家的题库是地里都能搜到吗

对，你在地里搜搜，它家题库感觉挺小的

匿名用户 发表于 2024-12-3 14:28
对，你在地里搜搜，它家题库感觉挺小的

好的感谢

匿名用户 发表于 2024-12-3 08:21
对，总的来说就是要这几个table，但不需要每个都说具体是啥。game storage说了一下大概是啥。aggregated ...

多谢楼主好心！关于“而且没有clarify这个精准度。精准度这个是后来面试官challenge，还提到youtube的点赞数其实经常是estimated number比如1.5M而不是15xxxxxx这么精准的。”你的失误在哪里呢？感觉like写道数据库，到读的时候，应该有一定的延迟。这个设计要求是real-time like update吗？如果不是，like count应该是读的时候数据库或者cache的值，这样理解对吗？面试官challenge什么呢？

匿名用户 发表于 2024-12-4 00:12
多谢楼主好心！关于“而且没有clarify这个精准度。精准度这个是后来面试官challenge，还提到youtube的点 ...

我这里的失误点是，我默认就是需要看到具体准确的点赞数量啊，根本没有去主动讨论。实际上这里是个很好的tradeoff讨论点的。比如如果是当前很小的点赞数字，比如10个100个这种，肯定要更精准点，而如果是1.5M这种数字了的话真的丢个10个100个而data refreshness有delay一点也不要紧的。针对这个不同的data refreshness要求，自然你可以选择不同的设计了啊！怎么说怎么tradeoff，是否real time更新和怎么validation什么的都可以各种tradeoff搞了。你懂我的意思了么？

匿名用户 发表于 2024-12-4 08:53
我这里的失误点是，我默认就是需要看到具体准确的点赞数量啊，根本没有去主动讨论。实际上这里是个很好的 ...

谢谢！

匿名用户 发表于 2024-12-03 08:21:05
对，总的来说就是要这几个table，但不需要每个都说具体是啥。game storage说了一下大概是啥。aggregated的那个多说了一下schema啥样的有

楼主可以指点一下这3个点吗？多谢了！尤其是第一个点，这个难道不是只需要一个itemId, likeCount 的KV吗？有什么不同的选择呢

匿名用户 发表于 2025-03-08 18:07:57
楼主可以指点一下这3个点吗？多谢了！尤其是第一个点，这个难道不是只需要一个itemId, likeCount 的KV吗？有什么不同的选择呢

Fb这个有tech blog的，你自己直接去看看更好

匿名用户 发表于 2025-3-8 20:19
Fb这个有tech blog的，你自己直接去看看更好

我尝试各种搜过，但是没有找到。能麻烦楼主给个链接吗？

所以他的要求到底是要精确计算like数还是像YouTube那样可以有丢event这种

匿名用户 发表于 2025-04-14 16:13:08
所以他的要求到底是要精确计算like数还是像YouTube那样可以有丢event这种

YouTube这种