Google,Milyarlarca Kayıtı Nasıl Bu Kadar Hızlı Cevaplıyor?

Selamlar,

Geçmiş zamanlarda Google'nin bazı paylaşımlarını incelerken "En hızlı yanıt süresi." gibi bir ifadesini gördüm ve gerçekten de merak ettim.
Hepimizin her sitesinin orada kayıtlı olmasını geçtim bir de istek attığımda milyarlarca isteği nasıl işleyebiliyor?

Database yapısı nasıl olabilir?
Sorgulama sistemini neye göre ve nasıl yapıyor olabilir?
Tabii ellerinde kendilerine ait "datacenter" adaları var lakin ona oranla da kullanıcıları var. Yani terabaytlarca ram cpu gpu olabilir ama bunları optimize kullanmaları gerekiyor.
Backend tarafında o kadar veriyi nasıl o kadar optimize çalıştırıyor veya çekebiliyor?

Örnek mimari hakkında ufak bir örnekle açıklayabilir misiniz?
Teşekkürler.

Biraz uzun oldu ama yapay zekanın cevabı:

1) “Milyarlarca isteği” tek yere atmıyorlar: trafik kenarda kırılıyor

Google’da kritik fikir şu: kullanıcıya en yakın noktada iş başlar.

• Dünya çapında edge/PoP (Point of Presence) noktaları var. DNS ve anycast routing ile istekler en yakın/az yükteki bölgeye gider.
• Pop’larda:
  • TLS sonlandırma
  • Bot/DDOS filtreleme
  • önbellek (cache)
  • Basit/çok sık gelen sorgular için “hazır cevap”
    yapılır.

Sonuç: Merkezi datacenter’a giden istek sayısı ciddi azalır; gidenler de “ön işlenmiş” daha hafif istekler olur.

2) Arama motorunun veri yapısı: “dev bir database” değil, dev bir indeks

Arama dediğimiz şey DB sorgusu gibi görünse de aslında ana iş inverted index (ters indeks) kullanmak.
Yani kelimeden dokümana giden harita.

2.2 Bu indeks nasıl saklanır?

• İndeks, parçalara (shard) bölünür.
• Her shard birden fazla makinede replike edilir.
• Saklama tarafında Google’ın kendi dağıtık dosya sistemi (eski GFS → yeni Colossus) üzerinde durur.
• Meta/veri servisleri için Bigtable/Spanner benzeri dağıtık KV/kolon DB’ler kullanılır ama arama serving’in kalbi inverted indextir.

Sonuç: “tek dev DB” yerine binlerce shard + replika.

3) Crawl → Index → Serve: üç ana hat

Google Search’ü bir fabrika gibi düşün:

3.1 Crawl (toplama)

• Web botları sayfaları gezer.
• Robots.txt, site hız limitleri, içerik tazeliği vb. kurallar var.
• İçerik ham halde dağıtık depoya yazılır.

3.2 Indexing (işleme)

• Sayfadan metin çıkarma, dil algılama, spam/kalite skorları, link grafı, yapısal veri, medya analizi…
• MapReduce-benzeri batch işler ile dev paralel işlem yapılır.
• Çıktı: ters indeks parçaları + çeşitli sinyaller.

3.3 Serving (kullanıcı sorgusu)

• Sorgu gelir → normalizasyon (dil, yazım, eş anlam, niyet).
• İlgili shard’lara dağıtılır.
• Her shard kendi top K sonucunu döner.
• Aggregator bunları birleştirip sıralar, UI’ya taşır.

4) Sorgulama sistemi “neye göre” çalışır?

4.1 Adım adım query pipeline

1. Query rewrite
   • Yazım düzeltme
   • Eş anlamlı/benzer kelime genişletme
   • Yerelleştirme (TR → Türkiye kaynaklarını öne çekme)
   • Niyet sınıflandırma (bilgi mi, alışveriş mi, navigasyon mu?)
2. Candidate retrieval
   • Ters indeks ile “bu kelimeleri içeren” doküman havuzu çekilir.
   • Bu havuz milyonlar olabilir ama shard’larda çok hızlı bulunur.
3. Ranking
   • Yüzlerce sinyal:
     • metin eşleşmesi
     • link otoritesi (PageRank türevleri)
     • tazelik
     • kullanıcı memnuniyeti sinyalleri
     • spam/kalite
     • konum
     • sayfa hızı/UX
     • yapısal veri uyumu
   • Modern tarafta büyük kısmı ML/LLM destekli “learning-to-rank” modelleriyle tartılır.
4. Re-ranking / post-processing
   • Çeşitlilik (aynı kaynaktan 10 sonuç gelmesin)
   • Güvenlik filtreleri
   • Snippet üretimi
   • Görsel/video/news dikeyleri harmanlama

