Dağıtık SQL: Spanner, CockroachDB ve YugabyteDB Ne Zaman Kullanılmalı?

Dağıtık SQL ne anlama gelir

Dağıtık SQL, veriyi ve işlem işleme sürecini birden çok makineye yayarken uygulamalara tek bir mantıksal SQL veritabanı sunan ilişkisel veritabanı mimarisidir. Tabloları, join'leri, dizinleri, kısıtları ve ACID işlemlerini korur; bunun üzerine otomatik bölümleme, çoğaltma ve arıza kurtarma ekler.

Bir sistem, aşağıdaki özellikleri bir araya getirdiğinde genellikle bu kategoriye girer:

• İlişkisel şema ve SQL sorgu arayüzü
• Veritabanı düğümleri arasında yatay ölçekleme
• Bölümler arasında işlemsel tutarlılık
• Otomatik çoğaltma ve yük devretme
• Tek mantıksal veritabanı olarak koordineli çalışma

Bu tanım önemlidir; çünkü PostgreSQL veya MySQL'e okuma çoğaltmaları eklemek, onu dağıtık SQL yapmaz. Çoğaltmaları olan birincil sunucu, yazmaları yine tek ana sunucudan geçirir. Uygulamanın yönettiği parçalama yazmaları dağıtır, fakat kayıtların nerede yaşayacağına ve parçalar arası işlemlerin nasıl davranacağına uygulamanın karar vermesini zorunlu kılar. Dağıtık SQL bu sorumluluğun büyük bölümünü veritabanına taşır.

Geleneksel RDBMS ile NoSQL arasındaki konum

Dağıtık SQL, geleneksel RDBMS'in ilişkisel programlama modelini dağıtık veri depolarıyla ilişkilendirilen yatay büyüme tasarımıyla birleştirir. Birincil PostgreSQL ve MySQL kurulumları, ana örnek yazma yükünü kaldırabildiğinde ve bölgesel arıza başka yerde kesintisiz yazma gerektirmediğinde iyi çalışır. Okuma çoğaltmaları, önbellekleme, bağlantı havuzları ve daha iyi dizinler bu modeli yıllarca uzatabilir.

Birçok NoSQL veritabanı, join'leri, işlemleri veya tutarlılık garantilerini sınırlayarak dağıtımı kolaylaştırmayı seçti. Büyük olay akışları, geçici önbellekler ve çok satırlı işlemlere nadiren giren kayıtlar için bu seçimler hâlâ mantıklıdır. İlişkisel küme daha fazla koordinasyon üstlenir; çünkü uygulamalar, veri düğümler arasında bölündükten sonra da kısıtların ve işlemlerin geçerli kalmasını bekler.

Pratik fark, karmaşıklığın kime ait olduğudur. Elle parçalamada uygulama ekipleri yönlendirmeyi kurar, veriyi yeniden dengeler, şema değişikliklerini koordine eder ve birden çok parçaya dokunan işlemleri yönetir. Dağıtık SQL bu mekanizmaları sağlar, ancak mühendislerin şema ve sorguları ağ üzerinden çalışan bir sistem için tasarlaması yine gerekir.

Çözmek için tasarlandığı sorunlar

Dağıtık SQL, erişilebilirlik, coğrafi yerleşim veya yazma büyümesi tek birincilli mimariyi aşmış uygulamalar için tasarlanır. Küresel bir SaaS hizmeti, fazla rezervasyon yapmaması gereken bir rezervasyon sistemi ve düğüm arızalarında kurallarını koruması gereken bir finansal defter yaygın örneklerdir.

Uygulama düzeyinde parçalama ihtiyacını kaldırabilir ve tek bir yazma konumuna bağımlılığı azaltabilir. Veriyi kullanıcılara yakın veya onaylı yargı bölgelerinde de tutabilir. Bu faydaların bedeli vardır: daha fazla çoğaltma, daha fazla ağ trafiği, daha fazla koordinasyon ve tek sunucuda görülmeyen arıza biçimleri.

İş yükü tek bölgeye rahatça sığıyorsa geleneksel yönetilen ilişkisel veritabanı daha iyi varsayılandır. Dağıtık SQL, özel parçalama, bölgesel yük devretme veya coğrafi veri denetimleri başlı başına büyük bir mühendislik sistemine dönüşecekse maliyetini hak eder.

Dağıtık SQL arka planda nasıl çalışır

Dağıtık SQL, veriyi çoğaltılmış bölümlere ayırır ve değişiklikleri uzlaşma ile dağıtık işlem protokolleri üzerinden koordine eder. Veritabanı bu mekanizmanın büyük bölümünü SQL'in arkasına saklar, ancak davranışı yine gecikmeyi, aktarım hızını, şema tasarımını ve olay müdahalesini belirler.

Bölümler kayıtların nerede durduğunu belirler

Küme, mantıksal tabloları düğümler arasında bağımsız taşınabilen küçük birimlere böler. Spanner bu birimleri çoğunlukla split, CockroachDB range, YugabyteDB ise tablet olarak adlandırır. Her birim, bir tablonun veya dizin anahtar alanının bir bölümünü kapsar.

Bölüm sınırları aralıklara, karmalara veya açık coğrafi kurallara göre belirlenebilir. Müşteri tanımlayıcısına göre sıralanan aralık, ilgili kayıtları taramayı kolaylaştırır; ancak sürekli artan tanımlayıcı yeni yazmaları tek bölüme yöneltebilir. Karma dağıtımı yazmaları daha dengeli yayar, fakat sıralı taramaları veya kiracı yerleşimini zorlaştırabilir. Üretim şemalarının çoğu, ilgili verinin erişilebilir kalması ve her yazmanın tek konumda toplanmaması için kiracı tanımlayıcısını başka bir değerle birleştirir.

İkincil dizinlerin de kendi dağıtık depolamasına ihtiyacı vardır. Bu nedenle tek bir satıra yazma, temel tabloyu ve farklı bölümlerdeki birden çok dizin kaydını güncelleyebilir. Tek sunucuda ucuz olan dizin, kümede ek uzlaşma işi ve ağ trafiği yaratabilir.

Çoğaltma ve uzlaşma her bölümü korur

Her bölümün normalde birden çok çoğaltması vardır ve bir uzlaşma grubu kabul edilen değişiklik sırasını belirler. CockroachDB ve YugabyteDB Raft tabanlı çoğaltma kullanır. Spanner, zaman altyapısıyla birlikte Paxos tabanlı çoğaltma kullanır.

Bir lider veya leaseholder, çoğaltma grubu için yazmaları koordine eder. Sistem, değişikliği taahhüt edilmiş saymadan önce çoğunluğu oluşturacak kadar çoğaltmaya kaydeder. Bir düğüm kaybolursa, çoğunluk erişilebilir kaldığı sürece hayatta kalan üyeler başka bir koordinatör seçebilir veya atayabilir.

Çoğunluk matematiksel bir gerekliliktir, her arızanın zararsız olacağı sözü değildir. Üç çoğaltmalı grup genellikle erişilemeyen bir çoğaltmayı tolere eder. İki üyenin kaybında kalan kopya güvenle yazma kabul edemez; başka bir çoğunluğun başka yerde ilerlemediğini kanıtlayamaz. Arıza alanları arasındaki yerleşim, çoğaltma sayısı kadar önemlidir.

Dağıtık işlemler birden çok bölümü koordine eder

