Bu mimari, çok dilli depolamayı birleştirilmiş bir SQL arayüzünün arkasında soyutlayan bir Federated Query Layer gerektirir ve bölgesel gecikme kısıtlamalarına saygı gösterir. Temel bileşenler arasında Apache Calcite'ı kullanan bir Maliyet Tabanlı Optimize Edici, adaptif yönlendirmeye sahip bir Dağıtılmış İcra Motoru ve cross-store işlemleri için vektör saat versiyonlaması uygulayan bir Tutarlılık Yöneticisi bulunur.
Sorgu planlayıcı, bölge boyunca veri hareketini minimize etmek için depolama özel yetenekleri istismar eden fiziksel planlar üretir. Ara sonuçları ve sıcak indeksleri depolamak için CRDT desteğiyle Redis Cluster ile desteklenen bir Coğrafi Dağıtılmış Önbellek kullanılırken, Konsensüs Modülü kıtalar arasında şema meta verisi güncellemelerini koordine etmek için Raft'ı kullanır. Parçalanma toleransı için sistem, nihai tutarlı indeksler için çatışma-zorunlu kopyalanmış veri türleri (CRDT'ler) ve kritik finansal işlemler için yalnızca iki aşamalı taahhüt (2PC) ile Saga düzenlemesi'ne otomatik geri dönüş sağlar; bu, bölge arası gecikme eşiklerini aştığında gerçekleşir.
Küresel bir perakende kuruluşu, Kuzey Amerika, Avrupa ve Asya-Pasifik'te dağıtılmış PostgreSQL (stok), MongoDB (ürün açıklamaları), Neo4j (müşteri ilişkileri) ve Amazon S3 (tıklama akışı günlükleri) arasında aramayı birleştirmesi gerekti. Zorluk, karmaşık yüzey sorgularını 100 ms'nin altında bir gecikmeyle sunarken, ani satışlar ve ağ istikrarsızlığı sırasında stok tutarlılığını korumaktı.
Çözüm 1: Merkezileştirilmiş Veri Ambarı
Gecelik bir ETL hattı uygulamak, basit sorgulamalar sunmuş ama 24 saatlik veri bayatlığı getirmiştir. Analitik için maliyet etkin olmasına rağmen, bu gerçek zamanlı stok gereksinimini karşılayamamış ve yüksek trafik olayları sırasında aşırı satış riski taşımıştır. Bu yaklaşım, işlem verileri için kabul edilemez tutarlılık gecikmesi nedeniyle reddedilmiştir.
Çözüm 2: Basit API Toplama
Her arka ucu ardışık olarak sorgulayan bir mikro hizmet inşa etmek, taze veriler sağlarken, artan ağ gecikmesi sorunuyla karşılaşmış ve 2-3 saniyelik yanıt sürelerine neden olmuştur. Servis, join optimizasyonu eksikliği nedeniyle büyük sonuç kümesi üzerinde pahalı bellekte işlemler gerçekleştirmiştir. Ayrıca, önbellek koordinasyonu sağlayamaması nedeniyle, yoğun trafik dönemlerinde büyük yüklenmelere yol açmıştır.
Çözüm 3: Akıllı Federated Sorgu Motoru ile Adaptif Önbellekleme
Bir Trino tabanlı federated katman tasarladık; depolama gecikmesi profillerini anlayan özel bir Maliyet Tabanlı Optimize Edici ile donatılmıştır. Optimize edici, filtreleri PostgreSQL ve MongoDB'ye itmiştir, Neo4j içinde grafik geçişlerini gerçekleştirmiş ve sıklıkla yapılan toplama işlemlerini Redis Cluster içinde Yazma Yoluyla geçersiz kılma kullanarak önbelleğe almıştır. Tutarlılık için, bölümler sırasında bayat okumalara tespit etme ve uygulama düzeyinde birleştirme fonksiyonları ile çatışmaları uzlaştırmak amacıyla parça başına vektör saatleri uyguladık.
Çözüm 3'ü seçmemiz, gerçek zamanlı gereksinimlerle performans arasında bir denge kuruyordu. Sonuç, p99 gecikmesini 2,400 ms'den 85 ms'ye düşürdü, Black Friday sırasında 50,000 QPS'yi destekledi ve iki bölgesel kesintiye rağmen stok doğruluğunu %99,99 içinde korudu.
Bir sorgu, bir ilişkisel veritabanı ile bir belge deposu arasında tablolara katıldığında işlem tutarlılığını nasıl sağlarsınız?
Adaylar genellikle 2PC'yi evrensel olarak önerir, ancak bu parçalanma sırasında sonsuz bir şekilde engeller. Doğru yaklaşım, Saga modeli ile telafi edici işlemleri kullanarak cross-store işlemleri için yalnızca 2PC'yi parça içi işlemler için saklamaktır. Bir Orkestra uygulaması kurun ve Temporal veya Camunda kullanarak saga durumlarını bir WAL (Yazma Öncesi Günlük) içinde kalıcı hale getirin; bu, yöneticinin arızalarından kurtulmayı sağlar. Okuma tutarlılığı için, nedensellik ihlallerini tespit etmek ve çatışma çözümlerini uygulama katmanına dönmek için Versiyon Vektörleri kullanın.
Sorgu optimizasyonu, yürütme planları oluştururken heterojen depolama performansını nasıl dikkate alır?
Çoğu aday, kardinalite istatistiklerine odaklanır, ancak gecikme maliyet modellerini atlar. Optimize edici, PostgreSQL için SSD IOPS, S3'e ağ RTT'sini ve Redis içindeki bellek basıncını takip eden bir Katalog Servisi tutmak zorundadır. Toplam Maliyet = (CPU maliyeti) + (IO maliyeti × gecikme faktörü) + (Ağ transferi × bant genişliği maliyeti) formülünü hesaplar. Dinamik programlama (özellikle Selinger algoritması) kullanarak join sıralarını numaralandırır, ancak bölgesel gecikme bütçelerini aşan planları arama alanında erken budayarak üstel patlamayı önler.
Öncelikli sorgu sonuçları edge lokasyonları boyunca aynı anda süresiz sona erdiğinde önbellek stampedesini nasıl önlersiniz?
Standart TTL süresi dolması, arka uç veritabanlarını bunaltan büyük yüklenmelere neden olur. Bunun yerine, her kenar düğümünün resmi TTL'den önce bir zaman penceresi içinde önbellek girişlerini rastgele sona erdirdiği Olasılıklı Erken Süre Dolma uygulayın ve olasılık p'yi sorgu popülaritesine orantılı hale getirin. Ayrıca, aynı anda gerçekleşen kimlik sorgularını bir arka uç isteğine dönüştüren İsteği Birleştirme'yi uygulayarak Singleflight kalıbını (görün **Groupcache'da görüldüğü gibi) kullanın. Son olarak, temeldeki veriler değişirken önbellekleri proaktif bir şekilde güncelleyerek TTL sona ermesini beklemek yerine, Değişim Veri Yakalama (CDC) akışları aracılığıyla Debezium'den Önbellek Isıtma'sını kullanın.