Veritabanları ve Karmaşıklıkları Artık Neden Gereksiz

 (blog.redplanetlabs.com)
2 puan yazan GN⁺ 2024-01-11 | 1 yorum | WhatsApp'ta paylaş
  • Backend karmaşıklığının nedeni, belirli bir ürünün kusurlarından çok, veritabanlarının uzun süredir koruduğu kavramsal yapının uygulama tasarımını kısıtlamaya devam etmesidir
  • Veritabanları global mutable state gibi davranır; sabit veri modeli, sınırlı şema, normalizasyon ile denormalizasyon arasındaki gerilimi geliştiricinin sırtına yükler
  • Önerilen alternatif, event sourcing ile materialized views’ı birleştirerek kaynak veriyi indeks görünümlerinden ayırmak ve indeksleri veri modeli değil, dayanıklı veri yapıları olarak ele almaktır
  • Red Planet Labs’in Rama’sı depots, ETL, PStates, query topologies ile veri alımı, işleme, indeksleme, sorgulama ile dağıtım ve izlemeyi tek platformda birleştirir
  • Twitter ölçeğinde Mastodon’un yeniden uygulanması örneğinde Rama’nın 10 bin satır ve 9 kişi-ay ile hayata geçirildiği; karşılaştırılan Twitter tüketici ürününün ise 1 milyon satır ve yaklaşık 200 kişi-yıl gerektirdiği belirtiliyor

Veritabanı karmaşıklığının çıkış noktası

  • Sorunun odağı, belirli veritabanı ürünlerinin API’leri, operasyonel zorlukları veya keyfi sınırlamaları değil; bugüne kadar varlığını sürdüren kolektif kavramsal yapıdır
  • Mevcut yaklaşımın sorunları, ancak daha iyi bir yöntem ortaya çıktığında netleşir; alternatif olarak event sourcing ile materialized views birleşimi öneriliyor

Global mutable state olarak veritabanı

  • Programcılara global değişken kullanımını en aza indirmeleri öğretilir, ancak veritabanları da özünde global mutable statetir
  • Veritabanlarının sıradan global değişkenlere göre yönetilmesi daha zor olan yönleri vardır
    • Etkileşimler birden fazla sisteme yayıldığı için state hakkında akıl yürütmek zordur
    • State dayanıklı olduğu için, hata düzeltilse bile bozulmuş veri otomatik olarak onarılmaz
    • Bozulmanın kapsamını doğru belirlemenin veya kusursuz biçimde düzeltmenin zor olduğu durumlar vardır
    • Yedeğe dönmek ya da yedeğin bir bölümünü birleştirmek en iyi çözüm değildir
  • Event sourcing ve materialized views kullanıldığında görünümler kaynak logdan yeniden hesaplanabilir; böylece bozulmuş indeks state’ini düzeltme imkânı doğar

Sabit veri modelinin sınırları

  • Veritabanları key/value, document, relational, column-oriented, graph gibi veri modelleri merkezinde tasarlanır
  • Tek bir veri modelinin tüm kullanım senaryolarını desteklemesi zor olduğundan, şirketler çoğu zaman birden fazla veritabanını birlikte kullanır
  • Daha genel indeks soyutlaması veri modeli değil, veri yapısıdır
    • Key/value: map
    • Document: map of maps
    • Relational: map of maps, secondary indexes ek map’lerdir
    • Column-oriented: map of sorted maps
  • Dayanıklı veri yapıları diskte saklanır, çok büyük boyutlara ulaşabilir ve iç içe veri yapılarını da ifade edebilir
  • İndeksler veri yapısı kombinasyonları olarak tanımlandığında, mevcut veri modellerinin yanı sıra çok daha çeşitli indeks biçimleri oluşturulabilir
  • Uygulama domain modelini veritabanına uydurmak için eğip bükmek yerine, depolama biçimini domain modeline uydurmak mümkün olursa temel karmaşıklık azalır

