Loading article…
ドキュメント指向データベース、またはドキュメントストアとは、ドキュメント指向情報（半構造化データとも呼ばれる）を保存、検索、管理するために設計されたコンピュータプログラムおよびデータストレージシステムである。[ 1 ]
ドキュメント指向データベースは、NoSQLデータベースの主要なカテゴリの1つであり、「ドキュメント指向データベース」という用語の人気は、NoSQL自体の普及とともに高まっています。XMLデータベースは、 XMLドキュメントに最適化されたドキュメント指向データベースのサブクラスです。グラフデータベースは、生データを格納する方法は似ていますが、関係性というもう1つのレイヤーを追加することで、ドキュメントをリンクして高速な走査を可能にします。
ドキュメント指向データベースは、概念的には、NoSQLデータベースの一種であるキーバリューストアの拡張です。キーバリューストアでは、データはデータベースによって不透明なものとして扱われますが、ドキュメント指向システムは、ドキュメントの内部構造を利用してメタデータを抽出し、ストレージとクエリを最適化します。[ 2 ]実際には、最新のツールのおかげでその違いは最小限になる場合もありますが、ドキュメントストアは、最新のプログラミング技術でより豊かなプログラミング体験を提供するように設計されています。[注1 ]
ドキュメントデータベースは、従来のリレーショナルデータベース（RDB）とは大きく異なります。[注2 ]リレーショナルデータベースは、定義済みのテーブルにデータを格納するため、多くの場合、オブジェクトを複数のテーブルに分割する必要があります。一方、ドキュメントデータベースは、特定のオブジェクトに関するすべての情報を単一のドキュメントに格納し、各ドキュメントは固有の構造を持つ可能性があります。この設計により、データベースにデータをロードする際にオブジェクトリレーショナルマッピングを行う必要がなくなります。 [ 3 ]
ドキュメント指向データベースの中心概念は「ドキュメント」という概念です。実装によって具体的な定義は異なりますが、ドキュメント指向データベースでは一般的に、ドキュメントはデータを標準化された形式でカプセル化およびエンコードする自己完結型の単位として扱われます。[ 2 ] [ 3 ]一般的なエンコード形式には、XML、YAML、JSON、およびBSONなどのバイナリ表現が含まれます。[ 4 ]
ドキュメントストア内のドキュメントは、プログラミングにおけるオブジェクトの概念に相当します。ドキュメントは固定スキーマに従う必要はなく、同じコレクション内のドキュメントでも異なるフィールドや構造を持つことができます。フィールドはオプションである場合もあり、同じ論理型のドキュメントでも構成が異なる場合があります。たとえば、以下はJSONでエンコードされたドキュメントの例です。
{"firstName" : "ボブ" 、"lastName" : "Smith" 、"住所" ：{"タイプ" : "ホーム" 、「street1」：「5 Oak St.」、「都市」：「少年たち」、「状態」: 「AR」、「zip」: 「32225」、「国」：「米国」},「趣味」：「セーリング」、"電話" ：{"タイプ" : "セル" 、「番号」：「(555)-123-4567」}}2番目のドキュメントは、XMLでは次のようにエンコードされる可能性があります。
<contact> <firstname> Bob </firstname> <lastname> Smith </lastname> <phone type= "Cell" > (123) 555-0178 </phone> <phone type= "Work" > (890) 555-0133 </phone> <address> <type>自宅</type> <street1> 123 Back St. </street1> <city> Boys </city> <state> AR </state> <zip> 32225 </zip> <country> US </country> </address> </contact>これら2つのサンプル文書は、構造的な要素を共有しているものの、それぞれ固有のフィールドも含まれています。各文書内の構造、テキスト、その他のデータは、まとめて文書コンテンツと呼ばれ、検索操作や編集操作によってアクセスまたは変更できます。リレーショナルデータベースでは、各レコードに同じフィールドが含まれ、使用されていないフィールドは空のままになりますが、文書指向データベースでは、文書間でフィールドを統一する必要はありません。この設計により、一部の文書に新しい情報を追加しても、他の文書の構造に影響を与えることなく処理できます。
文書データベースは、文書コンテンツに加えて追加のメタデータを保存する機能をサポートすることが多い。このようなメタデータは、組織機能、セキュリティ、インデックス作成、またはその他の実装固有の機能に関連する可能性がある。[ 3 ]
文書指向データベースが文書を操作するためにサポートするコア操作は、他のデータベースのものと似ています。用語は完全に標準化されていませんが、これらの操作は一般的に作成、読み取り、更新、削除 ( CRUD ) として認識されています。[ 3 ] [ 4 ]
ドキュメント指向データベース内のドキュメントは、一意の識別子によってアドレス指定されます。この識別子（多くの場合、文字列、URI、またはパス）を使用して、データベースからドキュメントを取得できます。ほとんどのドキュメントストアは、検索を最適化するためにキーのインデックスを保持しており、一部の実装では、新しいドキュメントを作成または挿入するときにキーが必要です。[ 3 ] [ 4 ]
文書指向データベースは、キーベースのアクセスに加えて、通常、文書の内容や関連するメタデータに基づいて検索を可能にするAPIまたはクエリ言語を提供します。たとえば、特定のフィールドが指定された値と一致するすべての文書を返すクエリを作成できます。利用可能なクエリ機能、インデックスオプション、およびパフォーマンス特性は、実装によって異なります。
ドキュメント ストアは、格納されたドキュメントの内部構造とメタデータを活用する点で、キー バリュー ストアとは異なります。多くのキー バリュー ストアでは、値は不透明な「ブラック ボックス」データとして扱われ、データベース システムはその内部構造を解釈しません。対照的に、ドキュメント指向データベースは、ドキュメント コンテンツを分類および解釈できます。これにより、データの種類を区別するクエリが可能になります。たとえば、「55555」などの郵便番号に一致しない「555」を含むすべての電話番号を取得するクエリなどです。[ 3 ] [ 4 ]
文書データベースは通常、文書の内容やメタデータを更新または編集するためのメカニズムを提供します。更新には、文書全体を置き換える場合や、文書内の個々の要素やフィールドを変更する場合があります。[ 4 ]
文書データベースの実装では、以下のようなさまざまな文書整理方法がサポートされています。
これらの組織構造は、論理表現と物理表現（例えば、ディスク上またはメモリ上）の間で異なる場合がある。
ドキュメント指向データベースは、キーバリューストアの特殊な形態と見なすことができ、キーバリューストア自体もNoSQLデータベースのカテゴリです。基本的なキーバリューストアでは、格納された値は通常、データベースシステムによって不透明なものとして扱われます。対照的に、ドキュメント指向データベースは、ドキュメントの内部構造に基づいてクエリや変更を可能にするAPIまたはクエリおよび更新言語を提供します。高度なクエリ、取得、または更新機能を必要としないユーザーにとっては、ドキュメント指向データベースとキーバリューストアの区別は最小限かもしれません。[ 2 ]
Apache SolrやElasticsearchなどの検索エンジンや情報検索システムの中には、文書の保存機能や基本的な文書操作をサポートするものがあります。そのため、設計上の主な目標は異なるものの、文書指向データベースの機能的な定義の一部を満たす場合があります。
リレーショナルデータベースでは、データはテーブルとして表現される定義済みの型に整理されます。各テーブルには、固定された列（フィールド）を持つ行（レコード）が含まれているため、テーブル内のすべてのレコードは同じ構造を共有します。管理者は通常、クエリのパフォーマンスを向上させるために、選択したフィールドにインデックスを定義します。リレーショナルデータベース設計の中心的な原則はデータベース正規化であり、そうでなければ重複する可能性のあるデータは別々のテーブルに格納され、キーを使用してリンクされます。[ 5 ]異なるテーブルのレコードが関連付けられている場合、外部キーを使用してそれらを関連付けます。
例えば、アドレス帳アプリケーションでは、連絡先の名前、画像、電話番号、住所、メールアドレスなどを保存する場合があります。正規化されたリレーショナル設計では、連絡先、電話番号、メールアドレス用にそれぞれ別のテーブルを作成することがあります。電話番号テーブルには、関連する連絡先を参照する外部キーが含まれます。完全な連絡先レコードを再構築するために、データベースは外部キーを使用して各テーブルから関連情報を取得し、それらを結合して単一のレコードを作成します。
対照的に、ドキュメント指向データベースは、オブジェクトに関連するすべてのデータを単一のドキュメント内に格納し、データベースには単一のエントリとして保存します。アドレス帳の例では、連絡先の名前、画像、連絡先情報が1つのドキュメントにまとめて保存されます。ドキュメントは一意のキーを使用して取得され、複数のテーブルを参照する必要なく、関連するすべての情報がまとめて返されます。[ 3 ]
ドキュメント指向モデルとリレーショナルモデルの重要な違いは、ドキュメントの場合、データ形式が事前に定義されていないことです。ほとんどの場合、あらゆる種類のドキュメントをデータベースに保存でき、ドキュメントの種類や形式は時間の経過とともに変化する可能性があります。たとえば、COUNTRY_FLAG などの新しいフィールドを、既存のドキュメントに影響を与えることなく、挿入される新しいドキュメントに追加できます。検索を容易にするために、ドキュメント指向システムでは、管理者が特定の種類の情報を見つけるためのヒントをデータベースに提供することが一般的に許可されています。これらのヒントは、リレーショナルデータベースのインデックスと同様の方法で機能します。[ 2 ]また、多くのシステムでは、アドレス帳の一部としてエントリにタグを付けるなど、ドキュメント自体の内容以外の追加のメタデータも許可されており、これにより、たとえばすべてのアドレス帳エントリなど、関連情報を検索できます。これはテーブルと同様の機能を提供しますが、概念（データのカテゴリ）と物理的な実装（テーブル）を分離します。[ 4 ]
従来の正規化されたリレーショナル モデルでは、データベース内のオブジェクトは、テーブルで定義されているもの以外に固有の構造を持たない、個別のデータ行として表現されます。このため、プログラミング オブジェクトと対応するデータベース行との間で変換を行う際に困難が生じることがあり、これはオブジェクト リレーショナル インピーダンス ミスマッチとして知られています。[ 6 ]対照的に、ドキュメント ストアでは、プログラミング オブジェクトをデータベースに直接マッピングし、その内部構造の大部分を保持することがよくあります。このアプローチを使用するデータベースは、NoSQLシステムと呼ばれることがよくあります。
ほとんどのXMLデータベースは、文書指向型データベースである。