Як Google може бути таким швидким?


89

Які технології та рішення щодо програмування дозволяють Google так швидко подавати запит?

Кожного разу, коли я щось шукаю (один із декількох разів на день), мене завжди вражає, як вони подають результати майже в 1 секунду. Яку конфігурацію та алгоритми вони могли б створити для досягнення цього?

Примітка: Це неймовірне мислення, що навіть якби я поставив настільний додаток і використовував його на своїй машині, мабуть, це не було б наполовину швидше, ніж Google. Продовжуй вчитися, кажу я.


Ось декілька чудових відповідей та рекомендацій:

Відповіді:


47

Затримку вбиває доступ до диска. Отже, розумно вважати, що всі дані, що використовуються для відповіді на запити, зберігаються в пам'яті. Це передбачає тисячі серверів, кожен з яких копіює один із багатьох осколків. Тому критичний шлях пошуку навряд чи вдарить до будь-якої з їхніх флагманських розподілених системних технологій GFS, MapReduce або BigTable. Вони будуть використовуватися для обробки результатів сканера, грубо.

Зручна річ пошуку полягає в тому, що немає необхідності мати чітко узгоджені результати чи повністю актуальні дані, тому Google не може заборонити відповідати на запит, оскільки з’явився більш сучасний результат пошуку.

Отже, можлива архітектура досить проста: інтерфейсні сервери обробляють запит, нормалізуючи його (можливо, викреслюючи слова зупинки тощо), потім розподіляючи його до будь-якої підмножини реплік, що володіє цією частиною простору запитів (альтернативна архітектура - розділити дані за веб-сторінками, так що з кожним набором реплік потрібно зв’язуватися для кожного запиту). Багато, багато реплік, мабуть, запитуються, і найшвидші відповіді виграють. Кожна репліка має індексне відображення запитів (або окремих термінів запиту) до документів, які вони можуть використовувати для дуже швидкого пошуку результатів у пам'яті. Якщо різні результати повертаються з різних джерел, інтерфейсний сервер може класифікувати їх, коли випльовує html.

Зауважте, що це, мабуть, значно відрізняється від того, що насправді робить Google - вони створили життя цієї системи, тому може бути більше кеш-пам’яті в дивних районах, дивні індекси та якась прикольна схема балансування навантаження серед інших можливих відмінностей .



22

Один факт, який мені завжди здавалося смішним, полягає в тому, що Google насправді управляється біоінформатикою (`` Кей, я вважаю це смішним, тому що я біоінф ... штука). Дозволь пояснити.

Біоінформатика на початку мала проблему дуже швидко шукати невеликі тексти у гігантських рядках. Для нас "гігантська струна" - це, звичайно, ДНК. Часто не одна ДНК, а база даних кількох ДНК різних видів / особин. Маленькі тексти - це білки або їх генетичний аналог, ген. Більшість перших робіт обчислювальних біологів були обмежені для пошуку гомологій між генами. Це робиться для встановлення функції нещодавно знайдених генів, відзначаючи схожість із генами, які вже відомі.

Тепер ці низки ДНК справді дуже збільшуються, і (з втратами!) Пошук повинен здійснюватися надзвичайно ефективно. Таким чином, більша частина сучасної теорії пошуку струн була розроблена в контексті обчислювальної біології.

Однак, досить давно, звичайний пошук тексту був вичерпаний. Потрібен був новий підхід, який дозволяв здійснювати пошук великих рядків у підлінійний час, тобто без перегляду кожного окремого символу. Було виявлено, що це можна вирішити, попередньо обробивши великий рядок і побудувавши над ним спеціальну структуру даних індексу. Запропоновано багато різних таких структур даних. Кожен має свої сильні та слабкі сторони, але є один, який особливо вражає тим, що дозволяє шукати в постійний час. Зараз, в порядку порядку, в якому працює Google, це вже не є суто істинним, оскільки необхідно враховувати балансування навантаження між серверами, попередню обробку та деякі інші складні речі.

Але по суті так званий індекс q-грам дозволяє шукати в постійний час. Єдиний недолік: структура даних стає смішно великою. По суті, для того, щоб дозволити пошук рядків з до q символів (звідси і назва), потрібна таблиця, яка має одне поле для кожної можливої ​​комбінації q літер (тобто q S , де S - розмір алфавіту , скажімо 36 (= 26 + 10)). Крім того, має бути одне поле для кожної позиції літери в рядку, який було проіндексовано (або для Google для кожного веб-сайту).

Для зменшення простого розміру Google, ймовірно, використовуватиме кілька індексів (насправді вони це роблять , пропонуючи такі послуги, як виправлення орфографії). Найкращі з них працюватимуть не на рівні символів, а на рівні слова. Це зменшує q, але робить S нескінченно більшим, тому їм доведеться використовувати таблиці хешування та зіткнень, щоб справлятися з нескінченною кількістю різних слів.

На наступному рівні ці хешовані слова вказуватимуть на інші структури даних індексу, які, в свою чергу, будуть хешувати символи, що вказують на веб-сайти.

Коротше кажучи, ці структури даних індексу q- грамів є, безперечно, найбільш центральною частиною алгоритму пошуку Google. На жаль, немає хороших нетехнічних статей, які б пояснювали, як працюють індекси q- грам. Єдина публікація, яку я знаю, що містить опис того, як працює такий індекс, - це, на жаль, моя бакалаврська робота .


