Date: Fri, 15 Feb 2002 12:53:45 -0700 Subject: IOC awards presidency also to Gore (RNN)-- In a surprising, but widely anticipated move, the International.

Slides:



Advertisements
Similar presentations
The Inside Story Christine Reilly CSCI 6175 September 27, 2011.
Advertisements

Crawling, Ranking and Indexing. Organizing the Web The Web is big. Really big. –Over 3 billion pages, just in the indexable Web The Web is dynamic Problems:
The Search Engine Architecture CSCI 572: Information Retrieval and Search Engines Summer 2010.
Advanced Databases: Lecture 2 Query Optimization (I) 1 Query Optimization (introduction to query processing) Advanced Databases By Dr. Akhtar Ali.
“ The Anatomy of a Large-Scale Hypertextual Web Search Engine ” Presented by Ahmed Khaled Al-Shantout ICS
Information Retrieval in Practice
The Buddhist who understood (your) Desire
The Anatomy of a Large-Scale Hypertextual Web Search Engine
Presentation of Anatomy of a Large-Scale Hypertextual Web Search Engine by Sergey Brin and Lawrence Page (1997) Presenter: Scott White.
Anatomy of a Large-Scale Hypertextual Web Search Engine (e.g. Google)
© nCode 2000 Title of Presentation goes here - go to Master Slide to edit - Slide 1 Anatomy of a Large-Scale Hypertextual Web Search Engine ECE 7995: Term.
The Anatomy of a Large-Scale Hypertextual Web Search Engine Sergey Brin and Lawrence Page.
Anatomy of Google (circa 1999) Slides from Project part B due a month from now (10/26)
ISP 433/633 Week 7 Web IR. Web is a unique collection Largest repository of data Unedited Can be anything –Information type –Sources Changing –Growing.
Query Optimization 3 Cost Estimation R&G, Chapters 12, 13, 14 Lecture 15.
The Anatomy of a Large-Scale Hypertextual Web Search Engine Sergey Brin and Lawrence Page Distributed Systems - Presentation 6/3/2002 Nancy Alexopoulou.
Google and Scalable Query Services
1 The anatomy of a Large Scale Search Engine Sergey Brin,Lawrence Page Dept. CS of Stanford University.
Overview of Search Engines
An Application of Graphs: Search Engines (most material adapted from slides by Peter Lee) Slides by Laurie Hiyakumoto.
“ The Initiative's focus is to dramatically advance the means to collect,store,and organize information in digital forms,and make it available for searching,retrieval,and.
The Anatomy of a Large- Scale Hypertextual Web Search Engine Sergey Brin, Lawrence Page CS Department Stanford University Presented by Md. Abdus Salam.
The Anatomy of a Large-Scale Hypertextual Web Search Engine By Sergey Brin and Lawrence Page Presented by Joshua Haley Zeyad Zainal Michael Lopez Michael.
The Anatomy of a Large-Scale Hypertextual Web Search Engine Presented By: Sibin G. Peter Instructor: Dr. R.M.Verma.
Anatomy of a search engine Design criteria of a search engine Architecture Data structures.
Crawling Slides adapted from
Chapter 2 Architecture of a Search Engine. Search Engine Architecture n A software architecture consists of software components, the interfaces provided.
Web Search. Structure of the Web n The Web is a complex network (graph) of nodes & links that has the appearance of a self-organizing structure  The.
1 University of Qom Information Retrieval Course Web Search (Link Analysis) Based on:
CSE 6331 © Leonidas Fegaras Information Retrieval 1 Information Retrieval and Web Search Engines Leonidas Fegaras.
©Silberschatz, Korth and Sudarshan13.1Database System Concepts Chapter 13: Query Processing Overview Measures of Query Cost Selection Operation Sorting.
Search Xin Liu. 2 Searching the Web for Information How a Search Engine Works –Basic parts: 1.Crawler: Visits sites on the Internet, discovering Web pages.
Search - on the Web and Locally Related directly to Web Search Engines: Part 1 and Part 2. IEEE Computer. June & August 2006.
Gregor Gisler-Merz How to hit in google The anatomy of a modern web search engine.
The PageRank Citation Ranking: Bringing Order to the Web Lawrence Page, Sergey Brin, Rajeev Motwani, Terry Winograd Presented by Anca Leuca, Antonis Makropoulos.
Search Engines. Search Strategies Define the search topic(s) and break it down into its component parts What terms, words or phrases do you use to describe.
The Anatomy of a Large-Scale Hypertextual Web Search Engine Sergey Brin & Lawrence Page Presented by: Siddharth Sriram & Joseph Xavier Department of Electrical.
The Anatomy of a Large-Scale Hypertextual Web Search Engine Kevin Mauricio Apaza Huaranca San Pablo Catholic University.
The Anatomy of a Large-Scale Hyper textual Web Search Engine S. Brin, L. Page Presenter :- Abhishek Taneja.
Search Engines1 Searching the Web Web is vast. Information is scattered around and changing fast. Anyone can publish on the web. Two issues web users have.
Copyright © D.S.Weld12/3/2015 8:49 PM1 Link Analysis CSE 454 Advanced Internet Systems University of Washington.
David Evans CS150: Computer Science University of Virginia Computer Science Class 38: Googling.
1 1 COMP5331: Knowledge Discovery and Data Mining Acknowledgement: Slides modified based on the slides provided by Lawrence Page, Sergey Brin, Rajeev Motwani.
Physical Database Design Purpose- translate the logical description of data into the technical specifications for storing and retrieving data Goal - create.
Search Xin Liu.
The Nuts & Bolts of Hypertext retrieval Crawling; Indexing; Retrieval.
1 Google: Case Study cs430 lecture 15 03/13/01 Kamen Yotov.
1 CS 430: Information Discovery Lecture 20 Web Search Engines.
The Anatomy of a Large-Scale Hypertextual Web Search Engine S. Brin and L. Page, Computer Networks and ISDN Systems, Vol. 30, No. 1-7, pages , April.
The Anatomy of a Large-Scale Hypertextual Web Search Engine (The creation of Google)
Search Engine and Optimization 1. Introduction to Web Search Engines 2.
The Anatomy of a Large-Scale Hyper-textual Web Search Engine 전자전기컴퓨터공학과 G 김영제 Database Lab.
Presented By: Carlton Northern and Jeffrey Shipman The Anatomy of a Large-Scale Hyper-Textural Web Search Engine By Lawrence Page and Sergey Brin (1998)
1 Efficient Crawling Through URL Ordering Junghoo Cho Hector Garcia-Molina Lawrence Page Stanford InfoLab.
Information Retrieval in Practice
Why indexing? For efficient searching of a document
Search Engine Architecture
Chapter 12: Query Processing
The Anatomy Of A Large Scale Search Engine
CSE 454 Advanced Internet Systems University of Washington
CSE 454 Advanced Internet Systems University of Washington
Google and Scalable Query Services
The Anatomy of a Large-Scale Hypertextual Web Search Engine
Hongjun Song Computer Science The University of Memphis
CSE 454 Advanced Internet Systems University of Washington
CSE 454 Advanced Internet Systems University of Washington
Anatomy of a search engine
Web Search Engines.
The Search Engine Architecture
Presentation transcript:

