五千年(敝帚自珍)

主题:【半原创】Flickr 网站架构研究(1) -- 西电鲁丁

共:💬69 🌺366
全看树展主题 · 分页首页 上页
/ 5
下页 末页
家园 送花得宝

恭喜:你意外获得【通宝】一枚

鲜花已经成功送出。

此次送花为【有效送花赞扬,涨乐善、声望】

[返回] [关闭]

家园 据我粗浅的理解,shard就是把数据库横着剖分开

每个shard上的数据库结构看起来都差不多,shard A上面如果有某些表,表里存着一些客户的某些类型的数据(评论啦,照片的metadata啦等等),那么shard B上也是这么一套,只不过是针对另一些客户。文章中也说“Shard只适用于不需要join操作的表”,也就是说各客户之间的交互应该是很少的。如果是办一个用户之间交互很多的,比如Facebook这样的网站,这个架构就完全不适合了。这时候可能要把数据库纵向剖开,关于论坛的数据库在一个服务器上,在线聊天的又在另一个上……

家园 每个shard上的数据库结构应该是基本一样的,

客户之间的交互主要靠数据冗余,即两边各放一份,牺牲空间换效率;把不同的表放在不同的数据库上只适合于不太大的表;没看到太多的关于Facebook的介绍,(暂时也没有时间,先完成这个系列再说,坑里不再挖坑)不过Facebook的规模比Flickr要大得多,根据2008年的数据,Flickr的服务器数量大约是几百台,而Facebook是上万台,光Memcached服务器就有6,7百台,也可能是象你说的,不过应该更进一步,关于论坛的数据库在一个Shard集群(包括中央数据库和多个Shard)上,在线聊天的又在另一个上……

Shard+Memcached基本上是各大网站的事实标准了。

家园 做大做小

在IT领域想做出一点成就,首先要认准方向。

什么方向容易出成果?要么做大,要么做小。

像云计算类似的技术,就是“大”的技术。上万台servers的集群,能不能协调作战,充分发挥能力,这就是做大的功夫。

Yahoo网站的开通,使大家认识到了大型网站的技术难度。但是直到Amazon和Ebay发轫以后,大家才看到大型网站的技术方向。Google,Flickr,Facebook等等后起的大型网站,把做大的技术又大大推进了一步。

研究Flickr的架构,与Google的技术横向比较,是一个苦活,但是惟其艰苦,越发彰显其价值。

这个系列写得好,值得反复阅读,细细体会。过几天,我写篇读后感,一来与鲁丁兄交换想法,二来表达对兄台与大家分享这么有意义的文章的感激。

家园 谢谢邓兄参与讨论,花谢!

Flickr(服务器规模几百台),Facebook(上万台),Google(几十万台)应该是比较典型的大型网站,比起后两者,Flickr只能算小弟弟,所以研究起来也是相对最”容易“的。文章的主要信息来源包括我曾经在河里推荐的 "http://highscalability.com/"和Cal Henderson 的书”Building Scalable Web Sites“,一些细节是我自己的推测和其他网站资源的参考和印证,不一定完全正确,但正如我前面所说,主要是抛砖引玉,希望引得各位大牛参与讨论,可以共同学习,提高。

家园 几个疑问

1.

服务器的硬件配置:

- 6-disk 15K RPM RAID-10.

- 2U boxes.

RAID 放在何处?2U boxes在何处?能不能在上图中标一下?

2.

Storage Manager

- 运行私有的,适用于海量文件存储的Flickr File System

为什么需要重新发明一套Flickr FS,它与NFS之类有什么区别?

3.

“Dual Tree"架构是”Master-Master"和“Master-Slave"的有效结合,双Master 避免了“单点故障”,Master-Slave又提高了读取速度,因为用户表的操作90%以上是读。

只见到Master-Master,但是没有见到Master-Slave。猜想一下,如果Master是照片的元数据,那么Slave应该是照片本身,而照片是存在NetApp + Flickr FS里的。猜想正确吗?

总体感觉,这个架构的针对性非常强。如果flickr的业务发生重大变化,这套架构似乎就得动大手术了。

家园 关于Master-Master和Master-Slave

读了第二篇,发现先前的理解出错了。Master也好,Slave也好,读写的对象都是元数据。

再次看看结构图。是不是可以这样理解,

1. 在“Dual tree central DB”那个框中,描绘了双Master以及Slaves,只不过没有具体把各个Master与它所管辖的Slaves,用连线串在一起。

2. "Master-master shards" 这三个框没有画完整。最好画成“Shards”,每一个shard的框中,不仅有两个Masters,还有所属的Slaves。

另外,又想到一个问题。

Memcached Cluster

- 中间层缓存服务器,用于缓存数据库的SQL查询结果等。

当数据库中的相关数据更新以后,Memcached 如何随即更新?会不会也像Master向Slaves同步那样,当Memcached cluster规模大了以后,就各个Memcached node,无法及时保持一致?

家园 不好意思,图都不是原创,从PPT里COPY来的

1。 这个RAID-10根据我的理解应该是服务器的内置SCSI硬盘;2U是指刀片服务器的厚度,1U等于4.45厘米,2U就是8.9厘米,大型机房大都用这种标准机架。

2。这个会在这个系列的后续里介绍,正在积累资料,不过关于Flickr FS的资料很难找。

