論理削除（ソフトデリート）と物理削除（ハードデリート）では、テーブルの件数が増えていった場合、どちらのパフォーマンスが優れているのでしょうか？
まず手始めに、Chat-GPTに聞いてみます。
いいねボタンを論理削除または物理削除で実装する場合のそれぞれのメリットとデメリットは以下の通りです。
論理削除のメリット:
- データ保持: 論理削除は実際にデータを削除せず、削除フラグや状態を更新する方法です。ユーザーが誤っていいねを取り消した場合でも、データは保持されます。後から取り消しをやり直したり、履歴を確認する場合に役立ちます。
- 復元可能性: 削除されたいいねを復元する必要がある場合、論理削除では簡単に復元できます。ユーザーが誤っていいねを削除した場合や、アカウントの一時的な無効化後に再アクティベートされた場合などに役立ちます。
- レポートや分析: 論理削除を使用すると、削除されたいいねの統計情報を保持しながら、分析やレポート作成が容易になります。データの完全性を保ちつつ、ユーザーの行動パターンやトレンドを追跡できます。
論理削除のデメリット:
- パフォーマンス: 論理削除では削除されたデータをフィルタリングする必要があります。データベースクエリやアプリケーションのロジックが複雑になり、パフォーマンスに影響を与える可能性があります。特に、大規模なユーザー数を想定している場合は、パフォーマンスの問題に注意が必要です。
- ストレージ: 論理削除では、削除されたデータを保持する必要があります。これにより、不要なデータがデータベースに残るため、ストレージの使用量が増加する可能性があります。長期間にわたって大量のデータを保持する場合、ストレージの管理が必要です。
物理削除のメリット:
- パフォーマンス: 物理削除では、削除されたデータを完全に削除するため、データベースのクエリや処理のパフォーマンスが向上する可能性があります。データベース内のデータ量が大きくなる場合や、高トラフィックのシステムで効果的です。
- ストレージ: 物理削除では、削除されたデータを完全に削除するため、ストレージの使用量を最小限に抑えることができます。データベースの容量を最適化する必要がある場合や、ディスクスペースが制限されている場合に有用です。
物理削除のデメリット:
- データの喪失: 物理削除はデータを完全に削除するため、削除されたデータを復元することはできません。誤っていいねを削除した場合や、後から取り消したい場合に困難です。ユーザーの間違った操作や、意図しない削除が起こる可能性があるため、注意が必要です。
- 分析の制限: 物理削除では、削除されたデータは完全に失われるため、分析やレポート作成において削除されたデータを考慮することができません。特定の期間内のいいね数やトレンドを正確に把握する必要がある場合、物理削除ではデータの完全性が損なわれる可能性があります。
以上が、いいねボタンを論理削除または物理削除で実装する場合のそれぞれのメリットとデメリットです。状況や要件に応じて、どちらのアプローチを選択するかを検討することが重要です。
上記の回答から、パフォーマンスの観点で考えると論理削除は物理削除に比べて懸念点が多いことがわかります。しかし、Chat-GPTの意見を鵜呑みにするのは少し、心許ない気もします。
そこで、stackoverflowでこの問題について検索していたところ
最も高い評価を受けている以下の回答を見つけることができました。
▼UPDATE vs INSERT performance
https://stackoverflow.com/questions/7299731/update-vs-insert-performance?rq=3
I am not a database guru but here my two cents:
Personally I don't think you have much to do in this regard, even if >INSERT would be faster (all to be proven), can you convert an update >into an insert?! Frankly I don't think you can do it all the times.
During an INSERT you don't usually have to use WHERE to identify which >row to update but depending on your indices on that table the operation >can have some cost.
During an update if you do not change any column included in any indices >you could have quick execution, if the where clause is easy and fast >enough.
Nothing is written in stones and really I would imagine it depends on >whole database setup, indices and so on.
こちらの回答を要約すると、
- INSERTとUPDATEのどちらを選択するかは状況次第。
- INSERT操作は通常WHERE句を必要としないが、インデックスに基づくコストが発生する場合がある。
- インデックス付きの列が変更されず、WHERE句が単純であれば、UPDATEは短時間で実行できる。
- 最終的な結果はデータベースのセットアップに依存する。
といった結論になっており、INSERT（物理削除）とUPDATE（ソフトデリート）のどちらを選択するかは状況次第で、どうやらインデックスの有無がパフォーマンスに大きく影響するようです。
次に、インデックスの利用を想定した場合に、どのくらいパフォーマンスに影響するのか具体的に数値を計測し、検証しているサイトを見つけました。
▼Oracle INDEXを追加したときUPDATEとINSERTにどのくらい影響するのか
https://products.sint.co.jp/siob/blog/add-index#toc-6
こちらのサイトでは、インデックスの数を増やした場合に、UPDATEとINSERTでそれぞれ処理速度を計測し、グラフ化しています。
INSERT、UPDATEともにインデックス数と件数に応じて実行時間が増していくという予想どおりの結果になりました。ここで注目したいのは、インデックス数が、１つしかない場合は有意な差がないのにも関わらず、２つ、３つと追加していくとUPDATEの実行時間を表す曲線の傾きが大きくなるという点です。
上記から、トラフィック量やレコード数が多くなると想定されるサービスにおいては、論理削除よりも物理削除の方が処理速度は速くなるということが言えそうです。