Desain Berpusat pada Data (2018)

• Edisi online Data-Oriented Design adalah materi yang dibuka agar pembaca yang ingin mempelajari desain berpusat pada data dapat melihat inti isinya secara gratis
• Beberapa bab non-inti dari keseluruhan buku dihilangkan, tetapi materi ini disusun dengan fokus pada isi esensial yang diperlukan untuk belajar
• Karena dokumen ini dikonversi otomatis dari LaTeX ke HTML, mungkin masih ada kesalahan format, gambar rusak, dan daftar kode sumber yang rusak
• Untuk daftar kode sumber yang rusak, kode referensi dapat dilihat di repositori GitHub terpisah
• Membeli buku cetak adalah cara membaca dengan format yang lebih baik, sekaligus membantu mempertahankan edisi online bagi pembaca yang kesulitan membeli

---

Karakter edisi online

• Data-Oriented Design disediakan sebagai edisi ringkas online gratis yang membahas desain berpusat pada data
• Beberapa bab non-inti dikecualikan, tetapi alur inti yang diperlukan sebagai materi pembelajaran tetap disertakan
• Materi ini ditujukan bagi pembaca yang ingin mempelajari pendekatan melihat desain dengan menempatkan data itu sendiri sebagai pusatnya

Kualitas konversi dokumen dan referensi kode

• Dokumen online dibuat secara otomatis sehingga beberapa formatnya mungkin terasa janggal
• Alat untuk mengonversi dari LaTeX ke HTML belum sempurna, sehingga gambar atau daftar kode sumber bisa rusak
• Jika daftar kode sumber rusak, kode yang dirujuk dapat ditemukan di GitHub

Buku cetak dan masukan

• Buku cetak dapat dibaca dengan format yang lebih baik dibanding edisi online
• Membeli buku cetak membantu menjaga versi online tetap tersedia bagi pembaca yang tidak memiliki kemampuan untuk membeli
• Masukan dapat dikirim ke [e-mail]

[GN⁺]

Komentar Hacker News