Normalizasyon ve denormalizasyon gerilimi

  • İlişkisel veritabanı kullanıcıları sonunda normalizasyon ile denormalizasyon arasında seçim yapmak zorunda kalır
  • Normalize depolama, net bir doğruluk kaynağı oluşturur ve tutarsızlık olasılığını azaltır; ancak join sayısı arttığı için sorgu maliyeti yükselebilir
  • Performans nedeniyle aynı bilgi birden fazla biçimde saklanırsa, hata olduğunda veri tutarsızlığı oluşabilir
  • RDBMS mimarisi, doğruluk kaynağı ile hızlı sorgular için indeks depolarını aynı datastore içinde birleştirir
  • Çözüm, bu iki rolü ayıran bir yapıdır
    • Bir alt sistem doğruluk kaynağını ifade eder
    • Diğer alt sistem, bu kaynaktan istenen sayıda indeks deposunu materialize eder
    • İkinci sistem kaynak veriden indeksleri yeniden hesaplayabiliyorsa tutarsızlıklar düzeltilebilir

Sınırlı şema ve domain ifadesi

  • Veritabanlarında saklanabilen değer türleri üründen ürüne büyük ölçüde değişir
    • Bazı veritabanları yalnızca byte array gibi blob’lara izin verir
    • Bazı veritabanları integer, floating-point, string, date gibi çeşitli tiplere izin verir
  • Domain nesnelerinin içindeki iç içe bilgileri doğrudan sorgulamak veya toplulaştırmak için birinci sınıf temsil olarak saklamak nadirdir
  • Veritabanının uygulama dili ile uygulama dilinin farklı olması birlikte çalışabilirliği zorlaştırır; Postgres için protobuf extension gibi eklentiler de zahmetli ve sınırlıdır
  • ORM, domain temsili ile veritabanı temsilini eşler; ancak soyutlama sızarak sorunlara yol açabilir
  • Veriyi ideal domain temsilinden farklı bir şekilde indekslemek gerekiyorsa adaptör kodu gerekir ve verimli biçimde çalıştırılabilecek sorgular da sınırlanabilir

Karmaşık dağıtım ve à la carte model

  • Eksiksiz bir backend yalnızca veritabanından oluşmaz; veritabanları, işleme sistemleri, izleme araçları, zamanlayıcılar gibi birçok aracın birlikte kullanılması gerekir
  • Büyük ölçekli backend’lerde onlarca aracı birleştirmek gerekebilir; uygulama güncellemeleri de migration, kod güncellemesi ve altyapı değişikliklerinin orkestrasyonuna dönüşür
  • Production’a hazır olmak için yeterli telemetri gerekir; ancak her aracın veri toplama yöntemi farklı olduğundan bunları tek bir izleme dashboard’unda birleştirmek de ayrı bir mühendislik problemi haline gelir
  • Günümüzde baskın geliştirme biçimi, mimarinin her parçası için en uygun aracı seçip ekleyen à la carte modele yakındır
  • Bağımsız tasarlanmış araçları birlikte çalışır hale getirmek başlı başına büyük bir iştir; sabit veri modelleri ve sınırlı şemalar nedeniyle araçları uygulamaya uydurmak yerine uygulama araçlara uydurulur
  • Backend kurulumu için tutarlı bir model olmadığı için à la carte model yerleşmiştir; tutarlı bir modelde soyutlama, otomasyon ve yeniden kullanım imkânı artar

Backend’e basit bir modelle bakmak

  • Backend’in ana işlevleri yeni veriyi almak ve bu veri hakkındaki soruları yanıtlamaktır
  • En genel sorgu, backend’in aldığı tüm veriler üzerinde bir fonksiyon çalıştırma biçiminde ifade edilebilir
    • query = function(all data)
  • Gerçekte veri kümesi 10PB olabilir ve sorgu yanıtının milisaniyeler içinde gelmesi gerekebilir; bu nedenle pratik sistemlerde indeks gerekir
  • İndeks eklenmiş model şöyle ifade edilir
    • indexes = function(data)
    • query = function(indexes)
  • Mevcut backend’ler bu modelin bileşenlerini çok sayıda dar kapsamlı araca bölerek uygular
    • RDBMS backend’leri veri ve indeksler için RDBMS kullanır; ek indeksleme için ElasticSearch gibi ayrı bir veritabanı da kullanılabilir
    • Hesaplama çoğu zaman API server handler’larında veya queue/worker tabanlı arka plan işlerinde yapılır
    • Büyük ölçekli backend’ler Cassandra, MongoDB, Neo4j, Kafka, Hadoop, Storm, Kafka Streams gibi araçları birleştirebilir
  • Tüm bileşenleri bütünleşik ve genel amaçlı biçimde uygulayan bir araç varsa, yukarıdaki karmaşıklıktan kaçınılabileceği sonucuna varılıyor

