リソース管理で、DAGを用いたコンテンツアドレス指向が、ロケーション指向より優れている点

ロケーション指向のリソース管理よりも、DAGを用いた管理の方が優れている用例を紹介しながら、
なぜ優れているかを理解していきたい。

比較的小規模なリソース管理では

比較的小規模なリソース管理では、「バージョニング」を実現するときにコンテンツアドレス指向のリソース管理は効果を発揮します。

こちら(https://proto.school/merkle-dags/07)の記事をぜひお読みください！

この記事の写真部分を見てください。

この前提において、ロケーション指向のリソース管理の考え方でいくと、では、バージョン1、バージョン2の両方を全部持っておく必要がありますよね。

バージョン1を保存する領域にあるものと、バージョン2を保存する領域に多くの重複リソースが生まれることになります。。

(※この部分は自分用です。スルーしてください。)ここで、二つから参照しているなら共通化すればいいのでは？と僕は一瞬迷ってしまいました。
しかし、それはロケーション指向ではなく、コンテンツアドレス指向の考え方でした😅。当初の自分は混乱してしまったのでメモです。

コンテンツアドレス指向だと、バージョン1とバージョン2で同じ部分を違う箇所に保存する必要がなくなります！つまり、部分的に2/1になるのです

Gitを使うにあたって、Gitがどのように変更の履歴を管理しているのかを詳しく理解しなくても全然使えます！
もし読者の方が、今からGitを学習しようとしているのなら、身構える必要はありません！Gitは素晴らしいものです！

Gitは、バージョン管理のツールです。
DAGが得意とするパターンです。

Gitは、MerkleDAGによく似た構造を採用しています。

これによって、同じファイルを複数管理することなく、差分を表示させたり、変更履歴を確認したりできるようになるのです。

普段開発していると、Gitは「変更した差分」だけを管理しているように思えますが、厳密にはそうではありません。変更があったファイルのスナップショットだそうです！

コミットはスナップショットであり差分ではない

gitマニアになれそうです！

プロジェクトのバージョン管理のような小さなスケールではなく、もっと巨大なユースケースを考えてみましょう！

Web閲覧でのリソース管理です！

これほど巨大なユースケースはありませんね😂

ロケーション指向だと、一つの「場所」にコンテンツがあるので、似たようなデータを持っている場合でももう一度取得する必要がある場合がほとんどです！

ワードプレスのテーマ作成を例に考えてみましょう！
もしこれがコンテンツ指向の管理だったとしたら、一度ワードプレスのテーマの根幹部分を取得して、そのあとはそれぞれのページに加わった変更部分だけを読み込んでいけば、全く別のテーマでも、根幹部分を再度取得する必要はなくなります。

最初、読んだときにヘッダーとかフッターのことかと思っていましたが、どうやらそうではなさそうです。
サイトを構築するときに、テーマを利用しますよね！そのテーマを所有するサーバーにダウンロードするということかなと思いました。

Webサイトの制作を仕事にしていたら、サーバーにワードプレスをインストールして、サーバーにテーマをインストールして、、、。といった作業を何度も行なったことがあると思います。それを削減する方法として、コンテンツ指向型は非常に効果を発揮するかもしれないということです。

具体的な方策が提示されていたわけではないので、未実現なのかもしれません。この技術を使って実現できそうな未来を感じ取るためには十分でしょう！

コンテンツアドレス指向の管理方法でできそうなことは、web全体のリソースの効率化だということが感じ取れました。