Veritabanları ve Karmaşıklıklarının Artık Neden Gereksiz Olduğu

Veritabanlarının sorunları ve karmaşıklıklarının neden gereksiz olduğu

• Veritabanları küresel değiştirilebilir durumdur; bu da kodun karmaşıklaşmasına ve anlaşılmasının zorlaşmasına yol açar.
• Veri modelleri sınırlıdır ve tüm kullanım senaryolarını destekleyemez; bu yüzden birden fazla veritabanı kullanmak gerekir.
• Normalizasyon ile denormalizasyon arasındaki sorun, veri tutarlılığı ile performans arasında bir gerilim yaratır.
• Sınırlı şemalar, alan ifadesini veritabanına uydurmak için ek karmaşıklık doğurur.
• Karmaşık dağıtım süreçleri, çeşitli araçların birleştirilmesi ve entegrasyonu nedeniyle maliyeti ve karmaşıklığı artırır.

Uygulama arka ucu oluşturmak için tutarlı bir model

• Arka ucun temel işlevi yeni verileri almak ve bu veriler hakkında soruları yanıtlamaktır.
• İdeal arka uç tasarımı, gerçek kısıtları karşılarken mümkün olduğunca ideale yakın olmalıdır.

Rama

• Rama, arka uç geliştirme platformudur; Mastodon'u yeniden uygulayarak Twitter ölçeğinde bir hizmet sunar.
• Rama, veri, indeksler, ETL, sorgular ve arka ucun diğer tüm unsurlarını genel bir yaklaşımla uygular.
• Rama, karmaşık dağıtımı sadeleştirir ve izlemeyi entegre ederek geliştirme ve bakım maliyetlerini büyük ölçüde azaltır.

GN⁺ görüşü

• Veritabanlarının küresel değiştirilebilir durum sorunu, kodun karmaşıklığını ve hata olasılığını artırır; bu, geliştiricilerin sıkça karşılaştığı bir problemdir.
• Rama, mevcut veritabanlarının sınırlamalarını aşan ve arka uç geliştirmenin karmaşıklığını azaltan yeni bir yaklaşım sunar.
• Bu yazı, veritabanı ve arka uç sistemlerinin karmaşıklığını azaltmak isteyen geliştiriciler için ilgi çekici ve faydalı bilgiler sunuyor.

[GN⁺]

Hacker News yorumu

• Gerçeğin kaynağını temsil eden tek bir alt sistem ve bu kaynaktan türetilen çeşitli indeks depolarını uygulayan başka bir alt sistem kullanmalısınız. Bu, event sourcing ile materialized view'ların birleşimidir.

  • Event sourcing ve materialized view'lar: Gerçeğin kaynağını temsil eden sistem ile buna dayanan indeks depolarını ayrı yönetmek çözüm olarak sunuluyor.

• Okuma modeli ile yazma modelini ayırıyoruz: yazma modeli ("gerçeğin kaynağı") geleneksel ilişkisel alan modeliyle oluşturulur ve neredeyse tüm komutlar paylaşılan alan olay kuyruğuna yayımlanan olaylar üretir. Okuma modeli ise olayları tüketip görünümler oluşturan worker'lardan meydana gelir.

  • Okuma/yazma modeli ayrımı: Yazma modeli ilişkisel bir alan modelinden oluşur; komutlar olay üretip alan olay kuyruğuna yayımlar. Okuma modeli ise bu olayları tüketerek görünümler oluşturur.

• Veri değiştiğinde materialize etmek, ürünün tek bir işi çok hızlı yapması gerektiğinde avantaj sağlayabilir. Ancak karmaşık transaction'lar gerektiğinde ya da farklı biçimde düzenlenmiş veri gerektiren yeni özellikler eklenmek istendiğinde sorun ortaya çıkar.

  • Veriyi materialize etmenin sınırları: Tek bir işe optimize edildiğinde faydalıdır, ancak karmaşık transaction'lar veya yeni veri yapıları gerektiren özellikler eklenirken sorun yaratabilir.

• Bunun "Twitter ölçeğinde bir Mastodon istemcisi" ile kanıtlandığını iddia etmek, gerçekten günde 40 milyon kullanıcılı bir web sitesini işletmiyorsanız mümkün değildir.

  • Ölçeğin önemi: Gerçekten büyük kullanıcı ortamlarını simüle etmek mümkün değildir; bu yüzden böyle bir iddiayı desteklemek zordur.

• Daha iyi yaklaşım, event sourcing ile materialized view'ların birleşimidir.

  • Event sourcing ile materialized view'ların birleşimi: Karmaşıklığı artırsa da daha iyi bir yaklaşım olarak öneriliyor.

• Tek bir veri modeli tüm kullanım durumlarını destekleyemez.

  • Veri modelinin çeşitliliği: Tüm kullanım durumlarını tek bir veri modeliyle desteklemek mümkün değildir.

• Veritabanlarıyla ilgili bir şikayetim yok.

  • Veritabanlarının geçerliliği: Veritabanlarına yönelik bir şikayet yok; hâlâ geçerli bir araç olarak görülüyorlar.

• Eşzamanlılık, izolasyon, kısıtlar gibi kavramlar eksik mi? "Sorgu topolojisi" gerçekten geliştirici deneyimi açısından üstün mü?

  • Sorgu topolojisine dair soru işaretleri: Eşzamanlılık, izolasyon ve kısıtlar gibi önemli kavramların eksik olduğu, ayrıca sorgu topolojisinin geliştirici deneyimi açısından gerçekten üstün olup olmadığı sorgulanıyor.

• Rama için ELI5'e ihtiyacım var. Dokümantasyon kafa karıştırıcı ve lütfen "paradigma değişimi" ya da "platform" gibi moda sözcükler kullanmayın.

  • Rama için basit açıklama talebi: Rama'nın kolay anlaşılır, net ve moda sözcüklerden arındırılmış bir açıklaması isteniyor.

• Event sourcing (+ materialized view'lar ve indeksler), RDBMS'yi terk etmek anlamına gelmez. İkisi birlikte kullanılabilir.

  • Event sourcing ve RDBMS'nin birlikte kullanımı: Event sourcing ile materialized view'lar RDBMS ile birlikte kullanılabilir; birbirini dışlayan yaklaşımlar değiller.

Arka plan bilgisi:

• Event Sourcing: Sistemin durum değişikliklerini olaylar olarak kaydedip, bunları yeniden oynatarak sistem durumunu yeniden kurmayı mümkün kılan tasarım kalıbı.
• Materialized Views: Veritabanı sorgu sonuçlarını fiziksel olarak saklayarak veri okuma performansını artıran teknik.
• RDBMS (Relational Database Management System): İlişkisel veritabanlarını yöneten sistem.