Boyuttan önce yazıcı sayısını sorun
Bir uygulamanın küçük olması, veri modelinin basit olduğu anlamına gelmez. Aynı sayacı iki sunucunun artırması birkaç baytlık bir problem olabilir; binlerce sabit içerik kaydını yalnız derleme sırasında okumak daha kolaydır. İlk soru dosyanın kaç megabayt olduğu değil, aynı durumu kimlerin hangi sırayla değiştirdiğidir.
Inscribi Director’ın açık JsonStore sınıfı adı verilen kaydı JSON dosyasından okur. Yazarken önce geçici dosya üretir, ardından dosyayı hedef ada taşır. Büyük tamsayıları metne dönüştürerek JSON’a uygunlaştırır. Bu küçük arayüz, köprü durumunu saklayan kodun depolama ayrıntısından ayrı kalmasını sağlar. Ancak arayüzün küçük olması, bütün tutarlılık sorunlarını çözdüğünü göstermez.
Atomik değiştirme neyi çözmez?
Geçici dosya ve yeniden adlandırma düzeni, okuyan tarafın yarım yazılmış hedef dosyayı görmesi riskini azaltmak için kullanılır. İncelenen kodda kayıtlar arası işlem, çoklu yazıcı kilidi veya açık disk eşitleme çağrısı yoktur. Bu yüzden tek dosya değiştirme davranışını, birkaç dosyanın birlikte güncellenmesi veya güç kesintisinde kesin dayanıklılık garantisi olarak sunmak doğru değildir.
Ayrıca bridge nesnesi durumu belleğine alıp değiştirir. Aynı kaydı başka bir süreç de değiştiriyorsa, dosyanın eksiksiz JSON olması güncellemenin güncel bilgi üzerine yapıldığını kanıtlamaz. Son yazan süreç diğerinin değişikliğini ezebilir. İkinci sunucu ekleme kararı, bu nedenle yalnız dağıtım ayarı değildir; depolama varsayımını da değiştirir.
Kayıp güncellemeyi küçük bir örnekle görün
Aşağıdaki örnek gerçek uygulama kodu veya yürütülmüş yük testi değildir. İki çalışanın aynı ilk değeri okuduğu bir sıralamayı gösterir. Her biri doğru biçimde bir ekler; fakat ikisi de aynı başlangıçtan hareket ettiği için son değer iki artışı içermez. JSON’un geçerli olması bu mantıksal kaybı yakalayamaz.
stored = {"count": 0}
worker_a = dict(stored)
worker_b = dict(stored)
worker_a["count"] += 1
worker_b["count"] += 1
stored = worker_a
stored = worker_b
assert stored["count"] == 1 # Two increments, one surviving update.Seçenekleri hata biçimleriyle karşılaştırın
Bu tablo başlangıç kararı içindir. Bir veritabanı seçmek doğru işlemleri kendiliğinden yazmaz; kilit, yeniden deneme ve yedekleme davranışını yine tasarlamak gerekir. SQLite belgesi birden fazla okuma işlemini, fakat aynı anda yalnız bir yazma işlemini desteklediğini açıklar. Uygulama bu yazma sınırına uygun hata davranışı oluşturmalıdır.
| Seçenek | Karmaşıklık | Ölçeklenme sınırı | Başlıca hata biçimi |
|---|---|---|---|
| Tek yazıcılı JSON | Düşük; dosya ve şema yönetimi | Bir yetkili yazıcı, küçük durum | Eski bellek durumu, bozuk veya kayıp dosya |
| Yerel SQLite | Orta; şema ve transaction tasarımı | Tek makinede eşgüdümlü erişim | Yazma çekişmesi, yanlış transaction sınırı |
| Paylaşılan veritabanı servisi | Daha yüksek; bağlantı ve işletim | Birden fazla uygulama örneği | Ağ kesintisi, bağlantı sınırı, yarış koşulu |
Geçişi tetikleyen gereksinimi yazın
Bir kullanıcı işlemi birkaç kaydı birlikte değiştirecekse, paralel arka plan işleri eklenecekse veya geçmiş değişiklikler denetlenebilir olmalıysa mevcut dosya düzenini yeniden değerlendirin. “İleride büyürüz” yerine somut tetikleyici belirlemek, gereksiz altyapıyı ertelemeyi ve gerektiğinde gecikmeden geçmeyi sağlar. Geri yükleme testi de ilk günden tasarımın parçasıdır.
Geçiş sırasında mevcut dosyaları yedekleyin, şemayı doğrulayın ve içe aktarılan kayıt sayısını kaynakla karşılaştırın. Yeni uygulamanın yazmaya başladığı anı belirleyerek eski ve yeni deponun bağımsız biçimde değişmesini önleyin. Küçük bir uygulamada iyi karar, en az satır kod yazmak değil; hangi hata karşısında neyin korunacağını açıkça belirlemektir.
Kurtarma provasında yalnız dosyanın açıldığını görmeyin. Kaydedilmiş bir bekleyen işlemle uygulamayı yeniden başlatın; hangi durumun geri geldiğini ve dış servise yeni istek gönderilip gönderilmediğini kontrol edin. Böylece verinin korunması ile iş akışının doğru devam etmesini ayrı ayrı sınamış olursunuz. Bu deneme için canlı ücretli servis yerine kontrollü bir sahte servis kullanmak, tekrarların sonucunu görünür ve deneyin maliyetini sınırlı tutar.