Okuma-yazma ayrımı
Bir şirketin işi büyümeye devam ettiğinde ve kullanıcı sayısı önemli ölçüde arttığında, orijinal veritabanı muhtemelen kendini sürdüremeyecektir. O zaman evet
- Ölçeklendirme, donanımın performansını artırıyor, ancak kullanıcı sayısının artmaya devam etmesi muhtemel ve artan performans yakında tüketilecek.
- Okuma-yazma ayrımı: Veritabanı tutamaz, özellikle son 24 saatteki en popüler ürünler gibi karmaşık sorgular varsa, bu sadece çok fazla okuma ve yazma işidir. Çok karmaşık SQL ifadeleri gerektirir ve tabii ki çalışması yavaştır.
Ancak, okuma ve yazma işlemlerini ayırmak için veritabanının ana ve köle kütüphanelere bölünmesi gerekir.
Piyasadaki ana ilişkisel veritabanları veri çoğaltmayı destekler, bu yüzden bir veritabanını iki role bölebilirsiniz: Master ve Slave, master üzerinde işlemler yazabilir ve ana sunucuyu diğer köle sunucularla senkronize edebilirsiniz.
Okuma işlemleri ve veri analizi gibi çevrimdışı işlemler Slave sunucuda gerçekleştirilir.
İnternetteki birçok uygulamanın okunduğunu biliyoruz, böylece birden fazla köleye yükü paylaşabilir ve verinin erişilebilirliğini ve doğruluğunu garanti edebilir.
Ancak, ilgili orijinal uygulama kodu da değiştirilmelidir ve veri yazmak için ana kütüphaneyi kullanacak şekilde değiştirilmelidir; veri okurken ise köle kütüphanesi kullanılır ki bu yeniden yazmaya eşdeğerdir.
Karmaşık sorgular
Ancak, kodu yeniden yazdıktan sonra bile, çok fazla karmaşık sorgu kullanıldığı için performansın hâlâ önemli ölçüde iyileşmediğini gördüm ve veritabanı bileşeninde birleştirmelerin çok performans açısından yoğun olduğunu söyledik.
Yani son 24 saatin popüler ürünlerini ayrı bir tablo depolayabilir miyiz, böylece sadece basit SQL kullanmamız yeterli olur.
Başka bir deyişle, tek bir veritabanı tablosu seti raporlar, aramalar, işlemler gibi farklı davranışlar için uygun değildir.
Mevcut tablo, veri eklemek ve değiştirmek için tasarlanmıştır ve karmaşık sorgular için uygun değildir.
Ama aynı zamanda bu sorgu tabanının nasıl güncellendiğini, bu gecikmeyi tolere edip edemeyeceğimizi, gerçek zamanlı olarak güncellenip güncellenmeyebileceğini de düşünmemiz gerekiyor.
CQRS
Gecikmenin tolere edilip edilmeyeceği iş açısından değerlendirilmelidir; örneğin son 24 saatte popüler en iyi ürünler gibi, biraz eski bilgiler çok etkili olmaz, sadece nihai tutarlılık gereklidir.
CQRS (Komut Sorgusu Sorumluluğu Ayrımcılığı) kullanabiliriz; yani komutları eklemek veya değiştirmek için sorgu sorumluluklarından komutların ayrılmasıdır.
CQRS'de vurgu okuma (Sorgu) ve yazma (Komut) ayrımı üzerindedir, çünkü kullanıcıların okunduğu veri genellikle güncel değildir, bu yüzden veritabanından okumaya neden ihtiyaç duyulabilir, doğrudan bir okuma veri kaynağı oluşturabilirsiniz. Cache olabilir, XML, JSON vb. olabilir.
Daha önce bahsedilen güncelleme sorunu nasıl çözülür? Event'i kullanabilirsiniz, yani bir olay, örneğin bir ürün satıldığında, orijinal Okuma Modelini değiştirmek için bir olay yayınlayabilirsiniz.
Bu şekilde, senkronizasyon olay mekanizması aracılığıyla asenkron hale gelir.
Son olarak, bu yöntem en iyi şekilde sadece karmaşık sorgular için kullanılır ve orijinal basit sorgular hala ilişkisel veritabanında alınır. Neden? Yeni bir teknolojinin tanıtılması, eşzamanlı mutasyon adımları ve olay mekanizmaları gibi bir fiyat gerektirdiği için, yeni teknolojilerin dezavantajlarını değil, sadece avantajlarını göremeyiz.
|
Yayınlandı 4.05.2020 09:58:50
|
|
|
|
