第5章. CockroachDBのスキーマ設計
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
健全なデータ・モデルは、高いパフォーマンスと保守性を備えたアプリケーションの基盤である。 この章では、リレーショナルスキーマ設計の基本を復習し、特に分散データベース演算に関係するスキーマ設計の側面と、列ファミリやJSONバイナリ(JSONB)サポートなどの高度なCockroachDB機能に焦点を当てる。よく設計されたCockroachDBアプリケーションをサポートするテーブル、インデックス、その他のスキーマ・オブジェクトの作成について説明する。
CockroachDBは、オンラインで効率的にスキーマを変更するメカニズムをサポートしているが、本番アプリケーションへのスキーマ変更は、通常、アプリケーションコードと本番データベース構成の座標変更を伴う、影響の大きい変更である。 下手をすると、アプリケーションの機能、可用性、パフォーマンスが失われる危険性がある。 したがって、CockroachDBのスキーマを本番環境で変更することは十分に可能だが、アプリケーション設計時にスキーマを正しくする方がはるかに良い。
リレーショナルデータベースの設計は大きなトピックであり、多くの書籍や継続的な議論の対象となってきた。 ここでは、高度な設計原則をカバーしようとは思わないし、さまざまな設計パターンの純粋性についての議論に参加しようとも思わない。 ほとんどのデータベースモデルは、リレーショナルモデルの数学的な純粋さと、物理的なデータベースシステムによって課される実用性との妥協の産物である。 したがって、この章では、リレーショナル・モデルの理論的側面のみを簡単にカバーする一方、CockroachDBの実装でうまく機能するモデルを設計するための実際的な側面にかなり深く潜ることを試みる。
論理データモデリング
アプリケーションのデータモデルは、一般的に2つのフェーズで作成される。論理データモデルを確立するには、アプリケーションによってストアされ、処理される情報をモデリングし、必要なすべてのデータが正しく、完全に、そして一義的に表現されていることを確認する。 次に、論理データモデルは物理データモデルにマッピングされる。物理データモデルには、DBMS で作成されるテーブル、インデックス、ビューが記述される。
論理データモデルは通常、アプリケーションの機能要件のみを満たす。 物理データモデルは、非機能要件、特にパフォーマンス要件も満たさなければならない。
実際には、特にアジャイルなどの反復開発環境では、この2つのフェーズはしばしば曖昧になる。 とはいえ、明示的に行われるかどうかは別として、アプリケーションが処理する可能性のあるデータを決定するために必要な分析と、そのデータが特定のデータベースシステムでどのように表現されるのが最適かを決定するために必要な分析との間には、間違いなく違いがある。
第1章で、リレーショナルモデルの核となる概念のいくつかを紹介した。 理論的には、論理データモデリングでは関係、タプル、属性を扱い、物理設計ではテーブル、行、列を扱う。 しかし、学界以外では、これらの区別は無視されることが多く、実際には、テーブルとカラムの言語を使って論理モデルを開発するのが一般的である。
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access