1. The Anatomy Of A Large Scale Search Engine
Based on a paper by:
Sergey Brin & Lawrence Page
Computer Science Department, Stanford University
- submitted to WWW7 (1997)
lecture by: Tal Blum
for the SDBI seminar
בהרצאה זו אני סוקר מאמר של האדונים סרגי ברין ו- לורנץ פייג’ , שני דוקטורנטים ממחלקת מדעי המחשב באוניברסיטת סטנפורד.
המאמר הוגש לכינוס www7 בשנת 1997, לכן חלו שינויים מאז יצא המאמר לחלקם אני אתייחס.

2. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Index
Introduction
Design Goals
System Features
Related Work
System Anatomy
Results & Performance
Conclusions
Future Work
References
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

3. The Anatomy Of A Large Scale Hypertextual Web Search Engine
What is Google?
Large-scale search engine
makes extensive use in hypertext
designed to crawl & index the web efficiently
gives better results
prototype at or
googol = 10^100
בהרצאה זו אני מציג את מנוע החיפוש גוגל דוגמא למנוע חיפוש בסדר גודל גדול ,אשר משתמש בצורה חזקה במבנה המוגדר ע’’י ההיפר טקסט. google מיועד לזחול ולמפות את הרשת במהירות וביעילות ולתת תוצאות טובות יותר מאשר מנועי חיפוש קיימים. ניתן להשתמש ולבדוק את אב הטיפוס בכתובת או .
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

4. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Why talk about google?
To engineer a SE is a challenging task
millions of pages, terms, queries
little academic research
SE today is not what it was 5 years ago
the first detailed public description of SE
better results using hypertext
uncontrolled hypertext collections
בלתכנן מנוע חיפוש יש הרבה אתגר, יש מאות מיליוני דפים, מיליוני מילים שונות, ומנוע החיפוש צריך לענות על עשרות מיליוני שאילתות מידי יום.
למרות החשיבות של מנועי החיפוש לא נעשה מחקר רב עליהם, מעבר לזאת לתכנן מנוע חיפוש כיום זה שונה מאוד מאשר לפני 5 שנים.
המאמר עליו אני מרצה נותן תאור לעומק של מנוע חיפוש בסדר גודל גדול הראשון שיצא ואולי אף היחיד שנותן תאור פומבי כזה מפורט.
מלבד בעיות של התאמת שיטות מסורתיות של חיפוש לdata מסדר גודל של ה-web , המאמר גם מטפל בשאלה של איך לנצל את המידע הנוסף הנמצא ב hypertext.
בנוסף המאמר גם נוגע בבעייתיות של איך לטפל ביעילות ב- data-bases בהם כל אחד יכול לפרסם כל מה שברצונו.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

5. The Anatomy Of A Large Scale Hypertextual Web Search Engine
The web - IR challenge
2 main ways for surfing:
high quality human maintained lists (Yahoo)
too slow to improve
cannot cover esoteric topics
expensive to build and maintain
search engines (google, altavista)
search by keywords
too many low quality matches
people try to mislead automated search engines
כמות המידע ברשת גדלה בצורה אקספוננציאלית וכך גם מספר האנשים המשתמשים ברשת כדי להוציא מידע.
אנשים גולשים ברשת בשני אופנים עיקריים:
דרך אחת היא ע”י רשימות חיפוש המסודרות לפי נושאים, שנוצרו בידי אדם.
דרך אחרת היא ע”י מנועי חיפוש המחפשים ב-data-base לפי רשימת מילים
(יש גם רשימות לפי נושאים חצי אוטומטיות לדוגמא Infoseek המשתמשות בשיטות של למידה חישובית, אך סובלות מחלק מהבעיות של מנועי חיפוש לפי מילים)
רשימות ע”י אדם מכסות נושאים פופולריים בצורה טובה , אך הם סובייקטיבים, יקרים לבנות ולתחזק, ולא יכולים לכסות את כל הנושאים האזוטריים.
מנועי החיפוש האוטומטיים המסתמכים על התאמת מילות מפתח בד”כ מחזירים יותר מידי תוצאות עם איכות נמוכה.
כדי להפוך את העניינים לגרוע יותר, מפרסמים, כדי לזכות בתשומת לב ה אנשים , נוקטים בצעדים שמטרתם להטעות את מנועי החיפוש האוטומטים.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

6. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Web Growth
כמו שאנו רואים ה-www גדל בצורה אקספוננציאלית כאשר בהתחלה כמות הדפים הייתה מכפילה עצמה כל 3 חודשים , ואף כיום קצב ההכפלה הוא לפחות כל חצי שנה.
נשים לב כי גם % האתרים המסחריים מתוך הכלל גם כן גדל, דבר שכמו שאמרתי מקשה על מנועי החיפוש
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

7. Web Search Engine Scaling-Up 1994-2000
First SE WWWW (1994) had an index of 110,000 web pages, 1500 queries
November 1997 index of million web pages, 20 million(Altavista)
expected that by 2000 SE will have an index of billion web pages, hundreds of millions of queries
הטכנולוגיה של מנועי החיפוש צריכה להתמודד עם העלייה הדרמתית במספר הדפים.
ב-1994 למנוע החיפוש הראשון WWW WORM היה אינדקס בגודל 110,000 . מנובמבר 1997 למנועי החיפוש הרציניים יש אינדקס של 2 עד 100 מליון דפים, עד שנת 2000 מצפים שלמנוע חיפוש מכובד יהיו יותר ממיליארד מסמכים.
באותו זמן מספר השאילתות שהוגשו למנוע חיפוש גדל אף הוא מ-1500 שאילתות ליום ב-1994 , ל-20 מליון שאילתות ליום לפי AltaVista, ולמאות מיליוני שאילתות ביום לפי הצפוי בשנת 2000.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

8. Web Search Engine Scaling-Up 1999
Challenges in Creating a Search Engine which scales even to today web
Fast crawling technology
gather documents, keep them up to date
Efficient storage space
indices, optionally the documents
Handle queries quickly
rate of thousands per second
יצירת מנוע חיפוש שמותאם ל- WWW אפילו כפי שהיא היום מציבה הרבה אתגרים.
- טכנולוגית crawling מהירה כדי לאסוף מסמכים ולהיות מעודכן לשינוי המסמכים
- שימוש בזיכרון צריך להיעשות בצורה יעילה וחסכונית, כדי לשמור את כניסות המילים ואולי אף את המסמכים.
- שאילתות צריכות להיענות במהירות ובקצב של מאות עד אלפים לשניה.
אתגרים אילו נעשים קשים יותר ויותר כשה-www גדלה.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

9. Google: Scaling with the web
Improved Hardware Performance
exceptions disk seek time, OS
Google is designed to scale well to extremely large data sets
Google’s data structure are optimized for fast & efficient access
Google is a centralized SE
מצד שני ביצועי החומרה ועלותה משתפרים בצורה דרמתית ומפצים בצורה חלקית על גדילת ה-www. אולם יש כמה יוצאי דופן ראויים לציון , disk seek time ו-קשיחות מערכת ההפעלה למשל.
- הרבה מחשבה הושקעה בכדי להתאים את Google ל-data-sets גדולים במיוחד.
- Google משתמש במבני נתונים, המתאימים גם ל-data-sets גדולים במיוחד מבלי לפגום במיוחד במהירות.
- יוצרי Google מצפים שמחיר אכסון text ירד בהשוואה לעליה בכמות ה-text דבר שייתן עדיפות למערכות ריכוזיות דוגמת Google.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

10. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Design Goals
Improved Search Quality
Junk Results
Number of documents has increased by many factors
User ability to look at documents has not
As the collection size grows we need tools with very high precision even at the expanse of recall
Use of hypertextual information
In google: link structure & anchor text
המטרה העיקרית של מתכנני Google הייתה לשפר את איכות תוצאות החיפוש.ב-1994 אנשים האמינו שמנוע חיפוש שלם יוכל למצוא הכל בקלות(best of the web 1994), אולם כבר ב-1997 המצב הוא אחרת מי שהשתמש במנוע חיפוש יכול להעיד ששלמות ה- index אינה הפרמטר היחיד באיכות החיפוש.
תוצאות זבל , לפעמים מעיפים את כל התוצאות שהמשתמש מעונין בהם. לדוגמא ב רק אחד מ-4 מנועי חיפוש המובילים החזיר את עצמו כתשובה לשאילתה של שמו. אחד הגורמים העיקריים לכך הוא העובדה שמספר המסמכים גדל בכמה סדרי גודל בעוד שיכולת המשתמש להסתכל על מספר מסמכים לא גדלה, אנשים מוכנים רק להסתכל על מספר עשרות של מסמכים. בגלל זה כאשר גודל אוסף המסמכים גדל אנו זקוקים לכלים מאוד מדויקים. הדיוק מאוד חשוב אפילו על חשבון recall. יש אופטימיות רבה לגבי שימוש באינפורמציה של ה-hypertext לשיפור תוצאות החיפוש. ב-google משתמשים במבנה הטופוגרפי של הלינקים וב-text של הלינק.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

11. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Design Goals (2)
Academic Search Engine Research
SE has migrated from academic domain to the commercial
SE technology became mostly a black art & advertising oriented.
Get people usage Information
considered commercially valuable
Support novel research activities on large-scale web data
כמו שראינו ה-web גם נעשה מאוד מסחרי, מ-1.5% של web sites ב-1993 ל-מעל 60% ב-1997, באותו זמן גם מנועי החיפוש נדדו מהתחום האקדמי לתחום המסחרי.
עד לפרסום המאמר רב הפיתוח של מנועי החיפוש נעשה בחברות עם פרסום מועט של פרטים טכניים, דבר זה גרם לכך שטכנולוגית מנועי החיפוש נשארה “black art” ומוטה לכיוון פרסום(OpenText , Yahoo).
מתכנני google חשבו שחשוב שיהיה מנוע בתחום האקדמי, עתה זה מצחיק או עצוב כי גם google מכיוון שהיה מוצלח כל כך נהפך למסחרי, גייס הרבה כסף ולא מפרסם פרטים טכניים יותר.
דבר נוסף שחשבו עליו בתכנון המנוע הוא שרצו שהרבה אנשים ישתמשו בו, המחקר המעניין ביותר יתבסס על המידע של שימוש אנשים במנוע, הבעיה היא שמידע זה הוא בעל ערך מסחרי לכן קשה להשיגו.
המטרה האחרונה הייתה ליצור ארכיטקטורה שתתמוך בפעולות מחקר חדשות על web data בהיקף גדול. סביבה בה יכולים חוקרים אחרים לבוא ולעבד חלקים גדולים מה-web. לשם כך google שומר את כל הדפים שהוא עובר עליהם בצורה מכווצת.בזמן הקצר שהמערכת פעלה (עד לפרסום) כבר השתמשו בה הרבה חוקרים ויצאו מספר מאמרים. רעיון נוסף הוא ליצור מעין מעבדה מוכנה בה אנשים יוכלו לעשות ניסויים מעניינים.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

12. The Anatomy Of A Large Scale Hypertextual Web Search Engine
System Features
PageRank: Bringing order to the web
most web SE has largely ignored the link graph
518 million hyperlinks
correspond well with people idea of importance
Pr(A) = (1-d) + (Pr(T1)/C(T1)+…+Pr(Tn)/C(Tn))
difference from traditional methods
not counting links from pages equally
normalizing by the number of links in a page
different from Hits of Kleiberg
גרף הציטוטים או הלינקים לא נמצא בשימוש נרחב במנועי החיפוש כיום.
ב-google יצרו מפות המכילות כ-518 מיליון לינקים. המפות מאפשרות חישוב מהיר של PageRank של דף, מידה אובייקטיבית, לא תלויה בשאילתה , של חשיבות לפי ציטוט, אשר תואמת בצורה טובה את המושג של אנשים של חשיבות או מוסמכות.לכן PageRank מהווה דרך טובה לדרג דפים בצורה טובה. למשל דרוג פשוט של דפים רק לפי ה-titles שלהם משתפר פלאים כאשר מוסיפים את PageRank והוא משפר מאוד גם ל-text מלא.
צידוק רואים בכך שדף יקבל ערך גדול אם הרבה דפים מצביעים עליו או דפים מוסמכים.לדוגמא אם דף אינו מאיכות גבוהה או לינק שבור אז לא סביר שהרבה יצביעו עליו או yahoo.
PageRank מאופיין ע”י כך שהוא אינו מחשיב לינקים מכל מדפים בצורה שווה וע”י כך שהשפעה של לינקים של דף מנורמלת ע”י מספר הלינקים בדף.
שימו לב כי ההגדרה של PageRank היא מעגלית. ניתן לחשב את PageRank ע”י שימוש באלגוריתם איטרטיבי פשוט. והערך מתאים לווקטור העצמי העיקרי של המטריצה המנורמלת של ה-web. מי שמכיר את האלגוריתם Hits של kleinberg שנלמד ב-IPL רואה דמיון לשיטה זו, שם היו hubs & authorities והפתרון היה הווקטור העצמי העיקרי של המטריצה מוכפלת בtranspose שלה.
עוד דבר מצחיק הוא שפירוט השיטה אמורה להיות במאמר של page אך הוא או שלא יצא מעולם או נגנז כשהמנוע נהיה מסחרי
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