• Salah satu nasihat terbaik yang pernah saya terima untuk menulis kode yang berkinerja tinggi dan mudah dikomposisikan adalah “structure of arrays, bukan array of structures”, dan tulisan ini sangat terasa sejalan dengan itu
  Ternyata arsitektur entity-component cocok bukan hanya untuk game, tetapi juga untuk aplikasi bisnis
  Hanya saja banyak pengembang perusahaan sudah terlalu terbiasa dengan model CRUD bergaya penyimpanan record, sehingga sulit berpikir dalam kolom, bukan baris, dan sering kali terasa tidak alami membayangkan memasukkan ID entitas ke tabel published alih-alih mengubah field boolean published menjadi true
  Meski begitu, begitu menyadari betapa mudahnya pendekatan ini diperluas secara polimorfik, kita jadi ingin memakai pendekatan ini untuk semua data. Lalu muncul peluang baru untuk memanfaatkan data komponen secara silang, dan kita mulai bertanya-tanya kenapa antarmuka jaringan boleh punya tanggal lahir, atau kenapa invoice bisa punya alamat IPv6, kenapa kucing bisa masuk ke pool DHCP, dan kenapa limegreen dihapus serta pada hari Selasa nilainya 5 dolar — dan itu adalah separuh dari keseruannya
  Saya tidak setuju dengan klaim bahwa pendekatan ini sepenuhnya tidak cocok dengan pemrograman berorientasi objek. Saya pernah memakai pendekatan seperti ini juga dengan Active Record di Ruby, dan itu tetap berjalan baik bahkan di ranah yang biasanya tidak dilekati istilah “berkinerja tinggi”. Ini sangat cocok terutama karena sistem objek Ruby lebih dekat ke Smalltalk daripada C++/Java, sehingga jauh lebih menyukai komposisi daripada pewarisan

  • Ini memang tidak berbenturan dengan mekanisme pemrograman berorientasi objek, tetapi programmer harus mengubah cara memandang masalah
    Dalam bahasa berorientasi objek, biasanya kita fokus pada satu “objek yang ingin kita pikirkan” seperti pengguna, posting blog, atau transaksi uang, lalu mengimplementasikannya secara terpisah dari yang lain, menyembunyikan data, dan memikirkan metode apa yang akan diekspos ke bagian lain dari sistem. Konsep enkapsulasi sangat kuat
    Dalam desain berorientasi data, lebih umum jika data dari domain yang berbeda tetap dapat diakses, dan subsistem memilih apa yang dibutuhkannya untuk menyelesaikan pekerjaannya. Java atau Ruby tidak melarang ini, tetapi jelas ada hambatan psikologis bagi programmer
  • Artikel Wikipedia tentang “Array of Structure (AoS) and Structure of Arrays (SoA)” menjelaskan kompromi antara SoA dari sisi performa dan AoS dari sisi intuisi serta dukungan bahasa: https://en.wikipedia.org/wiki/AoS_and_SoA
    Itu juga membahas dukungan perangkat lunak yang memungkinkan SoA diakses seolah-olah AoS, seperti data frame di R, Pandas di Python, dan DataFrames.jl di Julia
  • Di dunia data, “structure of arrays” setara dengan indeks berbasis kolom seperti Snowflake atau OLAP, sedangkan “array of structures” setara dengan basis data relasional yang memakai indeks berbasis halaman/baris
    Saya sangat menyukai Snowflake dan merasa itu akan merebut pasar para pesaingnya. Menarik juga bahwa Snowflake “mendukung” foreign key tetapi tidak menegakkannya. Dengan kata lain, Snowflake adalah “NoSQL” sebanyak yang masih bisa saya toleransi
  • Menurut saya ada dua jenis desain berorientasi data. Yang pertama adalah pendekatan “structure of arrays, bukan array of structures” seperti yang disebut di atas
    Yang kedua adalah menyerah pada enkapsulasi, memisahkan data dari metode yang menanganinya, dan memodelkan seluruh aplikasi berdasarkan bagaimana data mengalir agar lebih mudah dipahami dan diubah. Untuk ketepatan yang lebih tinggi, kita juga bisa memakai struktur data immutable dan fungsi murni
  • Saya pernah mencoba memperkenalkan ECS ke aplikasi non-game juga, dan sebuah perusahaan keuangan di London menerima saran ini untuk mengelola kompleksitas sistemnya. Itu sangat cocok
    Bagi yang penasaran, ini pengantar ECS yang sangat singkat: https://dev.to/ovid/the-unknown-design-pattern-1l64

