【IT168 应用】社交数据正在以前所未有的速度猛烈袭来。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补充道。7. 存储配置文件

　　社交配置文件数据是指用户通过注册Facebook或谷歌服务进而登录站点时所产生的信息。其中包括个人喜好、兴趣、好友列表等等。这部分数据非常重要，因此需要以安全高效的方式加以存储。

　　“大多数配置文件数据本身被以文档索引形式加以保存，这是出于性能方面的考虑，”Janrain公司产品副总裁Vidya Shivkumar指出。“另外，在某些情况下这些数据也可能被保存在关系类数据库中以满足查询需求。”

　　举例来说，Janrain公司就利用了关系类、键值存储与文档索引。

　　8. 总量巨大

　　社交数据的总量很可能极为庞大，需要企业用户为其配备同样庞大的存储阵列。在很多情况下，利用来自Amazon、谷歌、微软等企业的云存储服务可能是满足这方面的需求的非常好的选择。Janrain公司就使用了Amazon的基础设施托管方案。

　　“企业为什么一定要亲手打理存储事务呢?”Shivkumar反问道。“很多供应商都推出了这类功能性服务，管理者没有理由不认真加以考量。”

　　9. 不要对重复数据删除报太大期望

　　重复数据删除的效果要依工作负载的具体情况而定。例如在传统备份及虚拟机领域，重复数据删除功能可以带来优秀的空间节约比率。然而在推文及博客等往往需要经过压缩的信息面前，重复数据删除技术的效果就要大打折扣了——虽然在图片方面的收益还算不错。

　　“之所以重复数据删除发挥获得良好作用，主要是因为很多用户会上传同样的图片，”Peterson解释道。

　　10. 无需备份

　　Peterson指出，社交数据一般不会采取通常意义上的备份手段。相反，由于基础设施分布在各地，信息副本也会同时保存在每套设施当中。举例来说，NetApp公司推出的StorageGrid就允许用户通过元数据查询创建数据类。

　　“我们可以数据类添加一些规则，例如要求至少在两个不同的数据中心处保存两套副本，”Peterson指出。“整个过程跟备份无关;这只是一款引擎，用于确保无论发生何种情况、我们的数据都在两个不同的物理地点拥有两套副本。”