データ中心設計 (2018)
(dataorienteddesign.com)- Data-Oriented Design のオンライン版は、データ中心設計を学びたい読者が中核内容を無料で確認できるよう公開された資料である
- 書籍全体の一部の非中核章は省かれているが、学習に必要な 必須内容 を中心に構成されている
- LaTeX から HTML へ自動変換された文書のため、書式の乱れ、壊れた画像、壊れたソースコード一覧が残っている可能性がある
- 壊れたソースコード一覧については、別途 GitHub リポジトリ で参照コードを確認できる
- 紙の書籍の購入は、よりよい版面で読む方法であると同時に、購入が難しい読者向けのオンライン版維持にも役立つ
オンライン版の性格
- Data-Oriented Design は、データ中心設計を扱う無料のオンライン要約版として提供されている
- 一部の非中核章は除外されているが、学習資料として必要な中核的な流れは含まれている
- データそのものを中心に据えて設計を見るアプローチを身につけたい読者に向けられている
文書変換の品質とコード参照
- オンライン文書は自動生成されているため、一部 書式が不自然 な場合がある
- LaTeX から HTML へ変換するツールが完全ではないため、画像やソースコード一覧が壊れることがある
- ソースコード一覧が壊れている場合、参照されているコードは GitHub で見つけられる
紙の書籍とフィードバック
- 紙の書籍はオンライン版よりもよい版面で読める
- 紙の書籍の購入は、購入余力のない読者のためにオンライン版を継続して維持する助けになる
- フィードバックは support@dataorienteddesign.com に送ることができる
1件のコメント
Hacker Newsのコメント
高性能で組み合わせ可能なコードを書くうえで受けた助言の中でも、最高のもののひとつが「構造体の配列ではなく、配列の構造体を扱え」だった。この文章からもその響きを強く感じる
実際、エンティティ・コンポーネント・アーキテクチャはゲームだけでなく業務アプリケーションにもよく合う
ただ、多くの企業開発者は記録保管型のCRUDモデルに慣れきっていて、行ではなく列で考えるのに苦労するし、
publishedブール値フィールドをtrueに切り替える代わりにpublishedテーブルにエンティティIDを入れるという発想が自然でないことも多いそれでも、この方式がどれほど簡単に多相的に拡張できるかに気づくと、あらゆるデータにこのアプローチを使いたくなる。すると、コンポーネントデータを横断利用する新しい機会が生まれ、ネットワークインターフェースに誕生日があったり、請求書にIPv6アドレスが付いていたり、猫がDHCPプールに入っていたり、limegreenが削除されていたり、火曜日には5ドルだったりする構造がなぜ許されるのか疑問に思い始めるが、それが面白さの半分でもある
この方式がオブジェクト指向と完全に相容れないという主張には同意しない。RubyのActive Recordでもこのアプローチを使ったことがあり、通常は「高性能」とはあまり結びつかない領域でもうまく機能した。RubyのオブジェクトシステムはC++/JavaよりSmalltalkに近く、継承よりも コンポジション を強く好むので、特によく合っていた
オブジェクト指向言語では通常、ユーザー、ブログ記事、金銭取引のような「考えたい対象」ひとつに集中し、それを他から切り離して実装し、データを隠したうえでシステムの他の部分にどのメソッドを公開するかを考える。カプセル化 の概念が非常に強い
データ指向設計では、異なるドメインのデータにアクセス可能で、サブシステムが自分の作業に必要なものを選んで使うやり方のほうが一般的だ。JavaやRubyがそれを妨げるわけではないが、プログラマーには明確な心理的障壁がある
また、Rのデータフレーム、PythonのPandas、JuliaのDataFrames.jlのように、SoAをAoSのようにアクセスできるようにするソフトウェア支援にも触れている
自分はSnowflakeがとても好きで、他の競合の昼飯を奪うことになると思っている。Snowflakeが外部キーを「サポート」してはいるが強制しない点も面白い。言い換えると、Snowflakeは自分が受け入れられる程度の「NoSQL」だ
もうひとつは、カプセル化を手放し、データとそのデータを扱うメソッドを分離し、アプリ全体をデータがどう流れるかを基準に考え、理解しやすく変更しやすいようにモデリングする方式だ。より正確さを求めるなら、不変データ構造 と純粋関数を使うこともできる
興味のある人向けのごく短いECS紹介: https://dev.to/ovid/the-unknown-design-pattern-1l64
「データ配置が、ある一つの観点から導かれた単一の解釈によって定義されるのか？」は、技術選定とアーキテクチャの観点で最も重要な問いかもしれない。通常、この問いに答えるにはビジネスや顧客と話す必要がある
データに対して全体で使える有効な「ビュー」が正確に1つだけあると確信できるなら、それをコードに刻み込むのも理にかなっている。少しでも確信がないなら、リレーショナルスタイルのモデルの方が適している可能性が高い。この問題のゲーム理論に気づいた企業の多くは、結局 SQL に行き着く
どうして皆が1つの大きな SQL データベースから離れたように見えるのか不思議に思う。書き込み処理の垂直スケーラビリティを脅かす「Web スケール」のエッジケースはあるが、F100 企業を含め、ほとんどの会社はそこにすら到達しないと思う
それは特定のデータセットを最もうまくモデル化する方法や最高の性能とは無関係で、完全にスキーマの柔軟性と、スキーマ移行の失敗で障害が起きた過去が理由だった。NoSQL 設計ではそうした問題は起きず、SQL データベースの利点も、スキーマが固定されていない NoSQL の大きな利点を打ち消すほどではなかった
もちろん、キー・バリュー・ストアを誤って使えば性能やコストは大きく悪化しうる。DynamoDB のようなクラウドプラットフォームでは、データを適切に構造化できずに大量のスキャンを行い、コストが爆発した例を数多く見た
古い大企業なので、非技術職の人たちが過去に作った技術的解決策が固定化され、そのまま維持され続けなければならないことが多い。運用データベースから始まり、事業の種類が変わるたびに別の世代のデータモデルへつながっていく SQL データ変換の5段階 が存在する
レイヤーが積み重なるほど、以前のレイヤーの上にさらに積み上げ続けることになる。10年前に抽象化レイヤー2の上に作られたアプリケーションが、今ではレイヤー4のデータを必要とするなら、そのデータを古いレイヤーへ戻すスクリプトを作って先へ進む。最終的には、相互依存するテーブルやビューが、奇妙で直感的でない形でデータを読み取る巨大な塊になり、それを整理するプロジェクトは高コストすぎると判断されて2030年代まで先送りされた
こうした問題を見て、どうすれば避けられたのかと考えるのは理解できる。だが理由はよくわからないものの、ソフトウェアエンジニアに規律を必要とするやり方を適用するのは不可能に見え、何とかしてスパゲッティを作れないようにしなければならない。そこで分離が出てくる。他のサービスのデータを読めなければ、両側の速度を殺すスパゲッティは作れない
アプリケーションの垂直分離は、企業における貧弱なエンジニアリング規律という人間の問題に対する、ソフトウェア的な解決策になる
最近、データ指向設計に全面的に基づいたオープンソースフレームワークを公開したが、この設計がぴったり合うという反応を多くもらった。すべてのデータを1か所に置くと、本当に多くのことが簡単になる
https://sql.ophir.dev
巨大な DB には、誰も使っておらず、なぜ存在するのかもわからないが、まだ必要かもしれないので消せない残骸が大量にあり、読み取りと書き込みには異なる最適化戦略が必要だった
また、チームが素早く動くには、DBA がチケットに返答するのを待つのではなく、データベースとデータストアに対する 所有権 を持つ必要があった
大きな古い会社で働いていたとき、問題の大半は政治的・事務的なものだった。1つの大きな SQL データベースは効率的だが、それを所有する組織が新しい CTO 戦略や別の中核事業部門と意見が合わなくなった瞬間に問題になる
そこに、このモデルの回復力の低さを示す障害が加わると、すぐに政治的な厄介事となり、技術的な解決策は誰の目にも依然として明白でも、推進するのが難しくなる
この助言全体は 文脈依存 だ
ゲームには列指向のアプローチを必要とする処理が多いだけで、すべてのドメインがそうではない。ゲーム向けのベストプラクティスを他のドメインに盲目的に押し込めば、皆を苦しめ、ほとんどのシステムを悪化させるだけだ
bool の構造体フィールドはビットセットにできるし、nullable なフィールドは疎または密なマップにできる。ポインタや参照フィールドは、プールをインデックスする、より小さい幅の整数配列にできる
CPU がメモリアクセスで頻繁に止まる環境では、こうした変化の影響を過小評価できない。L3 キャッシュと RAM レイテンシ の差は、おおよそ10倍に達することがある
性能が少しでも問題になるプログラムであれば、これは良い性能を確保するための方法の1つである可能性が高い
最新ハードウェアで今後も拡張し続けると期待できるのは、論理密度だけだ。SRAM やキャッシュサイズは最新のリソグラフィではもはやうまくスケールせず、RAM 帯域幅もかなり前から大きくは増えていない。コアあたりの帯域幅はむしろ減っているかもしれない。メモリアクセスはずっとボトルネックだった
データ指向設計は特定のサブシステムの内部では非常に妥当だが、高レベルのゲームプレイコードでは、特定のジャンルを除けば必ずしもそうではない
Mike Acton の CppCon 2014 の発表 Data-Oriented Design and C++ は、これまでで最高のプログラミング発表だと思う。ぜひ見る価値がある: https://youtu.be/rX0ItVEVjHc
以前は Unity DOTS も主導していたが、残念ながら今の Unity は揺らいでいるように見える。DOTS の作業自体は未完成でも堅実だ
キャリアの大半を Web アプリを書くことに費やしてきたが、この発表を見て「なぜ誰かが C を使うのか」を理解できるようになった
Andrew Kelley が、データ指向設計が Zig コンパイラの作業にどのような影響を与えたかを説明した、有益で面白い発表をしている: https://vimeo.com/649009599
初心者でも最初からデータ指向のやり方でプログラミングを学べる。
このスタイルを初心者に教える本としては How to Design Programs と A Data-Centric Introduction to Computing がある。
https://htdp.org/
https://dcic-world.org/
この本のオンラインレビューを見つけた: https://gist.github.com/seece/25ed1b2108cf5782718b026382f2c5...
「多くのプロジェクトを苦しめ、遅らせる元凶は、最適化を早まって行うべきではないという頑なな姿勢だった。後半段階での最適化がそれほど難しい理由は、多くのソフトウェアが、必要でない場合ですらあちこちにオブジェクトインスタンスを置くやり方で積み上げられているからだ。」
性能が最優先のアプリケーションも確かにあるし、そうでないアプリケーションもある。性能が重要なアプリでは 早すぎる最適化 も許容されるのか、ということを考えさせられる。こう読むのが正しいのか気になる。
Data-Oriented Programming というものもある: https://www.manning.com/books/data-oriented-programming
この二つの概念が同じものなのか気になる
データ指向設計は初心者向きだ。人やビジネスを扱うより、データモデリングの純粋性 だけを扱うからだ。
子どもの頃、新しいプロジェクトの最初の段階はエンティティ・リレーションモデルを描くことで、それがすべての土台になっていた。
今では、データモデルを始める前に問題やドメインを理解し、能力とそれをどうまとめ、どう境界づけるかを先に考える
ただ、この文章は、最初からデータ要件を集めることに集中すれば、ビジネス要件の議論自体があまり必要なくなるかもしれない、と言おうとしているようにも見える
DoD を使うときの重要な概念の一つは、データを抽象化の背後に隠さないことだ。少ないほどよい という立場だ。
ところが紹介文をざっと読んでみると、むしろ逆に感じられた。言葉が多すぎて、肝心の概念を抽象化してしまっている。自分のワインを飲んでいないようで、皮肉に感じたのは私だけだろうか
導入段落はかなり素晴らしい。流麗な文章と興味深いアイデアのおかげで、続きを読む気にさせられる。
「データこそが、私たちの持つすべてだ。データとは、ユーザー体験を作るために私たちが変換しなければならないものだ。文書を開くときに読み込むものもデータだ。画面上のグラフィックス、ゲームパッドのボタンのパルス、スピーカーが空気中に波を生み出す原因、レベルアップの仕組み、敵があなたの位置を知って撃てるようになる方法もデータだ。ダイナマイトが爆発するまでの時間や、トゲに落ちたときに失うリングの数もデータだ。ゲームを終えた美しいシーンの中のあらゆる粒子の現在位置と速度であり、ディスクから読み込まれてあなたの人生に入り込んだそれは、コンパイラに食わせたソースコード、アセンブラが指示した命令、そしてデコードされた命令で動く機械の変換を経た結果なのだ。」
舞台を整えて、オブジェクト指向の抽象化の考え方から抜け出させるための「冷や水を浴びせる一撃」としては有用かもしれない。だがそれ以外では、エンジニアが「周りを見ろ！ すべては原子でできている！ 工学とは根本的には原子を動かすことだ！」と言うのと同程度の有用性しかないように思える。
間違ってはいないが、実際に工学をするうえではあまり役に立たない