• “Apakah tata letak data didefinisikan oleh satu interpretasi tunggal yang berasal dari satu sudut pandang?” mungkin merupakan pertanyaan terpenting saat memilih teknologi dan meninjau arsitektur. Biasanya, untuk menjawab pertanyaan ini, kita perlu berbicara dengan bisnis dan pelanggan
  Jika yakin bahwa benar-benar hanya ada satu “view” valid atas data yang akan dipakai di seluruh sistem, masuk akal untuk menanamkannya ke dalam kode. Jika ada sedikit saja keraguan, model bergaya relasional kemungkinan lebih cocok. Banyak perusahaan pada akhirnya bermuara ke SQL setelah menyadari teori permainan dari masalah ini
  Banyak orang bertanya-tanya mengapa semua orang tampak menjauh dari satu basis data SQL besar. Memang ada kasus tepi “web scale” yang mengancam skalabilitas vertikal untuk operasi tulis, tetapi saya rasa sebagian besar perusahaan, termasuk perusahaan F100, bahkan tidak akan mencapainya

  • Di perusahaan teknologi F100 tempat saya dulu bekerja, ada pedoman RDBMS dilarang tanpa persetujuan eksplisit
    Itu tidak ada hubungannya dengan cara terbaik memodelkan dataset tertentu atau performa terbaik, melainkan sepenuhnya karena riwayat gangguan akibat fleksibilitas skema yang rendah dan kegagalan migrasi skema. Dalam desain NoSQL, masalah seperti itu tidak muncul, dan keunggulan yang diberikan basis data SQL tidak cukup untuk mengimbangi manfaat besar NoSQL yang tidak memiliki skema kaku
    Tentu saja, jika key-value store dipakai dengan buruk, performa dan biaya bisa rusak parah. Di platform cloud seperti DynamoDB, saya sering melihat kasus data tidak distrukturkan dengan benar sehingga terjadi banyak scan dan biayanya meledak
  • Kami tidak sepenuhnya menjauh dari satu basis data SQL besar, tetapi kami memang mengalami kelompok masalah tertentu yang tampaknya terkait dengan arsitektur itu
    Karena ini perusahaan besar yang sudah lama berdiri, sering kali solusi teknis yang dibuat orang nonteknis di masa lalu mengeras dan harus terus dipertahankan. Ada 5 tahap transformasi data SQL yang dimulai dari basis data operasional lalu berlanjut ke model data dari generasi berbeda setiap kali jenis bisnis berubah
    Semakin banyak layer yang menumpuk, semakin banyak pula kami terus menambah di atas layer sebelumnya. Jika aplikasi yang dibuat 10 tahun lalu di atas layer abstraksi 2 kini membutuhkan data dari layer 4, kami membuat skrip untuk mengembalikan data itu ke layer sebelumnya lalu terus lanjut. Pada akhirnya, ini menjadi gumpalan besar tabel dan view yang saling bergantung dan membaca data dengan cara yang aneh serta tidak intuitif, dan proyek untuk merapikannya dinilai terlalu mahal sehingga ditunda sampai tahun 2030-an
    Saya paham orang melihat masalah seperti ini dan bertanya-tanya bagaimana itu bisa dihindari. Namun entah kenapa, tampaknya mustahil menerapkan cara yang membutuhkan disiplin pada software engineer, jadi Anda harus membuat mereka tidak bisa membuat spaghetti bagaimanapun caranya. Di sinilah pemisahan muncul. Jika Anda tidak bisa membaca data milik layanan lain, Anda tidak bisa membuat spaghetti yang memperlambat kedua sisi
    Pemisahan vertikal aplikasi menjadi solusi perangkat lunak untuk masalah manusia berupa disiplin engineering yang buruk di perusahaan
  • Hacker News tidak mewakili seluruh ekosistem teknologi. Saya rasa sebagian besar aplikasi masih memakai satu basis data SQL besar
    Baru-baru ini saya merilis framework open source yang sepenuhnya berbasis desain berorientasi data, dan saya banyak mendapat tanggapan bahwa desain ini sangat pas. Ada sangat banyak hal yang menjadi lebih mudah jika semua data berada di satu tempat
    https://sql.ophir.dev
  • Di tempat-tempat saya bekerja, alasannya seperti ini: kami beralih ke microservices, satu basis data raksasa memperlambat performa, dan pengoperasian serta pemeliharaan DB besar sangat sulit
    Di DB raksasa ada banyak sisa-sisa yang tidak dipakai siapa pun dan tidak jelas kenapa masih ada, tetapi belum ada yang yakin apakah itu masih diperlukan, dan strategi optimasi untuk baca dan tulis juga harus berbeda
    Selain itu, agar tim bisa bergerak cepat, mereka perlu memiliki ownership atas basis data dan penyimpanan data tanpa harus menunggu DBA menjawab tiket
  • Saya rasa penyebabnya sama seperti alasan microservices dan DevOps menjadi populer. Politik jadi lebih mudah
    Saat saya bekerja di perusahaan besar yang tua, sebagian besar masalahnya bersifat politis dan administratif. Satu basis data SQL besar memang efisien, tetapi masalah muncul saat organisasi yang memilikinya tidak sejalan dengan strategi CTO baru atau unit bisnis inti lain
    Jika kemudian terjadi gangguan yang menunjukkan rendahnya ketahanan model ini, itu cepat menjadi masalah politik, dan meski solusi teknisnya masih terlihat jelas bagi semua orang, tetap sulit untuk mendorongnya

