海量索引数据的机群分布.docx
- 文档编号:5738174
- 上传时间:2022-12-31
- 格式:DOCX
- 页数:18
- 大小:179.29KB
海量索引数据的机群分布.docx
《海量索引数据的机群分布.docx》由会员分享,可在线阅读,更多相关《海量索引数据的机群分布.docx(18页珍藏版)》请在冰豆网上搜索。
海量索引数据的机群分布
海量索引数据的机群分布
2010-07-1811:
27
索引数据的存储是搜索中很重要的一个环节,在数据量较小的情况下,如普通的中小网站,一般存在的文档数在千万级以下,这个时候,可以简单的实现搜索系统,将所有的索引数据存放在一台机器上。
而网页搜索引擎需要索引的数据重量到了上百亿上千亿的级别。
因此,需要成千上万台的机器来存放如此巨量的网页数据。
那么如何将如此巨量的数据分布存放到这些机器上呢?
较为简便直观的方法是每台机器上存放一定不相同的文档集合,每个机器对不重复的一部分网页文档建立索引。
即按照文档分割的方式分布。
按照文档分割的方式,分布规则有几种:
1)简单按照docid取模,比如有N台索引机器,则第i台机器处理的文档的集合为dataset(i)={docid|docid%N=i},这样处理的好处有几个:
i.数据分布均匀,海量的数据,取模基本可以保证每个机器上分布着数量相当,大小相当的网页文档索引。
ii.docid定位方便,要查找一个docid的数据在那个机器上,简单取模即可定位。
iii.定位方便带来的一个直接好处是文档数据更新方便,一个doc的数据始终在一个机器上,更新时标记删除上面旧的数据,索引保存新的数据即可。
最大的缺点则是扩容麻烦,当总数据量超过N台机器的最大装载量,需要扩容到N+1台机器时,原来的数据分布被全部打散,数据在N+1台机器上需要全部重新分布。
2)针对取模分布方式扩容不方便的问题,引入了按照路由表分布。
缩小数据集合的切分粒度,比如N台机器,存放的数据集是mN个.定义一张路由表,给出每个数据集存放在哪个机器上。
当数据量增大时,数据集个数保持不变,而每个集合内的数据量增加。
机器数从N增加到N+i,则每个机器上存放的数据集个数减少,变为mN/(N+i)。
这时,让之前的N台机器上各取出mi/(N+i)个数据集重新分布到新增的i台机器上。
然后只需要重新定义一张新的路由表,建立一个新的路由关系。
这样的好处是,扩容的时候,不需要对所有的数据做重新分布,只需要对需要变动的数据进行搬迁。
一个要求是m需要取到一个合理的数值,使得N+i=系统设计的最大机器时,每个机器上仍然能够保存接近均匀数目的数据集。
3)按照时间划分,根据预期每天需要索引的数据量,计算出,每台机器能够承载的索引天数。
第[iN,(i+1)N)天内的数据放到第i台机器上。
这样处理的好处是扩容方便,直接增加新的机器用来存放新的索引,老的机器和数据不用动。
缺点是docid定位不方面,没有明显的规则快速计算出一个doc存在在哪个机器上。
4)按照doc的类型来划分。
数据的类型可以有多种定义:
比如按照来源类型(新闻,博客,论坛...),按照数据的好坏(pr高低,是否重点网站)按照类型划分的好处是,可以根据检索请求,针对不同类型的数据做不同的检索处理。
这种划分方式通常和其它的划分方式复用。
5)按照索引项来划分。
倒排索引的组织结构是一系列索引项到每个索引项存在的文档序列的映射。
当数据量大到无法用单机来装载时,则可以按照索引项进行分割,不同的机器存放不同索引项的倒排列表。
索引项分割的方式也可以有多种
i.简单按照索引项ID取模
ii.按照索引项的访问频度;访问频度高的可以在多个机器上存放多套索引。
按照索引项来划分的缺点是,在检索时,如果一个检索串涉及到多个索引项的求交。
而这多个索引项可能分布到多个不同的机器,则需要将这几个索引项的倒排数据传输到一个集中的机器上进行求交处理。
这将增加系统的复杂性和检索耗时。
6)混合划分部署
现实应用中,往往不是简单的使用上面的一种划分,而是将多种划分混合使用。
比如先按照时间来做一层划分,分离出时新性数据和非时新性数据。
对非时新性数据再按照页面质量划分,按照数据类型划分,按照文档取模/路由划分,特定的数据会再按照索引项来划分。
以上是各种常见对索引数据在多机上分布的方式。
前些年google开发了gfs,bigtable等分布式系统,来通过进行数据的分布式存储管理,并提供自适应的多副本容灾容错,平台扩容等功能。
国内外各大公司和开源组织也跟上开发类似的系统。
其基本的原理也可以认为是采用了一种类似路由表的方式来对数据进行分布查找定位。
当然,使用这样系统的好处是上层应用在某种程度上,不需要关心数据与底层具体硬件位置的关联了。
高性能、高流量互联网应用架构设计实战原则
2009-05-1814:
22
FreeWheel是由前DoubleClick高管DouglasKnopper,JonHeller和DianeYu于2007年创建,由硅谷顶级的风险投资机构BatteryVentures投资的互联网视频广告技术服务提供商,总部位于硅谷的PaloAlto,提供互联网视频广告投放、监测、预测和内容互联增值等关键解决方案。
不同于其他外资企业,FreeWheel的研发中心设在中国,数据运营中心则设立在美国纽约。
FreeWheel北京研发团队成立两年多来,在敏捷软件开发、RubyOnRails开发大型复杂商业系统、视频广告技术、完全离岸的产品研发与跨国运营等方面受到关注。
本文将谈谈FreeWheel在高性能、高流量互联网应用系统架构设计上所遵循的基本原则。
原则一:
假设故障总会发生(Designwithfailureinmind)
在设计和实现大型互联网在线应用时,架构师必须考虑到系统各模块、各应用服务器、各开源应用软件的故障比率和失效的潜在原因。
当服务的可用性(Availability)成为系统设计的首要目标时,尤其需要在设计阶段就充分考虑如何在系统某部分发生故障时,仍然保持一定的服务可用性。
一些基本的假设包括:
·没有Bug的软件不存在,只是故障率高低不同,应优先关注高故障率应用。
·硬件总会发生故障,需要备份和冗余。
·导致某应用崩溃的请求,如不能及时终止或被redirect,可能会导致所有服务器一个接一个的瘫痪。
·构建仅包括最简单输入输出逻辑和固定输出内容的Dot模式Server,以应对应用服务群大面积瘫痪或负载极限发生时的服务响应。
·每次release正式升级前,在模拟生产环境的Staging环境运行版本测试
原则二:
数据分区处理(PartitionYourData)
在分布式计算环境下,如何高效的处理海量数据?
如何在Bug发生后更加容易的重新批处理?
一个基本的设计原则就是分区(Partition),即将待处理信息按照生成节点、内在一致性(SelfContain)、时间等因素进行分组,让每个平行处理节点可尽量仅处理切分后的数据,而减少节点间的数据交换。
分区的基本原则包括:
·应用流量均衡LoadBalance和数据分区结合
·容易在分组内进行再分区
·减少分组数据之间的状态依赖
·减少数据中心之间的数据交换
原则三:
冗余(Redundancy)
冗余几乎是高可用系统设计的必然选择,也是老生常谈的话题,然而如何做到成本与效率的最佳平衡则是架构设计考虑的重点。
可以参考的经验包括:
·优先减少单点故障。
·单个应用可快速重启恢复。
·应用间减少启动和运行依赖,尽量可独立工作。
·与其依赖热备冗余,不如建立服务中断后的快速恢复预案(依赖热备系统,在实战中总是很难理想地恢复全部服务)。
可扩展、高可用、负载均衡网站架构设计方案
2009-06-0813:
22
基本需求:
1、高可用性:
将停止服务时间降低到最低甚至是不间断服务
2、可扩展性:
随着访问的增加,系统具备良好的伸缩能力
3、可视性:
系统、服务的状态处于一个实时的监控之下
4、高性能高可靠性:
经过优化的体系结构及合理的备份策略
5、安全性:
结构上的安全及主机的安全策略
基本思路
1、对于访问频繁,用户量大的对象(bbs,blog)采用某种合理的方式负载到多个服务器上。
把数据库独立出来,准备2套mysql数据库,以实现主从复制,即减轻负载,又提高了可靠性。
更近一步,使用mysqlproxy技术,实现主从服务器的读写分离,大大提高这个系统的性能和负载能力。
2、数据库与外部网络隔离,只允许web服务器(bbs,blog等)通过私有地址方式访问。
这样就提高了数据库的安全性,同时也节省了宝贵的带宽。
3、部署监控系统,通过监控主机存活、服务、主机资源,实时把系统的健康状态置于可视状态,对系统的运营状态心中有数。
4、备份是想都不用想的事情,使用单独的服务器集中备份,是一个比较不错的主意。
拓扑结构
业务逻辑
技术实现
1、负载均衡。
2台同样配置的linux服务器,内核支持lvs,配置keepalived工具,即可实现负载转发。
一旦其后的真实服务器出现故障,keepalived会自动把故障机器从转发队列删除掉,等到故障修复,它又会自动把真实服务器的地址加入转发列表。
由于lvs支持会话保持,因此对于bbs这样的应用,一点也不用担心其登录丢失。
2、mysql主从复制。
即保证数据的安全,又提高了访问性能。
我们在前端的每个web服务器上加入mysqlproxy这个工具,即可期待实现读写的自动分离,让写的操作发生在主数据库,让查询这类读操作发生在从数据库。
3、nagios是一个开源的,受广泛欢迎的监控平台。
它可对主机的存活、系统资源(磁盘空间、负载等)、网络服务进行实时监控。
一旦探测到故障,将自动发送邮件(短信)通知故障。
4、备份。
包括web数据和数据库服务器的备份。
对于web服务而言,GNUtar即可实现备份的一切愿望。
简单的设置一下crontab就可以让系统在我们做梦的时刻老老实实的帮我们备份了。
但是,由于空间的限制,不可能一直备份下去,所以要做一个合适的策略,以不断的用新的备份去替换陈旧的备份数据;多少天合适?
看磁盘容量吧。
对于数据库,先mysqldump一下,再tar.完成这些工作后把备份文件传输到备份服务器集中。
一个比较省事的方法是把备份服务器以NFS方式挂接到web服务器及数据库服务器。
5、web服务器。
至少包括apache和mysqlproxy这两个组件。
Apache做bbs和blog的容器,以虚拟机方式把用户的请求转发到bbs目录或blog目录。
6、安全措施。
包含两层安全,一层是主机本身,另一层是结构(mysql从外部网络隔离)。
实践证明,iptables是一个非常值得信赖的防火墙工具。
在实际应用中,采取先关门后开窗的策略,大大增强系统的安全性。
组件
一、硬件:
负载均衡2台(dell1950),web服务器2-3台(dell1950),数据库2台(dell2950),存储NAS(5T格式化后容量),备份4u服务器(带磁盘阵列5T容量),监控服务器1台(dell1850).
二、软件:
操作系统centos5(定制安装),负载均衡ipvsadm、keepalived,监控nagios,web服务apache+php等,数据库mysql,数据库代理mysqlproxy.
进度安排
1、lvs负载均衡配置及测试:
2-3天
2、web服务器配置:
2-3天
3、mysql主从服务器配置:
1-3天
4、web数据迁移:
1天
5、数据库数据迁移:
2天
6、上线测试:
1-2天
7、正式上线:
2天
keepalived.conf
!
ConfigurationFileforkeepalived
global_defs{
router_idLVS_DEVEL
}
vrrp_instanceVI_1{
statemaster
interfaceeth0
virtual_router_id59
priority100
advert_int1
authentication{
auth_typePASS
auth_pass1111
}
virtual_ipaddress{
61.61.61.100
#61.61.61.101
}
}
virtual_server61.61.61.10080{
delay_loop6
lb_algorr
lb_kindDR
persistence_timeout50
protocolTCP
real_server61.61.61.10280{
weight100
TCP_CHECK{
connect_timeout3
nb_get_retry3
delay_before_retry3
connect_port80
}
}
real_server61.61.61.10380{
weight100
TCP_CHECK{
connect_timeout3
nb_get_retry3
delay_before_retry3
connect_port80
}
}
}
真实服务器虚拟ip设置脚本
#!
/bin/bash
#description:
startrealserver
VIP=61.61.61.100
./etc/rc.d/init.d/functions
case"$1"in
start)
echo"startLVSofREALServer"
/sbin/ifconfiglo:
0$VIPbroadcast$VIPnetmask255.255.255.255up
echo"1">/proc/sys/net/ipv4/conf/lo/arp_ignore
echo"2">/proc/sys/net/ipv4/conf/lo/arp_announce
echo"1">/proc/sys/net/ipv4/conf/all/arp_ignore
echo"2">/proc/sys/net/ipv4/conf/all/arp_announce
;;
stop)
/sbin/ifconfiglo:
0down
echo"closeLVSDirectorserver"
echo"0">/proc/sys/net/ipv4/conf/lo/arp_ignore
echo"0">/proc/sys/net/ipv4/conf/lo/arp_announce
echo"0">/proc/sys/net/ipv4/conf/all/arp_ignore
echo"0">/proc/sys/net/ipv4/conf/all/arp_announce
;;
*)
echo"Usage:
$0{start|stop}"
exit1
esac
YouTuBe网站技术架构
2009-03-3111:
20
YouTube发展迅速,每天超过1亿的视频点击量,但只有很少人在维护站点和确保伸缩性。
平台ApachePythonLinux(SuSe)MySQLpsyco,一个动态的Python到C的编译器lighttpd代替Apache做视频查看状态,支持每天超过1亿的视频点击量。
成立于2005年2月,于2006年3月达到每天3千万的视频点击量于2006年7月达到每天1亿的视频点击量。
技术开发,2个系统管理员,2个伸缩性软件架构师2个软件开发工程师,2个网络工程师,1个DBA,处理飞速增长的流量。
代码while(true){identify_and_fix_bottlenecks();drink();sleep();notice_new_bottleneck();}每天运行该循环多次。
Web服务器:
1,NetScaler用于负载均衡和静态内容缓存
2,使用mod_fast_cgi运行Apache
3,使用一个Python应用服务器来处理请求的路由
4,应用服务器与多个数据库和其他信息源交互来获取数据和格式化html页面
5,一般可以通过添加更多的机器来在Web层提高伸缩性
6,Python的Web层代码通常不是性能瓶颈,大部分时间阻塞在RPC
7,Python允许快速而灵活的开发和部署
8,通常每个页面服务少于100毫秒的时间
9,使用psyco(一个类似于JIT编译器的动态的Python到C的编译器)来优化内部循环
10,对于像加密等密集型CPU活动,使用C扩展
11,对于一些开销昂贵的块使用预先生成并缓存的html
12,数据库里使用行级缓存
13,缓存完整的Python对象
14,有些数据被计算出来并发送给各个程序,所以这些值缓存在本地内存中。
这是个使用不当的策略。
应用服务器里最快的缓存将预先计算的值发送给所有服务器也花不了多少时间。
只需弄一个代理来监听更改,预计算,然后发送。
视频服务:
1,花费包括带宽,硬件和能源消耗
2,每个视频由一个迷你集群来host,每个视频被超过一台机器持有
3,使用一个集群意味着:
-更多的硬盘来持有内容意味着更快的速度-failover。
如果一台机器出故障了,另外的机器可以继续服务-在线备份
4,使用lighttpd作为Web服务器来提供视频服务:
-Apache开销太大-使用epoll来等待多个fds-从单进程配置转变为多进程配置来处理更多的连接
5,大部分流行的内容移到CDN:
-CDN在多个地方备份内容,这样内容离用户更近的机会就会更高-CDN机器经常内存不足,因为内容太流行以致很少有内容进出内存的颠簸
6,不太流行的内容(每天1-20浏览次数)在许多colo站点使用YouTube服务器-长尾效应。
一个视频可以有多个播放,但是许多视频正在播放。
随机硬盘块被访问-在这种情况下缓存不会很好,所以花钱在更多的缓存上可能没太大意义。
-调节RAID控制并注意其他低级问题-调节每台机器上的内存,不要太多也不要太少。
视频服务关键点:
1,保持简单和廉价
2,保持简单网络路径,在内容和用户间不要有太多设备
3,使用常用硬件,昂贵的硬件很难找到帮助文档
4,使用简单而常见的工具,使用构建在Linux里或之上的大部分工具
5,很好的处理随机查找(SATA,tweaks)
缩略图服务:
1,做到高效令人惊奇的难
2,每个视频大概4张缩略图,所以缩略图比视频多很多
3,缩略图仅仅host在几个机器上
4,持有一些小东西所遇到的问题:
-OS级别的大量的硬盘查找和inode和页面缓存问题-单目录文件限制,特别是Ext3,后来移到多分层的结构。
内核2.6的最近改进可能让Ext3允许大目录,但在一个文件系统里存储大量文件不是个好主意-每秒大量的请求,因为Web页面可能在页面上显示60个缩略图-在这种高负载下Apache表现的非常糟糕-在Apache前端使用squid,这种方式工作了一段时间,但是由于负载继续增加而以失败告终。
它让每秒300个请求变为20个-尝试使用lighttpd但是由于使用单线程它陷于困境。
遇到多进程的问题,因为它们各自保持自己单独的缓存-如此多的图片以致一台新机器只能接管24小时-重启机器需要6-10小时来缓存
5,为了解决所有这些问题YouTube开始使用Google的BigTable,一个分布式数据存储:
-避免小文件问题,因为它将文件收集到一起-快,错误容忍-更低的延迟,因为它使用分布式多级缓存,该缓存与多个不同collocation站点工作-更多信息参考GoogleArchitecture,GoogleTalkArchitecture和BigTable
数据库:
1,早期-使用MySQL来存储元数据,如用户,tags和描述-使用一整个10硬盘的RAID10来存储数据-依赖于信用卡所以YouTube租用硬件-YouTube经过一个常见的革命:
单服务器,然后单master和多readslaves,然后数据库分区,然后sharding方式-痛苦与备份延迟。
master数据库是多线程的并且运行在一个大机器上所以它可以处理许多工作,slaves是单线程的并且通常运行在小一些的服务器上并且备份是异步的,所以slaves会远远落后于master-更新引起缓存失效,硬盘的慢I/O导致慢备份-使用备份架构需要花费大量的money来获得增加的写性能-YouTube的一个解决方案是通过把数据分成两个集群来将传输分出优先次序:
一个视频查看池和一个一般的集群。
2,后期-数据库分区-分成shards,不同的用户指定到不同的shards-扩散读写-更好的缓存位置意味着更少的IO-导致硬件减少30%-备份延迟降低到0-现在可以任意提升数据库的伸缩性。
数据中心策略:
1,依赖于信用卡,所以最初只能使用受管主机提供商。
2,受管主机提供商不能提供伸缩性,不能控制硬件或使用良好的网络协议
3,YouTube改为使用colocationarrangement。
现在YouTube可以自定义所有东西并且协定自己的契约
4,使用5到6个数据中心加CDN
5,视频来自任意的数据中心,不是最近的匹配或其他什么。
如果一个视频足够流行则移到CDN
6,依赖于视频带宽而不是真正的延迟。
可以来自任何colo
7,图片延迟很严重,特别是当一个页面有60张图片时
8,使用BigTable将图片备份到不同的数据中心,代码查看谁是最近的
个别技术点:
1,Stallfortime。
创造性和风险性的技巧让你在短期内解决问题而同时你会发现长期的解决方案。
2,Proioritize。
找出你的服务中核心的东西并对你的资源分出优先级别
3,Pickyourbattles。
别怕将你的核心服务分出去。
YouTube使用CDN来分布它们最流行的内容。
创建自己的网络将花费太多时间和太多money
4,Keepitsimple!
简单允许你更快的重新架构来回应问题
5,Shard。
Sharding帮助隔离存储,CPU,内存和IO,不仅仅是获得更多的写性能
6,Constantiterationonbottlenecks:
-软件:
DB,缓存-OS:
硬盘I/O-硬件:
内存,RAID
7,Yousucceedasateam。
拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队,如安装打印机,安装机器,安装网络等等的人。
Withag
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 海量 索引 数据 机群 分布