Büyük bir veritabanına yapılan sorgu ihmal edilebilir gecikme ile nasıl geri döner?


12

Örneğin, Google'da bir şey ararken sonuçlar hemen anında geri döner.

Google'ın sayfaları algoritmalar vb. İle sıraladığını ve dizine eklediğini anlıyorum, ancak dizine eklenebilecek olası tüm sorguların sonuçlarının (ve sonuçların kişiselleştirildiğini ve bunun daha da olanaksız kıldığını) hayal ediyorum?

Ayrıca, Google'ın donanımındaki donanım gecikmesi çok fazla olmaz mı? Google'daki verilerin tümü TB / sn SSD'lerde depolansa bile, işlenecek çok miktarda veri göz önüne alındığında donanım gecikmesinin çok büyük olduğunu düşünüyorum.

MapReduce bu sorunun çözülmesine yardımcı oluyor mu?

EDIT: Tamam, bu yüzden popüler aramaların bellekte önbelleğe alınabileceğini anlıyorum. Peki popüler olmayan aramalar ne olacak? Yaptığım en belirsiz arama için bile, aramanın 5 saniyeden daha uzun olduğu bildirilmedi. Bu nasıl mümkün olabilir?

Yanıtlar:


13

Sorunu çözenin MapReduce olup olmadığından emin değilim, ancak ortaya koyduğunuz tüm bu soruları çözmek için kesinlikle MapReduce olmaz. Ancak burada dikkate alınması gereken önemli şeyler vardır ve bu , farklı makinelerde tüm bu TB'lerden gelen sorgular üzerinde bu kadar düşük gecikme süresinin olmasını mümkün kılar :

  1. dağıtılmış bilgi işlem: dağıtılması, endekslerin farklı makinelerde basitçe dağıtıldığı anlamına gelmez, aslında farklı kümeler boyunca çoğaltılır, bu da birçok kullanıcının düşük alma süresiyle farklı sorgular gerçekleştirmesine izin verir (evet, büyük şirketler bu kadarını karşılayabilir makinelerin);
  2. önbellekleme: önbellekler, tarama adımında, sayfaların alınmasında veya sonuçların sıralanması ve sergilenmesinde, yürütme süresini büyük ölçüde azaltır;
  3. çok sayıda ince ayar: yukarıdaki ve çok etkili algoritmaların / çözümlerin tümü, yalnızca uygulama da verimli olduğunda etkili olabilir. Referans yeri, sıkıştırma, önbellekleme gibi tonlarca (sabit kodlanmış) optimizasyon vardır; hepsi genellikle işlemenin farklı bölümlerine uygulanabilir.

Bunu göz önünde bulundurarak, sorularınızı ele almaya çalışalım:

ancak her olası sorgunun dizine eklenmesinin mümkün olmadığını hayal ediyorum

Evet, olası her bir sorgu için sonuç elde etmek mümkün olabilir ve aslında mümkün değildir . Dünyada sınırsız sayıda terim vardır (yalnızca doğru şekilde yazılan terimlerin girileceğini varsaysanız bile) ve bu n -> infterimlerden üssel sayıda sorgu vardır ( 2^n). Peki ne yapılır? Önbelleğe almak. Ama çok fazla sorgu / sonuç varsa, hangilerini önbellekleyecek? Önbellek politikaları. En sık / popüler / kullanıcıyla alakalı sorgular önbelleğe alınmış sorgulardır.

Google'ın donanımındaki donanım gecikmesi çok büyük olmaz mı? Google'daki verilerin tümü TB / sn SSD'lerde depolansa bile

Günümüzde, bu kadar gelişmiş işlemcilerle, insanlar bir saniye (veya daha az) içinde bitmesi gereken ve çok fazla veriyle ilgilenen her olası görevin, çok çekirdekli ve çok fazla belleğe sahip son derece güçlü işlemciler tarafından işlenmesi gerektiğini düşünüyorlar. Ancak, iktidar piyasası tek şey paradır ve yatırımcılar onu boşa harcamak istemezler. Peki ne yapılır?

Tercihen, her biri basit / erişilebilir (maliyet açısından) işlemcileri kullanan birçok makine olması, bu da çok sayıda küme oluşturma fiyatını düşürmesidir. Ve evet, işe yarıyor. Basit performans ölçümlerini düşünürseniz, ana darboğaz her zaman diske kaynar . Ancak bu kadar çok makine olduğunda, sabit diskler üzerinde çalışmak yerine ana belleğe kadar şeyler yüklenebilir.