13. The Anatomy Of A Large Scale Hypertextual Web Search Engine
System Features (2)
Anchor Text
Associate link text with the page it points to
advantages
anchor provide more accurate description
can exist for documents that can’t be indexed
images, programs, databases, mp3, non-text docs, s
can return web pages that hadn’t been crawled
was first used in WWW Worm 1994
ברב מנועי החיפוש הטקסט בתוך הלינק מיוחס לדף בתוכו נמצא הלינק. ב-google מייחסים אותו בנוסף לדף עליו הוא מצביע.
לכך יש מספר יתרונות:
ראשית anchor text מספק תיאור מדויק יותר של התוכן של דף מאשר הטקסט של הדף. שנית ניתן לייחס anchor text גם למקורות שלא ניתן לזחול עליהם כמו images, s, databases etc כך מנוע החיפוש יכול להחזיר יותר סוגי מידע. יתרון נוסף הוא בכך שהמנוע יכול גם להחזיר דפי טקסט שהוא לא זחל עליהם, דבר שאף יכול לגרום לבעיות כגון דפים שאינם קיימים .
Anchor text השתמשו לראשונה ב-www worm 1994 בעיקר כדי לתאר מקורות שאינם טקסט, ולהרחיב את הכיסוי מבלי להגדיל את הdata יותר מידי. ב-google משתמשים בזה בעיקר כדי לשפר את תוצאות החיפוש.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

14. The Anatomy Of A Large Scale Hypertextual Web Search Engine
System Features (3)
Other Features
Location Information
Use of proximity in search
Visualization Information
Font relative Size
Full raw HTML is available
users can view a cashed version of the page
users can view the page as it was when indexed
can be used for research
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

15. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Related Work
SE have short history (wwww 1994)
commercial services closely guard the details of their databases
work on specialized features of SE
especially on post-processing results of SE
work on Information Retrieval Systems
especially on well controlled environments
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

16. IR &Differences Between the Web and Well Controlled Collections
“TREC 96”s “Very Large Corpus” is only 20GB compared to 147GB of Google crawl
The Web is a vast collection of heterogeneous documents
language, vocabulary, format
things that work well for TREC often do not produce good results on the web
there is no control over what people put on the web
עבודה רבה נעשתה ב-information retrieval על אוספי hyperlink, אולם רוב המחקר נעשה על אוספים הנשלטים ע”י החוקרים והומוגנים, כמו אוספים של מאמרים מדעיים, או news על נושאים קשורים.ה-benchmark העיקרי נ-IR בגודל 20 GB בהשוואה ל 147 GB מהזחילה על 24 מליון דפי web.
מודל ה-ווקטור space הנפוץ ב-IR , שהופך כל שאילתה ודף לווקטור נוטה להחזיר מסמכים קצרים. לדוגמא ביל קלינטון יש מספיק מידע מוסמך עליו.
ה-web הוא אוסף גדול של מסמכים הטרוגנים שלא בשליטת החוקרים. שונות בין המסמכים יכולה להיות פנימית כמו שפה או מושגים שונים כגון s, או מספרי מוצרים וכו, או אפילו פורמט שונה HTML, PDF IMG SOUND.
שוני נוסף הוא שב-רשת meta אינפורמציה על דף היא דבר חיצוני בד”כ כגון פופולריות ,הצבעה , תדירות עדכון של דף.
שוני גדול נוסף הוא שברשת איו שום שליטה על מה שאנשים יכולים לשים ברשת,תוסיפו לזה את המשקל שיש למנועי חיפוש על תעבורה ברשת ומקבלים בעיה רצינית כאשר אנשים מנסים להטעות את מנועי החיפוש.יש חברות שמתמחות בכך.
מעניין לציין ש-metadata נכשל ב-web, בגלל שטקסט שאינו נראה למשתמש אידיאלי להטעיית מנועי חיפוש.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