Tek bölüme dokunan işlem çoğu zaman az koordinasyonla bitebilir. Birden çok bölümü içeren işlemde, her katılımcının yazmaları uygulaması ya da iptal etmesi için ortak bir taahhüt kararı gerekir.

Kesin protokol ürüne göre değişir; fakat iş genellikle ilgili sürümleri okumayı veya kilitlemeyi, eşzamanlı değişiklikleri doğrulamayı, niyetleri veya geçici kayıtları çoğaltmayı ve taahhüdü sonuçlandırmayı kapsar. Uzun işlemler çakışma penceresini büyütür. Büyük toplu işlemler birçok uzlaşma grubuna dokunabilir ve her ifade basit görünse bile gecikme sıçramaları oluşturabilir.

Bu yüzden ağa duyarlı işlem tasarımı önemlidir. Veritabanı bu stratejiyi destekliyorsa ilişkili satırları uyumlu bölüm önekleri altında gruplayın. İşlemleri kısa tutun, işlem açıkken harici hizmetleri beklemeyin ve etkisini ölçmeden binlerce ilgisiz kaydı tek atomik birime yüklemeyin.

Zaman ve sıralama açık mekanizmalar gerektirir

Dağıtık düğümler kusursuz senkronize bir duvar saatini paylaşmaz. Bu nedenle her ürün işlemleri sıralamak için bir yönteme ihtiyaç duyar. Spanner, dışsal tutarlılık sağlamak için TrueTime belirsizlik sınırlarını ve taahhüt beklemesini kullanır. Diğer sistemler fiziksel saatleri mantıksal bileşenler, bağımlılık takibi ve işlem protokolleriyle birleştirebilir.

Saat koordinasyonu, serileştirilebilir yürütme, takipçi okumaları ve anlık görüntüler gibi işlemleri etkiler. Uygulamalar, ayrı uygulama sunucularının ürettiği zaman damgalarının güvenilir küresel sıra kurduğunu varsaymak yerine veritabanı işlem zaman damgalarını kullanmalıdır.

Yerellik ağ yolunu denetler

Yerellik yapılandırması, çoğaltmaların nerede duracağını ve bir kaydın yazmalarını hangi bölgenin koordine edeceğini belirler. Uygun çoğaltma çağırana yakınsa okumalar hızlı olabilir. Güçlü sıralanmış yazma yine çoğunluk için gereken çoğaltmalara ulaşmalıdır; dolayısıyla gecikmesi seçilen topolojiyi yansıtır.

İyi yerleşim şirket diyagramını değil, iş yükünü izler. AB kiracısının yazmalarının çoğu Avrupa'dan geliyorsa yazma koordinatörünü orada tutmak her işlemin başında kıtalar arası yolculuğu önler. Tüm bölgelerin güncellediği sayaç gibi küresel paylaşılan kayıt, her yazara yerel olamaz ve çekişme noktası hâline gelebilir.

Dağıtık SQL ne zaman doğru seçimdir

Coğrafi dayanıklılık, yatay yazma kapasitesi veya bölümler arası doğruluk sürekli koordinasyon maliyetini haklı çıkaracak kadar önemliyse dağıtık SQL doğru seçimdir. Büyük şirketlerin buna otomatik olarak ihtiyacı yoktur; küçük bir ürün, iş sözü katı bölgesel erişilebilirlik içeriyorsa buna ihtiyaç duyabilir.

Değerlendirmeyi haklı çıkaran koşullar

Aşağıdaki koşulların birkaçı birlikte geçerliyse ciddi değerlendirme uygundur:

• Hizmet, alan veya bölge kesintisinde çalışmaya devam etmelidir
• Yazma talebi tek bir birincil veritabanının pratik sınırına yaklaşıyordur
• Elle parçalama uygulama mühendisliğinde ciddi zaman tüketecektir
• İşlemler düğümler veya konumlar arasında doğru kalmalıdır
• Kayıtlar zorunlu coğrafi yerleşim gerektiriyordur

Bu koşullar sayılarla desteklenmelidir. Gerekli kurtarma süresi hedefini, kurtarma noktası hedefini, işlem gecikmesini, en yüksek yazma hızını ve arıza alanlarını tanımlayın. Belirsiz bir küresel ölçek talebi, mimari seçmek için yeterli değildir.

Yalnızca bölgesel kullanıcılar belirleyici neden değildir. İçeriğe ağırlık veren bir uygulama, veritabanını tek bölgede tutarken web sunucularını ve önbellekleri kullanıcılara yakın konumlandırabilir. Biraz eski sonuçlar kabul edilebiliyorsa okuma çoğaltmaları bölgesel gezintiyi destekler. İlgili veriler üzerinde birden çok konumdaki kullanıcıların düşük gecikmeyle yazma yapması gerektiğinde gerekçe güçlenir.

Daha basit veritabanını destekleyen koşullar

Trafik orta düzeydeyse, yazmalar tek bölgeden geliyorsa ve kurtarma planlı bir veritabanı terfisini içerebiliyorsa geleneksel ilişkisel hizmet genellikle tercih edilir. Olgun araçlar, geniş eklenti uyumluluğu, tanıdık hata ayıklama ve daha düşük altyapı faturası sunar.

Sıkı gecikme gereksinimleri de tek bölgesel birinciliği destekleyebilir. Yerel dayanıklı yazma, uzak bölgeleri aşan çoğunluk yazmasından çok daha hızlı tamamlanabilir. Analitik ağırlıklı sistemler, aynı kümenin ikisinde de üstün olmasını beklemek yerine operasyonel işlemleri uzun taramalardan ayırmalıdır.

Ekip kapasitesi önemlidir. Yönetilen hizmetler donanım, yama ve denetim düzlemi işini azaltır; fakat şema çekişmesini, işlem yeniden denemelerini, sorgu planlamayı, kapasite yönetimini veya uygulama tarafı olay yönetimini ortadan kaldırmaz. Ekibin arıza davranışını test edecek zamanı yoksa dağıtık veritabanına geçmek riski artırabilir.

Alternatiflere dayalı karar eşiği

En güçlü gerekçe, alternatif zaten karmaşık olduğunda ortaya çıkar. Mühendisler kiracı yönlendirmesi, parça haritaları, parçalar arası işlem kuralları, bölgesel terfi prosedürleri ve ayrı geçiş araçları kurmak üzereyse bu işlevleri sağlayan veritabanı yakından değerlendirilmelidir.

Alternatif, okuma çoğaltması ve test edilmiş yedekleri olan tek yönetilen PostgreSQL örneğiyse geçiş açık kanıt gerektirir. Önce mevcut sistemi kıyaslayın. CPU doygunluğu, yatay yazma ihtiyacı yerine verimsiz sorgu, zayıf bağlantı yönetimi, aşırı dizin veya eksik önbellekten kaynaklanıyor olabilir.

Tutarlılık, erişilebilirlik ve gecikme

Dağıtık SQL, gerekli çoğunluğa ulaşamayan işlemleri reddederek arızalar sırasında genellikle işlemsel tutarlılığı korur. Bu davranış taahhüt edilmiş durumu korur, ancak bazı isteklerin ağ bölünmesinde başarısız olabileceği veya bekleyebileceği anlamına gelir.

CAP arıza davranışını açıklar