Date: Fri, 15 Feb :53: Subject: IOC awards presidency also to Gore (RNN)-- In a surprising, but widely anticipated move, the International Olympic Committee president just came on TV and announced that IOC decided to award a presidency to Albert Gore Jr. too. Gore Jr. won the popular vote initially, but to the surprise of TV viewers world wide, Bush was awarded the presidency by the electoral college judges. Mr. Bush, who "beat" gore, still gets to keep his presidency. "We decided to put the two men on an equal footing and we are not going to start doing the calculations of all the different votes that (were) given. Besides, who knows what those seniors in Palm Beach were thinking?" said the IOC president. The specific details of shared presidency are still being worked out--but it is expected that Gore will be the president during the day, when Mr. Bush typically is busy in the Gym working out. In a separate communique the IOC suspended Florida for an indefinite period from the union. Speaking from his home (far) outside Nashville, a visibly elated Gore profusely thanked Canadian people for starting this trend. He also remarked that this will be the first presidents' day when the sitting president can be on both coasts simultaneously. When last seen, he was busy using the "Gettysburg" template in the latest MS Powerpoint to prepare an eloquent speech for his inauguration-cum-first-state-of-the-union. --RNN Related Sites: Gettysburg Powerpoint template: 2/18

Agenda: Page Rank issues (computation; Collusion etc) Crawling Announcements: Next class: INTERACTIVE (read Google paper and come prepared with smart questions/comments/answers) Homework 2 socket closed.. Question: Are you reading the papers????????

