큰 데이터베이스에 대한 쿼리는 무시할 수있는 대기 시간으로 어떻게 반환됩니까?


12

예를 들어 Google에서 무언가를 검색하면 결과가 거의 즉시 반환됩니다.

Google은 알고리즘 등을 사용하여 페이지를 정렬하고 색인을 생성하지만 가능한 모든 단일 쿼리의 결과를 색인화하는 것은 불가능하다고 생각합니다 (결과는 개인화되어 더 불가능합니다).

또한 Google 하드웨어의 하드웨어 대기 시간이 크지 않습니까? Google의 데이터가 모두 TB / s SSD에 저장되어 있어도 처리해야 할 데이터의 양이 많기 때문에 하드웨어 대기 시간이 엄청납니다.

MapReduce가이 문제를 해결하는 데 도움이됩니까?

편집 : 좋아, 그래서 인기있는 검색을 메모리에 캐시 할 수 있음을 이해합니다. 그러나 인기없는 검색은 어떻습니까? 내가 수행 한 가장 모호한 검색에도 불구하고 검색이 5 초 이상으로보고 된 적이 없다고 생각합니다. 이것이 어떻게 가능한지?

답변:


13

글쎄, 문제를 해결하는 것이 MapReduce인지 확실하지 않지만 제기 한 모든 질문을 해결하기 위해 MapReduce만으로는 아닙니다. 그러나 여기에서 고려해야 할 중요한 일이 있고, 그것을 만드는 것이 가능한 다른 컴퓨터에있는 데이터의 이러한 TB의 모든에서 쿼리에 낮은 지연 시간을 가지고 :

  1. 분산 컴퓨팅 : 분산되었다고해서 인덱스가 단순히 다른 머신에 분산되어 있다는 것을 의미하는 것은 아니며, 실제로는 서로 다른 클러스터를 따라 복제되므로 많은 사용자가 낮은 검색 시간으로 다른 쿼리를 수행 할 수 있습니다. 기계);
  2. 캐싱 : 캐시는 크롤링 단계, 페이지 검색 또는 결과 순위 및 표시를 위해 실행 시간을 엄청나게 단축합니다.
  3. 많은 조정 : 위의 모든 매우 효율적인 알고리즘 / 솔루션은 구현이 효율적인 경우에만 효과적 일 수 있습니다. 참조, 압축, 캐싱의 지역 성과 같은 수많은 (하드 코딩 된) 최적화가 있습니다. 이들 모두는 일반적으로 처리의 다른 부분에 적용 할 수 있습니다.

이를 고려하여 질문을 해결하십시오.

하지만 가능한 모든 단일 쿼리의 결과를 색인화하는 것이 불가능하다고 생각합니다.

그렇습니다. 실제로 가능한 모든 단일 쿼리에 대해 결과를 얻는 것은 불가능 합니다 . 세계에는 무한한 수의 용어가 있으며 (올바른 철자 만 입력한다고 가정하더라도)이 n -> inf용어에 대한 지수 쿼리 수가 있습니다 ( 2^n). 그래서 무엇을해야합니까? 캐싱. 그러나 쿼리 / 결과가 너무 많은 경우 캐시 할 쿼리 / 결과는 무엇입니까? 캐싱 정책. 가장 빈번한 / 인기있는 / 사용자와 관련된 쿼리는 캐시 된 것입니다.

Google 하드웨어의 하드웨어 대기 시간이 크지 않습니까? Google의 데이터가 모두 TB / s SSD에 저장된 경우에도

오늘날 고도로 발전된 프로세서를 사용하는 사람들은 1 초 이내에 완료해야하고 많은 양의 데이터를 처리하는 모든 가능한 작업을 여러 개의 코어와 많은 메모리를 가진 매우 강력한 프로세서로 처리해야한다고 생각하는 경향이 있습니다. 그러나 시장을 지배 하는 한 가지는 돈이며, 투자자들은 돈 낭비에 관심이 없습니다. 그래서 무엇을해야합니까?

실제로는 단순 / 액세스 가능한 (비용면에서) 프로세서를 사용하는 많은 머신을 선호하는 경우가 많으며, 이로 인해 다수의 클러스터를 구축하는 가격이 낮아집니다. 그리고 그렇습니다. 간단한 성능 측정을 고려하면 기본 병목 현상은 항상 디스크로 귀결됩니다 . 그러나 시스템이 너무 많으면 하드 디스크에서 작업하는 대신 주 메모리에 작업을로드 할 수 있습니다.