Rama’nın bileşenleri ve Mastodon örneği

  • Rama, bu ilkeler temel alınarak tasarlanmış bir backend geliştirme platformudur
  • Red Planet Labs, Rama’yı 15 Ağustos’ta “the 100x development platform” sloganıyla duyurdu
  • Maliyet azaltma örneği olarak Mastodon’u Twitter ölçeğinde yeniden uygulama çalışmasını gösteriyor
    • 100 milyon bot saniyede 3.500 gönderi paylaşıyor
    • Ortalama fanout 403
    • Twitter’ın eşdeğer tüketici ürününün 1 milyon satır ve yaklaşık 200 kişi-yıl gerektirdiği karşılaştırması yapılıyor
    • Rama uygulaması 10 bin satır ve 9 kişi-ay gerektirdi
    • Uygulama open-source ve complete, high-performance, production-ready olarak sunuluyor
  • Twitter’ın ölçeğe ulaşmak için social graph database, in-memory timeline database gibi özel veritabanlarını kendi geliştirdiği; yalnızca Puppet konfigürasyonunun 1 milyon satırdan fazla olduğu karmaşık bir dağıtıma sahip olduğu karşılaştırılıyor
  • Rama tabanlı uygulamanın, her alt problem için özel altyapıyı baştan geliştirmek yerine Rama’nın ilkel öğelerini birleştirerek benzer performans ve ölçeklenebilirlik sorunlarını çözdüğü söyleniyor
  • Mastodon uygulamasının performance numbers değerlerinin Twitter rakamlarıyla aynı ya da daha iyi olduğu belirtiliyor

Rama’nın programlama modeli

  • Rama’nın kavramları, yukarıda sunulan backend modeline doğrudan karşılık gelir
    • Depots: Keyfi verileri tutan dağıtık log’lardır ve dataya karşılık gelir
    • PStates: partitioned state kısaltmasıdır ve indekslere karşılık gelir
    • ETLs: function(data)ya karşılık gelir
    • Queries: function(indexes)a karşılık gelir
  • PStates, dayanıklı veri yapılarının keyfi kombinasyonları olarak ihtiyaç kadar oluşturulabilir
  • ETL ve query, Turing-complete dataflow API ile ifade edilir; hesaplama dağıtık olarak çalıştırılabilir
  • Rama, belgelerinde Java API eğitimleri sunar; ayrıca Clojure API de vardır

Rama’nın veritabanı karmaşıklığını azaltma biçimi

  • Rama’nın PStates’i veritabanına benzer bir rol oynar, ancak yalnızca ilgili PState’in sahibi olan ETL topology tarafından yazılabilir
    • Tüm yazmalar aynı ETL kodunda bulunduğu için state hakkında akıl yürütmek kolaylaşır
    • PStates, event sourcing log’u üzerinde materialized view olarak çalışır
    • Depot data doğruluk kaynağı olduğu için PState yeniden hesaplanabilir
  • Veri modeli kısıtları, PStates’in veri yapısı olarak tanımlanmasıyla ele alınır
    • Mastodon uygulaması yalnızca profiles, statuses, timelines için bile 33 PStates kullanır
    • Bazı PState’ler 10 kullanım senaryosunu, bazıları ise yalnızca tek bir kullanım senaryosunu destekler
  • PStates durable, partitioned, incrementally replicated özelliklerine sahiptir
    • incremental replication, leader partition arızasında takeover yapacak başka bir partition’ın hazır olduğu anlamına gelir
    • Mevcut leader’da görünenlerin daha sonra leader olacak partition’da da görülebileceği garanti edilir
  • Normalizasyon ve denormalizasyon sorunu depots ile PStates’in açık biçimde ayrılmasıyla ele alınır
  • Sınırlı şema sorunu, domain temsilinin aynen kullanılmasıyla hafifletilir

Dağıtım, entegrasyon ve izleme

  • Rama uygulamaları modules olarak adlandırılır; bir module birden fazla depots, ETLs, PStates ve query topologies içerebilir
  • Rama, module dağıtımı, güncellemesi ve ölçeklendirmesi için yerleşik mekanizmalar sağlar; her birinin terminalde one-liner ile yapıldığı söyleniyor
  • Rama “all or nothing” bir araç değil; diğer sistemlerle entegrasyonu kolay olacak şekilde tasarlandığından mevcut mimarilere kademeli olarak eklenebilir
  • Entegre bir platform olduğu için kendi izlemesini de yapar
    • İzleme verilerinin toplanması
    • İşlenmesi
    • İndekslenmesi
    • Görselleştirilmesi
  • cluster UI telemetry, module performansını anlamak, sorunları tespit ve teşhis etmek, ne zaman ölçekleneceğine karar vermek için kullanılır