3。照片的元数据是在Shard里,照片本身是存在NetApp,Flickr FS根据我现在的理解是一个分布式文件系统中间件。

总体感觉,这个架构的针对性非常强。如果flickr的业务发生重大变化,这套架构似乎就得动大手术了

,最近我所看到的是Flickr新增了Video共享功能,网上评论说自从被Yahoo收购后Flickr的进取心好像差了许多,可能和Yahoo自身的经营状况有关,Flickr是被包括在Yahoo向微软出售的优质资产里的,虽然交易没成,另外Flickr的两位创始人夫妇也先后离开了Yahoo,有传言说他们可能会创办一家社交游戏网站。

架构的变化不好说,如果有重大改变,也许会另起炉灶,技术的发展使几年前不可能的事情变成了可能,如果重新设计,应该能有更多的选择。

家园 关于MemCache与Slave的比较

1.

Flickr为中央数据库配置了Memcached作为数据库缓存,接下来的问题是,为什么用Memcached?为什么Shard不需要Memcached?Memcached和Master,Slave的关系怎样?

增加一个问题,从第一篇的图中看,Central DB同Shard一样,也有Master和Slave的配合。所以问题是,既然Central DB已经有了Slave,负责“读”,为什么还另外需要MemCached?

2.

"Write Through Cache"就是将所有的数据库”写“操作都先写入”Cache",然后由Cache统一去更新数据库的各个Node,“Write Through Cache"维护每一个Node的更新状态,当有读请求时,即将请求转向状态为”已同步“的Node,这样即避免了复制滞后和Memcached的同步问题,但缺点是其实现极为复杂

这里所说的“Cache”,是不是指MemCached?如果是这样的话,任何对Central DB的更改,先要放到MemCached里去,然后再push到Central DB?

这样颠倒主次关系的做法,是不是很容易make troubles?

家园 解释得很清楚

1. 关于服务器的硬件配置,是我先前理解错误。经兄台解释,恍然大悟。

2.

照片的元数据是在Shard里,照片本身是存在NetApp,Flickr FS根据我现在的理解是一个分布式文件系统中间件。

这个猜测很靠谱。同意。

多谢!

家园 shard的问题

同意荷包兄的意见,shard可以按行切,也可以按列切。

按行切的麻烦在于join operation会很麻烦。

按列切,join的事情好办些,但是读某个用户的所有数据时,速度会放慢。

家园 MemCached不负责Shard

同意鲁丁兄的看法,MemCached只负责Central DB的事情,而与Shard无关。

但是疑问是,Central DB本身已经有了Slave,为什么还需要额外加MemCached?

家园 老兄是认真看了。呵呵

1。这个架构图是从Cal Henderson的PPT里直接拷过来的,版权不是我的

2。如果我的理解没错的话,在Shard里,只有一对Master-Master,没有Slave。我想这是因为Shard已经切分得足够小,虽然大多数操作可能还是读,但已经没必要加Slaves,如果业务增加的话,会再次切分。

关于Memcached集群,文中没有提到是Memcached没有冗余和HA,每个数据根据hash key的值,只存在一个memcached的服务器的内存里,没有复制,因而一旦这个服务器垮掉了,memcached client端会重新计算hash key的值,应用逻辑每次要判断如果数据不在memcached里,会从数据库里再取,同时一旦更新也要同步更新memcached和数据库,这也是为什么Flickr要写一个write-through cache层的原因。

具体memcached的细节请参见外链出处,不好意思,篇幅有限,很多东西没有说清楚,有时间我会再修改的。

家园 1。这个原因我已经写了

Memcached作为数据库缓存的作用主要在于减轻甚至消除高负载数据库情况下频繁读取所带来的Disk I/O瓶颈,相对于数据库自身的缓存来说,具有以下优点:1)Memecached的缓存是分布式的,而数据库的缓存只限于本机;2)Memcached 缓存的是对象,可以是经过复杂运算和查询的最终结果,并且不限于数据,可以是任何小于1MB的对象,比如html文件等;而数据库缓存是以"row"为单位的,一旦"row"中的任何数据更新,整个“row"将进行可能是对应用来说不必要的更新;3)Memcached的存取是轻量的,而数据库的则相对较重,在低负载的情况下,一对一的比较,Memcached的性能未必能超过数据库,而在高负载的情况下则优势明显。
 一般来说内存访问是要快过disk的;

Memcached更多的是扩展了数据库的”读“操作,这一点上它和Slave的作用有重叠
 事实上,网上关于应用memcached还是Slave,一直是有争议的。

一个更激进的想法是所谓的"内存数据库",即所有数据都放入内存,数据库只是作为persist store, 参见http://natishalom.typepad.com/nati_shaloms_blog/2008/03/scaling-out-mys.html

2。 这个Cal Henderson自己也承认是很麻烦,是不是一定要这样做,有没有更好的办法,也许只有身在其中才知道。

这个cache根据我的理解是memcached,不过不敢肯定。

家园 我的问题应该这样表述

既然MemCached有什么多好处,尤其是对于“读”来说,这些好处更明显。那么为什么Central DB还需要Slave?

增加了Slave,对于“读”来说,看不出有太多好处,但是对于“写”来说,增加了同步的负担。

或许,是因为历史原因?也就是说,Flickr还没有来得及完全改造好?

全看树展主题 · 分页首页 上页
/ 5
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河