• Seluruh saran ini bergantung pada konteks
  Dalam game memang ada banyak operasi yang membutuhkan pendekatan berbasis kolom, tetapi tidak semua domain seperti itu. Jika praktik terbaik dari dunia game dipaksakan secara buta ke domain lain, itu hanya akan mempersulit hidup semua orang dan memperburuk sebagian besar sistem

  • Ini bukan hanya soal pendekatan berbasis kolom. Jika data dibuat dalam bentuk array of structs, ada peluang untuk mengemas data dengan lebih efisien dan sangat mengurangi penggunaan memori aplikasi
    Field boolean pada struct bisa menjadi bitset, field yang nullable bisa menjadi sparse atau dense map, dan field pointer atau reference bisa menjadi array integer dengan lebar lebih kecil yang mengindeks pool
    Dalam lingkungan di mana CPU sering berhenti karena akses memori, dampak perubahan seperti ini tidak bisa diremehkan. Perbedaan latensi antara cache L3 dan RAM bisa berada di kisaran 10 kali lipat
  • Saran untuk menjaga data yang sering diakses tetap bersebelahan di memori berlaku untuk hampir segala hal pada perangkat keras modern
    Jika sebuah program punya masalah performa sekecil apa pun, kemungkinan besar ini adalah salah satu cara untuk menjamin performa yang baik
  • Bahwa game memiliki banyak operasi yang membutuhkan pendekatan berbasis kolom juga sama sekali tidak jelas saat ECS pertama kali muncul. Butuh waktu lama untuk meyakinkan orang agar berpindah dari pendekatan berorientasi objek
  • Semakin lama terasa bahwa ini adalah satu-satunya cara untuk menulis kode berperforma tinggi
    Satu-satunya hal yang tampaknya akan terus berkembang pada perangkat keras modern adalah kepadatan logika. SRAM dan ukuran cache tidak lagi skala dengan baik pada litografi modern, dan bandwidth RAM juga sudah lama tidak meningkat banyak. Bandwidth per core bahkan mungkin menurun. Akses memori sudah menjadi bottleneck cukup lama
  • Bahkan di banyak area kode game pada umumnya, pendekatan berbasis kolom tidak selalu tepat, dan biasanya hanya berlaku pada bagian yang harus memproses setidaknya ribuan “objek”. Contohnya sistem partikel atau sistem navigasi dan tabrakan
    Desain berorientasi data sangat masuk akal di dalam subsistem tertentu, tetapi pada kode gameplay tingkat tinggi, kecuali untuk genre tertentu, itu belum tentu demikian

• Presentasi Mike Acton di CppCon 2014, Data-Oriented Design and C++, menurut saya adalah presentasi pemrograman terbaik yang pernah ada. Wajib ditonton: https://youtu.be/rX0ItVEVjHc

  • Benar-benar luar biasa dan juga merupakan presentasi favorit saya. Secara pribadi saya menganggap Mike Acton sebagai tokoh kunci yang mempopulerkan desain berorientasi data dan arsitektur ECS
    Sebelumnya ia juga memimpin Unity DOTS, tetapi sayangnya sekarang Unity tampak sedang goyah. Pekerjaan DOTS sendiri meski belum selesai tetap solid
  • Kalau ingin mendapat gambaran tentang bagaimana performa kelas dunia diwujudkan, tonton video ini
    Saya menghabiskan sebagian besar karier dengan menulis web app, tetapi setelah melihat presentasi ini saya jadi paham “mengapa seseorang memakai C?”

• Andrew Kelley juga pernah memberikan presentasi yang informatif dan menarik tentang bagaimana desain berorientasi data memengaruhi pekerjaannya pada kompiler Zig: https://vimeo.com/649009599

• Pemula pun bisa belajar pemrograman dengan pendekatan berorientasi data sejak awal
  Buku untuk mengajarkan gaya ini kepada pemula antara lain How to Design Programs dan A Data-Centric Introduction to Computing
  https://htdp.org/
  https://dcic-world.org/

  • Buku-buku ini bukan tentang hal yang dimaksud di sini

