帮你存储社交数据的十大对策

社交数据正在以前所未有的速度猛烈袭来。Facebook已经拥有约十亿用户，而Twitter的使用群体数量也在逼近五亿大关。这样的规模在过去简直无法想象。如今的Youtube网站需要提供体积庞大的音频与视频文件，同时还得十亿用户的评论及态度信息。更不用说其它一些社交媒体站点及企业社交应用所保存的海量非结构化数据了。

那么我们就在这里一同讨论应对社交存储需求持续上温的方案。

1. 单体体积小

要着手处理社交数据存储工作，第一步是了解其主要特征——即总容量庞大但单体体积较小。这与其它存储类型有着明显差异。

“社交媒体数据大多数体积较小——博文、推文以及图片等等都是如此。”NetApp公司大数据解决方案高级经理Bill Peterson注意到。“甚至视频资料在社交领域都保持着小巧的身材。”

2. 根据对象制定策略

即使同样是社交媒体数据存储工作，在不同平台上的处理方式也在所不同。举例来说，像Twitter与Facebook这样的企业需要把数据集中存储以满足用户们的浏览操作。另外，为了批量取回社交媒体数据，企业用户可以尝试对数据加以分析并深入了解其内容。前者就是我们通常所说的foreground copy，而后者则被称为background copy。

“基于对象的存储策略与goreground copy可谓天作之合，因为对象存储需要通过总体体积与地理跨度两大要素来形成一定规模，借以满足应用程序‘将所有图片保存在Facebook中’或‘将所有推文保存在企业VPN中’的需求，”Peterson解释道。“对象存储系统通常拥有基于http的接口，这使得技术人员能够轻松把此类对象引用到Web页面中并加以显示。

3. 分析友好特性

在背景（即社交媒体数据归档副本）方面，进行保存的最佳实践目的在于深入分析并掌握其宏观内容。为了让分析平台完成这项任务，我们通常需要将大量小型对象捆绑在一起形成大型文件。举例来说，如果大家想分析推文内容，必须先拥有一个包含着所有推文信息的整体文件，而非每条推文构成单独文件（或对象）。Hadoop就是处理这类分析任务的平台方案之一。

“Hadoop在处理大型文件（GB、TB乃至PB级别）方面效果拔群，但在处理大量小型文件方面则显得比较疲软，“Peterson解释道。”Hadoop还擅长处理数据流访问工作，可以说这套方案在设计上主要针对的是一次写入、多次读取的数据存储需求。“

4. 追求速度

社交数据要的就是速度。用户通常无法容忍应用程序出错或缓慢的服务响应，遇上这类情况，他们会果断移步其它社交平台。

“打理社交数据要求存储机制能够以接近实时的方式提供信息，这一特性使固态硬盘成为首选解决方案，”SMART Storage Systems公司总裁John Scaramuzzo建议道。“不过请大家注意，采用低成本MLC闪存的固态硬盘更加耐用，这样才能确保我们在获得预期的生产能力之外避免驱动器损坏给业务造成的不良影响。”

5. 慢速归档

我们显然不能简单把访问量稀少的社交数据直接丢弃、只保存那些更为热门的媒体资料。毕竟没人希望当法律部门的家伙来搜集证据时，自己只能无奈地告诉对方数据被删掉了。有鉴于此，我们应该根据机构的具体需要将数据划分为冷门与热门两大类。热门数据需要始终拥有快速响应能力，而其它的部分的访问速度则完全可以做出一定妥协。

“对于那些使用频率不高的数据，100毫秒左右的响应速度已经完全能够接受了，”Peterson表示。“而更冷门一些的对象则不妨采取更长的响应时间。”

6. 至少三层结构

Peterson建议大家至少在存储体系中部署三层结构：内存内（或闪存内）层、磁盘层以及冷门数据层。由内存内向磁盘层移动的过程需要经由基础缓存。而再向冷门数据层的移动过程则涉及将大量小型对象整合为少量大型对象的操作。

“如果大家不这样做，那么旧有数据层就会因为对象数量过多而陷入瘫痪，”Peterson补充道。