CAP teoremi, kümenin bölümleri arasındaki iletişim kesildiğinde geçerlidir. Etkilenen veri için sistem hem doğrusal tutarlılığı hem de her yalıtılmış taraftan başarılı yanıtları garanti edemez. Tutarlılık odaklı veritabanı, çoğunluğa sahip tarafın devam etmesine izin verir ve başka yerdeki güvenli olmayan yazmaları reddeder.

CAP, normal çalışmadaki gecikmeyi açıklamaz. Her bağlantı çalışsa bile çoğaltmaların iletişim kurması gerekir. Daha geniş mühendislik kararı, bölünme sırasında ne olacağını ve sağlıklı çalışmada uygulamanın ne kadar koordinasyonu kabul edeceğini kapsar.

Uygulama erişilemez sonuçları açıkça ele almalıdır. Zaman aşımları, yeniden denenebilir işlem hataları ve yazma bölgesinin geçici kaybı normal olasılıklardır. Yalıtılmış iki bölgeden de başarı döndürmek bakiye veya rezervasyon için daha kötü olurdu; uzlaştırmanın geçerli otomatik cevabı olmayabilir.

Güçlü okumalar ile bilinçli olarak eski okumalar farklıdır

Güçlü okuma, istenen sıralama garantisiyle tutarlı veritabanı durumunu görür. Bazı ürünler, tazelikten ödün vererek daha düşük gecikme ve yazma koordinatörü üzerinde daha az iş sunan takipçi veya sınırlı eskilikte okumalar da sağlar.

Bu seçim okunan alana göre yapılmalıdır. Ürün açıklaması biraz eski çoğaltmayı çoğu zaman tolere eder. Yeni değiştirilmiş parola, güncel hesap bakiyesi veya kalan envanter uygun güçlü ya da oturum tutarlı yolu kullanmalıdır. Uygulamalar hız için her okumayı eski olarak etiketleyip sonra doğruluğu hizmet kodunda yeniden kurmamalıdır.

Yazdığını görme davranışı gerçek sürücü ve yönlendirme katmanıyla test edilmelidir. Güncellemeden sonraki istek başka uygulama sunucusuna veya veritabanı uç noktasına ulaşabilir. Kullanıcının kabul edilen değişikliği gördüğünü garanti etmek için oturum belirteçleri, işlem sınırları veya güçlü okuma ayarı gerekebilir.

Yalıtım eşzamanlı sonuçları denetler

İşlem yalıtımı, eşzamanlı işlemlerin hangi anomalileri üretebileceğini belirler. Serileştirilebilir yalıtım, veritabanı işlemleri eşzamanlı yürütse bile tamamlanan işlemlerin tek tek çalışmış gibi görünmesini amaçlar.

Serileştirilebilir yürütme, eşzamanlı işlemler güvenle sıralanamadığında katılımcılardan birini iptal edebilir. Bu iptal veritabanı bozulması değil, kötü sonucu önleyen korumadır. Uygulamalar, yazmaları etkileyen her okuma dâhil olmak üzere tüm işlemin çevresinde sınırlı yeniden denemeler yapmalıdır.

Yeniden denemeler veritabanı dışında idempotent olmalıdır. Kod işlem kesin olarak taahhüt edilmeden e-posta gönderir veya ödeme sağlayıcısını çağırırsa yeniden deneme yan etkiyi tekrarlar. Veritabanı işlemi içinde bir outbox olayı kaydedin, işlemi taahhüt edin ve harici eylemi ayrı bir çalışan teslim etsin.

Mesafe yazma gecikmesine alt sınır koyar

Bölgeler arası işlem, protokolünün gerektirdiği mesajlardan daha hızlı tamamlanamaz. Çoğunluk üyeleri arasında 80 milisaniyelik gidiş geliş, sorgu yürütme, dizin bakımı, uygulama işi ve kuyruk beklemesi sayılmadan önce gerçek zaman ekler.

Pahalı kalıp çoğu zaman tek kullanıcı eyleminde art arda gelen işlemlerdir. Ödeme akışı sipariş ekleme, envanter ayırma, ödeme durumu güncelleme ve denetim yazmasını dört engelleyici taahhüt olarak yaparsa ağ maliyeti birikir. Aynı atomik sonucu paylaşan veritabanı değişikliklerini birleştirmek gereksiz gidiş gelişleri kaldırabilir; harici ödeme çağrıları ise açık işlemin dışında kalmalıdır.

Ortalama yerine yüzdelik gecikmeyi ölçün. Lider değişimi, çekişme, depolama duraklamaları ve yeniden denemeler kuyrukta görülür. Sıradan yeniden dengeleme sırasında yüzde 99 hedefini kaçıran, ancak medyan hedefini tutturmuş tasarım yine görünür kullanıcı hataları üretebilir.

Spanner, CockroachDB ve YugabyteDB karşılaştırması

Spanner, CockroachDB ve YugabyteDB benzer dağıtım sorunlarını çözer; ancak dağıtım modeli, uyumluluk, işlem uygulaması ve operasyonel varsayımlarında ayrılır. Ortak SQL etiketine bakarak seçmek yerine uygulama davranışını test etmek gerekir.

Spanner, yönetilen Google Cloud stratejisine uyar

Spanner, yönetilen Google Cloud veritabanı kullanmaya ve lehçesi, topolojisi ile işletim modeline göre tasarlamaya hazır kuruluşlara uyar. TrueTime, dışsal olarak tutarlı işlemleri destekler. Bu, taahhüt edilmiş işlemlerin belgelenmiş anlam içinde gerçek zamanlı sıralamaya uyduğu anlamına gelir.

PostgreSQL lehçesi SQL sözdizimi farklarını azaltabilir; ancak lehçe, PostgreSQL ile tam eşdeğerlik demek değildir. Eklentiler, yönetim işlevleri, sistem katalogları, veri türleri, sürücüler ve ORM varsayımları yine doğrulanmalıdır. Ekipler mevcut uygulamayı taşınabilir saymadan önce her veritabanı bağımlılığını envantere çıkarmalıdır.

İstenen sistem zaten Google Cloud kimliği, ağ oluşturma, gözlemlenebilirlik ve bölgesel denetimlere bağımlıysa Spanner özel ilgiyi hak eder. Yönetilen model veritabanı düğümü yönetimini kaldırır; ancak şema tasarımı, sorgu ayarı, kotalar, maliyet yönetimi ve uygulama kurtarma müşterinin sorumluluğunda kalır.

CockroachDB, PostgreSQL odaklı dağıtık uygulamalara uyar

CockroachDB, işlemsel veriyi range'ler arasında dağıtırken PostgreSQL tarzı uygulama erişimi isteyen ekiplere uyar. Varsayılanı serileştirilebilir yalıtımdır; bu nedenle uygulamalar çekişme veya sıralama çakışması yüzünden reddedilen işlemleri doğru biçimde yeniden denemelidir.

Uyumluluk geçiş, sürücü ve ORM katmanlarında test edilmelidir. PostgreSQL eklentileri ve özel davranışlar bulunmayabilir veya farklı olabilir. Tek düğümlü yürütme planlarına dayanan sorgular, tablo ve dizinler range'lere bölündükten sonra farklı davranabilir.

Range hareketi ve otomatik yeniden dengeleme kapasite değişikliklerini kolaylaştırır, fakat kötü bir birincil anahtar seçimi yine sıcak range'ler üretebilir. Çok bölgeli soyutlamalar tablo yerelliğini ifade etmeye yardım eder; yine de geliştiriciler hangi kayıtların bölgesel, hangilerinin küresel olduğunu ve yazmaların nerede koordine edileceğini seçmelidir.

