Как запрос в огромную базу данных возвращает с незначительной задержкой?

Например, при поиске в Google результаты возвращаются практически мгновенно.

Я понимаю, что Google сортирует и индексирует страницы с помощью алгоритмов и т. Д., Но я считаю невозможным индексировать результаты каждого отдельного запроса (и результаты персонализируются, что делает это еще более неосуществимым)?

Кроме того, не аппаратная задержка в аппаратных средств от Google будет огромной? Даже если бы все данные в Google хранились на твердотельных накопителях TB / s, я полагаю, что задержка аппаратного обеспечения огромна, учитывая огромное количество обрабатываемых данных.

Есть ли решить эту проблему MapReduce помощь?

РЕДАКТИРОВАТЬ: Хорошо, я понимаю, что популярные запросы могут быть кэшированы в памяти. Но как насчет непопулярных поисков? Даже для самого малоизвестного поиска, который я проводил, я не думаю, что этот поиск длился более 5 секунд. Как это возможно?

Ну, я не уверен , если это MapReduce , что решает проблему, но это , конечно , не был бы MapReduce в одиночку решить все эти вопросы вы подняли. Но вот важные вещи , которые следует принимать во внимание, и что делает его возможным , чтобы иметь такую низкую задержку на запросы всех этих терабайт данных в разных машинах:

1. распределенный вычислительное: будучи распределено не означает, что индексы просто распределяется в разных машинах, они на самом деле реплицируются по различным группам, что позволяет для многих пользователей, выполняющих различные запросы с низкой поискового времени (да, крупные компании могут позволить себе, что многому машин);
2. Кэширование: кэши чрезвычайно сократить время выполнения, будь то на стадии ползания, для поиска страниц, или для ранжирования и exihibition результатов;
3. много настроек: все вышеперечисленные и очень эффективные алгоритмы / решения могут быть эффективными только в том случае, если реализация также эффективна. Существует множество (жестко закодированных) оптимизаций, таких как локальность ссылок, сжатие, кэширование; все они обычно применимы к различным частям обработки.

Учитывая это, давайте попробуем ответить на ваши вопросы:

но я считаю невозможным индексировать результаты каждого возможного запроса

Да, это было бы, и фактически невозможно получить результаты для каждого возможного запроса . В мире существует бесконечное количество терминов (даже если вы предполагаете, что будут введены только правильно написанные термины), и существует экспоненциальное количество запросов от этих n -> infтерминов ( 2^n). Так что сделано? Кэширование. Но если есть так много запросов / результатов, какие из них кэшировать? Политика кеширования. Наиболее частые / популярные / релевантные для пользователя запросы - это те, которые кэшируются.

не будет ли аппаратная задержка в оборудовании Google огромной? Даже если все данные в Google были сохранены в твердотельных накопителях TB / s

В наши дни, с такими высокоразвитыми процессорами, люди склонны думать, что каждая возможная задача, которая должна завершиться в течение секунды (или меньше) и которая имеет дело с таким большим количеством данных, должна обрабатываться чрезвычайно мощными процессорами с несколькими ядрами и большим объемом памяти. Однако правящий рынок - это деньги, и инвесторы не заинтересованы их тратить. Так что сделано?

На самом деле предпочтение отдается большому количеству машин, каждый из которых использует простые / доступные (с точки зрения стоимости) процессоры, что снижает стоимость создания множества кластеров. И да, это работает. Основное узкое место всегда сводится к диску, если вы рассматриваете простые измерения производительности . Но когда машин так много, можно загружать их в основную память, а не работать на жестких дисках.

Карты памяти для нас дороги , простые люди, но они очень дешевы для предприятий, которые покупают много таких карт одновременно. Поскольку это не дорого, наличие большого объема памяти, необходимого для загрузки индексов и хранения кешей, не является проблемой. А поскольку машин очень много, суперскоростные процессоры не нужны, поскольку вы можете направлять запросы в разные места и иметь кластеры машин, отвечающие за посещение определенных географических регионов , что обеспечивает более специализированное кэширование данных и даже лучший отклик раз.

Есть ли решить эту проблему MapReduce помощь?

Хотя я не думаю, что использование или нет MapReduce - ограниченная информация внутри Google, я не осведомлен об этом. Однако реализация Google MapReduce (которая, безусловно, не является Hadoop) должна иметь много оптимизаций, многие из которых включают аспекты, обсужденные выше. Таким образом, архитектура MapReduce, вероятно, помогает определять физическое распределение вычислений, но есть много других моментов, которые следует учитывать, чтобы оправдать такую ​​скорость при запросе времени.

Итак, я понимаю, что популярные запросы могут быть кэшированы в памяти. Но как насчет непопулярных поисков?

