Garden

最近の記事

DBにはいろんな削除がある

26 min read

Tldr

Q. DBにおける「削除」の方法について教えてください。
A. DBの削除には主に3つの方法があります。物理削除はデータを完全に消去し、容量を節約できますが復元は困難です。論理削除は削除フラグでデータを非表示にするため復元が容易で履歴も残せますが、データ自体は残ります。イベントソーシングは削除も一つのイベントとして記録し、過去の変更を許さない不変性を重視します。GDPRのような法的要件では、物理削除や匿名化が必要な場合もあります。削除は単なる消去ではなく、データのライフサイクルと整合性を管理する重要な概念です。

Q. イベントソーシングを大真面目に採用したDBはありますか？
A. はい、EventStoreDBやDatomicなどがあります。EventStoreDBは追記のみで更新概念がなく、Datomicはデータベースを不変のデータ構造として扱い、過去の時点へのタイムトラベルが可能です。これらのDBは、イベントを再生することで究極のデバッグ能力や監査ログの保証、リードモデルの柔軟性を提供します。しかし、学習コストやイベントのバージョニングといった課題もあります。これらは上書きを制限し、真実の履歴を重視する設計思想を持つデータベースです。

Q. 論理削除の別バージョンとして、削除済みレコード用のテーブルを使う方法はありますか？
A. はい、アーカイブパターンとして知られる方法があります。これは、削除時にレコードをメインテーブルから削除済み専用のアーカイブテーブルへ移動させるものです。これにより、メインテーブルが軽量化され、検索パフォーマンスが向上し、型純粋性も保てます。しかし、スキーマ変更時の両テーブル同期や参照整合性の破壊が課題です。SQL標準には、DBが自動で履歴を管理するSystem-Versioned Temporal Tablesという機能もあります。この方法はパフォーマンス向上に有効ですが、保守コストやDB製品の選択が伴います。

Q. データ肥大化によるパフォーマンスの悪化は、アーカイブテーブルであれば避けられますか？
A. はい、メインテーブルのパフォーマンス悪化は劇的に避けられます。アーカイブテーブルを使うことで、メインテーブルのインデックスがスリム化され、検索効率が向上します。また、スキャンの範囲が制限され、書き込み（INSERT/UPDATE）も高速化されます。ただし、「全期間検索」が重くなることや、データ移動時のトランザクション管理など、システム全体の複雑性は増大します。テーブルパーティショニングも同様の効果を持つ解決策の一つです。これはデータに「忘却」という規律を持たせることと言えます。

Prompt

DBにおける「削除」の方法について…

DBにおける「削除」……。これは情報工学を学ぶキミにとって、単なるデータの消去ではなく、**「データのライフサイクルと整合性をどう管理するか」**という、極めて哲学的で戦略的なテーマだね！

「一度消したものは戻らない」という物理的な恐怖（ムチ）と、「履歴を残して安全に運用する」という設計の知恵（アメ）。このバランスをどう取るか、3つの主要なアプローチを解剖していこう！

1. 物理削除 (Hard Delete)

文字通り、DELETE 文を使ってデータベースのテーブルからレコードを物理的に抹消する方法だ。

  • クエリ: DELETE FROM users WHERE id = 1;

  • メリット: ストレージ容量を節約できるし、検索クエリに余計な条件がいらないから高速。

  • リスク: 「あ、間違えた！」が許されない。 バックアップから戻さない限り、データは虚無（never）へ消え去る。

  • 情報工学的視点: 参照整合性（Foreign Key）がある場合、親を消すと子も消える（CASCADE）か、エラーになる。まさに「一蓮托生」の規律だね。

2. 論理削除 (Soft Delete)

実務で最もよく使われる、**「削除フラグ」**を立てる方法だよ。データは物理的には残っているけれど、アプリケーションからは「消えたもの」として扱うんだ。

  • 手法: is_deleted というカラムを追加し、削除時に 1 (True) を入れる。

  • メリット: 簡単に復元（ロールバック）できるし、「いつ、誰が消したか」という監査ログ（履歴）としても機能する。

  • 心地よい制限: 「消す」のではなく「非表示にする」という状態遷移として捉える。これは音楽で言えば、**「音を消すのではなく、ミュート（弱音器）をかける」**ようなものだね。

3. 歴史的・不変的アプローチ (Event Sourcing)

キミが好きな「不変性（Immutability）」を極限まで高めた方法だよ。

  • 考え方: データを「現在の状態」として保存するのではなく、「発生した出来事（イベント）」の積み重ねとして保存する。

  • 削除の扱い: 「削除した」という新しい事実（イベント）を追加するだけ。過去の「作成した」という事実は永遠に残り続ける。

  • 哲学: 「過去は変えられない」という数学的な規律に基づいている。Gitのコミット履歴に近い感覚だね。

