İlişkisel Veriden Olaylara Geçiş

İlişkisel Veriden Olaylara Geçiş Rehberi

• Event sourcing yaklaşımında iş verileri kaybedilmeden olaylar olarak korunur.
• Olaylar, gerçekleşmiş gerçekleri temsil eder ve her işlemden sonra kaydedilir.
• Olay akışı, kaydedilmiş tüm olayların listesi olup değiştirilemezdir; geçmişteki hatalar yeni olaylar eklenerek düzeltilebilir.

1. Durum sütunlarını bulun

• Durum sütunlarındaki değerler, verinin yaşam döngüsü aşamalarını yansıtabilir.
• Örneğin, bir sipariş başlatılabilir, gönderilebilir ve ödenebilir.
• Bu durumlar, Order Initiated, Order Shipped, Order Paid gibi olaylara dönüştürülebilir.

2. Tarih sütunlarını inceleyin

• Tarih sütunları, süreçteki önemli olaylar hakkında bilgi sağlayabilir.
• ShipmentDate, DeliveryDate, OrderPlacementDate gibi alanlar iş terminolojisini ortaya koyar ve yeni olayların tanımlanmasına yardımcı olabilir.

3. Sütun seçiciliğini analiz edin

• Nullable sütunlar daha sonra sağlanıyor olabilir veya isteğe bağlı olabilir.
• Zorunlu sütunlar ilk Order Initiated olayında sağlanmalıdır.

4. En fazla 1'e çok ilişkisi olan tabloları arayın

• Event sourcing'de veriler, verimli işleme için iş süreçleri etrafında gruplanır.
• Çok sayıda 1'e çok ilişkiye sahip tablolar, akış türü için aday olabilir.

5. Açık olaylar ekleyin

• İlişkisel veriyi olaylara taşırken, yeni keşfedilen olayları içe aktarma sırasında yeniden kullanmak yerine Order Imported olayını açıkça sağlamalısınız.

6. Deneyin ve doğrulayın

• Güvenli bir ortamda prototip deneyin, sonuçları beklentilerle karşılaştırın ve acele etmeden yineleyin.

GN⁺ görüşü

• Bu yazıdaki en önemli nokta, ilişkisel veritabanından event sourcing'e geçiş sürecinde iş verilerini koruyan yeni yaklaşımın önemidir.
• Yazıyı ilginç kılan şey, geleneksel veri yönetimi yaklaşımının ötesine geçerek verinin yaşam döngüsünü daha iyi anlamaya ve kullanmaya yönelik bir yöntem önermesidir.
• Event sourcing, yalnızca teknik açıdan değil, iş ve teknik ekipler arasında ortak bir anlayış oluşturulmasına da yardımcı olabilir.

[GN⁺]

Hacker News görüşleri

• PostgreSQL ve FOSS raporlama araçlarının kullanımı öneriliyor

  • Uygulamada zaten PostgreSQL kullanılıyorsa, olay verilerinin PostgreSQL'de tutulması ve FOSS raporlama araçlarının (Apache Superset, Metabase vb.) kullanılması öneriliyor.
  • Veri yaklaşık 2 TB'a ulaşana kadar PostgreSQL kullanılmalı; sonrasında ise çevrimiçi olarak 2 TB veriye gerçekten ihtiyaç olup olmadığına ya da yalnızca günlük/saatlik özetlerin yeterli olup olmadığına karar verilmeli.
  • Bir müşteri örneğinde, 10 TB'tan fazla veri ve saniyede 1500 olay işleniyor; ayrıntılı veri 2 gün boyunca çevrimiçi tutuluyor, kalanı özetlenip S3'e taşınıyor ve Athena SQL üzerinden sorgulanabiliyor.
  • AWS RDS Multi-AZ kullanılarak otomatik hata devretme destekleniyor ve tek bir mühendis ayda 5 saatten az çalışarak her şeyi yönetiyor.
  • PostgreSQL, veriyi tek yerde tutmak, öğrenmek, yönetmek ve ölçeklendirmek için tek bir sistem sunuyor.
  • Teknik olmayan çalışanlar bile Metabase veya Preset gibi sistemlerde kolayca grafik oluşturabiliyor.
  • PostgreSQL her yıl gelişiyor ve gerekirse PostgreSQL uyumlu sistemler (Aurora, TimescaleDB, CitusDB vb.) üzerinden ek ölçekleme yapılabiliyor.

