Ну, я не впевнений, чи вирішує проблему саме MapReduce, але, безумовно, не було б MapReduce самостійно вирішити всі ці питання, які ви порушили. Але ось важливі речі , які слід брати до уваги, і що робить його можливим , щоб мати таку низьку затримку на запити всіх цих терабайт даних в різних машинах:
- розподілене обчислення: поширення не означає, що індекси просто розподіляються на різних машинах, вони фактично реплікуються вздовж різних кластерів, що дозволяє багатьом користувачам виконувати різні запити з низьким часом пошуку (так, величезні компанії можуть дозволити собі стільки машин);
- кешування: кеші значно скорочують час виконання, будь то для кроку сканування, для пошуку сторінок або для ранжирування та виставлення результатів;
- багато налаштувань: всі вищезазначені та дуже ефективні алгоритми / рішення можуть бути ефективними лише в тому випадку, якщо реалізація також є ефективною. Існує багато оптимізацій (жорстко закодованих), таких як місцевість довідки, стиснення, кешування; всі вони, як правило, підходять до різних частин обробки.
Враховуючи це, давайте спробуємо вирішити ваші питання:
але я вважаю, що результати кожного можливого запиту неможливо індексувати
Так, було б і насправді неможливо мати результати для кожного можливого запиту . У світі існує нескінченна кількість термінів (навіть якщо ви припускаєте, що будуть введені лише правильно написані терміни), і існує експоненціальна кількість запитів із цих n -> infтермінів ( 2^n). Отже, що робиться? Кешування. Але якщо є так багато запитів / результатів, які кешувати? Політика кешування. Найчастіші / популярні / актуальні для користувача запити - це кешовані.
Хіба затримка в апаратному забезпеченні Google не була б величезною? Навіть якщо всі дані в Google були збережені в TB / s SSD
У наші дні з такими високорозвиненими процесорами люди схильні думати, що кожне можливе завдання, яке повинно закінчитися протягом секунди (або менше), і яке стосується стільки даних, повинно оброблятися надзвичайно потужними процесорами з декількома ядрами і великою кількістю пам'яті. Однак одне, що керує ринком, - це гроші, і інвестори не зацікавлені в тому, щоб їх витрачати. Отже, що робиться?
Перевагою є власне багато машин, кожна з яких використовує прості / доступні (з точки зору вартості) процесори, що знижує ціну на створення безлічі кластерів. І так, це працює. Основне вузьке місце завжди зводиться на диск, якщо враховувати прості вимірювання продуктивності . Але як тільки таких машин дуже багато, можна дозволити собі завантажувати речі до основної пам'яті, а не працювати на жорстких дисках.
Карти пам’яті дорогі нам, просто людським істотам, але вони дуже дешеві для підприємств, які купують багато таких карток відразу. Оскільки це не дорого, наявність великої кількості пам'яті, необхідної для завантаження індексів та збереження кеш-пам’яті, не є проблемою. А оскільки машин дуже багато, немає необхідності в надшвидких процесорах, оскільки ви можете направляти запити в різні місця та мати кластери машин, відповідальних за відвідування конкретних географічних регіонів , що дозволяє більш спеціалізоване кешування даних та ще кращу відповідь разів.
Чи допомагає MapReduce вирішити цю проблему?
Хоча я не думаю, що використання або не MapReduce є обмеженою інформацією всередині Google, я не розбираюся з цього приводу. Однак реалізація MapReduce від Google (яка, безумовно, не Hadoop) повинна мати багато оптимізацій, багато з яких стосуються аспектів, обговорених вище. Так, архітектура MapReduce, ймовірно, допомагає керувати тим, як обчислення фізично розподіляються, але є багато інших пунктів, які слід враховувати, щоб виправдати таку швидкість у часі запитів.
Гаразд, тому я розумію, що популярні пошукові запити можуть зберігатися в пам'яті. А як же непопулярні пошуки?
На графіку нижче представлена крива того, як відбуваються види запитів. Ви можете бачити, що існує три основних види пошуку, кожен з яких займає приблизно 1/3 обсягу запитів (область нижче кривої). Сюжет показує закон про владу та підкреслює той факт, що найменші запити є найпопулярнішими. Другу третину запитів все ще можливо обробити, оскільки вони містять мало слів. Але набір так званих незрозумілих запитів , які зазвичай складаються із запитів не досвідчених користувачів, не є незначною частиною запитів.
І там є простір для нових рішень. Оскільки це не лише один чи два запити (але третина з них), вони повинні мати відповідні результати. Якщо ви наберете в чому - то занадто затінювати в пошуку Google, воно не повинно зайняти більше часу , щоб повернути список результатів, але, швидше за все , показати вам дещо - що виведений ви хочете сказати. Або може просто сказати, що не було жодного документа з такими термінами - або навіть скоротити ваш пошук до 32 слів (що зі мною щойно трапилось у випадковому тесті).
Є десятки застосовної евристики, які можуть бути або ігнорувати деякі слова, або намагатися розбити запит на більш дрібні, і зібрати найпопулярніші результати. І всі ці рішення можуть бути налаштовані та налаштовані на дотримання можливих час очікування , скажімо, менше секунди? : D