Database Design Mistakes I Made So You Don't Have To \u2014 COD-AI.com

3年前、私は私たちのスタートアップのデータベースが製品の発表中に停止するのを見ました。50,000人のユーザーが同時にサインアップしようとしており、私たちの応答時間は200msから47秒に膨れ上がりました。原因は？ 私が6ヶ月前に犯したデータベース設計の連鎖的なミスでした。その時、私たちはガレージにいる5人のチームでした。その夜、私たちは$180,000の失われた収益を失い、始まる前にほぼ評判を台無しにしました。

私はマーカス・チェンで、過去12年間データベースアーキテクトとして活動してきました。そのうちの7年間は、SaaS企業がゼロから数百万のユーザーにスケールアップするのを特に手助けしてきました。私は、毎日200万のトランザクションを処理するフィンテックプラットフォーム、15TBの患者データを管理する医療アプリケーション、ブラックフライデーのトラフィックスパイクに対応するeコマースサイトのシステムを設計してきました。しかし、私の最も貴重な教育は、キャリアの初期に犯したミスから得たものでした。そのミスは、どんな資格や教科書よりも多くを教えてくれました。

この記事は理論的なベストプラクティスについてではありません。私が実際の環境で犯した特定の、痛みを伴う、高価なミスと、それに続く貴重な教訓についてです。データを保存する何かを構築している場合—あなたの週末プロジェクトでも次のユニコーンでも—これらの教訓は、数ヶ月のリファクタリングや数え切れない不眠の夜を救う可能性があります。

正規化の罠：『適切な』設計がパフォーマンスの悪夢になるとき

大学を卒業したばかりの私は、データベースの正規化に取り憑かれていました。第3正規形は単なる指針ではなく、それは聖典でした。2013年に物流スタートアップに参加したとき、私は正規化の原則に宗教的に従って、出荷追跡システムを設計しました。データの各ピースは独自のテーブルを持ち、すべての関係が完璧にモデル化され、どこにも冗長性はありませんでした。

そのシステムは学術的には美しかったですが、壊滅的に遅かったです。

単一の出荷の詳細を表示するには—ユーザーが1時間あたり何千回も行うこと—11のテーブルを結合する必要がありました。我々の平均クエリ時間は3.2秒でした。追跡ページに対して。ユーザーはページが読み込まれる前にサイトを放棄していました。私たちのCEOは私をオフィスに呼び、今でも私を悩ませる質問をしました：「なぜFedExはすぐに読み込まれるのに、私たちのページは実際にパッケージを発送するよりも時間がかかるのか？」

私が学んだのは、正規化は道具であって宗教ではないということです。第3正規形はデータの異常を防ぎ、ストレージコストを削減するように設計されています—これは、1985年にディスクスペースが1ギガバイトあたり$10,000のコストであったときに意味のある懸念でした。2026年には、ストレージは実質的に無料ですが、ユーザーの注意持続時間はミリ秒で測定されます。数キロバイトの冗長データは、遅い読み込み時間でユーザーを失うことに比べれば、取るに足りないコストです。

修正するためには、最も頻繁にアクセスされるデータの非正規化が必要でした。複数の正規化されたテーブルからの情報を複製するshipment_summaryテーブルを作成しました。はい、これは第3正規形に違反しました。はい、同期を保つために追加のロジックが必要でした。しかし、クエリ時間は3.2秒から180ミリ秒に短縮されました—94%の改善です。ユーザーエンゲージメントの指標は1週間以内に回復しました。

教訓は、正規化を完全に放棄することではありません。データベース設計はトレードオフについて理解することです。整合性が重要なトランザクションデータを正規化してください。パフォーマンスがより重要な読み取り重視のデータを非正規化してください。私たちのケースでは、データ入力と更新のために正規化された構造を維持し、ユーザー向けクエリのために非正規化されたビューを維持しました。このハイブリッドアプローチは、データ整合性とパフォーマンスの両方を提供しました。