Bellek kartları bizim için pahalı , sadece insanlar, ama aynı anda çok fazla kart satın alan işletmeler için çok ucuzlar. Pahalı olmadığı için, dizinleri yüklemek ve önbellekleri el altında tutmak için gereken belleğe sahip olmak sorun değildir. Pek çok makineler olmadığından farklı yerlere sorguları yönlendirmek ve katılıyor sorumlu makinelerin kümeleri olabilir gibi, süper hızlı işlemciler gerek yoktur spesifik coğrafi bölgeleri daha izin verir, uzman veri önbelleğe alma ve daha iyi bir yanıt zamanlar.

MapReduce bu sorunun çözülmesine yardımcı oluyor mu?

MapReduce'u kullanmanın Google içinde kısıtlanmış bilgiler olduğunu düşünmeme rağmen, bu konu hakkında konuşamıyorum. Ancak, (kuşkusuz MapReduce Google'ın uygulama değil Hadoop) optimizasyonlar bir sürü olması gerekir yönlerini kapsayan birçok yukarıda ele aldı. Bu nedenle, MapReduce mimarisi muhtemelen hesaplamaların fiziksel olarak nasıl dağıtıldığına rehberlik etmeye yardımcı olur, ancak sorgulama süresinde bu hızı haklı çıkarmak için dikkate alınması gereken birçok nokta vardır.

Tamam, bu yüzden popüler aramaların bellekte önbelleğe alınabileceğini anlıyorum. Peki popüler olmayan aramalar ne olacak?

Aşağıdaki grafik , sorgu türlerinin nasıl oluştuğuna dair bir eğri sunmaktadır . Her biri sorgu hacminin yaklaşık 1 / 3'ünü (eğrinin altındaki alan) tutan üç ana arama türü olduğunu görebilirsiniz. Arsa güç yasasını gösterir ve daha küçük sorguların en popüler olduğu gerçeğini güçlendirir. Sorguların ikinci üçte biri, birkaç kelimeye sahip oldukları için hala işlenebilir. Ancak, genellikle deneyimli olmayan kullanıcıların sorgularından oluşan belirsiz sorgular kümesi, sorguların ihmal edilebilir bir parçası değildir.

Ağır kuyruklu dağıtım

Ve yeni çözümler için yer var. Yalnızca bir veya iki sorgu (ancak üçte biri) olmadığından, alakalı sonuçlara sahip olmaları gerekir . Bir Google aramasında çok karanlık bir şey yazarsanız , sonuçların listesini döndürmek daha uzun sürmez, ancak büyük olasılıkla size söylemek istediğinizi çıkardığı bir şey gösterir . Ya da sadece bu tür terimlerle bir belge olmadığını söyleyebilir - hatta aramanızı 32 kelimeye (burada rastgele bir testte başıma) indirebilir.

Bazı kelimeleri görmezden gelmek ya da sorguyu daha küçük olanlara bölmeye çalışmak ve en popüler sonuçları toplamak için düzinelerce uygulanabilir buluşsal yöntem vardır . Ve tüm bu çözümler , örneğin bir saniyeden daha kısa bir sürede mümkün olan bekleme sürelerine uyacak şekilde uyarlanabilir ve değiştirilebilir. : D


Başka bir sorgu eklemek için soruyu düzenledim.
resgh

@ad Burada düzenlemenizi ele almaya çalıştım; Umarım soruyu cevaplamaya yardımcı olur.
Rubens

10

MapReduce'un gerçek zamanlı herhangi bir şeyle ilgisi yoktur. ETL ve dizin oluşturma gibi bazı çevrimdışı görevler için uygun toplu iş odaklı bir işleme çerçevesidir. Google şu anda çoğu iş için MapReduce'dan ayrıldı ve Hadoop ekosistemi de aynı şeyi yapıyor.

Düşük gecikmenin cevabı genellikle önceden hesaplanmış endeksleri hafızada tutmaktır. Diske dokunan her şeyi hızlı ve ölçeklendirmek zordur. Impala gibi yeni nesil Hadoop tabanlı SQL motorları , örneğin Hive gibi MapReduce tabanlı altyapıya kıyasla bu kadar hız kazanıyor .

Arama altyapısı, her bir sorgunun sonuçlarını önbelleğe alamaz. Ancak ara sonuçları veya en çok yapılan sorgular için daha eksiksiz sonuçları önbelleğe alabileceğinden emin olabilirsiniz. Biraz önbellekleme ile tüm sorguların önemli bir azınlığı için sonuçlar sunabilirsiniz.

Arama da sunucular arasında bölünür. Böylece bir makine, sonucun bir parçasını almak ve daha sonra bunları birleştirmek için 100'e yetki verebilir.