17. The Anatomy Of A Large Scale Hypertextual Web Search Engine
System Anatomy
בשקף זה מבט מלמעלה של איך המערכת פועלת.
רב הקוד של google נכתב ב-C או C++ ליעילות ומורץ על Solaris או Linux.
ההורדה של עמודי web נעשית ע”י web crawler-ים מבוזרים (שלשה), ה-URL Server שולח רשימות של URL-ים לcrawlers. דפי ה-web מובאים ונשלחים ל-Store Server. שם הוא דוחס אותם ושומר אותם ב-Repository.
לכל URL ניתן זיהוי מיוחד לו - docID כאשר הוא מוצא כלינק חדש מדף.
פונקצית הindexing נעשית ע”י ה-Indexer וה-Sorter. ה-Indexer מבצע מספר דברים, הוא קורא מה-Repository, פותח את הכיווץ ומפרסס את הדף. כל דף נהפך לאוסף occurrences של מילים שנקראים hits. ה-Indexer מחלק את המילים לתוך אוסף של חביות ויוצר forward index ממוין חלקית. תפקיד נוסף של ה-Indexer הוא מוציא את כל הלינקים מדף ושומר אינפורמציה עליהם ב-Anchor file , קובץ זה מכיל כל מה שצריך כדי לדעת מאיפה,לאן והטקסט של הלינק.
ה-URLresolver קורא את ה-Anchor file והופך לינק יחסי למוחלט ואח”כ ל-docID , בנוסף הוא שם את ה-Anchor text לתוך ה-forward index מקושר ללינק עליו הוא הצביע. בנוסף הוא יוצר את הDB של הלינקים שהם זוגות docID.
ה-DB של הלינקים משמש לחישוב PageRank של כל המסמכים.
ה-Sorter לוקח את החביות שממוינות לפי docID וממיין אותן מחדש לפי wordID ליצירת ה-inverted index. פעולה זו נעשית במקום כך שמעט זיכרון זמני דרוש לפעולה. הוא גם יוצר רשימה של wordID-ים ומיקומם ב-inverted index. ה-Searcher רץ על server ומשתמש ב-PageRank, Lexicon, inverted
High Level Overview
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

18. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
מבני הנתונים של google עברו אופטימיזציה כדי שאפשר יהיה לזחול לאנדקס ולחפש בעלות נמוכה.
בעוד אך בעוד זמן CPU קטן disk seek time נשאר 10 ms לכן google מתוכנן להימנע ככל האפשר מגישה לדיסק, ולפיכך הייתה לזה השפעה רבה על תכנון מבני הנתונים.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

19. 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
ה-Repository מכיל את מלא הHTML של כל דף, כל דף מכווץ ע”י zlib , בבחירת שיטת הכיווץ יש trade-off בין מהירות לבין יחס כיווץ, הם בחרו ב-zlib למרות ש-bzip היה הרבה יותר מכווץ 4-1 לעומת הדפים נשמרים אחד אח ר השני כפי שרואים בציור docID , errorcode , אורך וURL.
ה-Repositery אינו דורש מבנים נוספים כדי לגשת איליו, ניתן לבנות את כל שאר המבנים רק ממנו.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

20. 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
הרשומה מכילה מידע אם הדף נזחל, אם כן פוינטר לרשימה המכילה את ה-URL שלו וה-title שלו, אחרת פוינטר לרשימה המכילה רק את ה-URL שלו.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

21. 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
מבנה נוסף הוא קובץ בו משתמשים כדי להפוךURL-ים ל docID-ים. הקובץ מכיל רשימה של checksum עם ה-docID המתאימים. כדי למצוא docID מתבצע חיפוש בינארי על הרשימה. ה-URLresolver משתמש בקובץ זה ב-batch mode אז כל הרשימה נמצאת בזיכרון, mode זה הוא חיוני בגלל שאים נבצע בקשה מהדיסק כל לינק, זה ייקח יותר מחודש להפוך את ה-DB של 322 מיליון לינקים.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

22. 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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

23. 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
הקידוד הידני מתאר 2 סוגים של hits,והם fancy & plain. Fancy כוללים כאילו בתוך URL, title, anchor text or meta tags, רגילים כוללים כל השאר.
גודל הפונט הוא יחסי לגודל שאר המסמך ע”י 3 ביטים, 111 מייצג fancy hit.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