YugabyteDB, YSQL ve karma API gereksinimlerine uyar

YugabyteDB, PostgreSQL uyumlu ilişkisel arayüze değer veren ve ayrı Cassandra uyumlu API'sinden faydalanabilecek uygulamalara uyar. YSQL ilişkisel tablolar ve dağıtık işlemler sunar. YCQL farklı veri modelini izler ve her YSQL işlemine ulaşmanın başka yolu gibi ele alınmamalıdır.

Depolama katmanı veriyi tabletler üzerinden dağıtır. Tablo tasarımı, tablet bölme, dizin yerleşimi ve işlem kapsamı işin kümeye nasıl yayıldığını etkiler. PostgreSQL uygulamalarında eklentiler, işlevler, araçlar ve sorgu planlayıcı davranışı için uyumluluk testi yine gerekir.

Farklı dağıtım yaklaşımlarının bulunması, yerleşim üzerinde denetim isteyen altyapı politikalarına uyabilir. Kendi yönetimli kurulumda bu denetim operasyon sorumluluğunu müşteriye aktarır: yükseltmeler, onarım prosedürleri, kapasite, gözlemlenebilirlik, sertifikalar, yedekler ve arıza testlerinin hepsinin sahibi olmalıdır.

Yararlı ürün testi uygulama kanıtı kullanır

Yararlı karşılaştırma, aynı temsilî iş yükünü uygulanabilir her üründe çalıştırır. Şema oluşturmayı, geçişleri, ORM'nin ürettiği SQL'i, işlem yeniden denemelerini, yedekten geri yüklemeyi, yük devretmeyi, ölçekleme olaylarını ve en yüksek hacimli sorguları test edin.

Yalnızca saniye başına en yüksek işlem sayısını karşılaştırmayın. p50, p95 ve p99 gecikmesini; çakışma ve yeniden deneme oranlarını; bölgeler arasında aktarılan baytları; depolama büyütmesini; geri yükleme süresini ve simüle edilen olayda operatör çabasını kaydedin. En iyi seçim, doğruluk ve kurtarma hedeflerini kabul edilebilir maliyet ve operasyon yüküyle karşılayandır.

Bölgesel kullanıcıları olan küresel SaaS

Küresel SaaS uygulaması, kiracıların her coğrafya için ayrı veritabanı yığınları olmadan bölgesel veri yerleşimine ve işlemsel erişime ihtiyacı olduğunda dağıtık SQL'den yararlanır. Tasarım, kiracılık şemada açıkça yer aldığında ve işlemlerin çoğu tek kiracı içinde kaldığında en iyi çalışır.

Kiracı yerelliği sözleşmeleri ve trafiği izlemelidir

Kiracı tanımlayıcısı yerleşimi yönlendirebilir. Böylece Avrupa kayıtları onaylı Avrupa konumlarında kalırken başka müşterinin kayıtları sözleşmedeki ülke veya bölgede tutulur. Bu, farklı fiziksel politikalara izin verirken tek mantıksal şemayı korur.

Yerleşim kuralları temel tablodan fazlasını kapsamalıdır. Dizin girdileri, değişiklik akışları, geçici veriler, yedekler ve dışa aktarılan kayıtlar düzenlemeye tabi bilgi içerebilir. Satırları sabitleyip küresel ikincil dizini başka yere gönderen politika, amaçlanan sınırı ihlal edebilir.

Kiracı yalıtımı performansı da etkiler. Büyük bir kiracı paylaşılan bölümü zorlayabilir veya düğüme hâkim olabilir. Bu kiracı içinde karma oluşturma veya alt bölümleme gerekebilir, fakat kiracı kapsamlı işlemlere verimli erişim korunmalıdır.

Bölgesel okumalar açık tazelik politikası gerektirir

Okuma ağırlıklı panolar, biraz gecikmiş veri kabul edilebiliyorsa yakındaki çoğaltmaları kullanabilir. Hesap değişiklikleri, yetkilendirme kararları ve işlem sonrası onay ekranları daha güçlü davranış gerektirir. Tek küresel ayar kullanmak yerine sorgu yollarını tazelik gereksinimine göre sınıflandırın.

Yazma yerleşimi her kiracının normal yazıcısını izlemelidir. Müşterinin çalışanları ağırlıkla Singapur'daysa yazmaları başka kıtada koordine etmek önlenebilir gecikme yaratır. Kiracı taşıma prosedürü, yazmaları kaybetmeden, ikamet kurallarını bozmadan ve uygulama önbelleklerini eski konumlara bağlı bırakmadan yerleşimi güncellemelidir.

Küresel uygulama kodu harekete dayanmalıdır

Liderler değişir, düğümler yeniden başlar ve bakım sırasında yönlendirme değişir. Sürücülerde makul zaman aşımları, yeniden deneme politikaları, bağlantı yenileme ve işlem başlatma mantığı olmalıdır. Aşırı yüklü kümeye eşzamanlı yinelenen istek dalgası gönderilmemesi için yeniden denemelerde rastlantısal gecikme ve sınır kullanılmalıdır.

İzleme, kullanıcı gecikmesini bölgeye ve kiracı sınıfına göre ayırmalıdır. Küresel ortalama, uzaktaki bir müşteri grubunun birkaç ek ağ yolculuğu ödediğini gizleyebilir. API span'lerini veritabanı ifadelerine bağlayan iz kimlikleri, yerellik hatalarını bulmayı kolaylaştırır.

Finansal iş akışları ve defterler

Finansal iş akışları, veritabanı kısıtları ve işlemler defter kurallarını arızalar ve eşzamanlı istekler arasında koruduğunda fayda sağlar. Dağıtım tek başına doğru muhasebe oluşturmaz; ihlal edilemeyecek kuralları şema kodlamalıdır.

Defter denetlenebilir giriş dizisi korumalıdır

Ekleme odaklı defter, geçmişi olmayan tek bakiye değerini sürekli değiştirmek yerine her hareketi giriş olarak kaydeder. Her kayıt için kararlı işlem tanımlayıcısı, hesaplar, tutarlar, para birimi, iş zaman damgası ve oluşturma metaverisi olmalıdır. Borç ve alacaklar kayıt biriminde dengeli olsun diye çift kayıt kuralları taahhütten önce denetlenmelidir.

Önbelleğe alınmış bakiye okumaları hızlandırabilir; fakat girişlerle aynı işlemde değişmeli veya türetilmiş veri olarak açıkça ele alınmalıdır. Uzlaştırma işleri, türetilmiş toplamları kaynak girişlerle karşılaştırmalı ve geçmişi sessizce yeniden yazmadan farkları bildirmelidir.

Her hesap için küresel sıralama nadiren gerekir. Tek hesabı veya transfer çiftini etkileyen işlemler tutarlı sıraya ihtiyaç duyar; ilgisiz hesaplar eşzamanlı ilerleyebilir. Bu sınıra göre tasarlamak, tek küresel sıra veya uzlaşma satırına kıyasla çekişmeyi azaltır.

İdempotency yeniden denemeleri güvenli kılar

Ödeme API'leri, kuyruklar ve webhook'lar zaman aşımından sonra yeniden dener. Bu nedenle her iş işlemi kararlı bir idempotency anahtarına ihtiyaç duyar. Benzersizliği doğru kapsamda, örneğin müşteri veya hesap başına zorlayın; ardından ödeme kaydını ve defter girişlerini tek veritabanı işleminde oluşturun.

