『データベース指向アプリケーションデザイン』の 12 章「データシステムの将来」を読んだのでそのメモ
12.1 データのインテグレーション
データが利用される様々な環境のすべてに適した単一のソフトウェアなどはおそらく存在しないので、そういったアプリケーションの機能を実現するには、複数のソフトウェアを組み合わせざるを得なくなります
だからこそ、あらゆるユースケースを知り、それらへ対応する方法を知識と知っておくことが、対応するための第一歩って感じで本書が紹介されてきたのかなーと思った。
この章は、導出データや分散トランザクション、全順序の限界など、今までの章で紹介されてきた概念を総合的にまとめている。
12.2 データベースを解きほぐす
章のタイトルがいまいちピンと来なかった。
データベースを、単なるデータを保存してクエリを実行して取り出せるようにするだけの存在として捉えるのではなく、Unix のファイルシステムと通ずる部分として「情報管理」システムとしての側面を捉え、複数の視点からデータベースについて考察することで、理解を深めることなのかな。
様々なストレージや処理のツールが 1 つのシステムにまとめ上げられる筋道は、2 つあると推測する
フェデレーテッドデータベース: 読み取りの統合
幅広い下位層のストレージエンジンや処理の方法に対し、統一されたクエリインターフェースを提供
んーちょっと何を言っているのか。。
解体されたデータベース: 書き込みの統合
ここも理解できないので、後回し。
12.2.2 データフロー中心のアプリケーション設計
12.2.2.1 導出関数としてのアプリケーションコード
12.2.2.2 アプリケーションコードと状態の分離
この辺りは、少しアプリケーション設計よりの話もあるので、ちょっとは理解しながら読むことができる。
例えば
トレンドは、状態を持たないアプリケーションのロジックを状態管理（データベース）から分離することであり、アプリケーションロジックをデータベースに置くことや、永続化される状態をアプリケーション中に置くことではなかった
とかは、責務の分離などを日頃から意識するので、あーってなるはず。
12.2.2.4 ストリームプロセッサとサービス
マイクロサービスの話が出てきた。もはやアプリケーションのお話に近いのか？
疎結合を通じて組織的にスケーラビリティを得られるなどのメリットが書いてある。マイクロサービスごとにチームで独立することができるのは、非常にありがたい。それぞれのサービスが独立してデプロイしたりできるので、チーム間の調整が減る。
12.2.3.2 ステートフルでオフライン動作できるクライアント
これも結構アプリケーション開発に関わる話題。firestore などのオフライン対応のデータベースを使うことで、オフライン時にもアプリケーションを動かすことができる。
Notion もオフラインで動作できるし、オンラインになった瞬間にデータをクラウドに保存してくれる。やはりこのアプリケーションの設計はもうすでに活用されるレベル。知ってはいたが、実際に活用する場面が想像できていなかった。
12.3 正確性を求めて
12.3.1.1 操作を厳密に一度だけ実行する
操作を冪等にすることが最も効果的なアプローチ。
12.3.1.2 重複の抑制
重複する操作を抑制することで、正確性を保証することができる。が、トランザクションの仕組みを理解するだけでは難しく、リクエストをエンドツーエンドで考慮しなければならない。まあこれは当たり前で、ある部分だけの重複が抑制されていたとしても、最終的な利益を享受するエンドユーザーにとって重複が抑制されなければ意味がない。「12.3.1.4 エンドツーエンド論」に繋がる。
アプリケーション自身がエンドツーエンドで重複抑制などの処置をする必要があります
ソフトウェアのバグがあっても整合性を保つ
アプリケーション側でやることはあると言いつつも、データベースシステム側でもやるべきことをやる。例えば外部キーやユニーク制約など。
12.4 正しいことを行う
私たちはデータが抽象的なものであるかのように話をしていますが、多くのデータは、人の行動、関心、アイデンティティなど、人に関するもの
人間性と尊厳を持って扱わなければなりません
この観点は全くなかったけど、言われてみれば確かにそうだなー。
12.4.1 予測分析
システム的に雇用から弾き出され、空の旅、保険の適用、借家、金融サービス、あるいはその他の社会的に重要な局面からも阻害されることになれば、それは「アルゴリズムによる監獄」と呼ばれるほど
ビッグデータがあると、実際それができちゃう世の中にいるのか。。こうなるのは避けたい、けど一定あり得そう。
私たちは、データが人々を傷つけるために使われないようにし、その代わりにデータの良い方向の可能性を見出さなければなりません
データに基づく意思決定は確かに増えているけど、そのアルゴリズムがシステム的に特定の人種や宗教の人々を差別している場合、それは誰が責任を取るのか？そういった間違いを犯してしまう可能性がある以上、その回避策は見出す必要がある。納得。
12.4.2 プライバシーと追跡
A/B テストやユーザーフロー分析は、ユーザーインターフェースをどう改善しうるかを示す役に立ちます
しかし、企業のビジネスモデルによっては、追跡はそこで終わりません
サービスに費用を払っている広告主のために行われます
この関係にはより悪意を匂わせる監視という言葉が当てはまるのではないでしょうか
監視、と言い換えることができる性質を持っているのは、確かに。監視と言えちゃう以上、データを扱う際にそれは本当に利用するエンドユーザーのためになっているかを考える意識が必要そう。
プライバシーを保つということは、何もかも秘密にするわけではありません。これは、何を誰に明らかにするか、何を公にするか、何を秘密のままにしておくのかを選択する自由があるということです
要するに、判断する権利を持っていたら、それはプライバシーを保てているということ。
多くの企業は、ユーザーから不気味だと受け取られないという目標を持っています
思い返せば、「監視」を感じるサービスには、直感的に怪しい、と思うことがまあまあある。怪しいと思ったから、あまりここに履歴を残したくないな、と感じる。それが実際には「監視」を逃れる行為になっている、という思考の流れかも。だから企業はユーザーから不気味だと受け取られない、という目標があるのかな？
ソフトウェアとデータが世界に対してこれほど大きな影響力を持っていることを踏まえれば、私たちエンジニアは、私たちが暮らしたいと願うような社会に向かって働く責任を負っています。それは、人々に思いやりと尊重を持って接するような世界です。私たちが、共にこの目標に向かっていけることを、私は願っています
締めくくりの言葉が心に刺さる。ソフトウェアエンジニアとしての責任を果たしたいと思う。