Öğrenme ve benimseme yolu

İlgili okumalar

1 yorum

 
GN⁺ 2024-01-11
Hacker News yorumları

  • “Daha sonra açıklayacağım ama daha iyi yaklaşım event sourcing ve materialized view” denmiş; yani sonuçta çözüm karmaşıklığı artırmak mı? Elbette öyledir

    • Doğru yapılırsa backend mimarisini aksine büyük ölçüde basitleştirir. Düşük ölçekli uygulamalar bile genelde Postgres ve ElasticSearch gibi birden fazla veritabanı kullanır; arka plan işleri için kuyruk ve worker’lar da bulundurur.
      Bizim yaptığımız Twitter ölçeğinde Mastodon implementasyonu bunun doğrudan bir örneği. Twitter’ın aynı özellikleri ölçekli biçimde yapmak için yazması gereken koddan kelimenin tam anlamıyla 100 kat daha az, resmi Mastodon implementasyonundan da %40’tan fazla daha az kod. Aynı araçlarla ikinci kez yaptığımız için daha iyi tasarlamış değiliz; temelde daha iyi bir soyutlamayla yaptığımız için böyle
    • Karmaşıklık yok olmaz, yalnızca başka bir yere taşınır. Birçok işte bu çözümün ödünleri kötü olabilir.
      Ancak belirli bir ölçeği geçince her şey bir veri mühendisliği problemine dönüşür ve tüm sistem bağlamında bu yöntem görece basit bir çözüm hâline gelebilir. “Sadece mySQL/SQLite/Postgres kullanın” tavsiyesi, geçerliliğini yitirdiği ana kadar harikadır
    • Karmaşıklık daha mı artıyor? Yazar bunu son derece basit hâle getirmiş. Sadece kendi ürünü Rama’yı kullanmanız yeterli
    • Çalıştığım tüm şirketlerde event sourcing + materialized view aşırı karmaşaya, daha fazla hataya ve daha uzun kesintilere yol açtı. MySQL ya da PostGres veya Redis/DynamoDB gibi daha basit çözümlerin hepsi daha iyi çalıştı.
      Martin Fowler’ın orijinal event sourcing yazısı hiç yazılmamış olsaydı herkes için daha iyi olurdu diye içtenlikle inanıyorum. Vakaların %99’unda bunun kötü bir fikir olduğunu düşünüyorum
    • Programın domain’i doğası gereği X kadar karmaşıklık gerektiriyorsa, o karmaşıklığı bir şekilde uygulamanız gerekir. Bunu, zaten yazılmış ve sahada doğrulanmış başkalarının koduna bırakabilirsiniz ya da kendiniz yeniden yapabilirsiniz; ikincisi çok zaman alabilir ve sonuç da daha kötü olabilir. Bedava öğle yemeği yok

  • Bir şeyi kaçırmış olabilirim ama yazı eşzamanlılık, izolasyon, kısıtlar gibi kavramları tamamen atlamış görünüyor. Ayrıca “sorgu topolojisi” denen şey deklaratif de değil ve sorgu planlama/optimizasyon sorumluluğunu yazara yüklüyor gibi; gerçekten bunun daha iyi bir geliştirici deneyimi olduğunu mu düşünüyorlar?

    • Bu konular belgelerde yeterince ele alınıyor. Bu yazı backend geliştirmenin karmaşıklığı ve Rama’nın bunu nasıl ele aldığı hakkında; Rama’nın her yönünü eksiksiz açıklayan bir yazı değil. Hepsini açıklasa çok uzun olurdu. Rama’yı daha derin incelerseniz özelliklerinin ve garantilerinin çok güçlü olduğunu görebilirsiniz.
      Ve evet, Rama’nın sorgu biçimi çok daha üstün bir yaklaşım. Karmaşık bir sorgu planlayıcıya ihtiyaç duyulması çoğunlukla verinin indekslenme biçimindeki sınırlamalardan, özellikle de normalizasyon ile denormalizasyon arasındaki gerilimden kaynaklanır. Rama’da, sorguların ihtiyaç duyduğu biçimde zaten hazırlanmış birden fazla view’ı sağlam biçimde materialize etmek kolaydır.
      Rama kavramlarını yumuşak bir girişle tanıtan eğitim burada: https://redplanetlabs.com/docs/~/tutorial1.html

  • “Tek bir veri modelinin tüm kullanım senaryolarını destekleyemeyeceği” sözüne gelince, teorik olarak nesnelerin tuple’ları ve ilişkileriyle doğru biçimde modellenemeyecek bir alan ya da sonlu alan kümesi yoktur.
    Pratikte belirli bir veritabanının/şemanın kapsamı genellikle tek bir iş ya da problem alanıyla sınırlıdır; ancak türler uygunsuz biçimde çakışmadığı sürece bu da pek sorun olmaz. Yalnızca adlara dikkat ederseniz bir web perakendecisini ve bir sigorta şirketini aynı şemaya koysanız bile gayet çalışır.
    Her şeyi tam olarak tek bir veritabanına koymak süper güçtür. Bunu güçlü biçimde savunmamın en büyük nedeni, birden fazla veri deposuna yayılan dağıtık işlemlerden kaçınmaktır. Tüm iş tek bir işlem sistemi içinde gerçekleştiğinde semantik dramatik biçimde basitleşir.

    • “Her şeyi tek bir veritabanına koymak süper güçtür” sözüne özellikle katılıyorum.
      İnsanlar veriyi gerçekten kullanmaya başladığında, 1 milyon dolarlık büyük bir DB sunucusu, ucuz veritabanlarından oluşan yedekli bir diziden çok daha ucuzdur. Geliştirici, analist ya da yönetici fark etmez; herkes zamandan tasarruf eder, belki bazı DBA’ler bunun istisnası olabilir.
    • Büyük veritabanları yeni değil. Mesele yalnızca bundan ibaret olsaydı, insanlar son 40 yıldır sürekli bunu yapardı. Ama her zaman işe yaramadı; hatta bazen sık sık korkunç oldu.
      Teorik olarak her şey bundan ibaret olsa bile, bir başka kalıcı sorun uygulamadır. Günümüzde çoğu geliştirici veritabanlarının nasıl çalıştığını ve nasıl kullanılması gerektiğini iyi anlamadığı için onları berbat kullanıyor. Bu yüzden bu gerçekten kaçmak için NoSQL gibi yeni veritabanları yaptılar; daha az kafa yorup daha çok yapıştırıcı kod yazmaya çalıştılar. Bunun da korkunç sonuçlar verdiği ortaya çıktı.
      Çok geçmeden akış yeniden değişecek ve “yalnızca büyük tek bir veritabanı” yeniden moda olmaktan çıkacak; başka bir “basitlik” paradigması ortaya çıkacak. Mikroservislerde olduğu gibi, “tek büyük veritabanı” yerine “çok sayıda küçük veritabanı” basit kabul edilebilir. Tarihi anlamazsanız onu tekrarlamak zorunda kalırsınız.
    • Bir kullanım senaryosunun tuple’lar ve ilişkilerle modellenebileceğini söylemek, veritabanının o kullanım senaryosunun performans gereksinimlerini karşılayabileceği anlamına gelmez. Performans gereksinimleri karşılanamıyorsa o kullanım senaryosu desteklenmiyor demektir.
      Genel programlamada da tek bir veri yapısının ya da veri yapısı kombinasyonunun tüm kullanım senaryolarını destekleyememesiyle aynı şey. Bazen map gerekir, bazen liste, küme, kombinasyon ya da tamamen başka bir şey gerekir.
    • “Her şeyi tek bir veritabanına koymak süper güçtür” sözüne katılıyorum. Önceki şirketim, her uygulama için ayrı DB kullanan cargo-cult tarzı mikroservis düzenindeydi; iş açısından hiçbir fayda sağlamadan gereksiz biçimde karmaşık ve pahalı hale gelmişti. Elbette özgeçmiş doldurmak açısından bir faydası olmuştur. Mecburen gerekene kadar karmaşıklaştırmamak gerekir.
    • Kulağa rüya gibi gelen, gerçekten güzel bir fikir; ama gerçekte çalışmıyor. Bunu başaran biri var mı? Uç noktadan bakarsak, tüm dünyada tek bir birleşik veritabanına ve tek bir kullanıcı yetki sistemine ihtiyaç olduğu anlamına gelir.
      Elbette veri yapıları çeşitlidir, performans da gerekir; ayrıca sıradan insanların dokunamayacağı kadar kritik bir darboğaz haline gelir ve tüm değişikliklerin aşırı güvenli olması gerekir. Güvenlik de var. Birisi geliştirme hataları bölümünden HR ya da yöneticilere özel finans bölümüne geçmenin yolunu bulursa ne olur? Genel amaçlı bir ERM sistemi uygulamış olan herkes, birleşik bir sistemin ne kadar zor ve acılı olduğunu bilir.
      Ancak bu uç bir örnek. Bu ideale ulaşmaya çalışırken insanların nereye kadar gittiğini ve bunu nasıl yaptığını merak ediyorum. Tek bir sistemle işletilen bir iş hiç görmedim. Kişisel bilgi yönetim sistemleri nasıl? Her şey yerine oturuyor mu? Hızlı işler için hâlâ elektronik tablo, serbest biçimli şeyler için metin dosyası kullanmıyor muyuz?

  • Moda terimler toplamı gibi görünüyor. Dünyanın en büyük şirketlerinden birinde yıllardır veritabanlarıyla çalışıyorum ama topoloji kelimesini hiç duymadım.
    Bununla zaman tasarrufu sağlansa bile Java’yı ve bu framework’ü öğrenirken uçup gidecektir. Veritabanlarının kendisinde hiçbir sorun yok.

    • Eşdeğer bir işlevi Twitter ölçeğinde, Twitter’ın yazdığı koda kıyasla 100 kat daha az kodla yapan production-ready Mastodon implementasyonu olduğundan, “moda terimler toplamı” değerlendirmesine katılmak zor: https://github.com/redplanetlabs/twitter-scale-mastodon
    • Bana bu tür reklamlardan bir örnek gibi görünüyor.
      Burada metin tablosu yapmaya çalıştım ama sayfa gösterimi tamamen bozulduğu için ekran görüntüsü olarak yükledim: https://imgur.com/a/XtwSkyx

  • Rama’yı beş yaşındaki bir çocuğa anlatır gibi açıklasanız, nedir? Dokümantasyon da kafa karıştırıcıydı: https://redplanetlabs.com/docs/~/index.html
    “Paradigma değişimi” veya “platform” gibi moda sözcükleri çıkarırsanız iyi olur. Diyagram gerekiyorsa, daha net açıklayan bir yazı okumak isterim

    • Bir uygulamanın veri toplama, işleme, indeksleme ve sorgulama ihtiyaçlarını her ölçekte karşılayabilen bir backend geliştirme platformu. Backend’i birden fazla veritabanı, işleme sistemi, kuyruk ve zamanlayıcıyı birbirine karıştırarak kurmak yerine, Rama adlı tek bir platform içinde hepsini yapabilirsiniz.
      Rama bir küme olarak çalışır ve birden fazla uygulama bu kümeye “modül” biçiminde dağıtılır. Derin ve ayrıntılı telemetri de yerleşik olarak gelir.
      Rama’nın programlama modeli event sourcing ve materialized view’lardan oluşur. Bir Rama uygulaması oluştururken, ihtiyaç duyduğunuz kadar çok indeksi, istediğiniz biçimde, birden fazla kalıcı veri yapısı kombinasyonu olarak materialize edersiniz. İndeksler dağıtık veri akışı API’siyle materialize edilir.
      Rama mevcut şeylerden o kadar farklı ki, benim yapabileceğim üst düzey açıklama ancak bu kadar. Temelleri öğrenmek için en iyi kaynak rama-demo-gallery; içinde Rama’nın çeşitli kullanım senaryolarına uygulanmasını gösteren, kısa, baştan sona çalışan ve ayrıntılı yorumlanmış örnekler var. Hepsi ölçeklenebilir ve hata toleranslı: https://github.com/redplanetlabs/rama-demo-gallery
    • Benim okuduğum kadarıyla bu bir Kappa mimarisi, yani event sourcing’in bir varyasyonu.
      “Depot” adlı yalnızca ekleme yapılan bir event log’u var; bunun üzerinde keyfi view’lar oluşturuyorsunuz ve bunlara “P-States” deniyor. Rama yazılımı bu view’ların düşük gecikmeyle güncellenmesini vaat ediyor. Bunun üzerine kurulan uygulamalar view’ları sorguluyor ve Depot’a yeni event/komut gönderiyor.
    • Event sourcing veritabanına benziyor. Temelde doğrudan yazmak yerine mesaj yazıyorsunuz ve bu mesajlara göre güncellenen salt okunur tablolar oluşturabiliyorsunuz. Bazı alanlarda bunu bugün de yapıyoruz, ama geleneksel veritabanlarından kesinlikle daha karmaşık.
    • Bir başka NoSQL denemesi gibi görünüyor. “Ama bu sefer farklı!”

  • 1–10 TB ölçeğinde canlı event veri kümeleri üzerinde esnek bir materialized view motoru oluşturmak için bir yıllık bir proje yaptım; başka bir projeye geçmeden önce bizim mimarimiz de kabaca kodu indeksin bulunduğu yere gönderme fikrine yakınsamıştı.
    Rama bana epey cazip geliyor, ama tamamen irrasyonel bir nedenle JVM yüzünden benimsemeyecek gibiyim. Java/JVM’den hoşlanmıyorum, o kadar. Bu mimarinin başka ortamlara port edilmesini isterdim.

  • İş yerinde okuma modeliyle yazma modelini ayırıyoruz. Yazma modeli, yani hakikatin kaynağı, invariant’ları/kısıtları da olan geleneksel ilişkisel domain modeli ve ORM’e alışkın çoğu geliştirici için üzerinde akıl yürütmenin zor olmadığını düşünüyorum.
    Neredeyse tüm komutlar ayrıca event üretip ortak domain event kuyruğuna yayımlıyor. Okuma modelleri, event’leri tüketen worker’ların her birinin kendi ihtiyaç duyduğu şekilde view oluşturmasıyla ortaya çıkıyor ve yeniden oluşturulabiliyor. Örneğin kullanıcı yönetimi servisi hakikatin kaynağı; diğer servisler ise karmaşık bir UI göstermek için kullanıcı servisi ve diğer servislerden gelen event’lere dayanarak kendi okuma modellerini/indekslerini oluşturan view servisleri. Bu olmasaydı devasa join’ler ya da servisler arası yavaş API çağrıları gerekirdi.
    Teknik olarak event’leri yeniden oynatmak mümkün. Hatta platform kodundaki bir hata yüzünden son 3 yılın tüm event’lerini yeniden oynattığımız da oldu. Ama buna gerçekten ihtiyaç duyduğumuz neredeyse hiç olmadı diye düşünüyorum. Hatalar yüzünden view’ları yeniden oluşturmamız gerektiği oluyor, ama bunu genelde özel script’ler veya SQL migration’ları gibi geçici programlarla hallediyoruz. Mimarimizin adının tam olarak ne olduğunu bilmiyorum ve kimsenin buna “event sourcing” dediğini duymadım.
    Sonuçta eski usul MySQL + RabbitMQ ve biraz glue code. Yine de doğru yapmak için transaction outbox, en az bir kez teslim garantisi, eventual consistency, doğru event işleme sırasını koruma, event verilerini toplu işleme, DB yönetimi, event handler öldüğünde ne yapılacağı gibi konular yüzünden çok da basit değil. Zaten pratikte kendini kanıtlamış, dilden bağımsız bir düzenek ve hem PHP hem Go producer/consumer’larımız varken, Rama olmadan neyi kaçırdığımızı ve Rama’nın yukarıdaki listedeki sorunları nasıl çözdüğünü merak ediyorum. Rama daha çok Java tarafına göre ayarlanmış gibi görünüyor.

    • RDBMS kullanırken karmaşıklığı yönetmek için harika bir yol mühendislik etmişsiniz gibi görünüyor. Rama’nın bunun üzerine sunduğu birkaç şey var.
      Rama’nın indeksleri çok daha esnek. Örneğin 100 milyon elemanlı iç içe bir kümeye ihtiyacınız olsa bile bu basit. Kullanıcı ID’si → takipçi ID’leri kümesi gibi sosyal grafik indeksleri yaygın bir örnek. Parçacıklılığa göre bölünmüş zaman serisi indeksleri, yani entity → parçacıklılık → zaman bucket’ı → istatistik de aynı şekilde kolay.
      Rama’da saklanabilen veri tiplerinde sınırlama yok. Rama sorguları çok güçlüdür; indekslerin bir kısmı veya tamamı üzerinde gerçek zamanlı, isteğe bağlı dağıtık sorgular yapmak kolaydır. Uygulama genelinde derin ve ayrıntılı telemetri de yerleşiktir; ayrıca oluşturmanız veya yönetmeniz gerekmez.
      Dağıtım da yerleşik. Mevcut yönteminizde uygulama güncellemeleri worker kodu, şema migration’ı gibi birden fazla sisteme yayılabilir ve özellikle kesintisizlik istiyorsanız oldukça zor bir mühendislik işine dönüşebilir. Rama hesaplama ve depolamayı uçtan uca entegre ettiği için uygulama yayınlamak, güncellemek ve ölçeklemek tek satırlık bir terminal komutuyla yapılabilir.
      Rama çok daha ölçeklenebilir. Bu, özellik perspektifinden Rama; Rama ile kod yazarken impedance mismatch olmamasının ne kadar büyük fark yarattığını ise kelimelerle anlatmak zor, kullanıp görmek gerekir. Rama JVM içindir, dolayısıyla herhangi bir JVM diliyle kullanılabilir ve şu anda Java ile Clojure API’leri sunar.
    • “Müşteri adresini güncelle” gibi bir komutta SQL çalıştırıldıktan sonra RDBMS trigger’ı mı RabbitMQ’ya event gönderiyor, yoksa ORM SQL’i gönderip RabbitMQ’ya mı publish ediyor?
      Event’ler nerede ve hangi formatta saklanıyor? Daha ayrıntılı duymak isterim.
      Şu an eksik olan şey, tüm ekosisteme takılacak havalı bir isim gibi görünüyor.

  • Değişiklik anında veriyi somutlaştırmak, ürünün tek bir işi çok hızlı yapması gerektiğinde avantaj sağlayabilir. Ancak atomik yazmalarla birlikte güncellenmesi gereken karmaşık işlemler ortaya çıktığında ya da veriyi farklı bir şekilde düzenlemeyi gerektiren yeni bir özellik eklemek istediğiniz anda işler zorlaşır.
    Uygulama geliştirme kısmında “sadece bir indeks eklemek yeter” der gibi bunun hafife alınması da son derece tatmin edici değil. İndeks küresel durumdur; yalnızca bir katman aşağı taşınmıştır

    • “Yalnızca bir katman aşağı taşındığı” için, kritik olarak artık onu doğrudan yönetmeniz gerekmez. Yapmanız gereken tek şey sisteme neyin indeksleneceğini söylemektir. Bu durum ya da veri değil, koddur

  • Bu belgeyi okuduğumda hedef kitlenin kim olduğu ve neyi çözmeye çalıştığı net değil: https://redplanetlabs.com/docs/~/why-use-rama.html#gsc.tab=0
    Gerçek bir örnek alıp, RAMA ile bunun ne kadar kolay ve verimli olduğunu dönüştürerek göstermek faydalı olurdu

    • Çok sayıda örnek yayımladık.
      İlki Twitter ölçeğinde Mastodon uygulaması; aynı şeyi ölçekli şekilde yapmak için Twitter’ın yazdığı koddan 100 kat daha az kod içeriyor. Bu yalnızca tüketici ürünü kısmı için geçerli. Ölçeklenebilir olmayan resmi Mastodon uygulamasından bile %40’tan fazla daha az kod içeriyor: https://github.com/redplanetlabs/twitter-scale-mastodon
      rama-demo-gallery deposunda da Rama’nın çok farklı kullanım senaryolarına uygulandığı kısa, bağımsız ve ayrıntılı yorum satırlarıyla açıklanmış birçok örnek var. Kullanıcı profili yönetimi, zaman serisi analizi, atomik ve hataya dayanıklı banka havaleleri gibi örnekler içeriyor: https://github.com/redplanetlabs/rama-demo-gallery

  • Gerçekten günlük 40 milyon kullanıcılı bir web sitesi işletmiyorsanız, “Twitter ölçeğinde Mastodon istemcisi” ile bunun kanıtlandığını iddia edebilecek gibi görünmüyorsunuz. Gerçek ortamı, buna bağlı kod ve altyapı değişikliklerini, gerçek kullanıcıları, ağ kullanımını vb. simüle etmek imkânsız