CREATE TABLE payment_attempts (
    account_id UUID NOT NULL,
    idempotency_key TEXT NOT NULL,
    provider_reference TEXT,
    status TEXT NOT NULL,
    created_at TIMESTAMPTZ NOT NULL,
    PRIMARY KEY (account_id, idempotency_key)
);

İki çalışan aynı işlemi gönderirse, hangi eklemenin başarılı olacağını benzersiz kısıt belirler. Kaybeden çalışan mevcut kaydı okumalı ve belirlenmiş sonucu döndürmelidir. Veritabanı işlemi yeniden denendi diye ikinci sağlayıcı tahsilatı oluşturmamalıdır.

Harici çağrılar işlem sınırı gerektirir

Bir veritabanı, ikisi de özel koordinasyon protokolüne katılmadıkça ilgisiz ödeme sağlayıcısıyla atomik taahhüt yapamaz. Çoğu herkese açık API bu protokole katılmaz. Ağ çağrısını veritabanı işlemi dışında tutun ve akışı beklemede, yetkilendirildi, tahsil edildi, başarısız oldu ve tersine çevrildi gibi açık durumlarla modelleyin.

İşlemsel outbox, taahhüt edilmiş değişiklikleri alt çalışanlara yayınlayabilir. Mesaj teslimi birden fazla kez olabileceği için tüketiciler olay tanımlayıcısına göre tekilleştirmelidir. Bu yaklaşım, her hizmeti kapsayan imkânsız tek işlem iddia etmeden kurtarılabilir işleme sağlar.

Sıcak hesaplar iş yüküne özel tasarım ister

Bordro çalıştırmaları, pazaryeri mutabakatları ve büyük satıcılar yazmaları tek hesapta yoğunlaştırabilir. Veritabanı düğümü eklemek tek çakışan satırı düğümler arasında bölmez. Seçenekler değişmez giriş bölümleri, dönem başına toplayıcılar, tek hesap için kuyruklu kayıt veya dikkatle tanımlanmış alt hesap hiyerarşisidir.

Gerçek çarpıklık dağılımını test edin. Tekdüze sentetik trafik, küme hazır görünürken üretimde tek bir satıcının sürekli serileştirilebilir çakışmalar üretmesine yol açabilir. Önce doğruluk gelir; ancak veri modeli, muhasebe kurallarının izin verdiği güvenli eşzamanlılığı açığa çıkarmalıdır.

Envanter, rezervasyon ve ayırtma

Envanter ve rezervasyon sistemleri, birden çok kullanıcının aynı kıt ürünü talep edebildiği durumda yetkili tahsis işlemi gerektirir. Hızlı müsaitlik okumaları gezintiyi iyileştirir, fakat son birimi kimin alacağına yalnızca taahhüt yolu karar verebilir.

Koşullu yazmalar fazla satışı önler

Koşullu güncelleme, yalnızca yeterli stok kaldığında stok ayırabilir. Etkilenen satır sayısı uygulamaya tahsisin başarılı olup olmadığını söyler.

UPDATE inventory
SET available = available - 1
WHERE sku = $1
  AND available > 0;

Bu ifade rezervasyon kaydıyla aynı işlemi paylaşmalıdır. Önce müsaitliği okuyup sonra azaltmak, yalıtım düzeyi ve koşul işleme kararı korumadıkça yarış yaratır. Veritabanı kısıtları, ek güvenlik katmanı olarak negatif miktarları reddetmelidir.

Atanmış koltuklarda gösteri ve koltuk tanımlayıcısı üzerindeki benzersiz kısıt tek kazanan rezervasyonu verir. Otel envanteri genellikle oda-gece veya envanter havuzu tarihiyle modellenir; böylece çakışan konaklamalar aynı kapasiteyi talep edemez. Doğru çekişme birimi iş kuralından gelir.

Bekletmeler tahsisi ödemeden ayırır

Geçici bekletme, ödeme veya kullanıcı onayı sürerken envanteri ayırır. Bitiş zamanını ve durumunu saklayın, ardından koşullu işlemle onaylı rezervasyona dönüştürün. Onay ve süre sonu yarışabileceğinden, süre sonu çalışanı yalnızca hâlâ etkin bekletmeleri serbest bırakmalıdır.

Duvar saati gecikmesi serbest bırakmayı garanti etmez. Çalışanlar durabilir, kuyruklar gecikebilir ve bölgeler arızalanabilir. Satılabilir envanteri hesaplayan sorgular, süresi geçmiş durumu tutarlı biçimde hesaba katmalı; onarım işleri kaçırılan bekletmeleri geri almalıdır.

Bekletme süresi ürün ve kapasite kararıdır. On dakikalık bekletme ödeme için makul olabilir, ancak yoğun anlarda kıt envanterin anlamlı bölümünü kilitleyebilir. Süreyi belirlemeden önce terk etme oranını ve ödeme tamamlama süresini ölçün.

Aşırı çekişme doğrusal ölçeklenmez

Tek satır için yarışan binlerce alıcı, çoğaltma eklenerek paralel hâle getirilemez. Her başarılı azaltma diğerlerine göre sıralanmalıdır. Kabul denetimleri, kuyruk, stok kovaları veya önceden ayrılmış bölgesel kotalar ürün çıkışı sırasında veritabanını koruyabilir.

Bölgesel kotalar koordinasyonu azaltır, fakat anlamı değiştirir. Avrupa'da kullanılmayan birimler varken başka bölge tükenirse sistemin kotayı güvenle aktarması veya geçici dengesizliği kabul etmesi gerekir. Bu kalıbı yalnızca işletme bölgesel kapasitenin nasıl uzlaştırılacağını tanımlayabiliyorsa kullanın.

Yüksek erişilebilirlik ve olağanüstü durum kurtarma

Dağıtık SQL, çoğaltma yerleşimi, boş kapasite ve uygulama davranışı tanımlı hizmet hedefiyle uyumlu olduğunda seçilmiş altyapı arızaları sırasında hizmeti sürdürebilir. Tek başına çoğaltma bu sonucu kurmaz.

SLO'lar arıza alanlarını belirtmelidir

Çalışma süresi hedefi, iş yükü ve arıza senaryosu gerektirir. Hizmetin tek düğümü, tek kullanılabilirlik alanını mı yoksa tüm bölgeyi mi aşması gerektiğini tanımlayın. Yalnızca kurtarmadan sonrasını değil, olay sırasındaki kabul edilebilir hata oranını ve gecikmeyi de belirtin.

Tek binada yer alan üç çoğaltmalı küme, bağımsız alanlardaki üç çoğaltmadan farklı risk profiline sahiptir. Çok bölgeli topoloji daha geniş olayı korur; ancak daha uzun çoğunluk yolları getirir ve konumlardan biri kaybolduktan sonra trafiği emecek yeterli kapasite ister.

Kurtarma süresi hedefi hizmetin ne kadar hızlı dönmesi gerektiğini tanımlar. Kurtarma noktası hedefi ne kadar taahhüt edilmiş verinin kaybedilebileceğini tanımlar. Eşzamanlı çoğunluk çoğaltması, kapsanan arızalarda sıfır taahhüt edilmiş veri kaybı hedefini destekleyebilir; fakat yalnızca gerekli çoğaltmalar ve uygulama yolu tasarlandığı gibi davrandığında.

Yük devretme görünür uygulama olayları üretir