💡 豆知識：GDPRと「忘れられる権利」

ここで少し法的な「制約」の話をしよう。

ヨーロッパのGDPR（一般データ保護規則）には「忘れられる権利」というのがある。もしユーザーが「私のデータを消して！」と言ってきた場合、論理削除では不十分な場合があるんだ（物理的にサーバーから消さなきゃいけない）。

「安全のために残しておきたい」というエンジニアの欲求と、「完全に消してほしい」というユーザーの権利。このコンフリクトを解決するために、**「個人情報だけをランダムな文字列で上書き（匿名化）して、統計データとしての価値だけ残す」**という、エロガントな中間解も存在するよ。

🌟 結論：削除は「状態の遷移」である

キミがこれまで学んできた「型」や「ラムダ式」の世界観で言うなら、削除とは 「有効なデータの集合から、無効なデータの集合へ写像（Mapping）すること」 とも言える。

「物理削除」は破壊的な副作用だけど、「論理削除」や「イベントソーシング」は副作用を履歴という名の「構造」に変える行為なんだ。

キミが今作っている「AXON」では、ユーザーの投稿をどう扱うべきかな？

「間違えて消しちゃった！」と泣いているユーザーを救うための「論理削除」か、それともストレージを極限まで削ぎ落とす「物理削除」か……。

次は、この論理削除を Prisma や Zod と組み合わせて、クエリを書くときに自動で is_deleted: false を差し込む「自動フィルター」の作り方について話してみる？😉

Would you like to see how to implement an automatic soft-delete middleware in an ORM like Prisma?

Prompt

イベントソーシングを大真面目に採用したDBってあるの？

「イベントソーシングをDBそのものの設計思想として大真面目に採用した製品」は、実はいくつか存在するよ！

普通のDB（RDB）が「今のスナップショット」を正解とするのに対し、これらは**「過去から現在に至るすべての経緯（イベント）」こそが真実である**という、情報工学的に非常にピュアで、キミ好みの「規律」に満ちた設計になっているんだ。

代表的な「変態的（最高に褒めてる）」なDBを2つ紹介するね！

1. EventStoreDB (ESDB)

その名の通り、イベントソーシングのためにゼロから設計されたオープンソースのデータベースだ。

  • 哲学: データを「更新」することは決してない。新しいイベントを**Append Only（追記のみ）**で末尾に追加し続ける。

  • 心地よい制約: UPDATE という概念そのものが存在しないんだ！

  • プロジェクション: 「今の合計金額は？」といった現在の状態を知りたいときは、保存されたイベントを最初から再生（リプレイ）して計算する。これを高速化するために、バックグラウンドで「スナップショット」を作る機能も備わっているよ。

2. Datomic

これは、プログラミング言語 Clojure の生みの親である Rich Hickey が設計した、極めて哲学的な分散データベースだよ。

  • 不変性の極致: Datomicにおいて、データベースは「時間の経過とともに変化する値」ではなく、**「過去のすべての瞬間を内包する不変のデータ構造」**として扱われる。

  • タイムトラベル: 「2025年12月24日 21:00時点のDBの状態」に対してクエリを投げることが標準機能として備わっている。

  • 情報工学的視点: データを Entity - Attribute - Value - Transaction(Time) の4要素（Datom）で管理している。削除すら「その事実が追加された」という履歴に過ぎないんだ。

💡 なぜこれらが「大真面目」に採用されるのか？

普通のRDBでイベントソーシングをやろうとすると、テーブル設計が複雑になりすぎて、まさに「魔境」になりがちだよね。でも、これら専用DBを使うと以下のような「アメ」が得られるんだ。

① 究極のデバッグ能力（リプレイ）

バグが見つかったとき、当時のイベントをそのまま開発環境でリプレイすれば、「なぜその状態になったのか」を100%再現できる。 これは副作用を排除したラムダ計算の純粋さに通じるものがあるね。

② 監査ログが「仕様」として保証される

銀行システムや在庫管理のように、「1円の狂いも許されない、経緯がすべて」というドメインでは、イベントソーシングこそが最強の武器になるんだ。

③ リードモデルの柔軟性

保存されているのは「事実」だけなので、後から「やっぱりこういう分析画面も作りたい」と思いついたときに、過去のイベントを全部読み直して新しい形式のDB（RDBやElasticsearchなど）に変換して出力することができる。

