TigerBeetle dünyadaki en ilginç veritabanı

(amplifypartners.com)

23 puan yazan GN⁺ 2025-10-02 | 6 yorum | WhatsApp'ta paylaş

Finansal işlem veritabanı TigerBeetle, borç (debit) ve alacak (credit) işlemlerini yerel olarak destekleyen yeni bir veritabanı; mevcut SQL veritabanlarının tek bir işlem için 10-20 sorgu gerektirmesine karşılık tek bir round trip içinde 8.190 işlemi işleyebiliyor
Pek çok sistem hızlı kod yazımı ve bağımlılıkların büyümesini seçerken, bu proje kodu yavaş yazmak, deterministic simulation testing (DST) ve zero dependency gibi sağduyuya aykırı stratejilerde ısrar ediyor
Tek düğümlü mimariye dayanan geleneksel OLTP veritabanlarından ayrışarak, tasarımına dağıtık varsayılan, saat arızası toleransı (cluster time) ve depolama arızası toleransını yerleştirmiş; Viewstamped Replication ve Zig seçimiyle uygulama sadeliği ve görünürlüğü sağlamış
NASA'nın Power of Ten'inden ilham alan TigerStyle metodolojisini uygulayarak, fonksiyon başına ortalama 2'den fazla assertion kullanımı, statik bellek tahsisinin zorunlu tutulması ve assertion'ların üretim ortamında da etkin olması gibi sıkı kodlama standartlarına uyuyor
Gerçek zamanlı ödeme, oyun ve enerji faturalandırması gibi hiper-işlemsel çağa uygun bir yapıyla, yeni nesil OLTP için performans ve doğruluk ölçütü ortaya koyuyor ve 20-30 yıllık SQL veritabanlarının yerini alabilecek yeni nesil bir işlem işleme sistemi olarak öne çıkıyor

Borç/alacak merkezli veritabanına neden ihtiyaç var?

