Viacom:Redis在系统中的用例盘点
Viacom是全球最大的传媒集体之一,同时也遭遇了当下最大的数据难题之一:如何处理日益剧增的动态视频内容。
着眼这一挑战的上升趋势,我们会发现:2010年世界上所有数据体积达到ZB级,而单单2012这一年,互联网产生的数据就增加了2.8个ZB,其中大部分的数据都是非结构化的,包括了视频和图片。
覆盖MVN(以前称为MTV Networks、Paramount及BET),Viacom是个名副其实的传媒巨头,支持众多人气站点, 其中包括The Daily Show、osh.0、South Park Studios、GameTrailers.com等。作为媒体公司,这些网 站上的文档、图片、视频短片都在无时无刻的更新。长话短说,下面就进入Viacom高级架构师Michael Venezia 分享的Redis实践:
Viacom的网站架构背景
对于Viacom,横跨多个站点传播内容让必须专注于规模的需求,同时为了将内容竟可能快的传播到相应用户,他们还必须聚焦内容之间的关 系。然而即使The Daily Show、Nickelodeon、Spike或者是VH1 这些单独的网站上,日平均PV都可以达到千万,峰值时流量 更会达到平均值的20-30倍。同时基于对实时的需求,动态的规模及速度已成为架构的基础之一。
除去动态规模之外,服务还必须基于用户正在浏览的视频或者是地理位置来推测用户的喜好。比如说,某个页面可能会将一个独立的视频片段与本地 的促销,视频系列的额外部分,甚至是相关视频联系起来。为了能让用户能在网站上停留更长的时间,他们建立了一个能基于详细元数据自动建立页面的软件引擎, 这个引擎可以根据用户当下兴趣推荐额外的内容。鉴于用于兴趣的随时改变,数据的类型非常广泛——类似graph-like,实际上做的是大量的join。
这样做有利于减少类似视频的大体积文件副本数,比如数据存储中一个独立的记录是Southpark片段 “Cartman gets an Anal Probe”,这个片段可能也会出现在德语的网站上。虽然视频是一样的,但是英语用户搜索的可能就是另一个 不同的词语。元数据的副本转换成搜索结果,并指向相同的视频。因此在美国用户搜索真实标题的情况下,德国浏览者可能会使用转译的标题——德国网站上的 “Cartman und die Analsonde”。
这些元数据覆盖了其它记录或者是对象,同时还可以根据使用环境来改变内容,通过不同的规则集来限制不同地理位置或者是设备请求的内容。
Viacom的实现方法
尽管许多机构通过使用ORM及传统关系型数据库来解决这个问题,Viacom却使用了一个迥然不同的方法。
本质上,他们完全承担不了对数据库的直接访问。首先,他们处理的大部分都是流数据,他们偏向于使用Akamai从地理上来分配内容。其次, 基于页面的复杂性可能会取上万个对象。取如此多的数据显然会影响到性能,因此JSON在1个数据服务中投入了使用。当然,这些JSON对象的缓存将直接影 响到网站性能。同时,当内容或者是内容之间的关系发生改变时,缓存还需要动态的进行更新。
Viacom依靠对象基元和超类解决这个问题,继续以South Park为例:一个私有的“episode”类包含了所有该片段相关信 息,一个“super object”将有助于发现实际的视频对象。超类这个思想确实非常有益于建设低延迟页面的自动建设,这些超类可以帮助到基元对象到 缓存的映射及保存。