4
Я займався біоінформатикою 5 років, а пошукові системи після цього - і q-грами не такі важливі, як ви думаєте. Основною структурою даних для виду пошуку, який робить Google (на дуже-дуже базовому рівні), є перевернутий індекс.
SquareCog

Це здається неправильним. Google працює або працює на перевернутому індексі. q-грам буде корисним для фраз, але не в цілому
Стефан Савев

@Stefan: Той самий коментар уже зробив SquareCog - і я не заперечую, що перевернуті індекси відіграють велику (і, можливо, набагато більшу, ніж n-грамові індекси) роль. Я вибрав цю одну технологію, тому що n-грами - це моя структура даних про домашніх тварин, і я думаю, що ключове розуміння - Google швидкий, оскільки він насправді не повинен "шукати", він може зробити більш-менш прямий пошук - дійсно залежить від такого індексу (nb: це, мабуть, робиться за допомогою хешування, але це все одно n-грамовий індекс). Те, що цей індекс також інвертується, є випадковим для мене (хоча, мабуть, не для Google ;-)).
Конрад Рудольф

5

Ось декілька чудових відповідей та рекомендацій:


4

Вони запровадили хороші, розподілені алгоритми, що працюють на величезній кількості обладнання.


4

Одне з найважливіших затримок - веб-сервери - це отримання вашого запиту до веб-сервера та відповідь назад. Цю затримку зв’язує швидкість світла, якій дотримується навіть Google. Однак у них є центри обробки даних у всьому світі. Як результат, середня відстань до будь-якого з них менша. Це стримує затримку. Звичайно, різниця вимірюється в мілісекундах, але важливо, чи відповідь повинна надійти протягом 1000 мілісекунд.



3

Вони майже мають локальну копію Інтернету, кешовану на тисячах ПК у власних файлових системах.


Потрапляння на дискову файлову систему коштувало б багато з точки зору затримки (Amazon знайшла це з Динамо і пожертвувала деякою стійкістю за це); Я підозрюю, що все на критичному шляху зберігається в пам'яті.
HenryR

3

Google наймає найкращих із найкращих. Деякі з найрозумніших людей в ІТ працюють у Google. У них є практично нескінченні гроші, щоб кинути на обладнання та інженерів.

Вони використовують високооптимізовані механізми зберігання для завдань, які вони виконують.

Вони мають географічно розташовані ферми серверів.


3

Спроба узагальненого списку (який не залежить від того, чи маєте ви доступ до внутрішніх інструментів Google):

  1. Парелелізувати запити (наприклад, розбити один запит на менші набори)
  2. Async (зробіть якомога більше асинхронним, наприклад, не заблокуйте запит користувача)
  3. Пам'ять / кеш (Дисковий ввід / вивід повільний, зберігайте якомога більше в пам'яті)
  4. Попередньо обчислити (Виконайте якомога більше роботи перед тим, як чекати, не чекайте, поки користувач запитає дані / обробку)
  5. Подбайте про свій інтерфейсний HTML (див. Yslow та друзі)



1

Апаратне забезпечення.

Багато-багато обладнання. Вони використовують масивні кластери товарних ПК як свою ферму серверів.


Тільки для роз’яснення „масових”: сотні тисяч серверів. Думаю, ніхто за межами Google не знає справжньої цифри, і вона повинна постійно змінюватися.
Серхіо Акоста

1

TraumaPony має рацію. Тонни серверів та розумна архітектура для балансування навантаження / кешування та вуаля ви можете запустити запит менш ніж за 1 секунду. У мережі було багато статей, що описують архітектуру сервісів Google. Я впевнений, що ви можете знайти їх через Google :)




0

І алгоритми, які можуть використовувати цю апаратну потужність. Наприклад, як mapreduce .


MapReduce не використовується для відповіді на запити.
MSalters

MapReduce працює на великому кластері машин і є дуже масштабованим: типове обчислення MapReduce обробляє багато терабайт даних на тисячах машин. Впроваджено сотні програм MapReduce і щодня на кластерах Google виконується понад тисяча завдань MapReduce
Вінко Врсалович,

MapReduce майже напевно використовується для асинхронного індексування даних сканера. Я був би дуже здивований, якби це було на критичному шляху пошуку. Звільнення роботи MapReduce справді призвело б до затримки.
HenryR

Генрі - вони можуть використовувати його для маршрутизації в напрямках / картах. Але так, у загальному випадку. Ви не хочете, щоб відбувалося будь-яке жорстке обчислення, щоб відповісти на звичайний запит користувача.
SquareCog

0

Якщо вас цікавлять докладніші відомості про те, як працює кластер Google, я запропоную цю реалізацію HDFS із відкритим кодом .

Він заснований на Mapreduce від google.


HDFS - це розподілена файлова система. Клон mapreduce називається Hadoop і може працювати як на HDFS, так і у вашій локальній файловій системі.
SquareCog

0
  1. Багатоступеневе зберігання, обробка та пошук даних

  2. ЕФЕКТИВНИЙ розподіл (100 з 1000 машин) вищезазначених завдань

  3. Хороший фреймворк для зберігання вихідних даних та оброблених результатів

  4. Хороший фреймворк для отримання результатів

Те, як саме все це робиться, підсумовується за всіма посиланнями, які ви маєте в резюме запитання

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.