Google nasıl bu kadar hızlı olabilir?


89

Google'ın bir sorguya bu kadar hızlı hizmet vermesini sağlayan teknolojiler ve programlama kararları nelerdir?

Bir şeyi her aradığımda (günde birkaç kez), sonuçları 1 saniyeye yakın veya daha kısa sürede nasıl sundukları beni her zaman şaşırtıyor. Bunu gerçekleştirecek ne tür yapılandırma ve algoritmalara sahip olabilirler?

Yan not: Bir masaüstü uygulaması koyup makinemde kullansam bile muhtemelen Google'ın yarısı kadar hızlı olmayacağını düşünüyorum. Öğrenmeye devam et diyorum.


İşte sağlanan harika cevaplardan ve önerilerden bazıları:

Yanıtlar:


47

Gecikme, disk erişimleri tarafından öldürülür. Bu nedenle, sorguları yanıtlamak için kullanılan tüm verilerin bellekte tutulduğuna inanmak mantıklıdır. Bu, her biri birçok parçadan birini çoğaltan binlerce sunucu anlamına gelir. Bu nedenle, arama için kritik yolun, amiral gemisi dağıtılmış sistem teknolojileri GFS, MapReduce veya BigTable'dan herhangi birine denk gelmesi olası değildir. Bunlar, kabaca tarayıcı sonuçlarını işlemek için kullanılacaktır.

Aramayla ilgili kullanışlı olan şey, son derece tutarlı sonuçlara veya tamamen güncel verilere sahip olmanıza gerek olmamasıdır, bu nedenle Google'ın bir sorguya yanıt vermesinin engellenmemesi, çünkü daha güncel bir arama sonucu kullanılabilir hale gelmiştir.

Dolayısıyla, olası bir mimari oldukça basittir: ön uç sunucular sorguyu işler, normalleştirerek (muhtemelen durdurma sözcüklerini çıkararak vb.) Sonra onu sorgu alanının o kısmına sahip olan kopya alt kümelerine dağıtır (alternatif bir mimari web sayfalarına göre veriler, böylece her sorgu için her replika kümesinden biriyle iletişime geçilmesi gerekir) Pek çok kopya muhtemelen sorgulanır ve en hızlı yanıtlar kazanır. Her eşlemenin, bellekteki sonuçları çok hızlı bir şekilde aramak için kullanabilecekleri belgelere yönelik bir dizin eşleme sorguları (veya bireysel sorgu terimleri) vardır. Farklı kaynaklardan farklı sonuçlar gelirse, ön uç sunucusu bunları html'yi çıkarırken sıralayabilir.

Bunun muhtemelen Google'ın gerçekte yaptıklarından çok farklı olduğunu unutmayın - bu sistemin ömrünü bu sistemden çıkarmış olacaklar, bu nedenle diğer olası farkların yanı sıra garip alanlarda daha fazla önbellek, garip dizinler ve bir tür garip yük dengeleme şeması olabilir. .



22

Dışarıda bulduğum bir gerçek, Google'ın aslında biyoinformatik tarafından yönetiliyor olmasıdır ('kay, bunu komik buluyorum çünkü ben bir biyoinf… şeyim). Açıklamama izin ver.

Biyoinformatik, erken dönemlerde devasa dizilerdeki küçük metinleri çok hızlı arama konusunda zorluk yaşadı. Bizim için “devasa ip” elbette DNA'dır. Genellikle tek bir DNA değil, farklı türlerden / bireylerden birkaç DNA'nın veri tabanı. Küçük metinler proteinler veya bunların genetik karşılığı olan bir gendir. Hesaplamalı biyologların ilk çalışmalarının çoğu, genler arasındaki homolojileri bulmakla sınırlıydı. Bu, yeni bulunan genlerin işlevini, halihazırda bilinen genlerle benzerliklere dikkat çekerek oluşturmak için yapılır.

Şimdi, bu DNA dizileri gerçekten çok büyüyor ve (kayıplı!) Aramanın son derece verimli bir şekilde yapılması gerekiyor. Modern sicim arama teorisinin çoğu bu nedenle hesaplamalı biyoloji bağlamında geliştirildi.