Adding PageRank to a SearchEngine Weighted sum of importance+similarity with query Score(q, d) = w  sim(q, p) + (1-w)  R(p), if sim(q, p) > 0 = 0, otherwise Where –0 < w < 1 –sim(q, p), R(p) must be normalized to [0, 1].

Stability of Rank Calculations The left most column Shows the original rank Calculation -the columns on the right are result of rank calculations when 30% of pages are randomly removed (From Ng et. al. )

Effect of collusion on PageRank A B C A B C Assuming  0.8 and K=[1/3] Rank(A)=Rank(B)=Rank(C)= Rank(A)=0.37 Rank(B)= Rank(C)= Moral: By referring to each other, a cluster of pages can artificially boost their rank (although the cluster has to be big enough to make an appreciable difference. Solution: Put a threshold on the number of intra-domain links that will count Counter: Buy two domains, and generate a cluster among those..

What about non-principal eigen vectors? Principal eigen vector gives the authorities (and hubs) What do the other ones do? –They may be able to show the clustering in the documents (see page 23 in Kleinberg paper) The clusters are found by looking at the positive and negative ends of the secondary eigen vectors (ppl vector has only +ve end…)

Novel uses of Link Analysis Link analysis algorithms—HITS, and Pagerank—are not limited to hyperlinks -Citeseer/Cora use them for analyzing citations (the link is through “citation”) -See the irony here—link analysis ideas originated from citation analysis, and are now being applied for citation analysis -Some new work on “keyword search on databases” uses foreign-key links and link analysis to decide which of the tuples matching the keyword query are most important (the link is through foreign keys) -[Sudarshan et. Al. ICDE 2002]Sudarshan et. Al. ICDE Keyword search on databases is useful to make structured databases accessible to naïve users who don’t know structured languages (such as SQL).

Query complexity Complex queries (966 trials) –Average words 7.03 –Average operators ( +*–" ) 4.34 Typical Alta Vista queries are much simpler [Silverstein, Henzinger, Marais and Moricz] –Average query words 2.35 –Average operators ( +*–" ) 0.41 Forcibly adding a hub or authority node helped in 86% of the queries

Practicality Challenges –M no longer sparse (don’t represent explicitly!) –Data too big for memory (be sneaky about disk usage) Stanford version of Google : –24 million documents in crawl –147GB documents –259 million links –Computing pagerank “few hours” on single 1997 workstation But How? –Next discussion from Haveliwala paper…

Efficient Computation: Preprocess Remove ‘dangling’ nodes –Pages w/ no children Then repeat process –Since now more danglers Stanford WebBase –25 M pages –81 M URLs in the link graph –After two prune iterations: 19 M nodes

Representing ‘Links’ Table Stored on disk in binary format Size for Stanford WebBase: 1.01 GB –Assumed to exceed main memory , 26, 58, 94 5, 56, 69 1, 9, 10, 36, 78 Source node (32 bit int) Outdegree (16 bit int) Destination nodes (32 bit int)

Algorithm 1 =  DestLinks (sparse)Source source node dest node  s Source[s] = 1/N while residual >  {  d Dest[d] = 0 while not Links.eof() { Links.read(source, n, dest 1, … dest n ) for j = 1… n Dest[dest j ] = Dest[dest j ]+Source[source]/n }  d Dest[d] = c * Dest[d] + (1-c)/N /* dampening */ residual =  Source – Dest  /* recompute every few iterations */ Source = Dest }

Analysis of Algorithm 1 If memory is big enough to hold Source & Dest –IO cost per iteration is | Links| –Fine for a crawl of 24 M pages –But web ~ 800 M pages in 2/99 [NEC study] –Increase from 320 M pages in 1997 [same authors] If memory is big enough to hold just Dest –Sort Links on source field –Read Source sequentially during rank propagation step –Write Dest to disk to serve as Source for next iteration –IO cost per iteration is | Source| + | Dest| + | Links| If memory can’t hold Dest –Random access pattern will make working set = | Dest| –Thrash!!!

Block-Based Algorithm Partition Dest into B blocks of D pages each –If memory = P physical pages –D < P-2 since need input buffers for Source & Links Partition Links into B files –Links i only has some of the dest nodes for each source –Links i only has dest nodes such that DD*i <= dest < DD*(i+1) Where DD = number of 32 bit integers that fit in D pages =  Dest Links (sparse)Source source node dest node

3 Partitioned Link File , , 9, 10 Source node (32 bit int) Outdegr (16 bit) Destination nodes (32 bit int) 2 1 Num out (16 bit) Buckets 0-31 Buckets Buckets 64-95

Block-based Page Rank algorithm

Analysis of Block Algorithm IO Cost per iteration = –B*| Source| + | Dest| + | Links|*(1+e) –e is factor by which Links increased in size Typically Depends on number of blocks Algorithm ~ nested-loops join

Comparing the Algorithms

PageRank Convergence…

More stable because random surfer model allows low prob edges to every place.CV Can be done For base set too Can be done For full web too Query relevance vs. query time computation tradeoff Can be made stable with subspace-based A/H values [see Ng. et al.; 2001] See topic-specific Page-rank idea..

Summary of Key Points PageRank Iterative Algorithm Rank Sinks Efficiency of computation – Memory! –Single precision Numbers. –Don’t represent M* explicitly. –Break arrays into Blocks. –Minimize IO Cost. Number of iterations of PageRank. Weighting of PageRank vs. doc similarity.

Crawlers: Main issues General-purpose crawling Context specific crawiling –Building topic-specific search engines…

2/24 [Un]til I find a steady funder I'll make do with cheap-a## plunder Everybody wants a Google.. Wait! You will never never never need it It's free; I couldn't leave it Everybody wants a Google shirt Shameless corp'rate carrion crows Turn your backs and show your logos Everybody wants a Google shirt Shopping at job fairs Push my resume [But] jobs aren't what I seek I will be your walking student advertisement Can't live on my research stipend Everybody wants a Google shirt HP, Amazon Pixar, Cray, and Ford I just can't decide Help me score the most free pens and free umbrellas or a coffee mug from Bell Labs Everybody wants a Google.. ("Everybody Wants a Google Shirt" is based on "Everybody Wants to Rule the World" by Tears for Fears. Alternate lyrics by Andy Collins, Kate Deibel, Neil Spring, Steve Wolfman, and Ken Yasuhara.)

Discussion What parts of Google did you find to be in line with what you learned until now? What parts of Google were different?

Some points… Fancy hits? Why two types of barrels? How is indexing parallelized? How does Google show that it doesn’t quite care about recall? How does Google avoid crawling the same URL multiple times? What are some of the memory saving things they do? Do they use TF/IDF? Do they normalize? (why not?) Can they support proximity queries? How are “page synopses” made?

Beyond Google (and Pagerank) Are backlinks reliable metric of importance? –It is a “one-size-fits-all” measure of importance… Not user specific Not topic specific –There may be discrepancy between back links and actual popularity (as measured in hits) »The “sense” of the link is ignored (this is okay if you think that all publicity is good publicity) Mark Twain on Classics –“A classic is something everyone wishes they had already read and no one actually had..” (paraphrase) Google may be its own undoing…(why would I need back links when I know I can get to it through Google?) Customization, customization, customization… –Yahoo sez about their magic bullet.. (NYT 2/22/04) –"If you type in flowers, do you want to buy flowers, plant flowers or see pictures of flowers?"

The rest of the slides on Google as well as crawling were not specifically discussed one at a time, but have been discussed in essence (read “you are still responsible for them”)

SPIDER CASE STUDY

Web Crawling (Search) Strategy Starting location(s) Traversal order –Depth first –Breadth first –Or ??? Cycles? Coverage? Load? b c d e fg h i j

Robot (2) Some specific issues: 1.What initial URLs to use? Choice depends on type of search engines to be built. For general-purpose search engines, use URLs that are likely to reach a large portion of the Web such as the Yahoo home page. For local search engines covering one or several organizations, use URLs of the home pages of these organizations. In addition, use appropriate domain constraint.

Robot (7) Several research issues about robots: Fetching more important pages first with limited resources. –Can use measures of page importance Fetching web pages in a specified subject area such as movies and sports for creating domain-specific search engines. –Focused crawling Efficient re-fetch of web pages to keep web page index up-to-date. –Keeping track of change rate of a page

Storing Summaries Can’t store complete page text –Whole WWW doesn’t fit on any server Stop Words Stemming What (compact) summary should be stored? –Per URL Title, snippet –Per Word URL, word number But, look at Google’s “Cache” copy

Robot (4) 2.How to extract URLs from a web page? Need to identify all possible tags and attributes that hold URLs. Anchor tag: … Option tag: … Map: Frame: Link to an image: Relative path vs. absolute path:

Focused Crawling Classifier: Is crawled page P relevant to the topic? –Algorithm that maps page to relevant/irrelevant Semi-automatic Based on page vicinity.. Distiller:is crawled page P likely to lead to relevant pages? –Algorithm that maps page to likely/unlikely Could be just A/H computation, and taking HUBS –Distiller determines the priority of following links off of P

Anatomy of Google (circa 1999) Slides from

Number of indexed pages, self-reported Google: 50% of the web? Search Engine Size over Time The “google” paper Discusses google’s Architecture circa 99

System Anatomy High Level Overview

Google Search Engine Architecture SOURCE: BRIN & PAGE URL Server- Provides URLs to be fetched Crawler is distributed Store Server - compresses and stores pages for indexing Repository - holds pages for indexing (full HTML of every page) Indexer - parses documents, records words, positions, font size, and capitalization Lexicon - list of unique words found HitList – efficient record of word locs+attribs Barrels hold (docID, (wordID, hitList*)*)* sorted: each barrel has range of words Anchors - keep information about links found in web pages URL Resolver - converts relative URLs to absolute Sorter - generates Doc Index Doc Index - inverted index of all words in all documents (except stop words) Links - stores info about links to each page (used for Pagerank) Pagerank - computes a rank for each page retrieved Searcher - answers queries

Major Data Structures Big Files –virtual files spanning multiple file systems –addressable by 64 bit integers –handles allocation & deallocation of File Descriptions since the OS’s is not enough –supports rudimentary compression

Major Data Structures (2) Repository –tradeoff between speed & compression ratio –choose zlib (3 to 1) over bzip (4 to 1) –requires no other data structure to access it

Major Data Structures (3) Document Index –keeps information about each document –fixed width ISAM (index sequential access mode) index –includes various statistics pointer to repository, if crawled, pointer to info lists –compact data structure –we can fetch a record in 1 disk seek during search

Major Data Structures (4) URL’s - docID file –used to convert URLs to docIDs –list of URL checksums with their docIDs –sorted by checksums –given a URL a binary search is performed –conversion is done in batch mode

Major Data Structures (4) Lexicon –can fit in memory for reasonable price currently 256 MB contains 14 million words 2 parts –a list of words –a hash table

Major Data Structures (4) Hit Lists –includes position font & capitalization –account for most of the space used in the indexes –3 alternatives: simple, Huffman, hand- optimized –hand encoding uses 2 bytes for every hit

Major Data Structures (4) Hit Lists (2)

Major Data Structures (5) Forward Index –partially ordered –used 64 Barrels –each Barrel holds a range of wordIDs –requires slightly more storage –each wordID is stored as a relative difference from the minimum wordID of the Barrel –saves considerable time in the sorting

Major Data Structures (6) Inverted Index –64 Barrels (same as the Forward Index) –for each wordID the Lexicon contains a pointer to the Barrel that wordID falls into –the pointer points to a doclist with their hit list – the order of the docIDs is important by docID or doc word-ranking –Two inverted barrels—the short barrel/full barrel

Major Data Structures (7) Crawling the Web –fast distributed crawling system –URLserver & Crawlers are implemented in phyton –each Crawler keeps about 300 connection open –at peek time the rate pages, 600K per second –uses:internal cached DNS lookup –synchronized IO to handle events –number of queues –Robust & Carefully tested

Major Data Structures (8) Indexing the Web –Parsing should know to handle errors –HTML typos –kb of zeros in a middle of a TAG –non-ASCII characters –HTML Tags nested hundreds deep Developed their own Parser –involved a fair amount of work –did not cause a bottleneck

Major Data Structures (9) Indexing Documents into Barrels –turning words into wordIDs –in-memory hash table - the Lexicon –new additions are logged to a file –parallelization shared lexicon of 14 million pages log of all the extra words

Major Data Structures (10) Indexing the Web –Sorting creating the inverted index produces two types of barrels –for titles and anchor (Short barrels) –for full text (full barrels) sorts every barrel separately running sorters at parallel the sorting is done in main memory Ranking looks at Short barrels first And then full barrels

Searching Algorithm –1. Parse the query –2. Convert word into wordIDs –3. Seek to the start of the doclist in the short barrel for every word –4. Scan through the doclists until there is a document that matches all of the search terms –5. Compute the rank of that document –6. If we’re at the end of the short barrels start at the doclists of the full barrel, unless we have enough –7. If were not at the end of any doclist goto step 4 –8. Sort the documents by rank return the top K (May jump here after 40k pages)

The Ranking System The information –Position, Font Size, Capitalization –Anchor Text –PageRank Hits Types –title,anchor, URL etc.. –small font, large font etc..

The Ranking System (2) Each Hit type has it’s own weight –Counts weights increase linearly with counts at first but quickly taper off this is the IR score of the doc –(IDF weighting??) the IR is combined with PageRank to give the final Rank For multi-word query –A proximity score for every set of hits with a proximity type weight 10 grades of proximity

Feedback A trusted user may optionally evaluate the results The feedback is saved When modifying the ranking function we can see the impact of this change on all previous searches that were ranked

Results Produce better results than major commercial search engines for most searches Example: query “bill clinton” –return results from the “Whitehouse.gov” – addresses of the president –all the results are high quality pages –no broken links –no bill without clinton & no clinton without bill

Storage Requirements Using Compression on the repository about 55 GB for all the data used by the SE most of the queries can be answered by just the short inverted index with better compression, a high quality SE can fit onto a 7GB drive of a new PC

Storage Statistics Web Page Statistics

System Performance It took 9 days to download 26million pages 48.5 pages per second The Indexer & Crawler ran simultaneously The Indexer runs at 54 pages per second The sorters run in parallel using 4 machines, the whole process took 24 hours