淘宝应对"双11"的技术架构分析

图3 MyFOX的数据查询历程

　　现在，存储在MyFOX中的统计效果数据已经到达10TB，占有着数据魔方总数据量的95%以上，而且正在以天天凌驾6亿的增量增加着（如图2所示）。这些数据被我们近似匀称地漫衍到20个MySQL节点上，在查询时，经由MyFOX透明地对外服务（如图3所示）。

图4 MyFOX节点结构

　　值得一提的是，在MyFOX现有的20个节点中，并不是所有节点都是“同等”的。一样平常而言，数据产物的用户更多地只体贴“最近几天”的数据，越早的数据，越容易被萧条。为此，出于硬件成本思量，我们在这20个节点中分出了“热节点”和“冷节点”（如图4所示）。

　　顾名思义，“热节点”存放最新的、被会见频率较高的数据。对于这部门数据，我们希望能给用户提供尽可能快的查询速率，以是在硬盘方面，我们选择了每分钟15000转的SAS硬盘，根据一个节点两台机械来盘算，单元数据的存储成本约为4.5W/TB。相对应地，“冷数据”我们选择了每分钟7500转的SATA硬盘，单碟上能够存放更多的数据，存储成本约为1.6W/TB。

　　将冷热数据举行分散的另外一个利益是可以有用提高内存磁盘比。从图4可以看出，“热节点”上单机只有24GB内存，而磁盘装满约莫有1.8TB（300 * 12 * 0.5 / 1024），内存磁盘比约为4:300，远远低于MySQL服务器的一个合理值。内存磁盘比过低导致的结果是，总有一天，纵然所有内存用完也存不下数据的索引了——这个时间，大量的查询请求都需要从磁盘中读取索引，效率大打折扣。

　　NoSQL是SQL的有益增补

　　在MyFOX泛起之后，一切都看起来那么完善，开发职员甚至不会意识到MyFOX的存在，一条不用任何特殊修饰的SQL语句就可以知足需求。这个状态连续了很长一段时间，直到有一天，我们遇到了传统的关系型数据库无法解决的问题——全属性选择器（如图5所示）。

图5 全属性选择器

　　这是一个很是典型的例子。为了说明问题，我们仍然以关系型数据库的思绪来形貌。对于条记本电脑这个类目，用户某一次查询所选择的过滤条件可能包罗“条记本尺寸”、“条记本定位”、“硬沈阳小程序定制盘容量”等一系列属性（字段），而且在每个可能用在过滤条件的属性上，属性值的漫衍是极不匀称的。在图5中我们可以看到，条记本电脑的尺寸这一属性有着10个枚举值，而“蓝牙功效”这个属性值是个布尔值，数据的筛选性很是差。

　　在用户所选择的过滤条件不确定的情形下，解决全属性问题的思绪有两个：一个是穷举所有可能的过滤条件组合，在“云梯”上举行预先盘算，存入数据库供查询；另一个是存储原始数据，在用户查询时凭据过滤条件筛选出响应的记载举行现场盘算。很显着，由于过滤条件的排列组合险些是无法穷举的，第一种方案在现实中是不行取的；而第二种方案中，原始数据存储在什么地方？若是仍然用关系型数据库，那么你计划怎样为这个表建设索引？

　　这一系列问题把我们引到了“建立定制化的存储、现场盘算并提供查询服务的引擎”的思绪上来，这就是Prometheus（如图6所示）。

图6 Prom的存储结构

　　从图6可以看出，我们选择了HBase作为Prom的底层存储引擎。之以是选择HBase，主要是由于它是建设在HDFS之上的，而且对于MapReduce有优秀的编程接口。只管Prom是一个通用的、解决共性问题的服务框架，但在这里，我们仍然以全属性选择为例，来说明Prom的事情原理。这里的原始数据是前一天在淘宝上的生意业务明细，在HBase集群中，我们以属性对（属性与属性值的组合）作为row-key举行存储。而row-key对应的值，我们设计了两个column-family，即存放生意业务ID列表的index字段和原始生意业务明细的data字段。在存储的时间，我们有意识地让每个字段中的每一个元素都是定长的，这是为了支持通过偏移量快速地找到响应记载，制止庞大的查找算法和磁盘的大量随机读取请求。

 2/4   首页 上一页 1 2 3 4 下一页 尾页