Ancak, oldukça uzun bir süre önce, geleneksel metin araması tükenmişti. Alt doğrusal zamanda, yani her bir karaktere bakmadan büyük dizeleri aramaya izin veren yeni bir yaklaşıma ihtiyaç vardı. Bunun, büyük dizgiyi önceden işleyerek ve üzerinde özel bir dizin veri yapısı oluşturarak çözülebileceği keşfedildi. Bu tür birçok farklı veri yapısı önerilmiştir. Her birinin kendi güçlü ve zayıf yönleri vardır, ancak özellikle dikkat çekici olanı vardır çünkü sabit zamanda bir aramaya izin verir. Şimdi, Google'ın faaliyet gösterdiği büyüklük sırasına göre bu artık kesinlikle doğru değil çünkü sunucular arasında yük dengeleme, ön işleme ve diğer bazı karmaşık şeyler hesaba katılmalıdır.

Ancak özünde, sözde q-gram indeksi , sabit zamanda bir aramaya izin verir. Tek dezavantaj: Veri yapısı gülünç derecede büyüyor. Esasen, q karaktere kadar (dolayısıyla adı) dizelerin aranmasına izin vermek için , q harflerinin olası her kombinasyonu için bir alan içeren bir tablo gerektirir (yani, q S , burada S alfabenin boyutudur , 36 (= 26 + 10)) diyelim. Ek olarak, dizine eklenen dizedeki her harf konumu için (veya google söz konusu olduğunda, her web sitesi için) bir alan olmalıdır.

Sırf boyutunu azaltmak için, Google muhtemelen birden indeksleri kullanacaktır (aslında, onlar yapmak , yazım düzeltme teklif hizmetlerine). En üstte olanlar karakter düzeyinde değil, bunun yerine kelime düzeyinde çalışır. Bu, q'yu azaltır, ancak S'yi sonsuz derecede büyütür, bu nedenle sonsuz sayıda farklı sözcükle başa çıkmak için karma ve çarpışma tabloları kullanmak zorunda kalacaklar.

Bir sonraki aşamada, bu karma kelimeler diğer dizin veri yapılarına işaret edecek ve bu da web sitelerine işaret eden karakterleri karma hale getirecektir.

Uzun lafın kısası, bu q -gram indeksi veri yapıları, Google'ın arama algoritmasının tartışmasız en merkezi kısmıdır. Ne yazık ki, q -gram indekslerinin nasıl çalıştığını açıklayan teknik olmayan iyi belgeler yok . Böyle bir dizinin nasıl çalıştığına dair bir açıklama içeren bildiğim tek yayın… ne yazık ki, benim lisans tezim .


4
5 yıldır biyoinformatikteydim ve ondan sonra arama motorları - ve q-gramlar sandığınız kadar önemli değil. Google'ın yaptığı arama türü için temel veri yapısı (çok, çok temel düzeyde) tersine çevrilmiş dizindir.
SquareCog

Bu yanlış görünüyor. Google ters çevrilmiş bir dizinde çalışıyor veya çalışıyordu. q-gram ifadeler için yararlı olacak ama genel olarak değil
Stefan Savev

@Stefan: Aynı yorum zaten SquareCog tarafından yapılmıştı - ve ters çevrilmiş indekslerin büyük (ve muhtemelen n-gram indekslerden çok daha büyük) bir rol oynadığını inkar etmiyorum. Bu tek teknolojiyi seçtim çünkü n-gramlar benim evcil hayvan veri yapım ve bence temel bilgi - Google hızlı çünkü aslında "arama" yapmak zorunda değil, aşağı yukarı doğrudan arama yapabilir - böyle bir indekse bağlıdır (nb: bu muhtemelen hashing yoluyla yapılır, ancak bu hala bir n-gram indeksidir). Bu endeksin de tersine çevrilmesi benim açımdan önemli değil (muhtemelen Google için değil ;-)).
Konrad Rudolph


4

Çok sayıda donanım üzerinde çalışan iyi, dağıtılmış algoritmalar uyguladılar.


4

En önemli gecikmelerden biri, web sunucularının sorgunuzu web sunucusuna alması ve yanıtı geri getirmesidir. Bu gecikme, Google'ın bile uymak zorunda olduğu ışık hızına bağlıdır. Ancak, tüm dünyada veri merkezleri var. Sonuç olarak, bunlardan herhangi birine olan ortalama mesafe daha düşüktür. Bu gecikmeyi azaltır. Elbette, fark milisaniye cinsinden ölçülür, ancak yanıtın 1000 milisaniye içinde gelmesi gerekiyorsa bu önemlidir.



3

