某滴面试题，请教答案

[nightspirit]

订单列表上，用户可以看到他下的单一页的，好多，那么表数据很多，有好多亿条，那么怎么设计？

答：水平分表，使用用户 id 做 hash

那么已知订单 id，怎么获取订单详情？

答：union 订单表

上万的表直接联合么？

思考。。。答：可以维护 uid->订单 id 的 k-v 结构在 redis 中

扩展下，已知 XX （忘了啥字段了，当时紧张了）获取订单详情呢？

答：那就存个 hash 对应关系

司机的 APP 也能显示订单，怎么获取呢？

思考。。。答：不会了，之前公司都是千万级数据，没做过水平拆分

面试官怒了，你可以滚了，回去等消息吧

好的，我滚了。。。。（确实没做过啊，能想的我都想了）

当时太紧张了，前面的算法没答上来，有点自暴自弃，现在想想有了点答案了，只是我不知道对不对，请教大神这题答案

[oppoic]

那是面试官原话吗？

[nightspirit]

@oppoic 滚那个不是，我内心虚拟的，但能感觉面试官的鄙夷，前面算法还有锁的问题 我都答错了

[wellsc]

橙心优选还是出行啊

[uiosun]

坐等答案，这个数据体量，这种问题，该解决啊……

[jandou]

以前问过同样问题，他们家常规题目。

[beidounanxizi]

nosql hbase 可以做查询 另外 滴滴面试官 嗯 不说了
水平分表的话 排序 join 都不好操作
感觉楼主也是个憨批 有啥好怕的 🐶

[opengps]

很多时候考察的不是是不是会做，而是会不会去思考这种问题。
我以前 gps 项目面试也这么问过，然而能有思路的人太少，当然不像滴滴这么有实力可以挑面试的人

订单表作为需要联合查询，可能我分享的单表逻辑不适用，不过可以发出来分享下，外加其他比如一主多从等方案的结合应该可以适当提高下得分 https://www.opengps.cn/Blog/View.aspx?id=284&from=v2ex

[fantastM]

订单 id -> 用户 id，用户 id -> 订单 id

[fantastM]

#8 这两个关系都存一下

[Vegetable]

这提问方式压迫感挺强的，后续问题都是基于你的答案提的，挺考验临场水平的。

我感觉你后边的问题没答出来不是因为没有答案，而是他前边给的需求太少，按照这种条件给出来的答案本来就是设计不足的。

单纯的寻求这个答案好像不是很重要吧，超纲了等答案

[CEBBCAT]

楼主的第一段我实在读不通畅

[nightspirit]

@CEBBCAT 语文功底不是很好，他的意思是用户可以看到他所有下的订单，我们好多用户，订单表很大，我们怎么处理订单表

[nightspirit]

@beidounanxizi 因为面试机会少，有点患得患失

[rocky114]

司机的 APP 也能显示订单，怎么获取呢？

司机应该常看的订单就是六个月吧？六个月内的数据维护一份 map,六个月之前的数据查询慢就慢一点吧

[nightspirit]

@wellsc 做外卖的，不知道是哪边，我不熟

[angryfish]

对这类问题表示关注，等大神来回答

[cxshun]

@nightspirit #15 一般情况下，你要分表就需要按多维度去分，比如订单表，有可能按用户查，也有可能按订单查，那 OK，我们就按 [用户 ID] 和按 [订单 ID] 两个维度去分表，冗余多一个表。查询的时候根据不同条件查不同的表，也就是分不同的 DAO 或 Mapper，我们之前就是这样做的。
当然，其实还可以上 ES 的，当量大到一定程度，比如上亿，mysql 有可能撑不住，那上到 ES 是自然而然的事情了

[simapple]

原则上规避 io 瓶颈，先用设计策略，快速查询到必要的查询条件，再通过一个可控制数据返回量的条件查询，查出单个 request 需要的数据。如果必要，再设计预查询策略，在资源可用的情况下，提前准备好下一个 request 的数据。

[nightspirit]

@cxshun 多谢 思路多了起来

[zardly666]

能想到的就是每个用户都冗余维护一个订单列表的缓存项。在下单逻辑的时候，实时把缓存更新，查的时候就是秒查了。。坐等大神解答