Ayrıca bir dereceye kadar yaklaşmakla da kurtulabilirsiniz. Google, kelimenin tam anlamıyla bin sayfa arama sonucu oluşturmaz; sadece ilk sayfa hakkında doğru almak gerekir.

Google'ın dünya çapında milyonlarca bilgisayarı olduğunu unutmayın . Sorgularınız coğrafi olarak size yakın bir veri merkezine gidiyor ve bu yalnızca coğrafi bölgenize hizmet ediyor. Bu, veri merkezindeki zamanı işlemeyen ve ağ olan gecikmenin çoğunu keser.


İlk olarak, başka bir sorgu eklemek için soruyu düzenledim. Ayrıca: Önceden hesaplanmış önemli bir azınlıkla bile, sorgunun geri kalanının tamamlanması uzun zaman almalıdır. Ayrıca, süreç bir makineden 100 makineye devredildiğinde, gecikme süresi gerçekten artmaz (makineler arasındaki ağ gecikmesi ve toplam gecikme, tüm makinelerin gecikmelerinin maksimumudur)?
resgh

Demek istediğim, garip nadir bir sorgu olan "spagetti diamond" sorgusunu yanıtlamanın, "spagetti" ve "diamond" için önceden hesaplanmış sonuçlarla hızlandırılabileceği anlamına geliyor. DC-içi bağlantılar çok hızlı ve düşük gecikme süresine sahiptir. İçinizdeki ekstra bir veya iki sıçrama, bilgisayarınız ve DC arasındaki ~ 20 atlama ile karşılaştırıldığında hiçbir şey değildir. İşi dağıtmada baskın olan sorun, straggler problemidir; zamanında yanıt vermezlerse bazı alt kümelerden sonuçları bırakmanız gerekir. Bunların hepsi kaba genellemelerdir, ancak doğru yönü gösterir.
Sean Owen

4

MapReduce aramada kullanılmaz. Dizini oluşturmak için uzun zaman önce kullanıldı; ancak bu bir toplu işleme çerçevesidir ve web'in çoğu her zaman değişmez, bu nedenle yeni mimarilerin toplu işleme yerine artımlı olması gerekir.

Google'da arama, birçok ince ayarlı ekstra ağırlıklandırma ve optimizasyon haricinde, Lucene ve Elastik Arama'da olduğu gibi büyük ölçüde çalışacaktır. Ancak tam kalbinde, tersine çevrilmiş bir endeksi kullanacaklar . Başka bir deyişle, onlar do not Eğer bir arama sorgusu (önbelleğe olmasa bile) girdiğinizde birkaç terabayt arayabilirsiniz. Muhtemelen gerçek belgelere hiç bakmıyorlar. Ancak, hangi belgelerin sorgu teriminizle eşleştiğini listeleyen bir arama tablosu kullanırlar (stemming, yazım hataları, eşanlamlılar vb. Önceden işlenmiş). Muhtemelen her kelime için en iyi 10000 belgenin listesini alırlar (10k tamsayılar - sadece birkaç kb!) Ve bundan en iyi eşleşmeleri hesaplarlar. Sadece bu listelerde iyi eşleşmeler yoksa, bu tür sonraki bloklara vb.

Sık kullanılan kelimeler için sorgular kolayca önbelleğe alınabilir; ve ön işleme ile en iyi 10 bin sonucun bir listesini oluşturabilir ve daha sonra bunları kullanıcı profiline göre reddedebilirsiniz. "Kesin" bir cevap hesaplanarak kazanılacak hiçbir şey yoktur. İlk 10k sonuçlara bakmak muhtemelen yeterli; doğru cevap yok; ve 10001 konumundaki bir yerde daha iyi bir sonuç kaçırılırsa, kimse bilmeyecek veya fark etmeyecek (veya ilgilenmeyecektir). Büyük olasılıkla önişlemde zaten derecelendirilmişti ve sonunda kullanıcıya sunulan ilk 10'a (ya da kullanıcının aslında baktığı ilk 3)

Öte yandan, nadir bulunan terimler de zor değildir - listelerden biri sadece birkaç eşleşen belge içerir ve diğerlerini hemen atabilirsiniz.

Bu makaleyi okumanızı tavsiye ederim:

Büyük Ölçekli Hiper Metinsel Web Arama Motorunun Anatomisi
Sergey Brin ve Lawrence Sayfa
Bilgisayar Bilimleri Bölümü, Stanford Üniversitesi, Stanford, CA 94305
http://infolab.stanford.edu/~backrub/google.html

Ve evet, bunu yazan Google kurucuları. Bu son durum değil, ama zaten oldukça büyük bir ölçekte çalışacak.

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.