메모리 카드는 비싼 우리, 단순한 인간 존재에 대한,하지만 그들은 한 번에 같은 카드를 많이 구매 기업을위한 매우 저렴합니다. 비용이 많이 들지 않기 때문에 인덱스를로드하고 캐시를 유지하는 데 필요한 메모리가 많은 것은 문제가되지 않습니다. 또한 컴퓨터가 너무 많기 때문에 쿼리를 다른 장소로 보낼 수 있고 특정 지역 에 참석하는 컴퓨터 클러스터를 가질 수 있으므로 초고속 프로세서가 필요하지 않으므로 보다 전문적인 데이터 캐싱 및 더 나은 응답이 가능합니다. 타임스.

MapReduce가이 문제를 해결하는 데 도움이됩니까?

MapReduce를 사용하거나 사용하지 않는 것이 Google 내부의 제한된 정보라고 생각하지는 않지만이 시점에 대해서는 잘 모릅니다. 그러나 Google의 MapReduce 구현 (확실히 Hadoop 은 아님 )에는 위에서 설명한 측면과 관련된 많은 최적화가 필요합니다. 따라서 MapReduce의 아키텍처는 계산이 실제로 분산되는 방법을 안내하는 데 도움이되지만 쿼리 시간에서 이러한 속도를 정당화하기 위해 고려해야 할 다른 사항이 많이 있습니다.

좋아, 나는 인기있는 검색이 메모리에 캐시 될 수 있음을 이해합니다. 그러나 인기없는 검색은 어떻습니까?

아래 그래프 는 쿼리 종류 가 어떻게 발생 하는지를 보여줍니다 . 세 가지 주요 검색 유형이 있으며 각 검색 량의 약 1/3을 조회합니다 (곡선 아래 영역). 이 그림은 권력 법을 보여 주며, 작은 쿼리가 가장 많이 사용된다는 사실을 강화합니다. 쿼리의 두 번째 1/3은 단어가 적기 때문에 여전히 처리가 가능합니다. 그러나 일반적으로 경험이없는 사용자의 쿼리로 구성된 소위 모호한 쿼리 집합은 무시할 수있는 부분이 아닙니다.

두꺼운 꼬리 분포

그리고 새로운 솔루션을위한 공간이 있습니다. 하나 또는 두 개의 쿼리가 아니라 3 분의 1의 쿼리이므로 관련 결과 가 있어야합니다 . 당신이 뭔가에 입력하면 너무 모호 Google 검색, 그것은 결과의 목록을 반환하는 데 시간이 더 걸릴 수 없으나, 대부분의 아마 당신에게 뭔가 보여줄 것이다 추론 말하고자합니다. 또는 단순히 그러한 용어가 포함 된 문서가 없다고 말하거나 32 단어로 검색을 줄입니다 (여기서 무작위 테스트에서 나에게 발생했습니다).

수십 가지의 적용 가능한 휴리스틱이 있습니다. 일부 휴리스틱은 일부 단어를 무시하거나 쿼리를 작은 단어로 나누고 가장 인기있는 결과를 수집하려고 할 수 있습니다. 그리고 이러한 모든 솔루션은 실행 가능한 대기 시간 ( 예 : 1 초 미만) 을 고려하여 조정하고 조정할 수 있습니다 . :디


다른 쿼리를 추가하기 위해 질문을 편집했습니다.
resgh

@name 여기서 편집 내용을 해결하려고했습니다. 질문에 대답하는 데 도움이되기를 바랍니다.
Rubens

10

MapReduce는 실시간과 관련이 없습니다. ETL 및 인덱스 작성과 같은 일부 오프라인 작업에 적합한 배치 지향 처리 프레임 워크입니다. Google은 현재 대부분의 작업에서 MapReduce를 중단했으며 하둡 에코 시스템도 마찬가지입니다.

낮은 대기 시간에 대한 답변은 일반적으로 미리 계산 된 인덱스를 메모리에 유지하는 것입니다. 디스크에 닿는 것은 빠르게 확장하기가 어렵습니다. 예를 들어 Impala 와 같은 차세대 Hadoop 기반 SQL 엔진이 Hive 와 같은 MapReduce 기반 인프라에 비해 훨씬 빠른 속도를 얻는 방법 입니다.

검색 인프라는 모든 단일 쿼리의 결과를 캐시 할 수 없습니다. 그러나 중간 결과 또는 상위 쿼리에 대한보다 완전한 결과를 캐시 할 수 있습니다. 약간의 캐싱으로 모든 쿼리의 소수에 대해 결과를 제공 할 수 있습니다.

검색도 여러 서버로 분할됩니다. 따라서 한 대의 컴퓨터가 결과의 일부를 얻은 다음 각 기계에 100을 위임 할 수 있습니다.