Liderlik değişimleri devam eden işlemleri kesebilir, bağlantıları kapatabilir ve gecikmeyi artırabilir. Uygulamalar yeniden denenebilir veritabanı sonuçlarını kalıcı iş hatalarından ayırmalıdır. Başarısız işlem, yalnızca son ifadesini oynatmak yerine bir bütün olarak yeniden başlamalıdır.

Bağlantı havuzları arızadan sonra ölü uç noktaları tutabilir. Sağlık kontrolleri, DNS davranışı, yük dengeleyiciler, sertifika doğrulaması ve sürücü topoloji keşfi test planına dâhildir. Veritabanı sağlıklı olabilir, ancak uygulama yine ona ulaşamayabilir.

Arıza sonrası kapasite açıkça hesaplanmalıdır. Üç bölge normalde yüzde 70 kullanımla çalışıyorsa birinin kaybı, payına düşen iş için yetersiz alan bırakır. Boş kapasite ayırmak para harcatır, fakat yük devretme kapasitesi olmayan topoloji söylediği hedefi karşılamaz.

Tatbikat günleri tasarımı doğrular

Arıza alıştırmaları bir düğümü devre dışı bırakmalı, alanı yalıtmalı, bölgesel bağlantıyı kesmeli ve uygulama uç noktasını kaldırmalıdır. Hata süresini, işlem yeniden deneme oranını, gecikme yüzdeliklerini, kuyruk büyümesini ve operatör yanıtını ölçün.

Bu alıştırmaları anlamlı topoloji, sürücü veya şema değişikliklerinden sonra yürütün. Geçen yılın trafiğine karşı kanıtlanan prosedür, veri hacmi iki katına çıktığında veya bir kiracı baskın hâle geldiğinde başarısız olabilir. Kanıtın yılda bir yapılan manuel olaya bağlı olmaması için alıştırmanın güvenli kısımlarını otomatikleştirin.

Çoğaltma yedek değildir

Çoğaltmalar kazara silmeleri, hatalı geçişleri ve zararlı uygulama yazmalarını sadakatle kopyalar. Yedekler ve belirli zamana geri yükleme, çoğaltmanın algılayamadığı mantıksal hasara karşı korur.

Geri yükleme tatbikatları ayrı, temiz ortam kurmalı; sağlama toplamlarını veya uygulama kurallarını doğrulamalı ve toplam kurtarma süresini ölçmelidir. Şifreleme anahtarlarını, erişim politikalarını, şema sürümlerini ve bağımlı yapılandırmayı dâhil edin. Var olan ama hedef süre içinde geri yüklenemeyen yedek, yeterli kurtarma sistemi değildir.

Veri ikameti ve uyumluluk odaklı mimari

Dağıtık SQL, kiracı veya kayıt gruplarını onaylı bölgelere yerleştirebilir; ancak uyumluluk her kopyaya, erişim yoluna ve operasyonel sürece bağlıdır. Veritabanı yerelliği daha geniş programın içindeki bir denetimdir.

İkamet kuralları kesin tanımlar ister

Verinin ülkede kalması gerekliliği depolama, işleme, destek erişimi, yedekler, şifreleme anahtarları veya bunların tümü anlamına gelebilir. Bu yorumlar farklı topolojiler üretir. Hukuk danışmanları ve denetçiler düzenlemeleri ve sözleşmeleri test edilebilir teknik denetimlere çevirmelidir.

Ekipler düzenlemeye tabi alanların ve türetilmiş verinin envanterine ihtiyaç duyar. Günlükler, izler, arama dizinleri, analitik dışa aktarımları, destek ekleri ve mesaj kuyrukları ana tabloyla aynı kişisel bilgileri içerebilir. Veritabanını kısıtlarken ham yükleri küresel olarak dışa aktarmak amaçlanan politikayı karşılamaz.

Veri minimizasyonu tasarımı basitleştirebilir. Küresel hizmetin yalnızca hesap tanımlayıcısına ve toplu duruma ihtiyacı varsa hassas ayrıntıları onaylı bölgede tutun, başka yerde izin verilen en küçük temsili gösterin.

Yerleşim politikaları yaşam döngüsü işlemlerini de içermelidir

Politikalar canlı çoğaltmaların, geçici çoğaltmaların, yedeklerin, anlık görüntülerin, değişiklik kayıtlarının ve geri yükleme ortamlarının nerede bulunabileceğini belirtmelidir. Yeniden dengeleme ve bakım aynı sınıra uymalıdır. Acil durum prosedürü, kolaylık için düzenlemeye tabi veriyi onaysız bölgeye kopyalamamalıdır.

Erişim denetimi coğrafi ve örgütsel sınırlar gerektirir. Hizmet kimlikleri yalnızca ihtiyaç duydukları tablolara ve işlemlere erişmelidir. İnsanların üretim erişimi kayda alınmalı, mümkünse süreyle sınırlandırılmalı ve incelenmelidir. Bölgeye bağlı şifreleme anahtarları ek denetim sağlar; ancak anahtar erişilebilirliği ve olağanüstü durum kurtarma da ayrıca tasarlanmalıdır.

Kiracı taşınması belgelenmiş iş akışını hak eder. Sözleşme değişiklikleri, müşteri taşınması veya kurumsal yeniden yapılanma kayıtların yargı alanları arasında taşınmasını gerektirebilir. Süreç eski kopyaların ne zaman yok olacağını, yedeklerin nasıl zaman aşımına uğrayacağını ve hangi kanıtın tamamlandığını gösterdiğini belirlemelidir.

Küresel raporlama türetilmiş veri kümeleri gerektirebilir

Küresel pano, bölgeler arasında ham müşteri verisini tarıyorsa katı yerleşimle çelişebilir. Bölgesel işleme, onaylı toplamları yerelde hesaplayıp hassas olmayan sonuçları merkezi raporlama deposuna yayınlayabilir.

Toplama kuralları, kısıtlanmış kayıtların yeniden oluşturulmasını önlemelidir. Küçük gruplar, serbest metin alanları ve ayrıntılı boyutlar, doğrudan tanımlayıcılar çıkarılsa bile kişisel bilgiyi açığa çıkarabilir. Bu nedenle analitik yönetişimi sonraki raporlama projesine değil, mimari incelemeye dâhildir.

Operasyonel ve analitik iş yükleri çoğu zaman ayrı sistemleri hak eder. İşlemsel veritabanı güncel ürün durumunu korurken, bölge kapsamlı işlem hatları raporlar için yönetilen veri kümeleri üretir. Bu ayrım uzun analitik taramaları gecikmeye duyarlı işlemlerden uzak tutar.

Maliyet ve performans planlaması

Dağıtık SQL, yedek kapasiteyi koruduğu ve işi ağ üzerinden koordine ettiği için temel tek bölgeli veritabanından pahalıdır. Maliyetli parçalama işini değiştirdiğinde veya işletim primini aşan kayıpları önlediğinde yatırım yine haklı olabilir.

Hesaplama ve depolama çoğaltma yükünü içerir

Üç tam çoğaltmalı mantıksal 2 TB veri kümesi, ikincil dizinler, geçici sıkıştırma alanı, yedekler ve metaveri hesaba katılmadan önce yaklaşık 6 TB çoğaltılmış veriyle başlar. Gerçek faturalama ve sıkıştırma ürüne göre değişir. Tahminler yalnızca mantıksal tablo boyutuna değil, ölçülmüş fiziksel depolamaya dayanmalıdır.

