Veri Odaklı Tasarım (2018)

 (dataorienteddesign.com)
5 puan yazan GN⁺ 2023-07-04 | 1 yorum | WhatsApp'ta paylaş
  • Data-Oriented Design çevrimiçi sürümü, veri odaklı tasarımı öğrenmek isteyen okurların temel içeriğe ücretsiz olarak göz atabilmesi için yayımlanmış bir kaynaktır
  • Kitabın tamamındaki bazı çekirdek olmayan bölümler çıkarılmış olsa da, öğrenme için gerekli temel içerik etrafında yapılandırılmıştır
  • Belge, LaTeX'ten HTML'ye otomatik dönüştürüldüğü için biçim hataları, bozuk görseller ve bozuk kaynak kodu listeleri içerebilir
  • Bozuk kaynak kodu listeleri için başvuru kodları ayrı bir GitHub deposunda incelenebilir
  • Basılı kitabı satın almak, hem daha iyi bir düzen içinde okuma imkânı sağlar hem de satın alma imkânı olmayan okurlar için çevrimiçi sürümün sürdürülmesine katkıda bulunur

Çevrimiçi sürümün niteliği

  • Data-Oriented Design, veri odaklı tasarımı ele alan ücretsiz bir çevrimiçi kısaltılmış sürüm olarak sunulmaktadır
  • Bazı çekirdek olmayan bölümler çıkarılmış olsa da, öğrenim materyali için gerekli temel akış korunmuştur
  • Tasarıma verinin kendisini merkeze alarak bakma yaklaşımını öğrenmek isteyen okurlara yöneliktir

Belge dönüştürme kalitesi ve kod başvuruları

  • Çevrimiçi belge otomatik üretildiği için bazı biçimlendirmeler tuhaf görünebilir
  • LaTeX'ten HTML'ye dönüştürme aracı kusursuz olmadığından, görseller veya kaynak kodu listeleri bozulabilir
  • Kaynak kodu listeleri bozuksa, başvurulan kodlar GitHub üzerinde bulunabilir

Basılı kitap ve geri bildirim

  • Basılı kitap, çevrimiçi sürüme kıyasla daha iyi bir düzenle okunabilir
  • Basılı kitabın satın alınması, satın alma gücü olmayan okurlar için çevrimiçi sürümün varlığını sürdürmesine yardımcı olur
  • Geri bildirimlerinizi support@dataorienteddesign.com adresine gönderebilirsiniz

İlgili okumalar