⚠️ ただし、強烈な「ムチ」もある

  • 学習コスト: 思考回路を「スナップショット」から「イベント流」に完全に切り替える必要がある。

  • バージョニング: 3年前のイベントと、今のイベントでデータ形式が変わってしまった場合、どうやって互換性を保つかという「イベントの進化」問題に直面する。

🌟 結論：DBは「歴史書」になる

キミが「自由を制限して進むべき道を示すのが心地よい」と言ったけれど、イベントソーシングDBはまさに、**「上書き（改ざん）という自由を奪うことで、真実という道を示す」**仕組みなんだ。

キミが専門学校で学ぶ「普通のSQL」の世界を超えて、こうした「時間の概念を取り込んだDB」を知ることは、情報工学徒としての視野を一気に広げてくれるはずだよ！

次は、このイベントソーシングの考え方を Frontend（ReduxやReactのReducer） でどう応用するか、その「状態遷移の美学」について深掘りしてみる？😉

Would you like to explore how Redux’s action-reducer pattern is essentially a mini event-sourcing system inside your browser?

Prompt

論理削除の別バージョンとして、削除済みレコード用のテーブルを使う方法はないの？

さすが、キミの直感は鋭い！その「削除済みレコード専用のアーカイブテーブルに移動する」という手法は、情報工学の世界では**「履歴テーブル（History Table）」や「アーカイブパターン（Archive Pattern）」**として知られているよ。

論理削除と物理削除の「良いとこ取り」をしようとする、非常にコンストラティブなアプローチだね！この手法の「規律」と「美学」を解剖してみよう。

🛠 削除済みテーブルへの移動（アーカイブパターン）

この手法では、メインの users テーブルからデータを DELETE する際、その瞬間にトリガー（Trigger）やアプリケーションロジックを使って、全く同じ構造を持つ deleted_users テーブルへデータを「引っ越し」させるんだ。

✅ この手法が「アメ」をくれる理由

  1. メインテーブルの軽量化（パフォーマンス）

    論理削除（フラグ）だと、データが増えるほど WHERE is_deleted = false のスキャン対象が増えて、インデックスの効率が落ちていく。アーカイブパターンなら、メインテーブルには「生きているデータ」しか残らないから、クエリが常に爆速に保たれるんだ。

  2. 「型」の純粋性を守れる

    キミがさっき感じた「RustのORMとの相性」も解決するよ。メインテーブルを叩くときは、フラグのことを一切気にせず、ピュアな User 型として扱える。

  3. ストレージの階層化

    「生きたデータ」は高速なSSD（高価）に置き、「削除済みデータ」は安価で低速なHDDやクラウドストレージ上の別テーブルへ飛ばす、といったコスト最適化が可能になる。

⚠️ この手法が突きつける「ムチ（制約）」

ただし、この「心地よい整理整頓」には、それ相応のコストがかかるよ。

1. スキーマ変更の二重苦

テーブルが2つあるということは、カラムを追加するたびに両方のテーブルのスキーマを同期させなきゃいけない。これを忘れると、削除（引っ越し）の瞬間にシステムがクラッシュする「魔境」が生まれるんだ。

2. 参照整合性の破壊

これが一番の頭痛の種。もし posts テーブルが users を参照していた場合、ユーザーをアーカイブテーブルに移した瞬間、外部キー制約（Foreign Key）が切れてしまう。

  • 解決策: 関連データもすべて一緒にアーカイブするか、外部キーを外して「論理的な紐付け」だけにする必要がある。

💡 現代的な解決策：Temporal Tables（期間テーブル）

実は、SQL標準（SQL:2011）には、この「履歴管理」をDBエンジン側で自動化する System-Versioned Temporal Tables という機能があるんだ（SQL ServerやMariaDBなどでサポートされているよ）。

  • 仕組み: カラムを追加しなくても、DBが勝手に「過去のバージョン」を裏側の履歴テーブルに保存してくれる。

  • クエリ: SELECT * FROM users FOR SYSTEM_TIME AS OF '2025-12-01' と打つだけで、過去の時点のデータが復元される。

これこそ、キミが求めている**「自由（上書き）を制限し、時間の流れという規律をDBそのものに組み込む」**究極の形かもしれないね！

🌟 結論：どの「コード（Code）」を選ぶか？

  • フラグによる論理削除: 手軽だが、時間が経つと「濁る」。

  • アーカイブテーブル: 整理されるが、保守が「重い」。

  • Temporal Tables: 最もエロガントだが、DB製品を選ぶ。

キミが今開発している「AXON」の規模なら、まずは「アーカイブテーブル」的な発想で、削除済みデータを別テーブル（あるいはログ）に逃がす設計にしてみるのが、Rustの型安全性を活かす上でも面白い挑戦になると思うよ！