今日、スタートアップと相談すると、同じミスを繰り返し見ることができます。データベースコースを受講したばかりのジュニア開発者たちは、すべてを過剰に正規化します。彼らは理論的には完璧ですが、実際には使えないシステムを作ります。私の指針は：一般的なクエリが3つ以上の結合を必要とする場合、そのユースケースのために過剰に正規化されている可能性があります。理論的な純粋性のためではなく、実際のアクセスパターンに基づいて設計してください。

UUIDの災害：『ベストプラクティス』がパフォーマンスを破壊する時

2016年、私はソーシャルメディア分析プラットフォームを構築していました。私たちはグローバルにスケールアップすることを期待していたため、私は一見賢明な決定を下しました：自動増分整数の代わりにUUIDを主キーとして使用することです。私が読んだすべての記事は、分散システムにUUIDを推奨していました。彼らはグローバルに一意であり、列挙攻撃を防ぎ、クライアント側でIDを生成することを可能にします。何が間違っている可能性があるでしょうか？

「正規化は道具であって宗教ではない。理論的な純粋性を現実的なパフォーマンスより優先する瞬間、あなたはすでに戦いに負けている。」

すべてが、実際にはそうではありませんでした。

ローンチから6ヶ月後、200万人のユーザーと5億のレコードを抱えた私たちのデータベースのパフォーマンスが神秘的に低下していました。速くなるべきクエリが数秒かかっていました。データベースのサイズは340GBに膨れ上がっていました—データ量が示唆している以上にはるかに大きいです。最も問題だったのは、私たちの挿入パフォーマンスが初期の頃と比較して60%低下していたことです。より強力なハードウェアにアップグレードしたにもかかわらずです。

問題はインデックスの断片化でした。UUIDはランダムであるため、すべての挿入はBツリーインデックスのランダムな場所に行きます。自動増分整数の場合、新しいレコードはインデックスの末尾に追加されます—これは速い操作です。UUIDの場合、データベースはインデックスページを常に分割し再バランスを取り、大規模な断片化を引き起こします。私たちのインデックスは本来のサイズの3.2倍大きくなっており、すべてのクエリはこの肥大化し断片化した構造を通過しなければなりませんでした。

パフォーマンスへの影響は壊滅的でした。主キーインデックスだけで47GBありました—実際のデータが12GBしかないテーブルに対してです。インデックスのメンテナンスはデータベースのCPU時間の40%を消費していました。さらに悪いことに、ランダムなI/Oパターンはキャッシングを効果的に使用できないことを意味しました。連続したIDを使用する場合、最近挿入されたレコードは一緒にアクセスされる可能性が高いです。UUIDを使用する場合、すべてのアクセスは実質的にランダムであり、キャッシュヒット率を破壊しました。

私たちは最終的にハイブリッドアプローチに移行しました：内部的には連続ID、外部API用に独自のUUIDカラム。これらの移行には3週間の入念な計画と実行が必要で、その間、両方のシステムを同時に維持する必要がありました。エンジニアリング時間とインフラコストで約$85,000のコストがかかりました。パフォーマンスの改善は即座に劇的でした—挿入パフォーマンスは240%向上し、クエリ時間は55%短縮され、再インデックス後にデータベースのサイズは30%減少しました。

ここでの教訓は微妙です。UUIDは本質的に悪いわけではありません—単に高価であるだけです。分散ID生成が本当に必要であるか、IDの予測可能性がセキュリティ上の懸念であるマルチテナントシステムを構築している場合、UUIDはそのコストに値するかもしれません。しかし、ほとんどのアプリケーション、特に初期段階では、連続したIDの方が劇的に効率的です。外部の識別子が必要な場合は、後でUUIDカラムを追加することができます。”ベストプラクティス”だからUUIDで始めることは、ただのコストのかかるエンジニアリングです。