CPUs/discos 4x
Figura12: Limite superior para otempomédio de respostado sistemaemfunção dataxa
de hegadade onsultas derivado emnosso exemplo.
Analisando o Desbalan eamento entre os Servidores de Índi e Ho-
mogêneos
Como resultado da nossa análise da questão do desbalan eamento, veri amos que o e-
nário idealizado, que supõe tempos de serviço balan eados omo uma onseqüên ia da
distribuição uniforme de dados entre os servidoresde índi e homogêneos, éimprovável de
a onte er na práti a. Esta é uma ontribuição importante porque ontradiz uma suposi-
çãousual detemposdeserviço balan eadosfeitapormuitosmodelosteóri osnaliteratura
para simpli arsua tarefa de modelagem[20,23,44℄. Nossas des obertas são derivadas de
uma análise experimental detalhada usando um sistema de re uperação de informação e
dados reais obtidos de um me anismo de bus a real. Além de veri ar a presença de um
erto nívelde desbalan eamentoentre os servidoresde índi e homogêneos,identi amose
ara terizamos as prin ipaisfontes deste desbalan eamentoinesperado.
Oprin ipalfatorparaodesbalan eamentoéousodo a he dodis o nos diferentes ser-
vidores de índi e. Veri amosqueo desbalan eamentopara ada onsultaaumenta om o
númerodeservidoresdeíndi equere uperamosdo umentosne essáriosdo a hedodis o.
restantes usam o a he do dis o para a mesma onsulta. Por outro lado, o melhor aso
paraevitar desbalan eamentoéal ançadoquandotodososservidoresde índi eoperamna
regiãodo a he,levandoassimatemposdea essoadis orelativamentemenoresesimilares
através do luster de servidores. Outra fonte de desbalan eamento identi ada é o tama-
nhodamemóriaprin ipaldosservidoresde índi ehomogêneos,queafetaadisponibilidade
de re ursos para o uso do a he do dis o nos servidores. Veri amos que o desbalan ea-
mentomédiodiminuienquantootamanhodamemóriaprin ipalaumenta. Outrafontede
desbalan eamento identi ada é o número de servidores de índi e no luster. Veri amos
que, para um tamanho xo de memóriaprin ipal, o desbalan eamento médio nos tempos
de serviço entre osservidores de índi eaumenta om o númerode servidores no luster.
Um Modelo de Planejamento de Capa idade para Me anismos de
Bus a na Web
Também, propusemos um modelo de planejamento de apa idade para me anismos de
bus a na Web que onsidera o desbalan eamento nos tempos de serviço de uma onsulta
entre osservidores de índi ehomogêneos. Nosso modelo, baseado nateoriade las, ésim-
pleserazoavelmentepre iso. Paraajustaromodelo,exe utamosexperimentosnum luster
pequeno de servidores de índi e. Uma vez ajustado, omparamos as predições do nosso
modelo omosresultadosmedidosempiri amenteeen ontramosgrande on ordân ia. Até
mesmonopontodesaturação, asprediçõesdonossomodeloforamrazoavelmentepre isas.
Também, ilustramos omoapli arnossomodeloparapredizer otempode resposta deuma
onsultaao adotar CPUs e dis os mais rápidos doque aqueles emuso. Consideramosum
enário realísti o,onde uma oleção de
20
bilhões de do umentosé distribuída através de2, 000
servidoresdeíndi e. Emnossoexemplo,mostramosqueogerentedeumme anismo de bus a pode rapidamente predizer limites superiores para o tempo de resposta de umaonsultasem ter que exe utarexperimentos.
Dada a omplexidade da manutenção de me anismos de bus a, e a simpli idade e
razoável pre isão do nosso modelo, a reditamos que nosso modelo pode ser muito útil na
Umadireçãoparatrabalhofuturoéestender nossomodelode planejamentode apa idade
para suportar múltiplas threads de pro essamento nos servidores de índi e. Outra direção
para pesquisa émelhorarnosso modelo paraestimarafunção de distribuiçãodotempode
resposta de uma onsulta. A partir desta distribuição, pode-se en ontrar seus per entis.
Esta soluçãoéútilseogerentede umme anismo debus anaWebexigirqueo
q
-per entil dotempode resposta esperado de uma onsultaseja menorouigual a um limitede nido.Umaoutradireçãoparapesquisafuturaémodelar a hingdosresultados das onsultas
que permite ao me anismo de bus a responder onsultas repetidas re entemente a um
usto muito baixo desde que não é ne essário pro essar estas onsultas e a hing das
listasinvertidasdostermosdas onsultasquemelhoraotempode pro essamentodeno-
vas onsultas quein luempelomenosum termo ujalistaestá guardadaemmemória[48℄.
Uma outra direção para pesquisa é identi ar e analisar as razões para o uso do a he
do dis o, e eventualmente modelar a probabilidade de a erto no a he do dis o. Alguns
elementos queafetam ouso do a he do dis o são a lo alidadede referên iatemporaldas
onsultas e termosdas onsultas notráfego de entrada,a lo alidadede referên iaespa ial
das listasinvertidasdos termosdas onsultasnodis o,eotamanhodamemóriaprin ipal.
Umaoutradireçãoparatrabalhofuturoéveri ar,atravésdesimulação,apre isãodas
prediçõesde nosso modelo parame anismos de bus anaWeb de larga es ala,que ontam
om lusters om milhares de servidores de índi e para suportar oleções ompostas por
bilhõesde do umentos. Seria importante onsiderar um luster omposto por
p
servidores de índi e, tal quep
é grande o su iente para armazenar o índi e de uma oleção de20
bilhõesdepáginas,queéotamanhodosíndi esdoGoogleeYahoolevadoapúbli o[24℄. Édifí il obtergrandes oleçõesde do umentos usadas pelos me anismos de bus anaWebparagerarumapáginaderesposta pra ada onsultare ebida. Arazãoéqueo onjuntode
do umentos oletados é visto omo informação estratégi a e proprietária pelos prin ipais
operadores de bus a na Web. De fato, durante o urso desta tese, tivemos a esso apenas
auma oleçãodedo umentos omposta poraproximadamente
10
milhõesde páginasWeb oletadas pelo me anismo de bus a TodoBR da Web brasileira em2003
. Uma solução seria gerar uma oleçãosintéti a de do umentos grande, a partir de distribuiçõesque sãobaseadas em estatísti as provenientes de onjuntos de dados reais.
Umaoutradireçãoparapesquisafuturaédesenvolverumaabordagemparaen ontrara
arquitetura ótimapara umme anismo de bus anaWeb emtermosde usto,que ombine
O usto é dado pelo número de servidores de índi e na arquitetura. Portanto, o objetivo
seriasatisfazerostrêsrequisitosopera ionais omomenornúmerodeservidoresde índi e.
Este objetivopode ser formalizado aominimizarafunção de usto:
c = p × r
(9)aomesmo temposatisfazendo os seguintes requisitosopera ionais:
ft(p, r, X) ≤ T
(10)fu(p, r, X) ≤ U
onde
r
é o número de repli ações (de um luster de servidores de índi e);p
é o número de partiçõesdo índi e (atravésdos servidores de índi e num luster);T
é orequisito para o tempo de resposta;U
é o requisito para a utilização;X
é o requisito para a vazão; eft(p, r, X)
efu(p, r, X)
al ulam tempo de resposta e utilização, respe tivamente, para uma dada vazãoX
e uma dada arquitetura onde o índi e é parti ionado emp
divisões e repli ador
vezes.1 Introdu tion 1
1.1 Motivation . . . 1
1.2 Obje tives and Contributions . . . 3
1.3 Organizationof this Thesis . . . 4
2 Basi Con epts 5
2.1 AnAr hite ture for Web Sear h Engines . . . 5
2.1.1 Clusterof Index Servers . . . 5
2.1.2 Inverted Index. . . 6
2.1.3 Ve torSpa e Model. . . 7
2.1.4 Parallel Query Pro essing . . . 9
2.1.5 The Brokeris not the Main Bottlene k . . . 10
2.2 Queueing Networks . . . 12
2.2.1 Multiple-Class Open Queueing Networks . . . 13
2.2.2 Fork-Join Queueing Networks . . . 16
3 Related Work 19
3.1 IndexOrganization . . . 19
3.2 System Ar hite ture . . . 25
3.3 Workload Chara terization . . . 28
3.4 Performan e Modeling . . . 29
4 Analyzing Imbalan e among Homogeneous Index Servers 31
4.1 Introdu tion . . . 31
4.2 Workload Chara terization . . . 32
4.3 Chara terizing Imbalan e. . . 35
4.3.3 In uen e of Main Memory Size and Numberof Index Servers . . . . 44
4.4 Con ludingRemarks . . . 45
5 A Capa ity Planning Model for Web Sear h Engines 47
5.1 Introdu tion . . . 47
5.2 Workload Chara terization . . . 48
5.3 Capa ity Planningfor Sear h Engines . . . 55
5.3.1 Performan e ModelOverview . . . 57
5.3.2 Model Solution . . . 59
5.3.3 An Exampleof ModelAppli ability . . . 66
5.4 Con ludingRemarks . . . 70
6 Con lusions and Future Work 71
6.1 Con lusions . . . 71
6.1.1 Analyzing Imbalan e amongHomogeneous Index Servers . . . 71
6.1.2 A Capa ity PlanningModelfor Web Sear h Engines . . . 73
6.1.3 Query Workload Chara terizationof Four Web Sear hEngines . . . 73
6.2 FutureWork . . . 74
2.1 Ar hite ture of a typi alsear h engine. . . 6
2.2 Basi algorithmfor ranking using the ve tor spa e model. . . 9
2.3 Average time (se onds) at the broker per query as a fun tion of the query
arrivalrate (queries/se ond). . . 11
2.4 Fork-joinqueueing network. . . 17
3.1 Do umentpartitioning. . . 20
3.2 Term partitioning. . . 21
3.3 Google query-serving ar hite ture. . . 25
3.4 Fastsear h luster overview. . . 27
4.1 Frequen y of textterms in do uments and inqueries. . . 33
4.2 Relationshipbetween the frequen y of terms indo uments and in queries.. 34
4.3 PMF of the sizes of queries. . . 35
4.4 PMF of the sizes of inverted lists. . . 38
4.5 Distributionof lo al servi e times perquery. . . 38
4.6 PDFof lo aldisk a esstimes. . . 40
4.7 Imbalan e aused by the number of index servers operating in the a he
region. . . 41
4.8 Comparingquery frequen y and query size.. . . 42
4.9 PDFof exe ution times for relatedand unrelated queries. . . 43
4.10 Averageimbalan eas afun tion of the main memory size atindex servers. 44
5.1 Frequen y of unique queries and unique terms inqueries. . . 50
5.2 Query load variationthrough the onsidered datasets. . . 52
5.3 Mean number of queries over time (modulo one week) for the onsidered
datasets. . . 53
5.6 Queueing networkfor a Web sear h engine. . . 58
5.7 Average query residen e time at an index server as a fun tion of the query
arrivalrate (
p = 8
). . . 64 5.8 Average query system response time as a fun tion of the query arrivalrate(
p = 8
). . . 65 5.9 Average query system response time as a fun tion of the number of indexservers
p
(λ = 28
queries/se ond). . . 65 5.10 Upper-bound on the average query system response time as a fun tion of4.1 Correlationbetween thefrequen y of textterms inqueries andinsub olle -
tions. . . 35
5.1 Lengthof the onsidered querydatasets. . . 49
5.2 Query lass distribution. . . 51
5.3 Query arrivalrate (queries/se ond). . . 54
5.4 Query arrivalrate inthe folded TodoBR log(queries/se ond). . . 55
5.5 Sum of the squares of the dieren es between the measured and tted dis-
tributionof interarrivaltimes perquery lass. . . 57
5.6 Input and output parameters of our model. . . 60
5.7 Model input parameter values. . . 63
A ronyms
CCDF: ComplementaryCumulativeDistributionFun tion, afun tion omplementaryto
the CumulativeDistribution Fun tion.
CDF: Cumulative DistributionFun tion, a fun tion that ompletely des ribes the prob-
abilitydistribution of a randomvariable.
FCFS: First-ComeFirst-Served, aqueueingdis iplineinwhi h requestsare served inthe
order of arrivalata queue.
PDF: ProbabilityDensity Fun tion, afun tion that represents a probability distribution
interms of integrals.
PMF: Probability Mass Fun tion, a fun tion that gives the probability that a dis rete
random variable is exa tly equalto some value. A probability mass fun tion diers
from a probability density fun tion in that the values of the latter, de ned only for
ontinuous random variables, are not probabilities; rather, its integral over a set of
possible values of the random variable isa probability.
MVA: Mean Value Analysis, an e ient algorithm to solve produ t-form queueing net-
works and obtain meanvalues forqueue lengthsand response times.
Parameters