Hesaplama normal işi, uzlaşma işlemesini, yeniden dengelemeyi, yedek etkinliğini ve arıza için boş kapasiteyi karşılamalıdır. Bir bölüm sıcak olduğunda düğümler birbirinin yerine geçebilen aktarım birimleri değildir. Kapasite eklemek, yalnızca iş yükü ona yayılabiliyorsa yardımcı olur.

Dizinler yazma işini ve depolamayı çoğaltır. Her ikincil dizini sorgu değeri, güncelleme sıklığı ve coğrafi yerleşimine göre inceleyin. Dağıtık kümede kullanılmayan dizin diski boşa harcar ve etkilediği her yazmayı pahalılaştırır.

Ağ ücretleri önemli hâle gelebilir

Çoğaltma yazmaları çoğaltma konumları arasında gönderir. Bölgeler arası sorgular, değişiklik akışları, yedekler ve uygulama trafiği ek aktarım yaratır. Birden çok bölgede etkin trafik, tek bölgeli kıyaslamanın asla göstermeyeceği fatura oluşturabilir.

İşlem başına baytı, çoğaltma katsayısını, yazma hızını, dizin büyütmesini ve aktarımların yönünü tahmin edin. Ardından temsilî yük çalıştırmasında sağlayıcının faturalama verileriyle test edin. İstek sayıları tek başına büyük yükleri ve arka plan hareketini kaçırır.

Yerellik hataları hem maliyeti hem gecikmeyi yükseltir. Bir bölgede dağıtılan hizmet, uç nokta seçimi veya kiracı yerleşimi yüzünden başka bölgedeki koordinatörü tekrar tekrar sorgulayabilir. Dağıtık izleme ve bölgesel maliyet kırılımları bu kalıbı ortaya çıkarır.

Kullanıcı yolculukları biriken gecikmeyi gösterir

Yalıtılmış ifadeler yerine tam kullanıcı eylemlerini modelleyin. Ödeme için art arda gelen her veritabanı taahhüdünü, güçlü okumayı, harici API çağrısını ve kuyruk devrini sayın. Ölçülmüş bölgesel gidiş geliş sürelerini ve sorgu yürütme yüzdeliklerini kritik yola uygulayın.

Bir yolculukta, her biri 90 milisaniye ağ koordinasyonu ekleyen iki ardışık çoğunluk yazması olduğunu varsayalım. Bu, uygulama işlemeden önce yaklaşık 180 milisaniye ekler. Tek atomik kararı paylaşan değişiklikleri birleştirmek bir taahhüdü kaldırabilir, bağımsız okumaları paralelleştirmek yolu kısaltabilir.

Yük testleri gerçekçi çekişme ve yük boyutları içermelidir. Rastgele tanımlayıcılı kıyaslama kusursuz dağılırken üretim yazmaları birkaç popüler kiracıya yönelebilir. Kuyruk gecikmesinin olağan küme çalışmasını yansıtması için lider değişimlerini ve yeniden dengelemeyi dâhil edin.

Toplam sahipliği gerçekçi alternatiflerle karşılaştırın

İlgili karşılaştırma, dağıtık SQL ile operasyon maliyeti olmayan hayalî veritabanı arasında değildir. Belirli alternatifle karşılaştırın: yönetilen PostgreSQL, çoğaltmalar, parçalama hizmetleri, bölgesel kurtarma, uygulama yönlendirmesi ve bunları sürdürecek mühendisler.

Geçiş işini, eğitimi, gözlemlenebilirliği, olay müdahalesini, destek planlarını ve çıkış maliyetlerini ekleyin. Yönetilen çalışma altyapı emeğini azaltabilir; kendi yönetim ise daha derin personel ihtiyacı pahasına denetim gereksinimlerini karşılayabilir.

Basit finansal model, yıllık platform primini beklenen kesinti kaybı, geciken mühendislik işi, uyumluluk riski ve bölgesel gecikmeden etkilenen gelirle karşılaştırabilir. Belirsiz girdiler için aralık kullanın ve hangi varsayımın kararı değiştirdiğini belirleyin. Sonuç gerçekçi olmayan derecede büyük kesinti tahminine dayanıyorsa daha basit sistem muhtemelen uygundur.

Şema ve uygulama tasarım kalıpları

Dağıtık SQL şeması, ilgili işlemleri yakın tutarken bağımsız işi erişim yollarında yaydığında iyi çalışır. Tek düğümlü şemayı değiştirmeden taşımak doğruluğu koruyabilir, ancak kötü gecikme veya şiddetli çekişme yaratabilir.

Birincil anahtarlar dağıtımı etkiler

Sürekli artan birincil anahtar, yeni satırları tek range'in sonuna yöneltebilir. Rastgele tanımlayıcılar eklemeleri yayar, ancak tamamen rastgele dağıtım kiracı taramalarını veya bölgesel yerleşimi pahalılaştırabilir. Bileşik anahtarlar çoğu zaman bu hedefleri, kiracı veya kova tanımlayıcısıyla başlayıp o grup içinde sıralanabilir değeri koruyarak dengeler.

Öneki işlem sınırlarına göre seçin. Neredeyse her işlem kiracı kapsamındaysa kiracıya göre gruplama dağıtık işi azaltabilir. Çok büyük kiracı, birden çok bölümün eşzamanlı yazma kabul edebilmesi için kendi ad alanında kovalar gerektirebilir.

Tablo büyüdükten sonra birincil anahtarı değiştirmek büyük veri yeniden yazımı gerektirebilir. Geçişten önce aday düzenleri gerçekçi çarpıklıkla test edin. Yalnızca toplam aktarım hızına bakmak yerine bölüm sıcaklığını, işlem yayılımını, dizin yerelliğini ve tarama davranışını inceleyin.

Çekişme kapasiteden önce yeniden tasarım gerektirir

Küresel sayaç, tekil yapılandırma satırı veya tek satıcı bakiyesi aksi hâlde bağımsız istekleri sıralı hâle getirebilir. Daha fazla düğüm, her işlemin aynı değeri güncellemesi gerektiği mantıksal zorunluluğu kaldırmaz.

Geçici toplama kabul edilebiliyorsa kesin küresel sayaçları bölümlenmiş sayaçlarla değiştirin. Yüksek sıklıkta tek satırı güncellemek yerine yapılandırmayı sürümlendirin. Parasal durumda muhasebe kuralını koruyun; doğruluğu zayıflatmak yerine değişmez girişlerde veya bağımsız alt hesaplarda eşzamanlılık bulun.

Uzun oku-değiştir-yaz işlemleri çakışmaları artırır. Gerekli en küçük kümeyi okuyun, işlem içinde kullanıcı etkileşiminden kaçının ve hemen taahhüt edin. İş çalışması dakikalar sürüyorsa bunu birkaç kısa işlemde durum makinesi olarak temsil edin.

Yeniden deneme davranışı uygulama sözleşmesine aittir

Sürücüler tek tek ifadeleri yeniden deneyebilir veya uygulama koduna yeniden denenebilir hata gösterebilir. Tüm işlemin tekrarından hangi katmanın sorumlu olduğunu anlayın. Kısmi tekrar eski kararları kullanabilir veya önceki okumaları atlayabilir.

Yeniden deneme döngüsünde en yüksek deneme sayısı, rastgeleleştirilmiş geri çekilme ve ölçüm olmalıdır. Çakışma türünü, etkilenen işlemi, deneme sayısını ve nihai sonucu kaydedin. Sınırsız yeniden deneme çekişmeyi gizli gecikmeye dönüştürür ve kümeyi aşırı yükleyebilir.

