Google大牛JeffDean在WSDMACM的Web搜索和数据挖掘研讨会2009上面的演讲1.ppt

处理增长 处理增长 处理增长 推论 分片服务器的响应时间受到下列因素的影响： 需要完成的磁盘寻道数 从磁盘读取的数据量 重大性能改进可能来自于： 更好的磁盘规划 改进索引编码格式 1997-1999的索引编码格式 原始编码(97)很简单： hit:位置加上属性(字体尺寸，标题，等等) 对大的posting lists加上跳表 简单，字节对齐格式 解码开销小，但是不够紧凑 …需要大量的磁盘带宽 编码技术 位级编码： Unary(一进制编码):N个‘1’后面跟着个‘0’ Gamma:?log2(N)以一进制编码，后跟余数的二进制表示 Ricek:floor(N/2^k)以一进制编码，N mode 2^k在k位中 这个编码是当底为2的幂时，Golomb编码的一个特例 Huffman-Int:类似Gamma，只是log2(N)以Huffman编码来编码，而不是用Unary来编码 字节对齐编码： 变体：每个字节7位，加一个校验位 0-127:一个字节，128-4095:两个字节 基于块的索引格式 基于块的变长格式减少空间占用和Cpu开销 ?? ?块格式（N个文档，H个hit） ?降低索引尺寸约30%，解码更快 更深入的分片的推论 索引尺寸增大时必须加入新的分片来保持快速响应 …查询开销随着分片数的增加而增加 一般 = 1个磁盘寻道/分片/查询词 甚至是对于那些冷门的词 随着副本数量增加，可用内存总量也增加了 终于，有足够的内存保存整个索引的副本在内存中 从本质上改变了许多设计参数 2001年初: 内存内索引 内存索引系统 许多优点： ?大幅增加吞吐量 大大降低延迟 尤其是尾部：以前需要数GB磁盘I/O的开销较大查询变得更快了（例如：“circle of life”） 一些问题： 变化：需要触及上千台服务器，而不是十几个 例如，随机化的定时任务曾给我们带来很多麻烦 可用性：每个文档的索引数据只有1个或少数几个副本 查询的死亡可以一次性杀死所有的后端：非常不好 当有机器失效的时候索引数据的可用性（尤其是重要文档）：复制重要文档 大规模计算 现在的机器 机架自行设计 PC级主板 低端存储和网络硬件 Linux +自行设计的软件 服务设计，2004版本 新的索引格式 基于块的索引格式采用两级索引方案 每个hit编码为(文档编号，词的位置)形式的对 文档编号的偏移用Rice编码来编码 压缩率很高(原本为基于硬盘的索引设计)，但是解码较慢，对CPU性能很敏感 新格式：新的平面位置空间 旁边的数据结构保持文档的边界 Posting list仅是用偏移编码的位置 必须紧凑（不能每次出现都使用32位值） … 字节对齐变长编码 变长编码： 每个字节7位，一个连续标志位 连续标志位：解码需要大量分支/移位/掩码操作 字节对齐变长编码 变长编码： 每个字节7位，一个连续标志位 连续标志位：解码需要大量分支/移位/掩码操作 思想：用低二位编码字节长度 更好：更少的分支，移位和掩码操作 连续标志位：值只能限制在30位，解码仍旧需要移位 * 构建大规模信息检索系统中的挑战Jeff Dean?Google Fellow?jeff@翻译：银杏泰克有限公司 郝培强Tinyfool@/dev 为什么在信息检索公司工作 既有科学又有技术方面的挑战 许多有趣的未解的问题 涵盖计算机科学的诸多领域： 架构，分布式系统，算法，压缩，信息检索，机器学习，界面，等等。 规模远大于大多数其他系统 小团队就可以构建上亿用户使用的系统 信息检索系统的尺寸 必须在下列工程参数之间平衡取舍： 索引的文档数 每秒查询数? 索引的新鲜程度/更新率 查询延迟? 每个文档保存的信息? 评分/检索算法的复杂度和开销 工程难度大致等于这些参数的乘积 ?以上这些参数影响整体的性能，以及单位成本下的性能 1999 和 2009 文档数: 约7000万到数百亿?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?每日处理查询数:? ?索引中每个文档的信息数:? ?更新延迟:从月到分钟 平均查询延迟: 小于1秒到小于0.2秒 ?更多机器*更快的机器:? 约100倍 约1000倍 约3倍 约10000倍 约5倍 约1000倍 唯一不变的是改变本身 参数随时在变 常常是几个数量级的改变 在X规模下正确的设计在10X或100X规模下可能完全是错的 …以10倍规模的增长设计系统，在100倍增长之前计划重写系统 持续进化： 10年间7个重大版本 经常推出新版本，但是用户完全不知道我们做出了重大改变 其余要讨论的 Google搜索系统的演化 几代 抓取/索引/服务 系统 底层架构的简要描述 许多许多人一起工作 有趣的方向和挑战 1997年的Google