Neredeyse binlerce kişisel bilgisayarda özel dosya sistemlerinde önbelleğe alınmış yerel bir internet kopyası var.


Disk tabanlı bir dosya sistemine vurmak gecikme açısından çok maliyetli olacaktır (Amazon bunu Dynamo ile buldu ve bunun için bir miktar esneklikten ödün verdi); Kritik yoldaki her şeyin hafızada tutulduğundan şüpheleniyorum.
HenryR

3

Google, en iyinin en iyisini işe alır. BT'deki en zeki kişilerden bazıları Google'da çalışıyor. Donanıma ve mühendislere atacakları neredeyse sonsuz paraları var.

Gerçekleştirdikleri görevler için yüksek düzeyde optimize edilmiş depolama mekanizmaları kullanırlar.

Coğrafi olarak konumlandırılmış sunucu çiftlikleri var.


3

Genelleştirilmiş bir liste denemesi (bu, Google'ın dahili araçlarına erişiminizin olmasına bağlı değildir):

  1. İstekleri paralelleştirme (ör. Tek bir isteği daha küçük kümelere bölme)
  2. Zaman uyumsuz (mümkün olduğu kadar asynchronious olarak yapmak, örneğin kullanıcının isteğini engellemez)
  3. Bellek / önbellek (Disk G / Ç yavaş, bellekte olabildiğince saklayın)
  4. Ön hesaplama ( Önceden mümkün olduğunca çok iş yapın, kullanıcının veri / işlem istemesini beklemeyin)
  5. Senin hakkında Bakım ön uç HTML (yYAVAŞ ve arkadaşları görmek)



1

Donanım.

Çok ve çok donanım. Sunucu çiftlikleri olarak devasa ticari bilgisayar kümeleri kullanıyorlar.


Sadece 'kitlesel'i açıklamak için: yüz binlerce sunucu. Sanırım Google dışında hiç kimse gerçek sayıyı bilmiyor ve sürekli değişiyor olmalı.
Sergio Acosta

1

TraumaPony haklı. Yük dengeleme / önbelleğe alma için tonlarca sunucu ve akıllı mimari ve işte sorguları 1 saniyenin altında çalıştırabilirsiniz. İnternette google servis mimarisini anlatan çok sayıda makale vardı. Eminim onları Google'da bulabilirsin :)




0

Ve bu donanım gücünden yararlanabilen algoritmalar . Örneğin mapreduce gibi.


MapReduce sorgulara yanıt vermek için kullanılmaz.
MSalters

MapReduce büyük bir makine kümesi üzerinde çalışır ve oldukça ölçeklenebilirdir: tipik bir MapReduce hesaplaması, binlerce makinede çok sayıda terabaytlık veriyi işler. Yüzlerce MapReduce programı uygulandı ve Google'ın kümelerinde her gün binden fazla MapReduce işi yürütüldü
Vinko Vrsalovic

MapReduce, neredeyse kesinlikle tarayıcı verilerini eşzamansız olarak dizine eklemek için kullanılır. Arama için kritik yol üzerinde olsaydı çok şaşırırdım. Bir MapReduce işini tetiklemek gecikmeyi gerçekten öldürecektir.
HenryR

Henry - yönlerde / haritalarda yönlendirme yapmak için kullanıyor olabilirler. Ama evet, genel durum için. Normal bir kullanıcı sorgusuna yanıt vermek için herhangi bir ekstrem hesaplama olmasını istemezsiniz.
SquareCog

0

Google kümesinin nasıl çalıştığı hakkında daha fazla ayrıntıyla ilgileniyorsanız, HDFS'lerinin bu açık kaynaklı uygulamasını önereceğim .

Google tarafından geliştirilen Mapreduce'a dayanmaktadır .


HDFS, dağıtılmış bir dosya sistemidir. Mapreduce klonu Hadoop olarak adlandırılır ve HDFS veya yerel dosya sisteminizde çalışabilir.
SquareCog

0
  1. Çok aşamalı veri depolama, işleme ve alma

  2. Yukarıdaki görevlerin VERİMLİ Dağıtımı (100'lerce 1000 makine)

  3. Ham verileri ve işlenen sonuçları depolamak için iyi bir çerçeve

  4. Sonuçları almak için iyi bir çerçeve

Tüm bunların tam olarak nasıl yapıldığı, soru özetinde sahip olduğunuz tüm bağlantılarla özetlenmektedir.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.