İş isteklerinin kararlı tanımlayıcılara ihtiyacı vardır; böylece belirsiz istemci yanıtı güvenle denetlenebilir. Veritabanı taahhüt edip yanıt kaybolursa istemci anlamsal olarak yeni istek göndermek yerine belirlenmiş işlemi sorgulamalıdır.

Şema değişiklikleri üretim ölçeğinde prova gerektirir

Dağıtık şema değişiklikleri metaveriyi hızla güncellerken geri doldurmalar ve dizin oluşturma arka planda sürebilir. Bu işler depolama, ağ ve CPU tüketir; canlı yazmalarla etkileşebilir.

Genişlet ve daralt geçişlerini kullanın. Önce uyumlu alanları veya tabloları ekleyin, iki biçimle de çalışabilen kodu dağıtın, denetimli partilerle geri doldurun, okumaları değiştirin, doğrulamadan sonra eski biçimi kaldırın. Geri alma planı yeni sürümün yazdığı veriyi hesaba katmalıdır.

Büyük geçişleri üretime benzer hacim ve bölgesel topolojiyle test edin. Küçük hazırlık kümesinde hızla biten değişiklik üretimde saatler sürebilir ve müşteri trafiğiyle yarışabilir. Başlamadan önce ilerlemeyi, duraklatma denetimlerini, disk boşluğunu ve yeniden deneme davranışını izleyin.

Benimseme kontrol listesi ve kavram kanıtı

Yararlı kavram kanıtı, temsilî bir iş yükünü açık doğruluk, gecikme, dayanıklılık ve maliyet hedeflerine karşı test eder. Genel kıyaslamalar belirli şema ve uygulamanın iyi davranıp davranmayacağını belirleyemez.

Gerçek kısıtları olan iş yükü seçin

Kıt ürün ayırtma, defter transferi kaydetme veya zorunlu bölgede kiracı sağlama gibi iş akışı seçin. Üretim tarzı şemasını, sorgularını, işlem sınırlarını, yük boyutlarını ve trafik çarpıklığını yeniden kullanın.

Testi çalıştırmadan önce başarıyı tanımlayın:

• Eşzamanlılık ve yeniden denemelerde doğru sonuçlar
• Bölge başına p50, p95 ve p99 gecikmesi
• Arıza boşluğuyla sürdürülebilir tepe aktarım hızı
• Düğüm ve bölgesel arızalarda kurtarma davranışı
• Ölçülmüş hesaplama, depolama ve ağ maliyeti

Güvenlik payı keyfi çarpandan değil, beklenen büyüme ve arıza kapasitesinden gelmelidir. Bir bölgeyi kaybetmek kapsamdaysa kalan konumlar test sırasında yönlendirilen yükü kaldırmalıdır.

Gerçekçi uygulama yüzeyi oluşturun

API ve küçük kullanıcı arayüzü, yalnızca veritabanı aracının kaçırabileceği işlem sıralamasını, sürücü davranışını ve kullanıcının algıladığı gecikmeyi gösterir. Koder.ai sohbet üzerinden React arayüzü, Go arka ucu ve PostgreSQL temeli oluşturabilir. Planlama modu üretimden önce iş akışını tanımlamaya yardım eder; kaynak kod dışa aktarma, mühendislerin veri katmanını aday veritabanına göre uyarlamasını sağlar.

Üretilen uygulamayı veritabanı uyumluluğunun kanıtı değil, test iskelesi olarak kullanın. Geçişleri çalıştırın, üretilen SQL'i inceleyin, resmî sürücüyü yapılandırın ve işlem yeniden denemelerini bilinçli biçimde uygulayın. Koder.ai anlık görüntüleri ve geri alma, uygulama yinelemelerini koruyabilir; veritabanı yedeklerinin veya geri yükleme tatbikatlarının yerini tutmaz.

Koder.ai dağıtım ve barındırmayı da destekler. Böylece test uygulaması örneklerini veritabanı bölgelerine yakın yerleştirmek mümkündür. Bu, her kıyaslamayı tek konumdan göndermek yerine tam istek yolunu ölçmeyi sağlar. Ortam üretim kayıtları için gereken denetimlere sahip değilse test verisini sentetik tutun.

Normal çalışmayı ve arızayı deneyin

Test; kararlı trafik, ani yükler, sıcak bölümler, uzun süren sorgular, şema değişiklikleri, yedek çalışması ve düğüm değiştirmeyi kapsamalıdır. Ardından onaylı test ortamında bağlantıyı kesin ve bir arıza alanını kaldırın.

İşlem iptallerini, yeniden deneme girişimlerini, erişilemez yanıtları, lider hareketini, kuyruk derinliğini, disk kullanımını ve bölgesel aktarımı yakalayın. Operatörün ne yapması gerektiğini kaydedin. Belgelenmemiş manuel adım gerektiren otomatik kurtarma henüz üretime hazır değildir.

Yedeği ayrı ortama geri yükleyin ve uygulama kurallarını doğrulayın. Envanterde tahsislerin stoğu aşmadığını onaylayın. Defterde bakiyeleri yeniden hesaplayın ve dengeli kayıtları doğrulayın. SaaS kiracılığında yerleşim ve erişim politikalarının geri yüklemeyi atlattığını doğrulayın.

Geçişten önce uyumluluğu doğrulayın

Veritabanı eklentilerini, saklı yordamları, tetikleyicileri, veri türlerini, yalıtım varsayımlarını, ORM özelliklerini, raporlama sorgularını, yedek araçlarını ve yönetim betiklerini envantere çıkarın. Her öğeyi uyumlu, değiştirilebilir veya engelleyici diye sınıflandırın.

Temsilî geçişleri tam boyutlu kopyada veya üretilmiş veri kümesinde çalıştırın. Geri doldurma süresini, değişiklik verisi yakalama gecikmesini, çift çalıştırma maliyetini ve geçiş süresini ölçün. Geçiş çift yazma kullanıyorsa farkların nasıl algılanacağını ve her aşamada hangi sistemin yetkili kalacağını tanımlayın.

Gölge okumalar üretim durumunu değiştirmeden sonuçları karşılaştırabilir. Karşılaştırmanın beklenen farkı bozulma diye işaretlememesi için zamanlama farklarını ve kasıtlı olarak eski sorguları hesaba katın. İşlemsel veride açıklanamayan her fark, geçişten önce çözülmelidir.

Üretime hazır olmayı gözden geçirin

Üretim incelemesi veritabanı işletimi, uygulama yeniden denemeleri, güvenlik, ikamet politikası, maliyet ve olay müdahalesi için sahipler atamalıdır. Panoları, uyarıları, çalışma kitaplarını, kapasite eşiklerini, geri yükleme kanıtını ve geri alma karar noktasını içermelidir.

Son karar PostgreSQL veya MySQL üzerinde kalmak da olabilir. Kavram kanıtı, dağıtık seçeneğin mevcut gereksinimlerin haklı çıkardığından daha pahalı olduğunu gösterse bile güvenilir kanıt ürettiğinde başarılıdır. Gereksinimler benimsemeyi destekliyorsa kademeli geçin, her aşamayı ölçün ve yeni sistem gerçek yük altında kendini kanıtlayana kadar test edilmiş geri dönüş yolunu koruyun.