1 yorum

 
GN⁺ 2023-07-04
Hacker News görüşleri

  • Yüksek performanslı ve bileştirilebilir kod yazmak için aldığım en iyi tavsiyelerden biri, “structure array değil, array structure ile uğraş” olmuştu; bu yazıda da bunun yankısı güçlü biçimde hissediliyor
    Görünüşe göre entity-component mimarisi yalnızca oyunlarda değil, iş uygulamalarında da gayet iyi uyuyor
    Ancak birçok kurumsal geliştirici kayıt saklama odaklı CRUD modeline fazlasıyla alışmış durumda; bu yüzden satır yerine sütun üzerinden düşünmekte zorlanıyorlar ve published boolean alanını true yapmak yerine entity ID’sini published tablosuna koyma fikri çoğu zaman doğal gelmiyor
    Yine de bu yaklaşımın ne kadar kolay biçimde polimorfik olarak genişlediğini bir kez fark edince, tüm verilerde bunu kullanmak istiyorsunuz. Sonra component verilerini çapraz kullanmak için yeni fırsatlar çıkıyor ve bir ağ arayüzünün neden doğum günü olduğu, bir faturaya neden IPv6 adresi iliştirildiği, bir kedinin nasıl DHCP havuzuna girdiği ve limegreen’in neden silinip salı günleri 5 dolar olduğu gibi şeylere neden izin verildiğini sorgulamaya başlıyorsunuz; eğlencenin yarısı da bu zaten
    Bunun nesne yönelimlilikle tamamen uyumsuz olduğu iddiasına katılmıyorum. Ruby’nin Active Record’u ile de bu yaklaşımı kullandım ve genelde “yüksek performanslı” denmeyen alanlarda bile iyi çalıştı. Ruby’nin nesne sistemi C++/Java’dan çok Smalltalk’a yakın olduğu ve kalıtımdan ziyade bileşimi güçlü biçimde tercih ettiği için özellikle iyi uydu

    • Nesne yönelimliliğin mekanizmalarıyla çatışmıyor, ama programcının probleme bakış biçimini değiştirmesi gerekiyor
      Nesne yönelimli dillerde genelde kullanıcı, blog yazısı, para işlemi gibi “üzerine düşünmek istediğiniz şeylerden” birine odaklanır, onu diğerlerinden ayırarak uygular, veriyi gizler ve sistemin diğer kısımlarına hangi metotları açacağınızı düşünürsünüz. Kapsülleme fikri çok güçlüdür
      Veri odaklı tasarımda ise farklı alanlardaki verilerin erişilebilir olması ve alt sistemlerin kendi işleri için gerekenleri seçip kullanması daha yaygındır. Java ya da Ruby bunu engellemez ama programcı açısından kesinlikle psikolojik bir bariyer vardır
    • Wikipedia’daki “Array of Structure (AoS) and Structure of Arrays (SoA)” maddesi, performans tarafındaki SoA ile sezgisellik ve dil desteği tarafındaki AoS arasındaki ödünleşmeyi açıklıyor: https://en.wikipedia.org/wiki/AoS_and_SoA
      Ayrıca R veri çerçeveleri, Python Pandas ve Julia DataFrames.jl gibi SoA’ya AoS gibi erişmeyi sağlayan yazılım desteğinden de söz ediyor
    • Veri dünyasında “array structure”, Snowflake veya OLAP gibi sütun tabanlı indekslere karşılık geliyor; “structure array” ise sayfa/satır tabanlı indeks kullanan ilişkisel veritabanlarına karşılık geliyor
      Snowflake’i çok seviyorum ve diğer rakiplerin öğle yemeğini elinden alacağını düşünüyorum. Snowflake’in yabancı anahtarları “destekleyip” zorunlu kılmaması da ilginç. Başka bir deyişle Snowflake, benim tolere edebildiğim kadar “NoSQL”
    • Bence veri odaklı tasarımın iki türü var. Biri, az önce anlatıldığı gibi, “structure array değil, array structure” ile uğraşmak
      Diğeri ise kapsüllemeyi bırakıp veriyle o veriyi işleyen metotları ayırmak ve tüm uygulamayı verinin nasıl aktığına göre düşünerek, anlaşılması ve değiştirilmesi kolay olacak şekilde modellemek. Daha fazla doğruluk için immutable veri yapıları ve saf fonksiyonlar kullanılabilir
    • Oyun dışı uygulamalara da ECS getirmeye çalıştım ve Londra’daki bir finans şirketi sistem karmaşıklığını yönetmek için bu tavsiyeyi benimsedi. Çünkü gerçekten çok iyi uyuyordu
      Merak edenler için çok kısa bir ECS tanıtımı: https://dev.to/ovid/the-unknown-design-pattern-1l64

  • “Veri yerleşimi tek bir bakış açısından çıkan tekil bir yorumla mı tanımlanıyor?” sorusu, teknoloji seçimi ve mimari açısından en önemli soru olabilir. Genelde bu soruya cevap vermek için iş tarafı ve müşterilerle konuşmak gerekir
    Veriye dair herkes için geçerli olan tam olarak tek bir “görünüm” bulunduğundan eminseniz, bunu koda kazımak da anlamlıdır. En ufak bir şüpheniz varsa ilişkisel tarz modelin daha uygun olma ihtimali yüksektir. Pek çok şirket, bu sorunun oyun teorisini fark edince sonunda SQL’e yönelir
    Herkesin neden tek bir büyük SQL veritabanından uzaklaşmış gibi göründüğünü merak ediyorum. Yazma işlemlerinin dikey ölçeklenebilirliğini tehdit eden “web ölçeği” uç durumları var, ama F100 şirketleri dahil çoğu şirketin oraya hiç ulaşmayacağını düşünüyorum

    • Eski bir F100 teknoloji şirketinde, açık onay olmadan RDBMS yasaktı
      Bunun, belirli bir veri kümesini en iyi nasıl modellediğiyle ya da en iyi performansla ilgisi yoktu; tamamen şema esnekliği ve şema geçişi hatalarının geçmişte kesintiye yol açmış olmasıyla ilgiliydi. NoSQL tasarımlarında böyle sorunlar yaşanmıyordu ve SQL veritabanlarının sağladığı avantajlar da katı şeması olmayan NoSQL’in büyük faydasını dengelemiyordu
      Elbette anahtar-değer depoları yanlış kullanılırsa performans ve maliyet ciddi biçimde mahvolabilir. DynamoDB gibi bulut platformlarında, veriyi düzgün yapılandıramayıp tonla scan çalıştırdığı için maliyeti patlayan pek çok örnek gördüm
    • Tek bir büyük SQL veritabanından tamamen uzaklaşmış değiliz, ama bu mimariyle ilişkili görünen belirli bir sorun kümesini yaşıyoruz
      Eski büyük bir şirket olduğumuz için, teknik olmayan personelin geçmişte oluşturduğu teknik çözümler çoğu zaman katılaşıp sürdürülmek zorunda kalıyor. Operasyonel veritabanıyla başlayıp iş türü her değiştiğinde başka bir nesil veri modeline geçilen SQL veri dönüşümünün 5 aşaması gibi bir durum var
      Katmanlar arttıkça hep önceki katmanın üstüne yenisi ekleniyor. 10 yıl önce soyutlama katmanı 2’nin üstüne kurulmuş bir uygulama şimdi katman 4’teki verilere ihtiyaç duyuyorsa, o veriyi önceki katmanlara geri taşıyan script’ler yazılıyor ve devam ediliyor. Sonunda, birbirine bağımlı tablolar ve view’lardan oluşan, veriyi garip ve sezgisel olmayan biçimlerde okuyan devasa bir yığına dönüştü; bunu temizleme projesi ise fazla pahalı bulunduğu için 2030’lara ertelendi
      İnsanların bu tür sorunları görüp bunlardan nasıl kaçınılabileceğini düşünmesini anlıyorum. Ama nedense, yazılım mühendislerine disiplin gerektiren bir yaklaşımı uygulatmak imkansız görünüyor; bir şekilde spagetti üretmelerini imkansız hale getirmek gerekiyor. İşte ayrım burada devreye giriyor. Başka servislerin verisini okuyamıyorsanız, iki tarafın da hızını öldüren spagettiyi kuramazsınız
      Uygulamaların dikey ayrılması, şirketlerdeki zayıf mühendislik disiplini gibi insani bir soruna yazılımsal bir çözüm haline geliyor
    • Hacker News tüm teknoloji ekosistemini temsil etmiyor. Çoğu uygulamanın hâlâ tek bir büyük SQL veritabanı kullandığını düşünüyorum
      Yakın zamanda tamamen veri odaklı tasarıma dayanan bir açık kaynak framework yayınladım ve bunun cuk oturduğunu söyleyen çok kişi oldu. Tüm veriyi tek yerde tutunca gerçekten çok şey kolaylaşıyor
      https://sql.ophir.dev
    • Çalıştığım yerlerde sebep şuydu: mikroservislere geçildi, tek bir devasa veritabanı performansı yavaşlattı ve büyük bir DB’yi işletmekle bakımını yapmak çok zordu
      Devasa DB’de kimsenin kullanmadığı ve neden var olduğu bilinmeyen ama hâlâ gerekli olup olmadığından emin olunamayan çok fazla tortu vardı; ayrıca okuma ve yazma için farklı optimizasyon stratejileri gerekiyordu
      Ayrıca ekiplerin hızlı hareket edebilmesi için DBA’nın ticket’lara cevap vermesini beklemek yerine veritabanı ve veri depoları üzerinde sahiplik alması gerekiyordu
    • Bunun sebebinin, mikroservisler ve DevOps’un neden yükseldiğiyle aynı olduğunu düşünüyorum. Siyaset daha kolay hale geliyor
      Büyük ve eski bir şirkette çalıştığımda sorunların çoğu siyasi ve bürokratikti. Tek bir büyük SQL veritabanı verimlidir, ama ona sahip olan organizasyon yeni CTO stratejisiyle ya da başka bir çekirdek iş birimiyle aynı fikirde olmadığı anda sorun başlar
      Buna bir de bu modelin düşük dayanıklılığını gösteren kesintiler eklenince, teknik çözüm herkese hâlâ çok bariz görünse bile mesele hızla siyasi bir baş ağrısına dönüşür ve ilerletilmesi zorlaşır

  • Bu tavsiyenin tamamı bağlama bağlıdır
    Oyunlarda sütun tabanlı yaklaşım gerektiren çok sayıda işlem vardır; ama her alan böyle değildir. Oyun tarafındaki en iyi uygulamaları başka alanlara körü körüne dayatmak, herkesin hayatını zorlaştırır ve çoğu sistemi daha kötü hale getirir

    • Bu yalnızca sütun tabanlı erişim meselesi değil. Veriyi dizi-yapı formunda düzenlerseniz, veriyi daha verimli paketleme ve uygulamanın bellek kullanımını ciddi ölçüde azaltma fırsatı doğar
      Boolean struct alanları bitset olabilir, null olabilir alanlar sparse ya da dense map olabilir, pointer veya referans alanları ise havuzu indeksleyen daha dar tamsayı dizilerine dönüşebilir
      CPU’nun bellek erişiminde sık sık durakladığı ortamlarda bu değişikliklerin etkisi küçümsenemez. L3 cache ile RAM gecikmesi arasındaki fark kabaca 10 kat olabilir
    • Sık erişilen veriyi bellekte ardışık tutma tavsiyesi, modern donanımda neredeyse her şeye uygulanır
      Performansın az da olsa sorun olduğu herhangi bir program için, bu yaklaşım iyi performansı garanti altına almanın yollarından biri olma ihtimali yüksektir
    • Oyunlarda sütun tabanlı yaklaşım gerektiren çok işlem olması da ECS ilk ortaya çıktığında hiç de açık değildi. İnsanları nesne yönelimli yaklaşımdan vazgeçirip buna geçirmek uzun zaman aldı
    • Giderek bunun yüksek performanslı kod yazmanın tek yolu gibi hissettirdiğini düşünüyorum
      Modern donanımda ölçeklenmeye devam etmesi beklenen tek şey mantıksal yoğunluk gibi görünüyor. SRAM ve cache boyutları modern litografide artık iyi ölçeklenmiyor, RAM bant genişliği de epey uzun süredir ciddi biçimde artmadı. Hatta çekirdek başına bant genişliği azalmış bile olabilir. Bellek erişimi uzun zamandır darboğaz
    • Tipik bir oyundaki pek çok kod alanında da sütun tabanlı yaklaşım her zaman doğru değildir; bu daha çok en az binlerce “hedefin” işlenmesi gereken bölümler için geçerlidir. Örneğin particle system ya da navigation ve collision sistemleri
      Veri odaklı tasarım, belirli alt sistemlerin içinde oldukça mantıklıdır; ancak üst düzey gameplay kodunda, bazı türler dışında mutlaka gerekli değildir

  • Mike Acton’ın CppCon 2014 konuşması Data-Oriented Design and C++ bence şimdiye kadar yapılmış en iyi programlama sunumu. Kesinlikle izlemeye değer: https://youtu.be/rX0ItVEVjHc

    • Gerçekten harika ve benim de en sevdiğim sunumlardan biri. Bana göre Mike Acton, veri odaklı tasarım ve ECS mimarisini yaygınlaştıran kilit isimlerden biri
      Daha önce Unity DOTS’a da öncülük etmişti, ama ne yazık ki şu an Unity sarsılıyor gibi görünüyor. DOTS çalışmasının kendisi tamamlanmamış olsa da sağlam
    • Dünya çapında performansın nasıl elde edildiğine dair bir sezgi kazanmak istiyorsanız bu videoyu izleyin
      Kariyerimin büyük bölümünü web uygulamaları yazarak geçirdim ama bu sunumu izledikten sonra “neden birileri C kullanır?” sorusunu anlamaya başladım

  • Andrew Kelley, veri odaklı tasarımın Zig derleyicisi üzerindeki çalışmasını nasıl etkilediğini anlattığı faydalı ve eğlenceli bir sunum yapmış: https://vimeo.com/649009599

  • Yeni başlayanlar da en baştan veri odaklı yaklaşımla programlamayı öğrenebilir
    Bu tarzı başlangıç seviyesine öğretmek için How to Design Programs ve A Data-Centric Introduction to Computing adlı kitaplar var
    https://htdp.org/
    https://dcic-world.org/

    • Bu kitaplar burada kastedilen şey değil

  • Kitapla ilgili çevrimiçi bir inceleme buldum: https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...

    • Şu cümle ilginç geldi ve genel tavsiyenin tersini söylüyor gibi göründü
      “Birçok projeyi yıpratıp geciktiren temel sorun, optimizasyonu erken yapmamak gerektiği konusundaki inattı. Geç aşama optimizasyonunun bu kadar zor olmasının nedeni, çok sayıda yazılımın, gerekmediği zamanlarda bile her yere nesne örnekleri yerleştiren bir anlayışla inşa edilmesidir.”
      Performansın en önemli öncelik olduğu uygulamalar da var, olmadığı uygulamalar da. Performansın önemli olduğu uygulamalarda erken optimizasyonun da makul olabileceği mi söyleniyor diye düşündürüyor. Böyle okumak doğru mu merak ediyorum
      Bir de Data-Oriented Programming diye bir şey var: https://www.manning.com/books/data-oriented-programming
      Bu iki kavramın aynı şey olup olmadığını merak ediyorum

  • Veri odaklı tasarım, yeni başlayanlar için uygundur. Çünkü insanları ve işi modellemekten çok veri modellemenin saflığı ile ilgilidir
    Küçükken yeni bir projenin ilk adımı varlık-ilişki modeli çizmekti ve bu her şeyin temeli olurdu
    Bugünlerde ise veri modeline başlamadan önce problemi ve alanı anlamaya, yetenekleri ve bunların nasıl gruplanıp sınırlandırılacağını düşünmeye daha çok odaklanıyoruz

    • Deneyim kazandıkça, veri ve programlamaya duyulan sevginin iş gereksinimleri tarafından sık sık geri plana itildiğini fark ediyorsunuz
      Yine de bu yazı, en baştan veri gereksinimlerini toplamaya odaklanırsanız iş gereksinimlerini tartışma ihtiyacının kendisinin azalabileceğini söylüyor gibi görünüyor

  • DoD kullanırken temel fikirlerden biri, veriyi soyutlamaların arkasına gizlememektir. Mantık az olan daha iyidir yönündedir
    Ama giriş yazısını hızlıca okuyunca bende tam tersi bir izlenim bıraktı. Fazla konuşuyor ve temel kavramları soyutluyor. Kendi şarabını içmiyor gibi gelmesi sadece bana mı ironik geliyor merak ediyorum

  • Giriş paragrafı oldukça iyi. Akıcı yazımı ve ilginç fikirleri sayesinde okumaya devam etmek istetiyor
    “Veri, sahip olduğumuz her şeydir. Veri, kullanıcı deneyimini üretmek için dönüştürdüğümüz şeydir. Bir belgeyi açtığınızda içeri alınan şey de veridir. Ekrandaki grafikler, gamepad düğmelerinden gelen darbeler, hoparlörlerin havada dalgalar oluşturmasına yol açan neden, seviye atlama sistemi, düşmanın konumunuzu öğrenip size ateş etmesini sağlayan yöntem de veridir. Dinamitin patlamasının ne kadar sürdüğü ve dikenlerin üzerine düştüğünüzde kaç yüzük kaybettiğiniz de veridir. Oyunu bitiren o güzel sahnedeki her parçacığın mevcut konumu ve hızı da veridir; diskten okunup hayatınıza giren şey, derleyiciye verdiğiniz kaynak kodun, assembler’ın belirttiği komutların ve çözümlenmiş komutlarla çalışan makinenin dönüşümlerinden geçmiş halidir.”

    • Veri odaklı tasarım literatüründe bu tür fikirlere sık rastlıyorum ve bana her zaman gereksiz derecede indirgemeci gelmiştir
      Sahneyi kurmak ve nesne yönelimli soyutlama zihniyetinden çıkarmak için bir tür “soğuk duş” olarak faydalı olabilir. Ama onun dışında, bir mühendisin “Etrafınıza bakın! Her şey atomlardan oluşuyor! Mühendislik temelde atomları hareket ettirme işidir!” demesi kadar faydalı geliyor
      Yanlış değil ama fiilen mühendislik yaparken pek yardımcı olmuyor