次は、この「データの引っ越し」を、Rustの Drop トレイト や データベーストリガー のどちらで実装するのがより「規律にかなっているか」、議論してみる？😉

Would you like to explore how to implement an automatic “Move to Archive” logic using PostgreSQL Triggers?

Prompt

データ肥大化によるパフォーマンスの悪化は、アーカイブテーブルであれば避けられる？

結論から言うと、「メインテーブルのパフォーマンス悪化」は劇的に避けられるけれど、システム全体の「複雑性という名のコスト」は増大する、というトレードオフになるよ！

情報工学的な視点で、なぜアーカイブテーブルがパフォーマンスの特効薬になるのか、その「物理的な理由」を解剖してみよう。

1. インデックスの「スリム化」と検索効率

DBのパフォーマンスが悪化する最大の原因は、データの行数そのものよりも**「インデックスのサイズ」**にあるんだ。

  • B-Treeインデックスの深さ: データが数千万、数億件と増えると、インデックス（B-Tree構造）の階層が深くなる。すると、1つのデータを探すためのディスクI/O回数が増えてしまうんだ。

  • アーカイブの効果: 削除済みデータを別テーブルに移せば、メインテーブルのインデックスは「今生きているデータ」分だけで済む。階層が浅く保たれ、メモリ（Buffer Pool）にインデックスが収まりやすくなるから、検索が爆速に維持されるんだ。

2. スキャンの範囲制限

全件走査（Full Table Scan）や、範囲検索（Range Scan）が発生した時の挙動を考えてみて。

  • 論理削除フラグの場合: WHERE is_deleted = false と書いても、DBは「消されたデータ」の死体の山をかき分けて進まなきゃいけない。特にインデックスが効かないクエリだと、読み込むディスクブロック数が膨大になる。

  • アーカイブテーブルの場合: メインテーブルには「生きているデータ」が密集（高密度）している。DBは無駄なページを読み込む必要がなくなり、I/Oの効率が最大化されるんだ。

3. 書き込み（INSERT/UPDATE）の高速化

キミが好きな「副作用の管理」の話にも繋がるけど、実は書き込み性能も向上するよ。

  • インデックス更新の負荷: レコードを挿入・更新するたびに、DBはすべてのインデックスを更新する。テーブルが巨大だとこのコストが馬鹿にならない。

  • 断片化（Fragmentation）の抑制: 頻繁に論理削除（Update）を繰り返すと、DBのデータファイルの中に「穴（空き領域）」がボコボコ空いて、物理的な配置がバラバラになる。アーカイブ（引っ越し）を定期的なバッチ処理で行えば、メインテーブルの物理的な並びを綺麗に保ちやすくなるんだ。

🛠️ ただし、新たな「魔境」も現れる

アーカイブテーブルを採用すると、パフォーマンスと引き換えに以下の課題（規律の試練）に直面するよ。

  • 「全期間検索」の鈍化: 「削除済みも含めて過去10年の全データを集計したい」というリクエストが来た時、2つのテーブルを UNION ALL で繋ぐ必要があり、このクエリは非常に重くなる。

  • データの一貫性管理: メインからアーカイブへデータを移動させる瞬間にシステムが落ちたら？という「トランザクションの境界線」を厳密に管理する Rust のような堅牢な実装が求められるね。

💡 豆知識：パーティショニング（Partitioning）

実は、アーカイブテーブルを「自前」で作らなくても、DBの機能である 「テーブルパーティショニング」 を使うという中道（エロガントな解決策）もあるよ！

  1. created_at（作成日）などの基準で、1つのテーブルを物理的に複数の「パーティション」に分割する。

  2. 古いパーティションだけを、低コストなストレージへ物理的に追い出す。

  3. アプリケーション側からは、**「あたかも1つのテーブル」**に見える。

これなら、キミが心配しているパフォーマンス悪化を防ぎつつ、コードのシンプルさ（規律）も保てるんだ。

🌟 結論：アーカイブは「新陳代謝」

データの肥大化による悪化は、アーカイブによって確実に避けられる。これはプログラムに 「忘却（新陳代謝）」という規律 を持たせることなんだ。

「すべてを一つの場所に持ち続ける自由」を捨てて、「今必要なものだけを研ぎ澄ます制限」を受け入れる。まさに、キミが心地よいと感じた設計哲学そのものだね！

この「データの移動」を自動化する 「バックグラウンド・ワーカー（Rustの得意分野！）」 の設計について、さらに深掘りしてみる？😉

Would you like to discuss how to build a reliable Data Archiving Worker in Rust using a job queue?

グラフビュー

バックリンク

最近の記事

グラフビュー

バックリンク