• Saya menemukan ulasan online tentang buku ini: https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...

  • Kalimat berikut menarik dan terasa berlawanan dengan nasihat umum
    “Penyebab utama yang menyiksa dan menunda banyak proyek adalah keras kepala untuk tidak melakukan optimisasi terlalu dini. Alasan optimisasi tahap akhir begitu sulit adalah karena banyak perangkat lunak dibangun dengan menaruh instance objek di mana-mana, bahkan saat itu tidak diperlukan.”
    Jelas ada aplikasi yang menempatkan performa sebagai prioritas utama, dan ada juga yang tidak. Ini membuat saya bertanya-tanya apakah dalam aplikasi yang sensitif terhadap performa, optimisasi dini memang bisa masuk akal. Saya penasaran apakah pembacaan seperti ini tepat
    Ada juga yang disebut Data-Oriented Programming: https://www.manning.com/books/data-oriented-programming
    Saya penasaran apakah kedua konsep ini sama

• Desain berorientasi data ramah bagi pemula. Karena ia berurusan dengan kemurnian pemodelan data, bukan dengan manusia dan bisnis
  Dulu, langkah pertama proyek baru adalah menggambar model relasi entitas, dan itu menjadi dasar bagi semuanya
  Sekarang, sebelum memulai model data, kita cenderung memahami masalah dan domainnya dulu, lalu memikirkan kapabilitas serta bagaimana mengelompokkan dan memberi batas padanya

  • Kalau sudah berpengalaman, kita jadi tahu bahwa kecintaan pada data dan pemrograman sering tersingkir oleh kebutuhan bisnis
    Meski begitu, tulisan ini tampaknya ingin mengatakan bahwa jika sejak awal fokus pada pengumpulan kebutuhan data, diskusi tentang kebutuhan bisnis itu sendiri bisa jadi berkurang

• Saat memakai DoD, salah satu konsep intinya adalah tidak menyembunyikan data di balik abstraksi. Arah pikirnya adalah semakin sedikit semakin baik
  Namun ketika saya membaca cepat tulisan pengantarnya, kesannya justru kebalikan. Terlalu banyak kata dan konsep intinya malah diabstraksikan. Saya merasa ironis, seperti tidak meminum anggurnya sendiri; saya penasaran apakah hanya saya yang merasa begitu

• Paragraf pembukanya cukup hebat. Tulisan yang mengalir dan ide-ide yang menarik membuat saya ingin terus membaca
  “Data adalah satu-satunya yang kita miliki. Data adalah sesuatu yang harus kita transformasikan untuk menciptakan pengalaman pengguna. Data adalah apa yang kita baca saat membuka dokumen. Grafik di layar, denyut tombol gamepad, penyebab speaker menciptakan gelombang di udara, cara naik level, dan cara musuh mengetahui posisi Anda lalu menembak juga merupakan data. Waktu yang dibutuhkan dinamit untuk meledak dan jumlah cincin yang hilang saat jatuh ke duri juga adalah data. Semua posisi dan kecepatan partikel saat ini dalam adegan indah setelah Anda menamatkan permainan, dan hal yang dibaca dari disk lalu masuk ke hidup Anda, adalah hasil transformasi pada mesin yang dijalankan oleh instruksi yang didekode, yang berasal dari instruksi yang diarahkan assembler, yang berasal dari source code yang Anda berikan ke kompiler.”

  • Saya sering melihat gagasan seperti ini dalam literatur desain berorientasi data, dan rasanya selalu terlalu reduksionis tanpa perlu
    Mungkin ini berguna sebagai “siraman air dingin” untuk menyiapkan suasana dan membantu orang keluar dari pola pikir abstraksi berorientasi objek. Tetapi selain itu, manfaatnya terasa seperti seorang insinyur berkata, “Lihat sekeliling! Semua terbuat dari atom! Rekayasa pada dasarnya adalah pekerjaan memindahkan atom!”
    Itu tidak salah, tetapi tidak terlalu membantu untuk benar-benar melakukan rekayasa