A*o
2 楼
RE .....
A*o
3 楼
RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
A*o
4 楼
RE .....
f*x
5 楼
求问啊
这是个GL高频，而且我看到的面经是G烙印问的
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
w*s
6 楼
scheduler
event
notifier
...
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
event
notifier
...
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
A*o
7 楼
顶起来, 求大牛们给个指点
t*i
8 楼
同求
l*u
9 楼
顶
R*9
10 楼
G 电面碰到这道题了， 还是不懂怎么做
【在 l*****u 的大作中提到】
: 顶
【在 l*****u 的大作中提到】
: 顶
w*x
11 楼
Mark,周末找时间讨论一下.
l*1
12 楼
mark
q*8
13 楼
这种高度抽象的题，我觉得第一步面试官期待的是你能narrow down到一个个的基本问
题。任何一个小问题都够你们讨论整个面试。
题。任何一个小问题都够你们讨论整个面试。
l*a
14 楼
先说说看有什么功能需求.
讨论需求就可以花10几分钟
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
讨论需求就可以花10几分钟
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
d*i
15 楼
思考中。。。
M*M
16 楼
大牛些讲讲这个吧，谢谢！
h*u
17 楼
RE
p*2
18 楼
老三样 kafka cassandra spark
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
【在 A*****o 的大作中提到】
: RT. 看到L家面经考到类似, 想请版上牛牛们讨论下, 先谢谢了!
j*3
19 楼
具体说说，大牛！
【在 p*****2 的大作中提到】
: 老三样 kafka cassandra spark
【在 p*****2 的大作中提到】
: 老三样 kafka cassandra spark
p*2
20 楼
我能想到的功能
new
invite
display
modify
notify
delete
大牛觉得还有什么其他吗？
【在 j**********3 的大作中提到】
: 具体说说，大牛！
new
invite
display
modify
notify
delete
大牛觉得还有什么其他吗？
【在 j**********3 的大作中提到】
: 具体说说，大牛！
s*k
21 楼
show and resolve conflict among multiples users' calendar
scheduling periodic event
alarm before event occurrence
【在 p*****2 的大作中提到】
: 我能想到的功能
: new
: invite
: display
: modify
: notify
: delete
: 大牛觉得还有什么其他吗？
scheduling periodic event
alarm before event occurrence
【在 p*****2 的大作中提到】
: 我能想到的功能
: new
: invite
: display
: modify
: notify
: delete
: 大牛觉得还有什么其他吗？
m*t
22 楼
repeat( daily, weekly, months)
alarm, alerts by time intervals
email function
暂时想这么多
【在 p*****2 的大作中提到】
: 我能想到的功能
: new
: invite
: display
: modify
: notify
: delete
: 大牛觉得还有什么其他吗？
alarm, alerts by time intervals
email function
暂时想这么多
【在 p*****2 的大作中提到】
: 我能想到的功能
: new
: invite
: display
: modify
: notify
: delete
: 大牛觉得还有什么其他吗？
m*t
23 楼
还有，提供map的link
m*t
24 楼
又想起一个
holiday automatic mark
holiday automatic mark
p*2
25 楼
好吧？
大家都很投入。谁先开始？
大家都很投入。谁先开始？
p*2
26 楼
貌似还有multiple calendar
m*t
27 楼
开始什么？pseudo code? flowchart? 还是coding?
这种面试对互动能力和思维活跃度的功底要求很高
平时没这种能力的 装不了几秒就趴窝了
不过 我很喜欢这种面试style，lots of fun
这种面试对互动能力和思维活跃度的功底要求很高
平时没这种能力的 装不了几秒就趴窝了
不过 我很喜欢这种面试style，lots of fun
p*2
28 楼
我想先整理一下core functionality， 然后开始设计。我现在没时间，晚上好好搞搞
。感觉这东西很有意思。
我们晚上搞一下吧。
【在 m********t 的大作中提到】
: 开始什么？pseudo code? flowchart? 还是coding?
: 这种面试对互动能力和思维活跃度的功底要求很高
: 平时没这种能力的 装不了几秒就趴窝了
: 不过 我很喜欢这种面试style，lots of fun
p*u
29 楼
don't forget 2 tape it then share w/ us...
【在 p*****2 的大作中提到】
:
: 我想先整理一下core functionality， 然后开始设计。我现在没时间，晚上好好搞搞
: 。感觉这东西很有意思。
: 我们晚上搞一下吧。
m*t
30 楼
设计思路的路线是这样的流程:
1. what kind of fancy features they expected...
很多人都没明白对方说的是什么就上来求助了。
所以他们自己表达出来的很多题 都需要加以推敲， 是不是真正的原题。
2. features cases:
1) non special
2) special
先假设是case 1), 那么basic data structures 就要列出一个list
这里又分几种cases
a) 日历最重要的结构是timing
这部分又分成几个不同的组成部分
i. 当前的年月日 系统时间里取出
ii. 未来的时间年月日
iii. 过去的年月日
iv. 历史上的今天， 也包括国家假日
手机打字 不方便 胳膊都酸了
to be cont'd later
【在 p*****2 的大作中提到】
:
: 我想先整理一下core functionality， 然后开始设计。我现在没时间，晚上好好搞搞
: 。感觉这东西很有意思。
: 我们晚上搞一下吧。
1. what kind of fancy features they expected...
很多人都没明白对方说的是什么就上来求助了。
所以他们自己表达出来的很多题 都需要加以推敲， 是不是真正的原题。
2. features cases:
1) non special
2) special
先假设是case 1), 那么basic data structures 就要列出一个list
这里又分几种cases
a) 日历最重要的结构是timing
这部分又分成几个不同的组成部分
i. 当前的年月日 系统时间里取出
ii. 未来的时间年月日
iii. 过去的年月日
iv. 历史上的今天， 也包括国家假日
手机打字 不方便 胳膊都酸了
to be cont'd later
【在 p*****2 的大作中提到】
:
: 我想先整理一下core functionality， 然后开始设计。我现在没时间，晚上好好搞搞
: 。感觉这东西很有意思。
: 我们晚上搞一下吧。
p*2
31 楼
今天晚上做做这题吧？
m*t
32 楼
满版的设计题，脑袋都不够用了，我都忘光光了还有这道题，这种设计的主旋律就是，
1.先做features basics
2.在此基础上，其他的additional，一个一个往上加
通常basic requirement比较fixed，就那几个modules，timing这部分要设置几个分支
的模块
这个没有什么挑战度吧，就是围绕着不同时间的表达，再加上repeatable alerts，
还要做那个http的get/post一类的东东，就是你输入了content，要post上去的，存储
在一个local server database里，这就需要一个form结构吧
嗯，还得整个mini-DB
【在 p*****2 的大作中提到】
: 今天晚上做做这题吧？
1.先做features basics
2.在此基础上，其他的additional，一个一个往上加
通常basic requirement比较fixed，就那几个modules，timing这部分要设置几个分支
的模块
这个没有什么挑战度吧，就是围绕着不同时间的表达，再加上repeatable alerts，
还要做那个http的get/post一类的东东，就是你输入了content，要post上去的，存储
在一个local server database里，这就需要一个form结构吧
嗯，还得整个mini-DB
【在 p*****2 的大作中提到】
: 今天晚上做做这题吧？
m*t
33 楼
loca server database，这部分可以用javascript建立一个JDBC的web-based 数据系统
，这样你随时都可以show出自己的schedule
不过现在流行data center，都有动态存储servers了，应该不会再用古老的JDBC了
这种topic，要稍微了解一下目前工业所hot的DB存储模式，面试的时候，往上套就行了
，错不了
，这样你随时都可以show出自己的schedule
不过现在流行data center，都有动态存储servers了，应该不会再用古老的JDBC了
这种topic，要稍微了解一下目前工业所hot的DB存储模式，面试的时候，往上套就行了
，错不了
p*2
34 楼
假设有1 billion user
每个user平均每天new一个event
平均每天读10次
那么大概每秒10k的写和100k的读
如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
况100T应该是够了 （90%的user不怎么使用calendar）
从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
的SQL就不适合处理这么大量了。
每个user平均每天new一个event
平均每天读10次
那么大概每秒10k的写和100k的读
如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
况100T应该是够了 （90%的user不怎么使用calendar）
从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
的SQL就不适合处理这么大量了。
m*t
35 楼
这是另一个要考虑的分支，我暂时不清楚“眼下”最流行的big data的存储模式，可以
去了解一下
SQL是不能承受重负之重，如你所言，C*应该更好用
加十分！
【在 p*****2 的大作中提到】
: 假设有1 billion user
: 每个user平均每天new一个event
: 平均每天读10次
: 那么大概每秒10k的写和100k的读
: 如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
: 当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
: 况100T应该是够了 （90%的user不怎么使用calendar）
: 从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
: 的SQL就不适合处理这么大量了。
去了解一下
SQL是不能承受重负之重，如你所言，C*应该更好用
加十分！
【在 p*****2 的大作中提到】
: 假设有1 billion user
: 每个user平均每天new一个event
: 平均每天读10次
: 那么大概每秒10k的写和100k的读
: 如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
: 当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
: 况100T应该是够了 （90%的user不怎么使用calendar）
: 从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
: 的SQL就不适合处理这么大量了。
m*t
36 楼
在你发帖之前，我已经修改过原文了，因为我都是临场思考的，所以思路还在不断
update和补充中，痛苦地度过一个月黑风高的夜晚。。。
【在 p*****2 的大作中提到】
: 假设有1 billion user
: 每个user平均每天new一个event
: 平均每天读10次
: 那么大概每秒10k的写和100k的读
: 如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
: 当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
: 况100T应该是够了 （90%的user不怎么使用calendar）
: 从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
: 的SQL就不适合处理这么大量了。
update和补充中，痛苦地度过一个月黑风高的夜晚。。。
【在 p*****2 的大作中提到】
: 假设有1 billion user
: 每个user平均每天new一个event
: 平均每天读10次
: 那么大概每秒10k的写和100k的读
: 如果每个user可以使用1M的存储空间，那么total就是1PB，属于大数据了
: 当然实际使用的情况感觉应该没有这个大，但是potentilly还是可能的, 我感觉实际情
: 况100T应该是够了 （90%的user不怎么使用calendar）
: 从这个分析来说， Cassandra handle起来应该没什么问题，是一个不错的选择, 一般
: 的SQL就不适合处理这么大量了。
p*2
37 楼
就像月光说的，先分析core functionality
一般就是CRUD，这个用rest来实现就很好，frontend就先不提了，都是JS的工作
那么这步重要的是设计C＊的schema
我刚才看了一下，主要的大概有这样的信息
user gmail account: String
subject: String
start_at: timestamp
end_at: timestamp
Repeat: 比较复杂，可以用map
Where: string
Description: string
Reminder: map
Guests: set
NOSQL的schema的设计一般是按照query来的， Calendar的查询最典型的就是按照时间
来查询了，所以
partition key: email
clustering key: start_at
但是同一个start_at，同一个user是可以有多个event的，所以primary key里还需要另
外一个东西，我觉得可以每个event生成一个uuid，加入到primary key中。
一般就是CRUD，这个用rest来实现就很好，frontend就先不提了，都是JS的工作
那么这步重要的是设计C＊的schema
我刚才看了一下，主要的大概有这样的信息
user gmail account: String
subject: String
start_at: timestamp
end_at: timestamp
Repeat: 比较复杂，可以用map
Where: string
Description: string
Reminder: map
Guests: set
NOSQL的schema的设计一般是按照query来的， Calendar的查询最典型的就是按照时间
来查询了，所以
partition key: email
clustering key: start_at
但是同一个start_at，同一个user是可以有多个event的，所以primary key里还需要另
外一个东西，我觉得可以每个event生成一个uuid，加入到primary key中。
p*2
38 楼
辛苦了。
【在 m********t 的大作中提到】
: 在你发帖之前，我已经修改过原文了，因为我都是临场思考的，所以思路还在不断
: update和补充中，痛苦地度过一个月黑风高的夜晚。。。
m*t
39 楼
我去了解一下C*吧，既然你这么痴迷，dig out其魅力四射的激情点在哪儿。。。
先不要剧透，让我自己扛着铁锹，头顶照明灯，脚踩flashing shoes，
在伸手不见五指的夜色中，摸索无限。。。。
【在 p*****2 的大作中提到】
: 就像月光说的，先分析core functionality
: 一般就是CRUD，这个用rest来实现就很好，frontend就先不提了，都是JS的工作
: 那么这步重要的是设计C＊的schema
: 我刚才看了一下，主要的大概有这样的信息
: user gmail account: String
: subject: String
: start_at: timestamp
: end_at: timestamp
: Repeat: 比较复杂，可以用map
: Where: string
先不要剧透，让我自己扛着铁锹，头顶照明灯，脚踩flashing shoes，
在伸手不见五指的夜色中，摸索无限。。。。
【在 p*****2 的大作中提到】
: 就像月光说的，先分析core functionality
: 一般就是CRUD，这个用rest来实现就很好，frontend就先不提了，都是JS的工作
: 那么这步重要的是设计C＊的schema
: 我刚才看了一下，主要的大概有这样的信息
: user gmail account: String
: subject: String
: start_at: timestamp
: end_at: timestamp
: Repeat: 比较复杂，可以用map
: Where: string
p*2
40 楼
一般大数据了就要上NOSQL了，而NOSQL scale最好的就是C＊和HBase了。Couchbase也
许也不错，我了解的不多。其实选择面挺小的。
【在 m********t 的大作中提到】
: 这是另一个要考虑的分支，我暂时不清楚“眼下”最流行的big data的存储模式，可以
: 去了解一下
: SQL是不能承受重负之重，如你所言，C*应该更好用
: 加十分！
p*2
41 楼
我觉得存储，处理大数据是很有chanlleng的，不是说这些技术有多么好，是能干这事
的东西就很少。其实就那么几个。不然Hadoop问题那么多，还是那么流行，不是说
Hadoop好，而是没有其他的能干这活。当然现在Spark出来就不一样了。
【在 m********t 的大作中提到】
: 我去了解一下C*吧，既然你这么痴迷，dig out其魅力四射的激情点在哪儿。。。
: 先不要剧透，让我自己扛着铁锹，头顶照明灯，脚踩flashing shoes，
: 在伸手不见五指的夜色中，摸索无限。。。。
m*t
42 楼
我过了下周，会比较有空，这几天都非常忙，一堆一堆的deadline和meetings，忙得不
可开交的。
我先了解一下C*,回来再把个人的领悟和体会，report给你们。
【在 p*****2 的大作中提到】
:
: 我觉得存储，处理大数据是很有chanlleng的，不是说这些技术有多么好，是能干这事
: 的东西就很少。其实就那么几个。不然Hadoop问题那么多，还是那么流行，不是说
: Hadoop好，而是没有其他的能干这活。当然现在Spark出来就不一样了。
可开交的。
我先了解一下C*,回来再把个人的领悟和体会，report给你们。
【在 p*****2 的大作中提到】
:
: 我觉得存储，处理大数据是很有chanlleng的，不是说这些技术有多么好，是能干这事
: 的东西就很少。其实就那么几个。不然Hadoop问题那么多，还是那么流行，不是说
: Hadoop好，而是没有其他的能干这活。当然现在Spark出来就不一样了。
p*2
43 楼
好 感觉你很像pm
【在 m********t 的大作中提到】
: 我过了下周，会比较有空，这几天都非常忙，一堆一堆的deadline和meetings，忙得不
: 可开交的。
: 我先了解一下C*,回来再把个人的领悟和体会，report给你们。
【在 m********t 的大作中提到】
: 我过了下周，会比较有空，这几天都非常忙，一堆一堆的deadline和meetings，忙得不
: 可开交的。
: 我先了解一下C*,回来再把个人的领悟和体会，report给你们。
m*t
44 楼
你很聪明。。。^_^
【在 p*****2 的大作中提到】
: 好 感觉你很像pm
【在 p*****2 的大作中提到】
: 好 感觉你很像pm
相关阅读