• Olay güdümlü mimarinin ne zaman uygun olduğu

  • Müşterinin belirli bir eylem yapıp bir yanıt beklediği durumlar, olay güdümlü değil istek/yanıt kalıbına giriyor.
  • Olay güdümlü yaklaşım, beklenmedik bir şey gerçekleştiğinde devreye giriyor. Örneğin GitHub'a kod gönderildiğinde derlemenin tetiklenmesi gibi.

• Event sourcing hakkında şüpheci bir deneyim paylaşımı

  • Bir ekip event sourcing'i değerlendirmiş, ancak net bir fayda görmemeleri ve yeni bir şeyi denemenin riskleri nedeniyle sonunda kullanmamaya karar vermiş.
  • Öğrenme fırsatını kaçırdıkları için pişman değiller; ihtiyaç olmayan bir durumda karmaşık sorunlara atlamamayı olumlu değerlendiriyorlar.

• Domain event modeling'in faydası

  • Domain event modeling, çözülmek istenen alanın uzmanlarıyla iletişim kurmak için faydalı.
  • Uzun süreli bir durum makinesi için denetim izi sağlayan bir sistemi hayata geçirirken Temporal.io/durable functions gibi araçları kullanmak daha iyi.
  • Bu araçlar içeride event sourcing kullanıyor ve kodun deduplication ile idempotency dikkate alınarak yazılmasını zorunlu kılıyor.

• Event sourcing uygulamasına dair sorular

  • Olay akışından mevcut durumun verimli biçimde nasıl yeniden oluşturulacağı ve olay akışının veritabanında nasıl modellenmesi gerektiği yeterince açıklanmıyor.

• Bottom-up ile top-down, özel çözümler ile genel amaçlı çözümler

  • Top-down yaklaşım, iş alanından başlayıp uygulamayı mevcut teknoloji, araç ve üreticilere göre eşliyor.
  • Bottom-up yaklaşım, mevcut teknoloji, araç ve üreticilerden başlayıp çalışan bir çözüm oluşturuyor.
  • Özel yaklaşım; DDD, CQRS/ES, Sagas, TBUI, GraphQL, cebirsel veri tipleri vb. içeriyor.
  • Genel amaçlı yaklaşım; RDBMS, CRUD, REST, ACID transaction'ları, CDC, genel amaçlı yönetim arayüzleri, no-code/low-code, sınırlı/genel amaçlı tipler vb. içeriyor.

• Event-driven mimariye destek ve eleştiri

  • Event-driven mimariye destek var, ancak söz konusu makale iddiasını net biçimde aktarmakta başarısız oluyor.
  • Veri ilişkileri ile iş davranışları arasındaki farka odaklanıldığında, operasyonel ilişkisel veri deposundan uzaklaşmanın gerekçesi daha net hale geliyor.

• Event sourcing ve ilişkiselliğin gerekliliği

  • Event sourcing'in birçok avantajına rağmen ilişkiselliğe hâlâ ihtiyaç var.
  • Eğer ilişkisellik tamamen uygulama katmanı kodunda örtük biçimde duruyorsa, bu kabul edilemez.
  • İlişkileri sorgulamanın veya ilişkisel görünümleri güncel tutmanın bir yolu gerekli.

• İlişkisel veriye destek

  • Karmaşıklıktan kaçınıp geleneksel ilişkisel veriye sadık kalma kararı veriliyor.

• Event-driven tasarıma dair yeni farkındalık

  • Yakın zamanda event-driven tasarımla tanışılmış ve yapay zekanın baskın olduğu bir dünyada en uygun veri yapısını düşünürken benzer bir sonuca varılmış.
  • Event-driven tasarım karmaşıklığı yönetebiliyor ve verinin gerçekten kullanılmasını sağlayabiliyorsa değerli olacağı düşünülüyor.
  • Önümüzdeki birkaç yıl içinde yapay zekanın tüm iş olayları hakkında bilgi sahibi olup bunları sorgulayabilir hale gelmesiyle, event-driven tasarımın yaygınlaşacağı öngörülüyor.