r****n
发帖数: 179 | 1 遇到一家中型公司，去面了下,其中一道设计题比较有意思，就是设计一个天气预报的
service.
要求： 输入zip 或者城市，在网页上返回该地1-10天内的天气情况。
条件，假设后端可以用ftp的方式去下载更新各个地方的天气预报数据。
说下大概思路，Web server tier 碰到city names，则pass到 location app server,
location server负责parse然后 query Data store(such as HBase) 得到city name
to zip(可将一部分hot mappping 放到Redis/memcache 等 cache). Web server tier
拿到zip, 然后去查cache里有无数据，cache miss，就到Data store 去query 得到想
要的天气数据。后端还有一个app server 负责定期下载天气数据到DB，比如每小时，
同时转化成需要的schema：{key:zip, column family:day 1, value: weather data}.
不知道大家有没更好的想法，或者哪里有不妥? |
h***n
发帖数: 1600 | 2 为什么不直接用api fetch weather data? 我不懂为什么还要有自己的database.
users search什么，就fetch 相对应data就行了。然后搞一个cache，同样的query就用
cache。
咱是新手,说错了请轻批。 |
c********t
发帖数: 5706 | 3 LZ说了： 条件，假设后端可以用ftp的方式去下载更新各个地方的天气预报数据。
【在 h***n 的大作中提到】
: 为什么不直接用api fetch weather data? 我不懂为什么还要有自己的database.
: users search什么，就fetch 相对应data就行了。然后搞一个cache，同样的query就用
: cache。
: 咱是新手,说错了请轻批。
|
c********t
发帖数: 5706 | 4 问你个细节，memcache 什么时候更新，怎么更新？
,
tier
}.
【在 r****n 的大作中提到】
: 遇到一家中型公司，去面了下,其中一道设计题比较有意思，就是设计一个天气预报的
: service.
: 要求： 输入zip 或者城市，在网页上返回该地1-10天内的天气情况。
: 条件，假设后端可以用ftp的方式去下载更新各个地方的天气预报数据。
: 说下大概思路，Web server tier 碰到city names，则pass到 location app server,
: location server负责parse然后 query Data store(such as HBase) 得到city name
: to zip(可将一部分hot mappping 放到Redis/memcache 等 cache). Web server tier
: 拿到zip, 然后去查cache里有无数据，cache miss，就到Data store 去query 得到想
: 要的天气数据。后端还有一个app server 负责定期下载天气数据到DB，比如每小时，
: 同时转化成需要的schema：{key:zip, column family:day 1, value: weather data}.
|
j**********r
发帖数: 3798 | 5 就这点数据量，一个关系数据库就得了。弄个read replica备灾足以。杀鸡用牛刀显
示的是没有经验。一个天气预报网站你要cdn干啥，要multi DC干啥？
,
tier
}.
【在 r****n 的大作中提到】
: 遇到一家中型公司，去面了下,其中一道设计题比较有意思，就是设计一个天气预报的
: service.
: 要求： 输入zip 或者城市，在网页上返回该地1-10天内的天气情况。
: 条件，假设后端可以用ftp的方式去下载更新各个地方的天气预报数据。
: 说下大概思路，Web server tier 碰到city names，则pass到 location app server,
: location server负责parse然后 query Data store(such as HBase) 得到city name
: to zip(可将一部分hot mappping 放到Redis/memcache 等 cache). Web server tier
: 拿到zip, 然后去查cache里有无数据，cache miss，就到Data store 去query 得到想
: 要的天气数据。后端还有一个app server 负责定期下载天气数据到DB，比如每小时，
: 同时转化成需要的schema：{key:zip, column family:day 1, value: weather data}.
|
e*******s
发帖数: 1979 | 6 我想问一下
面系统设计的时候 大家都是画框架图么.
一个方框一个方框的联系来?
,
tier
}.
【在 r****n 的大作中提到】
: 遇到一家中型公司，去面了下,其中一道设计题比较有意思，就是设计一个天气预报的
: service.
: 要求： 输入zip 或者城市，在网页上返回该地1-10天内的天气情况。
: 条件，假设后端可以用ftp的方式去下载更新各个地方的天气预报数据。
: 说下大概思路，Web server tier 碰到city names，则pass到 location app server,
: location server负责parse然后 query Data store(such as HBase) 得到city name
: to zip(可将一部分hot mappping 放到Redis/memcache 等 cache). Web server tier
: 拿到zip, 然后去查cache里有无数据，cache miss，就到Data store 去query 得到想
: 要的天气数据。后端还有一个app server 负责定期下载天气数据到DB，比如每小时，
: 同时转化成需要的schema：{key:zip, column family:day 1, value: weather data}.
|
s****3
发帖数: 270 | 7 感觉问题不大 只有10天 DB 不会overstorage
有任何follow up 的考察点吗? |
w**z
发帖数: 8232 | 8 霸哥，现在面试都是靠忽悠，不忽悠拿不到offer 的。
就这点数据量，一个关系数据库就得了。弄个read replica备灾足以。杀鸡用牛
刀显
【在 j**********r 的大作中提到】
: 就这点数据量，一个关系数据库就得了。弄个read replica备灾足以。杀鸡用牛刀显
: 示的是没有经验。一个天气预报网站你要cdn干啥，要multi DC干啥？
:
: ,
: tier
: }.
|
j**********r
发帖数: 3798 | 9 忽悠也得靠谱呀，张口闭口NoSQL的，我多问俩问题露馅的居多。
【在 w**z 的大作中提到】
: 霸哥，现在面试都是靠忽悠，不忽悠拿不到offer 的。
:
: 就这点数据量，一个关系数据库就得了。弄个read replica备灾足以。杀鸡用牛
: 刀显
|
