| Twitter | Del.icio.us | Comments (14) | | Edit

Comments Powered by Disqus

留言评论 | Comments (14)

ePoll到底是什么?到底能搞什么?
似乎涉及到linux 内核了,没有细看

"一个大视频可能分成多个小文件" ----主要目的是为了节省带宽,优酷的下载并不是多线程的。比土豆快的原因主要在于CDN建设的好。

SSD上跑数据库的话,应该是利用0寻道时间的优势来支撑起读操作吧,如果连写操作都用SSD,如何保证SSD寿命问题?没法去北京现场,不知道是否涉及了这个话题?

epoll是linux下的一个函数了。
一开始是select,后来变成了poll。然后epoll有要代替poll拉。

这次会的内容好像非常丰富阿

数据库

优酷对数据库 Sharding 做了不少尝试,而且实现效果应该不错。DB 读写分离上有比较丰富的经验。


这张图看上去。难道还要去查询下user103所在的库位置?
这不是多了一步查询吗?意义不大。


epoll能改变原来select方式对大连接的问题。对网络本身的吞吐量没啥改进吧。

好文,收藏至20ju.com

TO 冷烟:

那样做,比较灵活吧。用户可以轻易的在不同的shard之间迁移。

不错的会场,又是在哪个五星级宾馆么?

不需要把原视频分段也能够分段下载啊。

如果说效果好,指的是拖拉的话,还说得过去(这样flv的metadata也是分段下载好的了,不需要统一等前面的下载完)

好文,收藏之,以后继续拜读楼主的大作!

如果说效果好,指的是拖拉的话,还说得过去(这样flv的metadata也是分段下载好的了,不需要统一等前面的下载完

这次会的内容好像非常丰富,酷对数据库 Sharding 做了不少尝试,而且实现效果应该不错。DB 读写分离上有比较丰富的经验。

To 冷烟

图中可以看出,他们把用户的资料分散到很多个shared去了。

可以这样考虑:所有用户分享的视频信息总量有1000个盘块。假设查询的时候只会做线性查询。

如果都放在一起,每次查某个视频的信息平均要查500个盘块。

如果按照图里面的方法,假定每个shared最大占50盘块。记录某个用户在哪个shared的表占5个盘块。
第一次查用户信息在哪个shared,平均2.5盘块
第二次查视频信息,平均25盘块
两次查询 一共27.5盘块。

查询是有两次,但可以少查询那么多盘块,提速是非常明显的。