Google이 쿼리를 빠르게 처리 할 수있게하는 기술 및 프로그래밍 결정은 무엇입니까?
내가 무언가를 검색 할 때마다 (하루에 여러 번 중 하나) 1 초에 가깝거나 짧은 시간 내에 결과를 제공하는 방식은 항상 나를 놀라게합니다. 이를 수행하기 위해 어떤 종류의 구성 및 알고리즘을 사용할 수 있습니까?
참고 : 데스크톱 응용 프로그램을 설치하여 내 컴퓨터에서 사용하더라도 Google만큼 빠르지 않을 것이라고 생각하는 것은 다소 압도적입니다. 내가 말하는 것을 계속 배우십시오.
다음은 몇 가지 훌륭한 답변과 조언입니다.
답변:
지연 시간은 디스크 액세스로 인해 중단됩니다. 따라서 쿼리에 응답하는 데 사용되는 모든 데이터가 메모리에 보관된다고 믿는 것이 합리적입니다. 이는 수천 대의 서버를 의미하며 각 서버는 여러 샤드 중 하나를 복제합니다. 따라서 검색의 핵심 경로는 자사의 주력 분산 시스템 기술인 GFS, MapReduce 또는 BigTable에 도달하지 않을 것입니다. 크롤러 결과를 대략적으로 처리하는 데 사용됩니다.
검색의 편리한 점은 강력하게 일관된 결과 나 완전히 최신 데이터를 가질 필요가 없기 때문에 더 최신 검색 결과를 사용할 수있게 되었기 때문에 Google이 쿼리에 응답 할 수 없다는 것입니다.
따라서 가능한 아키텍처는 매우 간단합니다. 프런트 엔드 서버가 쿼리를 처리하고이를 정규화 (불용어 등을 제거하여 가능) 한 다음 쿼리 공간의 해당 부분을 소유하는 복제본의 하위 집합에 배포합니다 (대체 아키텍처는 모든 복제 세트 중 하나가 모든 쿼리에 연결되어야 함). 많은 복제본이 쿼리되고 가장 빠른 응답이 이깁니다. 각 복제본에는 메모리에서 결과를 매우 빠르게 조회하는 데 사용할 수있는 문서에 대한 인덱스 매핑 쿼리 (또는 개별 쿼리 용어)가 있습니다. 다른 소스에서 다른 결과가 반환되는 경우 프런트 엔드 서버는 html을 뱉어 내면서 순위를 매길 수 있습니다.
이것은 아마도 구글이 실제로하는 것과는 먼 차이가있을 것입니다. 그들은 다른 가능한 차이점들 사이에서 이상한 영역, 이상한 색인 및 일종의 펑키 한 부하 분산 체계에 더 많은 캐시가있을 수 있도록이 시스템의 수명을 설계했을 것입니다. .
하나의 답변에 담기에는 너무 많습니다. http://en.wikipedia.org/wiki/Google_platform
내가 웃긴 사실을 발견 한 한 가지 사실은 Google이 실제로 생물 정보학에 의해 운영된다는 것입니다 ( '좋아요, 내가 생물 인 자라서 재미 있다고 생각합니다. 설명하겠습니다.
생물 정보학은 초기에 거대한 문자열의 작은 텍스트를 매우 빠르게 검색하는 데 어려움을 겪었습니다. 우리에게“거대한 끈”은 당연히 DNA입니다. 종종 단일 DNA가 아니라 다른 종 / 개체의 여러 DNA 데이터베이스입니다. 작은 텍스트는 단백질이거나 그에 상응하는 유전자 인 유전자입니다. 컴퓨터 생물학 자의 첫 번째 작업의 대부분은 유전자 간의 상 동성을 찾는 것으로 제한되었습니다. 이것은 이미 알려진 유전자와의 유사점을 주목하여 새로 발견 된 유전자의 기능을 확립하기 위해 수행됩니다.
이제 이러한 DNA 문자열은 실제로 매우 커지고 (손실이 있습니다!) 검색을 매우 효율적으로 수행해야합니다. 따라서 현대의 문자열 조회 이론의 대부분은 컴퓨터 생물학의 맥락에서 개발되었습니다.
그러나 꽤 오래 전부터 기존의 텍스트 검색이 소진되었습니다. 즉, 각각의 단일 문자를 보지 않고도 부 선형 시간에 큰 문자열을 검색 할 수있는 새로운 접근 방식이 필요했습니다. 이것은 큰 문자열을 사전 처리하고 그 위에 특별한 인덱스 데이터 구조를 구축함으로써 해결할 수 있음을 발견했습니다. 많은 다른 데이터 구조가 제안되었습니다. 각각 장단점이 있지만 일정한 시간에 조회가 가능하기 때문에 특히 주목할만한 것이 있습니다. 이제 Google이 운영하는 규모에 따라 서버 간의 부하 분산, 전처리 및 기타 정교한 작업을 고려해야하기 때문에 더 이상 엄격하게 사실이 아닙니다.
그러나 본질적으로 소위 q-gram 인덱스 는 일정한 시간에 조회를 허용합니다. 유일한 단점은 데이터 구조가 엄청나게 커진다는 것입니다. 기본적으로 최대 q 자 (따라서 이름) 의 문자열 조회를 허용 하려면 가능한 q 문자 조합 (즉, q S , 여기서 S 는 알파벳 크기)에 대해 하나의 필드가있는 테이블이 필요합니다. , 36 (= 26 + 10)). 또한 인덱싱 된 문자열의 각 문자 위치에 대해 하나의 필드가 있어야합니다 (또는 Google의 경우 각 웹 사이트에 대해).
깎아 지른듯한 크기를 완화하기 위해, 구글은 아마 여러 인덱스를 사용합니다 (사실, 그들이 어떻게 , 맞춤법 교정 등의 제공 서비스). 맨 위에있는 것은 문자 수준에서 작동하지 않고 대신 단어 수준에서 작동합니다. 이것은 q를 줄이지 만 S를 무한히 커지게하여 무한한 수의 다른 단어에 대처하기 위해 해싱 및 충돌 테이블을 사용해야합니다.
다음 수준에서 이러한 해시 된 단어는 다른 인덱스 데이터 구조를 가리키고 차례로 웹 사이트를 가리키는 문자를 해시합니다.
간단히 말해서, 이러한 q- gram 인덱스 데이터 구조는 틀림없이 Google 검색 알고리즘의 가장 핵심적인 부분입니다. 불행히도, q -gram 인덱스의 작동 방식을 설명하는 비 기술적 인 논문은 없습니다 . 그러한 색인이 어떻게 작동하는지에 대한 설명을 포함하는 내가 아는 유일한 출판물은… 아아, 나의 학사 논문 입니다.
다음은 몇 가지 훌륭한 답변과 조언입니다.
그들은 방대한 양의 하드웨어에서 실행되는 좋은 분산 알고리즘을 구현했습니다.
Google 연구 홈페이지 에서 Google 직원 중 일부가 작성한 연구 논문에 대한 몇 가지 지침을 찾을 수 있습니다 . Google 파일 시스템 과 map / reduce 알고리즘 에 대한 설명으로 시작 하여 Google 페이지 뒤에서 무슨 일이 일어나고 있는지 이해하려고 노력해야합니다.
이 링크는 또한 매우 유익한 Google 쿼리의이면에서
하드웨어.
많은 하드웨어. 그들은 서버 팜으로 대량의 상용 PC 클러스터를 사용합니다.
HenryR이 정확할 것입니다.
Map Reduce는 검색 자체에 대한 역할을 수행하지 않고 인덱싱에만 사용됩니다. Map Reduce 발명가와의 인터뷰 비디오를 확인하십시오 .
추가적인 이유는 그들이 TCP 느린 시작 알고리즘을 속이기 때문인 것 같습니다.
http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html