Ниже график представляет собой кривую , как виды происходят запросов. Вы можете видеть, что существует три основных вида поиска, каждый из которых содержит примерно 1/3 объема запросов (область под кривой). Сюжет показывает степенной закон и подтверждает тот факт, что меньшие запросы являются наиболее популярными. Вторая треть запросов все еще выполнима для обработки, так как они содержат мало слов. Но набор так называемых неясных запросов , которые обычно состоят из запросов неопытных пользователей, не являются ничтожной частью запросов.

И здесь есть место для новых решений. Поскольку это не просто один или два запроса (а одна треть из них), они должны иметь соответствующие результаты. Если вы введете что-то слишком неясное в поиске Google, вам не понадобится больше времени, чтобы вернуть список результатов, но, скорее всего, он покажет вам то, что он предположил, что вы хотели бы сказать. Или он может просто заявить, что не было документа с такими терминами - или даже сократить ваш поиск до 32 слов (что только что произошло со мной в случайном тесте здесь).

Существуют десятки применимых эвристик, которые могут либо игнорировать некоторые слова, либо пытаться разбить запрос на более мелкие и собрать наиболее популярные результаты. И все эти решения могут быть адаптированы и адаптированы для обеспечения допустимого времени ожидания , скажем, менее секунды? : D

MapReduce не имеет ничего общего с в реальном времени. Это пакетно-ориентированная среда обработки, подходящая для некоторых автономных задач, таких как ETL и построение индексов. Google перешел из MapReduce для большинства рабочих мест, и даже экосистема Hadoop делает то же самое.

Ответом на низкую задержку, как правило, является сохранение предварительно вычисленных индексов в памяти. Все, что касается диска, сложно сделать быстро и масштабно. Именно так движки SQL нового поколения на основе Hadoop, такие как Impala, получают такую ​​большую скорость по сравнению с инфраструктурой на основе MapReduce, например, Hive .

Инфраструктура поиска не может кэшировать результаты каждого запроса. Но он наверняка может кэшировать промежуточные результаты или более полные результаты для топовых запросов. Небольшое кэширование позволяет обслуживать результаты для значительного меньшинства всех запросов.

Поиск также распределен по серверам. Таким образом, одна машина может делегировать до 100 каждому, чтобы получить часть результата и затем объединить их.

Вы также можете уйти с некоторой степенью приближения. Google буквально не формирует тысячи страниц результатов поиска; это просто должно получить первую страницу о праве.

Имейте в виду, что Google имеет миллионы компьютеров по всему миру. Ваши запросы отправляются в центр обработки данных, расположенный рядом с вами, и это только ваша география. Это сокращает большую часть задержки, которая связана с сетью, а не с временем обработки в центре обработки данных.

MapReduce не используется в поиске. Он использовался давным-давно для построения индекса; но это основа пакетной обработки, и большинство из Интернета не меняется все время, так что новые архитектуры все инкрементные вместо партии ориентированные.

Поиск в Google будет работать в основном так же, как в Lucene и Elastic Search, за исключением большого количества точно настроенных дополнительных весов и оптимизаций. Но в самом центре, они будут использовать некоторую форму инвертированного индекса . Другими словами, они не искать несколько терабайт при вводе поискового запроса (даже если он не кэшированные). Скорее всего, они вообще не смотрят на фактические документы. Но они используют справочную таблицу, в которой указывается, какие документы соответствуют термину вашего запроса (с предварительно обработанным основанием, орфографическими ошибками, синонимами и т. Д.). Они , вероятно , извлечь список из верхних 10000 документов для каждого слова (10k целых чисел - всего несколько килобайта) и вычислить лучшие матчи из этого. Только если в этих списках нет подходящих совпадений, они расширяются до следующих таких блоков и т. Д.

Запросы для общих слов могут быть легко кэшированы; и с помощью предварительной обработки вы можете составить список лучших 10 тыс. результатов, а затем выполнить их повторный анализ в соответствии с профилем пользователя. Вычислять «точный» ответ тоже нечего. Глядя на верхней 10k результатов, скорее всего, достаточно; нет правильного ответа; и если будет пропущен лучший результат где-нибудь в позиции 10001, никто не будет знать или замечать (или заботиться). Скорее всего, он уже был ранжирован при предварительной обработке и не попал бы в топ-10, который представлен пользователю в конце (или в топ-3, на который фактически смотрит пользователь)

С другой стороны, редкие условия также не являются проблемой - один из списков содержит только несколько подходящих документов, и вы можете немедленно отказаться от всех остальных.

Я рекомендую прочитать эту статью:

Анатомия Крупномасштабного Гипертекстового Web Search Engine
Сергей Брин и Лоуренс Page
департамента компьютерных наук Стэнфордского университета, Стэнфорд, Калифорния 94305
http://infolab.stanford.edu/~backrub/google.html

И да, это основатели Google, которые написали это. Это не последнее состояние, но оно уже будет работать в довольно больших масштабах.