Yazma Veritabanı (Command Model):
- Bu, veri üzerinde değişiklik yapan (yeni veri ekleyen, güncelleyen, silen) işlemler için kullanılan veritabanıdır. Genellikle normalize edilmiş veri yapıları içerir, yani her veri parçası birden fazla tablodan oluşabilir ve ilişkiler karmaşıktır.
Okuma Veritabanı (Query Model):
- Okuma veritabanı ise daha hızlı ve verimli sorgular yapmak için denormalize edilmiş veri yapıları içerir. Yani, birden fazla tabloyu tek bir yerde birleştiren daha basit ve hızlı veri yapılarına sahiptir. Bu veri tabanı, okuma işlemleri için optimize edilmiştir.
Yeni Veriler Okuma Veritabanına Nasıl Gelir?
Bu süreçte iki ana yaklaşım vardır: Eventual Consistency (sonunda tutarlılık) ve Event Sourcing kullanımı. Yazma ve okuma veri tabanlarının eşitlenmesi (synchronization) için, yazma veri tabanında yapılan değişikliklerin okuma veri tabanına aktarılması gerekir. Bu işlem genellikle bir olay (event) tetiklendiğinde yapılır. Aşağıda, bunun nasıl çalıştığını açıklayalım:
1. Eventual Consistency (Sonunda Tutarlılık):
Bu yaklaşımda, yazma ve okuma veri tabanları arasında anında bir tutarlılık sağlanmaz. Yazma işlemleri (komutlar) önce yazma veri tabanında yapılır, sonra okuma veri tabanındaki veriler, sonradan güncellenir.
- Adımlar:
- Veri yazma: Kullanıcı bir sipariş oluşturduğunda, bu işlem yazma veri tabanına kaydedilir.
- Event Gönderimi: Yazma işlemi tamamlandığında, bir "sipariş oluşturuldu" gibi bir olay (event) tetiklenir.
- Okuma Veri Tabanı Güncellemesi: Bu olay, okuma veri tabanını güncelleyen bir mekanizma tarafından alınır. Bu mekanizma, okuma veri tabanına yeni sipariş bilgilerini ekler veya mevcut veriyi günceller.
Örnek:
Sipariş mikroservisi: Sipariş oluşturulduğunda, yazma veritabanına kaydedilir. Ancak okuma veritabanı bu yeni siparişi görmek için yazma veritabanından bir "sipariş oluşturuldu" olayı alır ve bu veriyi okuma veri tabanına ekler.
Not: Eventual Consistency, anında tutarlılık sağlamaz, ancak zaman içinde her iki veri tabanı da tutarlı hale gelir.
2. Event Sourcing:
Event Sourcing, her yazma işlemine bir olay (event) kaydeder. Bu olaylar yazma veritabanına kaydedilir ve okuma veritabanı bu olayları dinler ve veri modelini buna göre günceller.
- Adımlar:
- Event Oluşumu: Kullanıcı bir sipariş oluşturduğunda, bu işlem bir olay (event) olarak kaydedilir (örneğin: "Sipariş Oluşturuldu").
- Event Sourcing Uygulaması: Event sourcing mekanizması, bu olayı hem yazma veritabanında hem de okuma veri tabanında uygular. Bu sayede okuma veri tabanı güncellenir.
Örnek:
- Sipariş oluşturulduğunda, bu olay "Sipariş Oluşturma" olarak kaydedilir. Okuma servisi, bu olayı alır ve okuma veri tabanında siparişler tablosunu günceller.
3. Asenkron Güncelleme:
Çoğu mikroservis mimarisinde, asenkron işleme kullanılır. Yazma işlemi gerçekleştiğinde, okuma veritabanının güncellenmesi için bir mesaj kuyruğu (message queue) veya event stream (örneğin, Apache Kafka veya RabbitMQ) kullanılır. Bu şekilde, yazma işleminden sonra hemen okuma veritabanı güncellenmez, bunun yerine bir mesaj veya olay kuyruğa atılır ve okuma veritabanı bu olayı dinler.
- Adımlar:
- Yazma işlemi gerçekleşir ve event tetiklenir.
- Event, bir mesaj kuyruğuna gönderilir.
- Okuma veritabanını yöneten mikroservis, bu kuyruğu dinler ve yeni verileri okuma veri tabanına ekler veya günceller.
Örnek:
- Sipariş oluşturulduğunda, bir "sipariş oluşturuldu" olayı bir RabbitMQ kuyruğuna gönderilir.
- Okuma mikroservisi, bu kuyruğu dinler ve okuma veritabanındaki veriyi günceller.
4. Sık Güncelleme (Polling):
Bir başka yaklaşım ise, yazma ve okuma veri tabanları arasındaki senkronizasyonu belirli aralıklarla polling yaparak sağlamaktır. Okuma mikroservisi, belirli aralıklarla yazma veri tabanını sorgular ve değişiklik varsa okuma veritabanını günceller.
Örnek:
- Sipariş yazıldığında, okuma servisi her 5 saniyede bir yazma veri tabanını kontrol eder ve yeni siparişleri okuma veritabanına aktarır.
Sonuç:
Yazma ve okuma veri tabanlarının ayrılması, mikroservis mimarisinde yaygın bir CQRS uygulamasıdır. Yazma veritabanı, verilerin tutarlılığını ve işlem bütünlüğünü sağlarken, okuma veritabanı yalnızca okuma işlemlerine yönelik optimize edilmiş veri yapılarını tutar. Yazma veritabanında yapılan yeni işlemler, event-driven veya asenkron güncelleme teknikleriyle okuma veri tabanına aktarılır, böylece iki veri tabanı arasında tutarlılık sağlanır. Bu yaklaşımda eventual consistency (sonunda tutarlılık) esas alınır, bu da yazma ve okuma veri tabanları arasında anında tutarlılık sağlanmadığı, ancak bir süre sonra her iki veri tabanının da tutarlı hale geleceği anlamına gelir.
Hiç yorum yok:
Yorum Gönder