어느 정도의 근사치로 벗어날 수도 있습니다. Google은 문자 그대로 수천 페이지의 검색 결과를 형성하지 않습니다. 첫 페이지 만 가져와야합니다.

Google에는 전 세계에 수백만 대의 컴퓨터가 있습니다. 귀하의 문의는 지리적으로 가까운 데이터 센터로 이동하고 있으며 귀하의 지역에만 제공됩니다. 이는 데이터 센터에서 처리 시간이 아닌 네트워크 인 대부분의 대기 시간을 차단합니다.


먼저 다른 쿼리를 추가하기 위해 질문을 편집했습니다. 또한 : 사전에 계산 된 소수가 많더라도 나머지 쿼리를 완료하는 데 여전히 오랜 시간이 걸릴 것이라고 생각합니다. 또한 프로세스가 한 시스템에서 100 대의 시스템으로 위임 될 때 지연 시간이 실제로 증가하지 않습니까 (시스템 간 네트워크 지연 시간 및 총 지연 시간은 모든 시스템의 지연 시간의 최대 값입니까)?
resgh

이상한 희귀 한 쿼리 인 "스파게티 다이아몬드"쿼리에 응답하면 "스파게티"와 "다이아몬드"에 대한 사전 계산 결과가 개별적으로 표시 될 수 있습니다. DC 내부 연결은 매우 빠르고 대기 시간이 짧습니다. 여분의 홉 또는 2 개의 내부는 컴퓨터와 DC 사이의 ~ 20 홉과 비교할 수 없습니다. 일을 분배하는 데있어 지배적 인 문제는 쇠약 거리는 문제이다. 일부 응답이 제 시간에 응답하지 않으면 일부 하위 집합에서 결과를 삭제해야합니다. 이것들은 모두 총체적인 일반화이지만 올바른 방향을 가리 킵니다.
Sean Owen

4

검색에는 MapReduce가 사용되지 않습니다. 오래 전에 색인을 작성하는 데 사용되었습니다. 그러나 일괄 처리 프레임 워크이며 대부분의 웹은 항상 변경되지 않으므로 최신 아키텍처는 일괄 처리가 아니라 점진적으로 증가 합니다.

Google에서 검색하면 미세 조정 된 추가 가중치 및 최적화를 제외하고 Lucene 및 Elastic Search에서 작동하는 것과 거의 동일하게 작동합니다. 그러나 가장 중요한 것은 어떤 형태의 거꾸로 된 인덱스를 사용한다는 것 입니다. 즉, 검색 쿼리를 입력 할 때 (캐시되지 않은 경우에도) 몇 테라 바이트를 검색 하지 않습니다 . 그들은 실제 문서를 전혀 보지 않을 것입니다. 그러나 쿼리 용어와 일치하는 문서 (줄기, 맞춤법이 틀린 단어, 동의어 등이 모두 사전 처리됨)를 나열하는 조회 테이블을 사용합니다. 아마도 각 단어 (10k 정수-단지 몇 kb!)에 대한 상위 10000 개의 문서 목록 을 검색하고 그로부터 가장 일치하는 것을 계산합니다. 이 목록에 일치하지 않는 경우에만 다음 블록으로 확장됩니다.

일반적인 단어에 대한 쿼리를 쉽게 캐시 할 수 있습니다. 전처리를 통해 상위 10k 개의 결과 목록을 작성한 다음 사용자 프로필에 따라 순위를 다시 지정할 수 있습니다. "정확한"답변을 계산해도 얻을 수있는 것은 없습니다. 상위 10k 결과를 보는 것으로 충분합니다. 정답이 없습니다. 10001 위치 어딘가에 더 나은 결과를 놓치면 아무도 알지 못하거나 알아 차릴 수 없습니다. 이미 전처리 과정에서 순위가 ​​내려졌고 마지막에 사용자에게 표시되는 상위 10 개 (또는 사용자가 실제로 보는 상위 3 개)로 설정되지 않았을 수 있습니다.

반면에 희귀 한 용어도 큰 문제가되지 않습니다. 목록 중 하나에는 일치하는 문서가 몇 개만 포함되어 있으므로 다른 모든 단어는 즉시 버릴 수 있습니다.

이 기사를 읽는 것이 좋습니다.

대규모 하이퍼 텍스트 웹 검색 엔진의 해부학
세르게이 브린 (Sergey Brin)과 로렌스 페이지
컴퓨터 과학학과, 스탠포드 대학, 스탠포드, CA 94305
http://infolab.stanford.edu/~backrub/google.html

그렇습니다. 이것이 바로 구글 창립자입니다. 최신 상태는 아니지만 이미 꽤 큰 규모로 작동합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.