TigerBeetle, borç (debit) ve alacağı çekirdek primitive'ler olarak kullanan bir "finansal işlem veritabanı"
- Jim Gray'in 1985'te tanımladığı işlem kavramının özü, SQL transaction değil iş işlemi (borç/alacak) idi
- Gray, 20 yıl sonra da standart transaction processing'i "DebitCredit" olarak tanımladı: banka hesabından borç düş, çift taraflı muhasebe kaydı yap ve ardından terminale yanıt ver
- Borç/alacak yalnızca muhasebe ya da bankacılık için değil, işlemin özünü ifade eden ortak dil; ACID benzeri güvencelerin de nedeni bu
Mevcut SQL veritabanlarında borç/alacak uygularken ortaya çıkan sorunlar
- Tek bir borç/alacak işlemi için hesap bakiyesi sorgulama, satır kilitleme, kod içinde karar bekleme, borç/alacak kaydı yazma gibi 10-20 SQL sorgusu gerekiyor
- Ağ gidiş-dönüş süresi boyunca satır kilidini tutmak gerekiyor; pek çok işlemin aynı "house account"a erişmesi de sıcak satır sorununu büyütüyor
- Hindistan ve Brezilya'da aylık on milyarlarca anlık ödeme, ABD'de FedNow, enerji/oyun/bulutta gerçek zamanlı faturalandırma gibi gelişmelerle dünya 10 yıl içinde en az üç basamaklı oranda daha işlem odaklı hale geldi; ama bugün kullanılan SQL veritabanları 20-30 yıllık teknoloji
TigerBeetle'ün farklılaştığı noktalar
- Borç/alacağı birinci sınıf primitive olarak tasarlayarak tek bir 1MiB sorguda 8.190 işlemi tek bir round trip ile işliyor
- Kurucu Joran buna "1000x performans fikri" diyor ama bunu "özel bir şey değil" diye anlatıyor
- Normalde bir veritabanını inşa etmek 10 yıl sürerken, TigerBeetle 3,5 yılda tamamlandı ve Jepsen testlerini geçti
- Haziran 2025'te Kyle Kingsbury, tüm makinelerde çeşitli konumları bozmasına rağmen TigerBeetle'ün temelini kıramadı (yalnızca dayanıklılığı etkilemeyen read query engine'de 1 doğruluk hatası bulundu)

Modern veritabanı tasarımı

Varsayılan dağıtık mimari

Postgres ve MySQL'in geliştirildiği dönemde tek düğüm paradigması baskındı; bugün ise paylaşımlı bulut donanımı çağında dağıtık paradigma ana akım
- Modern veritabanlarının katı serializability sunması ve makineler arası işlemleri çoğaltarak yedeklilik, hata toleransı ve yüksek erişilebilirlik sağlaması gerekiyor
- Günümüzde en popüler OLTP veritabanlarından bazıları hâlâ büyük ölçüde tek düğümlü mimariye dayanıyor; bazılarında otomatik failover varsayılan olarak yerleşik değil
TigerBeetle'ün dağıtık tasarımı
- Varsayılan olarak dağıtık olacak şekilde inşa edilmiş; kümedeki istediğiniz sayıda makineye yalnızca binary'yi kurmanız yeterli
- Asenkron replikasyon, Zookeeper vb. gerekmiyor; bunun yerine MIT'nin öncü Viewstamped Replication uzlaşma protokolünün uygulanmasına yatırım yapılmış
- Zig toolchain'i dışında zero dependency korunuyor ve tüm çekirdek bağımlılıklara doğrudan yatırım yapılıyor

Saat arızası toleransı

TigerBeetle bir işlem veritabanı olarak, denetim ve regülasyon uyumluluğu için fiziksel zaman damgalarının doğruluğuna önem veriyor
- Linux'ta birden fazla saat var: CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC, CLOCK_BOOTTIME
- Donanım saatlerinin fiziksel kusurları nedeniyle saatler farklı hızlarda çalışabiliyor ve "drift" hatası oluşuyor; bu da kısa sürede birikerek "skew" hatasına dönüşüyor
- Normalde NTP bu hataları düzeltir; ancak kısmi ağ arızalarında NTP sessizce durursa, yüksek erişilebilirlikli uzlaşma kümesi karanlıkta çalışabilir
Cluster time uygulaması
- Kümedeki çoğunluğun saatlerini birleştirerek hata toleranslı bir saat olan "cluster time" oluşturuyor
- Gerekirse sunucunun sistem saatini yeniden hizalıyor; kusurlu saat sayısı çok fazlaysa güvenli biçimde kapanıyor
- Chrony, PTP ve NTP'nin gerçekten çalışmayı bıraktığını tespit edip operatörü uyarıyor
- Sunucular arası ofsetli saat zamanlarını izleyip örnekliyor, ardından Marzullo algoritması ile en doğru aralık tahminini çıkarıyor

Depolama arızalarının ele alınması

Geleneksel veritabanlarının varsayımı
- Disk arızası olduğunda sistemin hata mesajıyla birlikte öngörülebilir şekilde başarısız olacağını varsayar
- SQLite belgeleri: "SQLite, bozulma veya I/O hatası tespiti için veritabanı dosyasına yedeklilik eklemez ve okunan verinin daha önce yazılan veriyle tam olarak aynı olduğunu varsayar"
Gerçek depolama arızası senaryoları
- Disk sessizce bozuk veri döndürebilir, I/O yanlış yöne iletilebilir (okuma/yazma yolu) ya da hata kodu üretmeden aniden yavaşlayan gray failure yaşanabilir
TigerBeetle'ün depolama arızası toleransı
- Protocol Aware Recovery kullanarak, tüm kopyalardaki veri kopyaları bozulmadığı sürece erişilebilirliği koruyor
- Tüm veriler değişmez; checksum ve hash chain ile bozulma ya da kurcalama olmadığını güçlü biçimde garanti ediyor
- Kendi page cache'ini kullanması, veriyi O_DIRECT ile diske yazması ve doğrudan ham block device üzerinde çalışabilmesi (dosya sistemi gerekmemesi) sayesinde disk ile yazılım arasındaki katmanları en aza indiriyor
- Hazır LSM yerine kendi geliştirdiği LSM Forest'ı (yaklaşık 20 LSM ağacı) kullanıyor
- Yalnızca depolama arızası toleransı iddia etmekle kalmayıp, Jepsen tarafından doğrulanan tek dağıtık veritabanı
- Yerel makine arızasında yalnızca disk sektörü bozulsa bile depolama motoru global uzlaşmaya bağlı olduğu için küme üzerinden kendini iyileştirebiliyor

Neden Zig programlama dili seçildi?

Mevcut veritabanlarının dili
- Postgres C ile (1970'ler), MySQL C ve C++ ile (1979), MSSQL de C ve C++ ile yazıldı
- Programlama dilleri son 40 yılda büyük ölçüde gelişti; bugün sıfırdan kurulsa Rust ya da Zig seçmek mümkün
TigerBeetle'ün Zig'i seçme nedenleri
- Tüm C ekosisteminden yararlanabilmesi, güçlü bir toolchain ve compiler sunması
- Yazması kolay ve özellikle okuması kolay; bazı durumlarda TypeScript kadar kolay ama çok daha hızlı
- Statik bellek tahsisi mümkün; bu, TigerBeetle'ün temel ilkelerinden biri
- İyi bir developer experience sunuyor, hızlı öğrenilebiliyor (bu sayede TigerBeetle kaynak koduna hızlıca girilebiliyor)
- İlk Rust ekip üyelerinden Matklad (Rust Analyzer'ın yaratıcısı) ve Brian Anderson (Graydon ile birlikte Rust'ın ortak yaratıcısı) gibi isimler TigerBeetle'de çalıştı
- Rust'ta dinamik bellek tahsisi kullanmamak "hard mode" iken Zig'de bu daha kolay

Deterministic Simulation Testing ve VOPR

DST'nin temel kavramı

Deterministic Simulation Testing (DST), FoundationDB ekibinin (şimdi Apple'a ait) yaygınlaştırdığı yenilikçi bir test yaklaşımı
- Daha güvenli ve hatasız dağıtık veritabanlarını eskisine göre daha kısa sürede geliştirmek için kullanılıyor
- Dağıtık sistemlerde sonsuz sayıda eşzamanlılık problemi kombinasyonu var: mesaj kaybı, öngörülemeyen thread çalışma sırası vb.
- Klasik birim testleri ve entegrasyon testleri yetersiz kalıyor; formal verification ise pahalı ve yavaş
DST nasıl çalışır?
- Belirli bir zaman çizelgesinde sistemin karşılaşabileceği neredeyse tüm olası senaryoları deterministik olarak çalıştıran bir simülatör
- OS, ağ, disk sorunları ve çeşitli gecikmeler gibi dış etkenleri de hesaba katıyor
- Kısa sürede yıllara denk test sağlıyor (zamanın kendisi de deterministik olduğu için while true döngüleri mümkün)
- Özellikle veritabanları için uygun; çünkü bunlar I/O yoğun, hesaplama yoğun değil
- Jepsen testleri, DST'nin yapabildiklerinin bir alt kümesi

TigerBeetle'ün VOPR sistemi

VOPR (Viewstamped Operation Replicator) genel bakış
- Adını WarGames filmindeki WOPR simülatöründen alan, şirket içinde geliştirilmiş bir test kümesi
- Düğümlerin lider seçmesinden tekil durum ve ağ arızalarına kadar sayısız farklı koşul altında TigerBeetle'ü sürekli test ediyor
- Tek bir thread üzerinde tüm dağıtık kümeyi sanal olarak simüle edebiliyor
VOPR'nin ölçeği
- Dünyadaki en büyük DST kümesi olarak 1.000 CPU çekirdeğinde çalışıyor
- Ölçeği o kadar sıra dışı ki Hetzner, gerçekten bu kadar çok çekirdek isteyip istemediklerini soran özel bir e-posta göndermiş
- VOPR-1000, üretim öncesinde olabildiğince nadir koşulları yakalamak için 24x7x365 çalışıyor
- Simülatörde zaman deterministik olarak soyutlandığı ve yaklaşık 700 kat hızlandırıldığı için, günde yaklaşık 2.000 yıllık simülasyon çalışma süresi birikiyor

DST'nin oyunlaştırılması

TigerBeetle, DST'yi bir oyuna dönüştürerek sistem tepkileri içinde farklı arıza senaryolarını oynanabilir hale getiriyor
- Oyun sim.tigerbeetle.com adresinde oynanabiliyor
- Tarayıcıda gerçek bir VOPR örneği çalıştırılarak TigerBeetle simülasyonu yapılıyor
- WebAssembly'ye derlenmiş durumda; TigerBeetle mühendisleri gerçek sistemi görselleştirmek için oyun ön yüzünü inşa etmiş

TigerStyle ve Power of Ten

TigerStyle metodolojisi

TigerStyle, TigerBeetle'ün mühendislik metodolojisi ve GitHub'da açık olarak yayımlanmış
- "Mühendislik ve sanatın, sayı ve insan sezgisinin, akıl ve deneyimin, birinci ilkeler ve bilginin, kesinlik ve şiirin kesişiminde evrilen kolektif bir alışveriş"
- Tron: Legacy filmindeki "Biodigital Jazz" kavramını benimsiyor: insan ile dijital unsurların iç içe geçmesi, "Grid"in kaotik ama yapılandırılmış doğası ve teknoloji içinde insan potansiyelinin doğaçlamacı ruhla ifadesi
- TigerBeetle'de koda yalnızca bilim değil, sanat da enjekte eden bir ruh var
TigerStyle'ın etkisi
- NASA'nın kusursuz kod yazımı ilkeleri olan Power of Ten'den türetilmiş mühendislik ve kod ilkeleri sunuyor
- Sadelik ve zarafet gibi temalardan isimlendirme yöntemleri gibi uygulamalara kadar uzanıyor
- Resonate ve Turso gibi başka şirketleri de etkilemeye başlamış durumda
- Lex Fridman podcast'inde de ele alındı

Assertion kullanımı

Power of Ten'in 5. kuralı: Assertion
- Kodun davranışına ilişkin beklentiyi yazarken aynı anda açıkça kodlama fikri (sonradan değil)
- Tek satırda boolean olarak yazılır: assert(a > b)
TigerStyle'ın assertion kuralları
- Tüm fonksiyon argümanlarını, dönüş değerlerini, önkoşulları ve değişmezleri assert et; fonksiyon başına ortalama en az 2 assertion
- Assertion önemli ve şaşırtıcıysa yorum yerine assertion kullan
- Program çalışmadan önce tasarım bütünlüğünü doğrulamak için compile-time sabitler arasındaki ilişkileri assert et
- Yalnızca olması gerekeni değil, beklenmeyen negatif alanı da assert et; çünkü ilginç hatalar orada ortaya çıkabilir

Performans üzerine düşünme

Kod yazmaktan çok kod üzerine akıl yürütme ve tasarım daha önemli
- Performans sorununu çözüp devasa 1000x kazanımı elde etmek için en doğru zaman tasarım aşaması; ama bu, ölçüm ya da profiling yapılamayan tam nokta
TigerStyle'ın performans ilkeleri
- "Dört temel renk" (ağ, depolama, bellek, CPU) ve "iki doku" (bant genişliği ve gecikme) için temel peçete matematiği yapılmasını öneriyor
- Kontrol düzlemi ile veri düzlemini ayırma, erişimleri batch'leme, hot loop'ları bağımsız fonksiyonlara çıkararak compiler bağımlılıklarını azaltma gibi taktik ipuçları sunuyor

Doğrudan deneyin

TigerBeetle, modern araştırmayı eski bir problem alanına uygulayarak benzeri görülmemiş performans ve güvenilirlik garantileri sunuyor
Yerel borç/alacak modellemesi, varsayılan dağıtıklık, depolama ve saat arızası toleransı ile DST tabanlı kalite güvencesini birleştiren modern bir OLTP motoru
Sistem ve depolama mühendisliğini bir sanat biçimi olarak geliştirirken, süreç içinde eğlenmeyi de unutmuyor
DST'nin akıllıca kullanımı sayesinde yalnızca birkaç yıl içinde Jepsen standardında bir sistem inşa etti
Kurulum tek bir binary ile basit; resmî sitedeki basit kurulum script'i sayesinde yalnızca bir curl komutuyla hızlıca başlayıp deneyebilirsiniz

6 yorum

happing94 2025-10-03

Dağıtık bir düğümün neden veritabanı kullanmayacağını düşünürsen, postgres'in neden tek düğümlü olduğunu anlayabilirsin
Performanstan daha önemli olan şeyin ne olduğunu düşün

GN⁺ 2025-10-02

Hacker News yorumu

TigerBeetle harika olsa da, bu yazının TigerBeetle’a yatırım yapmış bir yatırımcı tarafından yazıldığını bilmekte fayda var ilgili bağlantı
- Önümüzdeki aylarda benim yazdığım bu tür gönderiler çıkmaya devam edecek, insanların daha aktif tartışmasını isterim; üste bir feragat notu eklemenin daha iyi olup olmayacağını merak ediyorum, eklemesi zor değil
- Söz konusu yazı yatırım şirketinin sitesinde açıkça “Portfolio Spotlight” olarak yayımlanmış, bu yüzden beklentiyi buna göre ayarlamak gerekir
- Yazının kaleme alınış biçimi hakkında özellikle bir şey söylemeyeceğim ama bunun bir yatırımcı yazısı olduğu çok kolay anlaşılıyor
TigerBeetle’ın doğruluğa yaklaşımının, kodlama pratiklerinin ve hiper uzmanlaşmış yönünün hayranıyım, ama gönderideki bazı noktaları eleştirmek istiyorum
- Multi-node ile ilgili açıklama biraz yanıltıcı. Cloud-native insanların ne dediğinden bağımsız olarak, iyi ayarlanmış tek bir DB ve bir connection pooler ile bile muazzam QPS kaldırılabilir. Eski şirketimde bakım sırasında yanlışlıkla tüm trafiği tek bir MySQL 8 RDS instance’ına yönlendirdiğimizde bile 80–90K QPS’i zorlanmadan kaldırıyordu. Instance da büyük değildi; sadece şema, sorgular ve ProxySQL/MySQL ayarları iyiydi. Pik zamanda writer ve iki read replica ile 120K QPS de rahatlıkla gidiyordu
- Sunucuda node-local NVMe kullanıyorsanız, önce CPU sınırına çarpma ihtimaliniz daha yüksek
- Yedeklilik meselesinde, ağ ortamına göre tasarlanmış RDBMS’ler sonuçta failover ve hot standby özelliklerine sahip oluyor
- TigerBeetle’ın consensus sistemi akıllıca ve harici bağımlılıkları yok, ancak büyük row’ları işlemeye çalışmıyor. Eğer tek seferde 1MiB paketlerle binlerce transaction işliyorsanız, geleneksel RDBMS’lerde yapılamayan şeyleri mümkün kılabilir
- Bu eleştiriler onların başarısını küçümsemek için değil; bu üründen hâlâ fazlasıyla etkileniyorum
  - Consensus protokolünün sınırına işaret etmek zaten tam da ana nokta. TigerBeetle, yalnızca transaction odaklı işleri ayırıp işlemek istiyor; tüm OLGP db’lerin yerini almak gibi bir hedefi yok. Amaç, kritik verileri ayrı bir transaction DB’sine taşımak. Benzer bir yaklaşım TurboPuffer tarafında da görülebilir
  - Modern RDBMS’lerin yeterince hızlı olduğu doğru, ama TigerBeetle’ın kullanım senaryosu yüksek contention içeren özel bir ortam. Gerçekten de birden fazla transaction aynı hesabı etkilediğinde küme genelindeki throughput’un dramatik biçimde düştüğünü testlerde bizzat gösterdiler. (Bkz: ilgili HN yorumu)
Joran ve ekibin DST, dağıtık sistem farkındalığı ve performans testleri konusundaki çalışmalarını gerçekten seviyorum; özellikle bağımlılıkları en aza indirme takıntıları etkileyici (gerçi OS’i de bir bağımlılık olarak görmek mümkün olabilir)
- Ama genel OLTP’yi (ekibin OLGP dediği şeyi) ele alış biçimlerinin her zaman biraz haksız olduğunu hissediyorum. Örneğin, finansal transaction’larda sadece row lock kullanan düşük performanslı SQL transaction örnekleriyle kıyas yapıp sanki herkes 50 yıl önceki OLTP tasarımını kullanıyormuş gibi anlatıyorlar
- Resmî performans sayfasında contention en fazla %1’e kadar düşürülebiliyor. Stripe gibi bir yerde OLTP DB’de contention’ın %1 olduğunu düşünmüyorum
- Contention’ı öngören, zarif biçimde yöneten ve aşırı transaction throughput’u sağlayan sistemler kurulabilir. Bu sistemler DB’yi contention’dan koruyarak ölçeklenmeye devam etmesini sağlar. Gerçekte büyük ödeme sistemlerinin throughput rakamları resmî benchmark’takinden çok daha yüksek
- Pazarlama dili bunları büyük ölçüde görmezden geliyor ve tüm geliştiricileri kötü transaction’lar atan acemiler gibi gösteriyor; oysa çoğu çok daha zeki mühendisler. Ödeme sektöründe 'payments engineer' diye bir rol bile var
- TigerBeetle müthiş, ama diğer OLTP sistemlerini yanlış anlamaya yönelten bu pazarlama kalıbı beni rahatsız ediyor
  - Övgü için teşekkürler
    - OLTP iş yüklerinin gerçekten %0 contention olduğunu söylemenin daha doğru olduğunu mu düşünüyorsunuz, merak ettim. Müşterilerimiz arasında farklı ülkelerden büyük aracı kurumlar, varlık yöneticileri ve borsalardan gelen, Postgres ile onlarca yıl çalışmış uzmanlar var. Mühendisler stored procedure gibi şeyleri elbette biliyor, ama eşzamanlılıkla ilgili problemler daha derinde, storage engine seviyesine kadar iniyor. OLTP contention gerçekten ölümcül
    - DBMS dışı ölçekleme ve karmaşık reconciliation system sorunlarından bıktık; öyle ki bu yüzden Chief Architect’ler TB odaklı startup’lar kuracak noktaya geldi
    - Vurgulamak istediğimiz mesaj, contention ve Amdahl’s Law gibi somut meseleleri görünür kılmak
  - Stripe’ın OLTP DB’sinde contention’ın %1 olmadığı söylenmiş ama Stripe, MongoDB tabanlı. Bunu bir RDBMS ile kıyaslamak elma ile armudu kıyaslamak gibi
  - Alttaki OS’in bağımlılık sayılıp sayılmayacağı konusunda, tamamen in-memory çalışan ve kexec sırasında bile kalıcılığını koruyan sistemlerle uğraşmışlığım var. Syscall bile yapılamayan durumda OS de gayet bir bağımlılık olabilir
  - Lock tabanlı transaction’lar ile commit anında koşul kontrolü yapan optimize yaklaşım arasında örnek verebilir misiniz, merak ettim
TigerBeetle’ı değerlendirdik ama aşağıdaki engeller vardı
- Cloudflare Workers kullanıyoruz ve TigerBeetle istemci uygulaması bunu desteklemiyor. sorun bağlantısı Cloudflare Containers ile belki mümkün olabilir ama bizim iş akışımız Workers merkezli
- Auth özelliği yok. Sunucuda (VPS vb.) yalnızca IP kısıtlama yapılabiliyor, ama serverless ortamda sabit IP yok ilgili sorun
  - IP’yi ECC anahtarıyla doğrulayan Wireguard yaklaşımı da bir çözüm olabilir
  - Aslında Cloudflare Workers ya da AWS Lambda ortamında 1000 worker’ın hepsi DB’ye connection açarsa sorun çıkar. Bu yüzden genelde DB’nin önüne bir proxy veya servis katmanı koyarak çözülür. Proxy DB’ye nasıl erişeceğini bildiği için, özel ağ içinde auth sorununu dert etmez
  - TigerBeetle çözüm ekibiyle görüşürseniz, end-to-end şifreleme üzerinden mantıksal düzeyde auth gibi özel çözümler önerebilirler
  - 2025 yılında auth özelliği olmayan bir DB olması inanılır gibi değil. Finansal bir DB ise en azından auth proxy/katman ekleme yöntemiyle ilgili bir rehber sitelerinde olmalı. HTTP kullanmıyorsa (dokümantasyondan net anlaşılmıyor), insanlar HTTP olmadan auth proxy’yi nasıl ekleyeceklerini de merak edecektir. Bu hâliyle internete açık bırakmak çok tehlikeli olur
“10 yılda transaction hacmi 1000 kattan fazla arttı ama kullanılan DB 20–30 yıllık SQL. Buna dayanabilir mi?” sorusu vardı; bence evet
- 30 yıllık yazılım olsa bile sürekli güncellendi ve zamanında sağlam temeller üzerine kuruldu
  - Joran (TigerBeetle) burada. Genel iş yüklerinde sorun yok ama transaction işlemede power law contention nedeniyle SQL row lock sorunları ortaya çıkıyor (Amdahl's Law’a bakın). Teorik azami performans sınırını hesaplayabileceğiniz bir contention calculator’ı sitemize koyduk, bakabilirsiniz contention calculator
  - DNS’in de 1983’te yayımlanmasına rağmen hâlâ internetin temel taşlarından biri olduğunu düşünürsek, temeli iyi atılmışsa 30 yılı aşkın sistemler gayet dayanabilir. SQL çoğu iş yükü için yeterince iyi
  - Yeni ve şık teknolojilerin, her zaman eski ama denenmiş ve doğrulanmış teknolojilerden daha iyi olacağı diye bir kural yok. Bazen yazılım mühendisleri sektördeki en “hafızasız” mühendisler gibi geliyor
  - Dağıtık sistemlerle onlarca DB’yi yönetirken dağıtık transaction’lar (Sagas vb.) gerçekten gerekli. Tek makine senaryosunda ise ilişkisel DB hâlâ çok iyi
  - Eski donanımda performans yetersizdi ama bugün teknoloji ilerlediği için artık daha hızlı ve daha iyi çalışıyor
FoundationDB ile ilgili olarak da TigerBeetle tartışmalarıyla oldukça fazla ortak nokta var
- Kod yazımı yavaş, DST, bağımlılıksız yaklaşım, üretimde varsayılan dağıtık ortam, saat kaymasına toleranslı optimistic locking, Jepsen’in sert testleri, yeni bir dille (Flow) test yazımı vb. FDB ile de çok benzer sorunlar çözülebilir ve bence TigerBeetle kullanım alanına daha iyi optimize edilmiştir
- FDB’nin yaygın olmamasının tek nedeni iyi hazırlanmış katmanların azlığı. Yine de bazı kişiler SQS, DynamoDB ve SQLite katmanları üzerinde çalışıyor
  - FDB’nin yaygın olmamasının asıl nedeni Apple. 2013’te çıktı, ürün o kadar beğenildi ki şirket satın alındı ve mevcut kullanıcıların hepsinin hizmeti kesildi. Münhasırlık sona erdikten sonra bile güven geri gelmedi
  - FDB ekibiyle birlikte DST hakkında bir yazı da hazırlıyoruz
  - Satın almadan sonra neler olduğunu gerçekten merak ediyorum
  - Kelimenin tam anlamıyla 'the one true database' olduğunu düşünüyorum
  - “Neden tüm hyperscaler’lar FDB kullanmıyor?” diye düşünüp GitHub aramasına baktım, meğer sonunda Apple’ın çatısı altına girmiş
Son zamanlarda TigerBeetle geliştirme tarzını Rust, Go vb. dillerde uygulamayı denedim; gerçekten çok güçlü biçimde tavsiye ederim
- Tek giriş noktası, neredeyse sıfır bağımlılık
- CI’ı yerelde çalıştırma, test/coverage/lint vb. her şeyi tek komutla yürütme
- property/snapshot/swarm testleriyle simülasyonu devreye alma fikri beni heyecanlandırdı
- Hızlı/yavaş ayrımı, tüm testlerde deterministic seed kullanımı
- Açık upper bound’lar + resource pool işletimi, dinamik allocation kullanan kodu bile daha anlaşılır kılıyor
- TB ekibinin videoları ve dokümanları sayesinde
  - TigerStyle’ın gerçekten yardımcı olduğunu duymak sevindirici, geri bildirim için teşekkürler
“Production’da assertion’ları açık tutuyoruz” kısmı etkileyiciydi
- Assertion’ların neden kapatıldığını hiç anlamamıştım. Production’da assert patlarsa bunu hemen bilmek istersiniz (retorik olarak söylüyorum)
  - Tarihsel olarak assertion’ları kapatmanın performans kazancı vardı. Ama bugün birkaç ek karşılaştırmanın etkisi büyük değil
  - Aslında assertion’ların amacı, geliştiricinin API’yi yanlış kullanmasını engelleyen kontrollerdir. Kullanıcı girdisi katmanında bunların anlamlı hata mesajları vb. iş mantığına dönüştürülmesi daha mantıklı
  - Kontrolü kolay olmayan şeyleri de assertion yapmak isteyebiliyorsunuz. Örneğin, bir listenin sıralı olduğunu doğrulamak gibi
  - Assertion’ın asıl amacı derleme/test zamanı kontrolüdür. Production’da kullanacaksanız if’e çevirebilirsiniz. Assert’in yalnızca kullanışlı bir sugar syntax olup olmadığını düşünmek gerekir
TB ekibi double-entry modelini finans dışındaki senaryolarda da daha geniş kitlelere anlatmalı. Hisse senetleri, konser biletleri vb. için de çok faydalı. API iyileştirmeleri tamamlandıysa artık kullanım biçimlerini anlatma zamanı
- Bir analist olarak SQL’i çok kullanıyorum ama kod yazan biri değilim. Genel çerçeveyi ve performans avantajlarını büyük ölçüde anlıyorum. Merak ettiğim şeyler var a) TigerBeetle veri yapısı pratikte nasıl görünüyor? Bildiğimiz tablo yapısı gibi olmadığını tahmin ediyorum b) SQL query yazılamıyorsa nasıl kullanılıyor c) Double-entry modeli hisse, bilet vb. şeylere uygularsak nasıl oluyor? Örneğin bir konser salonunun elinde 1000 bilet var ve birini satınca envanterden nakde, ertelenmiş gelirden performans yükümlülüğüne mi geçiyor? Yoksa bilet satılana kadar hiç entry olmuyor mu?
- Benzer bir double-entry sistemi Postgres’te de kurulabilir
“Çoğu ekip kodu hızlı, testleri eziyet gibi, bağımlılıkları yığınla olacak şekilde yazar” sözü 25 yıl önce aslında standarttı. Google ve Facebook “move fast and break things” kültürünü getirmeden önce herkes son derece yavaş, iyi test edilmiş şekilde geliştiriyordu. TigerBeetle’ın daha fazla takdir görmesini umuyorum. Jepsen raporu da okumaya değer Jepsen report
- 25 yıl bekleyip TigerBeetle’ın Google olup olmayacağını ya da yavaş ama kusursuz ürünün daha hızlı rakiplere yenilip yenilmeyeceğini görmek ilginç olur
- “Move fast and break things” Facebook’un mottosuydu. Google ise tam tersine teste kafayı takmıştı. Elbette gerçek ihtiyaçlara göre hareket etmek gerekir; mühendisler çoğu zaman fazla sayıda hayali gereksinim üretip verimsizlik yaratabiliyor. Ürünü gerçek kullanıcılara hızla ulaştırıp geri bildirim toplamak, “balonun içinde” sonsuza kadar cilalamaktan çok daha değerlidir

onestone 2025-10-02

Yukarıdaki yazının içeriğinden bağımsız olarak, TigerBeetle’in web sitesi de kendi başına oldukça etkileyici.

Bir şekilde çok hızlı olduğu hissini veriyor ve ağır bir teknik yaklaşım yerine bunu daha eğlenceli bir tasarımla anlatmaya çalışması hoşuma gitti.

Bağlantı: https://tigerbeetle.com