24. Major Data Structures (4)
Hit Lists (2)
כמו שרואים כדי לייצג את מספר ה-Hits , יש 8 ו-5 ביטים ב-2 סוגי האינדקסים. לשמור מקום, אורך הרשימה, משולב עם wordID ב-forward index, ועם ה-docID ב-inverted index, יש מספר טריקים כיצד לייצג מספר גדול יותר ע”י escape code ואז 2 הבייטים הבאים מייצגים את האורך.
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

25. 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
save considerable time in the sorting
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

26. 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
in Google they choose a compromise
דבר חשוב הוא הסדר לפיו מסודרים המסמכים בכל רשימת-מילה, אפשרות אחת היא למיין לפי docID , זה מאפשר מיזוג מהיר של רשימות של כמה מילים, אופציה אחרת היא למיין לפי דרוג של הופעת המילה במסמך, זה מאפשר לענות לשאילתות של מילה אחת בצורה טריביאלית (לוקחים את הראשונות) וכנראה שהתשובה לשאילתות של כמה מילים יהיו קרובות להתחלה. בשיטה זו מיזוג הרבה יותר קשה וזה אף מקשה על הפיתוח מכיוון ששינוי בפונקצית הדירוג מחייב בניה מחדש של האינדקס.
ב-google בחרו בפשרה בין 2 הגישות כדי להבחין בצורה מוגבלת בין טיב של דפים למילה, הם שומרים 2 רשימות של hits . הראשונה ל-hits שהם fancy כלומר חשובות מ-title, anchor ושניה לשאר, כך הם בודקים את הראשונה ואים אין מספיק תוצאות הם בודקים את השניה, בצורה זו זה לא תלוי בפונקצית הדרוג.
שימו לב כדי להחזיר תוצאות מהר מחזירים תוצאות תת-אופטימליות
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

27. 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
זחילה היא האפליקציה השבירה ביותר כיוון שהיא מעורבת באינטראקציה עם מאות אלפי סרברים אחרים שהם מעבר לשליטת המערכת. כדי לטפל בכזו כמות של דפים למנוע יש מערכת מהירה ומבוזרת לזחילה.
ב-google הם מריצים 3 crawlers כל אחד מחזיק בו-זמנית 300 התקשרויות. בזמן השיא הם מצליחים להוריד 100 דפים בשניה או 600 KB.
כדי לייעל כל crawler שומר טבלת DNS LOOKUP משל עצמו ב-cache.
אובייקטים כאילו הם מאוד מסובכים כל דף יכול להימצא במספר מצבים לפני חיפוש שם, אחרי,התקשרות, אחרי שליחת הבקשה, בזמן קבלת תשובה, לכן הcrawler משתמש ב-IO מסונכרן ובמספר תורים.
כנראה ששיטה זו עדיפה על לתת למערכת הC++ לטפל למקבילות.
להריץ מערכת כזו מקבלים הרבה טלפונים מבעלי אתרים, חלקם לא יודע על פרוטוקול שמאפשר שלא יזחלו על אתריו.
דברים לא צפויים יקרו למשל לזחול על משחק online בעיה שקרתה רק אחרי מיליון דפים
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

28. 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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

29. 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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

30. Major Data Structures (10)
Indexing the Web
Sorting
creating the inverted index
produces two types of barrels
for titles and anchor
for full text
sorts every barrel separately
running sorters at parallel
the sorting is done in main memory
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

31. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

32. The Anatomy Of A Large Scale Hypertextual Web Search Engine
The Ranking System
The information
Position, Font Size, Capitalization
Anchor Text
PageRank
Hits Types
title ,anchor , URL etc..
small font, large font etc..
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

33. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

34. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

35. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

36. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

37. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Storage Statistics
Web Page Statistics
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

38. The Anatomy Of A Large Scale Hypertextual Web Search Engine
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
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

39. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Conclusions
Scalable Search Engine
High Quality Search Results
Search techniques
PageRank
Anchor Text
Proximity Information
A Complete Architecture
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

40. The Anatomy Of A Large Scale Hypertextual Web Search Engine
Future Work
Improve search efficiency
Scale to 100 million
Boolean Operators
Text Surrounding Links
Personalization PageRank
Result Summarization
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

41. The Anatomy Of A Large Scale Hypertextual Web Search Engine
New Features
Google Scout
Documents Caching
Uncle Sam’s
Link: option
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine

42. The Anatomy Of A Large Scale Hypertextual Web Search Engine
The End
י"ב/תשרי/תשע"ט
The Anatomy Of A Large Scale Hypertextual Web Search Engine