从新浪微博看海量数据存储解读.docx

从新浪微博看海量数据存储?? 2014-01-05 20:13:34|??分类：?实验报告?|??标签：海量存储??|举报|字号?订阅 从新浪微博看海量数据存储? 一、新浪微博简介及特点 （一）新浪微博简介 新浪微博是一个由新浪网推出，提供微型博客服务的类Twitter网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片。新浪可以把微博理解为“微型博客”或者“一句话博客”。用户可以将看到的、听到的、想到的事情写成一句话，或发一张图片，通过电脑或者手机随时随地分享给朋友，一起分享、讨论；还可以关注朋友，即时看到朋友们发布的信息。 （二）新浪微博的特点 1.操作简单，信息发布门槛极低 140个字发布信息，在文字的基础上可以同时上传图片，视频等连接。内容不限制，所见所闻，所思所想，生活琐碎和宏大主题均可发布。 2.平台广泛，随时随地传播信息 除了电脑以外，手机的在线发布，使得使用广泛。支持手机等平台，通过手机发布，实现了全息发布方式，真正实现了随时随地发布和接收信息。 3.传播速度快，传播方式呈裂变 利用各种转发，名人推荐，媒体合作等，以不同的话题和主题，博得潜在消费人群的关注。新浪微博的传播路径：一个是“粉丝路径”。?A?发布信息后，A?的所有粉丝，都可以实时接收信息；另一个是“转发路径”。如果甲觉得A?的某条微博不错，他可以“一键”转发，这条信息立即同步到甲的微博里，同时，甲的所有粉丝，又都可以实时接收信息，然后以此类推，实现“病毒式”传播。 4.?信息交互简便快捷 除了上面所述的关注和转发功能，新浪微博还有“评论功能”、“回复功能”、“私信功能”，同时每次信息交互产生后给予用户新消息的提示，达到实时交互。这些功能为用户之间的信息交互提供了保证。 作为互联网3.0时代的产品，我认为其特点的核心为“微·快”。相比1.0和2.0时代下的网站和博客论坛，微博的发布对用户要求大大降低（无论是所需技术还是时间），发布信息微小符合快速阅读下的“快餐文化”。同时“快”还体现其传播速度之快，常常短时间引发巨大的讨论。 二、新浪微博数据库 新浪微博的特点决定了其使用的数据库，而且不断增加的用户数和访问量也导致其架构和数据库上的改变。 （一）MySQL数据库 新浪微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。最开始采用的是推的消息模式。新浪微博首席架构师杨卫华是这么描述的“假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。”?第一版的技术细节，典型的LAMP架构（Linux作为操作系统，Apache和Nginx作为Web服务器，MySQL作为数据库，PHP/Perl/Python作为服务器端脚本解释器），是使用Myisam搜索引擎，它的优点就是速度非常快。 后来随着用户越来越多，访问量剧增。每时每刻都有大量的信息被发布，最初的架构就有延迟的问题，而用户需要的是根据关注关系实时投递。后来就有了分片（分库分表）、拆分、异步处理和分布式系统。 1.sharding（分片） Sharding（分片） 只用于数据量大同时有性能瓶颈的库，大部分库不进行sharding处理。对于数据量比较大的库，在一开始就考虑sharding策略，例如索引数据和内容数据分开设计，每类数据库根据业务逻辑选择恰当的partitioning key，拆分成一定数量的表。（见图一）然后随着压力的增加进行垂直拆分，垂直拆分后的库再遇到性能瓶颈时首先考虑用硬件来解决。当硬件解决不了时才开始考虑水平拆分。在选择sharding方案时仔细考虑业务逻辑。对于读密集型应用，基本上通过增加slave来解决，对于写密集型应用才进行垂直和水平拆分工作。（图二） 图一 按不同partitioning key进行拆分 图二?master/slave的拆分 跨越越多的sharding，带来的开销就越大，这个数量是如何控制的？新浪首席DBA杨海潮这样回答的“目前我在设计之前就避免跨表操作，选择适当的paritioning key，也即合适的拆分维度，避免对后期业务的影响。根据业务逻辑的重要程度，如果业务逻辑是查询某一个用户的信息，那么会按用户进行拆分，那么保证一个用户的数据是落在一张表里面。按时间维度进行拆分，那么会分析数据的冷热程度，把80%以上的数据放在一个表，避免过多的跨表查询。在这种拆分维度满足不了业务需求时，我们会利用空间换时间的思想，同一份数据按多种维度进行拆分，让每种业务逻辑的查询语句都有很高的效率。” 关于sharding（分片）和partitioning（划分），sharding通常是指垂直拆分和水平拆分，是一个总体的概念，mysql的partiti