Önemli nokta: İlk retrieval çok hızlı “geniş ağ”; derin ML işi ise daha küçük top-N üzerinde çalışır → latency düşük kalır.

5) “O kadar RAM/CPU/GPU’yu nasıl optimize kullanıyorlar?”

5.1 Bellek hiyerarşisi ve cache katmanları

Google’da arama için RAM altın. Çünkü diskten okumak milisaniyeler, RAM’den nanosaniyeler.

• Edge cache: En popüler sorguların sonuçları
• Datacenter cache: Popüler shard blokları RAM’de tutulur
• OS / FS cache: sıcak veri
• Cold storage: nadir erişilen indeks parçaları disk/SSD’de

80/20 kuralı gerçek: sorguların küçük bir kısmı trafiğin çoğunu oluşturur → cache ile uçururlar.

5.2 Sharding + parallelism

• Bir sorgu tek makineye değil, yüzlerce shard sunucusuna paralel gider.
• Her shard kendi küçük parçasında çalışır.
• Paralel toplamına bakarsan “dev işlem” çok kısa sürer.

5.3 Load balancing ve hızlı failover

• Her shard’ın birden fazla kopyası var.
• En hızlı cevap veren replika kullanılır (tail latency azaltma).
• Bir makina yavaşsa “hedged requests” ile ikinci kopyaya aynı anda sorulur.

5.4 Süreç yönetimi (Borg/Kubernetes benzeri)

• Google’da iş yükleri konteyner/cluster scheduler ile dağıtılır:
  • CPU boşta kalmasın
  • RAM aşırı şişmesin
  • Aynı rack’e bağımlılık olmasın
• Arama gibi kritik servisler “yüksek öncelik” alır.

6) Gecikme (latency) neden bu kadar düşük?

Bir sorgunun bütçesi kabaca:

• Edge’e ulaşım: ~10–30 ms
• Query rewrite + routing: ~1–5 ms
• Shard retrieval (paralel): ~10–30 ms
• Ranking + snippet: ~5–20 ms
• UI dönüş: ~5–10 ms

Toplam: çoğu zaman <100 ms bandı.
Bunu tutturmak için:

• Paralel shard sorgusu
• Heavy ML sadece top adayda
• Cache
• Replika/hedge
• Ağa yakın computation

7) Basit bir “muhtemel Google Search mimarisi” şeması

1. Client
2. DNS/Anycast → Edge PoP
3. Edge cache / güvenlik
4. Query broker (DC içinde)
5. Shard router
6. Index servers (inverted index parçaları, RAM ağırlıklı)
7. Top-K aggregator
8. Ranking/ML servisleri
9. Snippet & vertical blender
10. Result cache → Edge → Client

8) Neden “datacenter adaları yetiyor” gibi görünüyor?

Çünkü kapasiteyi 3 şeyle efektif büyütüyorlar:

1. Veriyi böl (shard)
2. İşi paralelleştir
3. Sıcak veriyi RAM/cache’e al

Bu üçü sayesinde aynı donanım:

• daha çok sorgu taşır,
• daha düşük gecikme verir,
• arıza toleranslı olur.

9) Senin tarafına yansıyan pratik çıkarım (SEO açısından)

Google’ın sistemi anlamsal + kalite sinyallerine dayanıyor. Bu yüzden:

• Net konu ve niyet (sayfa tek soruyu çok iyi cevaplasın)
• Yapısal veri (schema)
• Tazelik + otorite (dış link kadar içerik tutarlılığı)
• Hız/UX
• Spam’den uzak doğal metin

Ters indeks “kelime eşleşmesiyle başlatır”, ama final sıralama kalite ve niyet çözümü

BigTable Spanner Colossus Veritabani kullaniyor Kullanıcı → Load Balancer → Index Sunucusu → Cache → Data Sunucusu Kı saca Google'ın sırrı dağıtık sistemler + agresif caching + custom hardware + in-house yazılım stack'i. Her katmanda optimizasyon yaparak milyarlarca isteği <200ms'de cevaplıyor.

Dünya çapında yüzlerce veri merkezi, Binlerce node, milyonlarca CPU çekirdeği,özel dosya sistemleri (GFS), özel veri tabanları (Bigtable), özel ağ protokolleri
Her kıtada edge, CDN, routing mühendisliği, Çok katmanlı cache, paralel sorgu, ML rerank vb.

milyar dolarlık bir iş

Google hızını şöyle sağlar: Dağıtık sistem, önbellekleme, güçlü veri tabanı (Spanner), yakın sunucular (edge), paralel işlem ve akıllı yük dengeleme.