ドキュメント指向データベース

ドキュメント指向データベース、またはドキュメントストアは、半構造化データとも呼ばれるドキュメント指向情報を保存、取得、管理するために設計されたコンピュータプログラムおよびデータストレージシステムです。^[1]

ドキュメント指向データベースは、 NoSQLデータベースの主なカテゴリの 1 つであり、「ドキュメント指向データベース」という用語の人気は、NoSQL という用語自体の使用とともに高まっています^{[2] 。XML}データベースは、XMLドキュメントで動作するように最適化されたドキュメント指向データベースのサブクラスです。グラフ データベースも同様ですが、リレーションシップという別のレイヤーが追加されており、これによりドキュメントをリンクして高速移動が可能になります。

ドキュメント指向データベースは、本質的には、別の NoSQL データベース概念であるキー値ストアのサブクラスです。その違い^[矛盾]は、データの処理方法にあります。キー値ストアでは、データはデータベースに対して本質的に不透明であると見なされますが、ドキュメント指向システムでは、ドキュメントの内部構造に依存して、データベース エンジンがさらなる最適化に使用するメタデータを抽出します。システム内のツールにより、違いは無視できる場合が多いですが、^[a]概念的には、ドキュメント ストアは最新のプログラミング手法でより豊かなエクスペリエンスを提供するように設計されています。

ドキュメント データベース^[b]は、従来のリレーショナル データベース(RDB) とは大きく異なります。リレーショナル データベースは一般に、プログラマーが定義した個別のテーブルにデータを保存し、1 つのオブジェクトが複数のテーブルにまたがる場合があります。ドキュメント データベースは、特定のオブジェクトのすべての情報をデータベース内の 1 つのインスタンスに保存し、保存されたすべてのオブジェクトは互いに異なる場合があります。これにより、データベースにデータをロードする際に オブジェクト リレーショナル マッピングを行う必要がなくなります。

ドキュメント指向データベースの中心となる概念は、ドキュメントの概念です。各ドキュメント指向データベースの実装では、この定義の詳細は異なりますが、一般的に、ドキュメントはデータ (または情報) を何らかの標準形式またはエンコーディングでカプセル化してエンコードすることを前提としています。使用されるエンコーディングには、XML、YAML、JSON のほか、BSONなどのバイナリ形式があります。

ドキュメント ストア内のドキュメントは、プログラミング概念のオブジェクトとほぼ同等です。標準スキーマに準拠する必要はなく、すべてのセクション、スロット、パーツ、キーが同じになることはありません。一般に、オブジェクトを使用するプログラムにはさまざまなタイプのオブジェクトがあり、それらのオブジェクトには多くのオプション フィールドがあることがよくあります。すべてのオブジェクトは、同じクラスのものであっても、見た目が大きく異なる場合があります。ドキュメント ストアは、1 つのストアでさまざまなタイプのドキュメントを許可し、その中のフィールドをオプションにし、多くの場合、異なるエンコード システムを使用してエンコードできるという点で似ています。たとえば、以下は JSON でエンコードされたドキュメントです。

{
    "firstName" : "ボブ" ,  
    "姓" : "スミス" , 
    "住所" ：{ 
        「タイプ」: 「ホーム」、 
        "street1" : "5 オーク ストリート" ,
        「都市」：「男の子」、 
        「状態」: 「AR」、 
        「郵便番号」: 「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> Home </type> <street1> 123 Back St. </street1> <city> Boys </city> <state> AR </state> <zip> 32225 </zip> <country> US </country> </address> </contact>  
  
    
    
  
    
      
    
    
    
    
  

これら 2 つのドキュメントは、構造要素の一部を共有していますが、それぞれに固有の要素もあります。ドキュメント内の構造、テキスト、およびその他のデータは、通常、ドキュメントのコンテンツと呼ばれ、取得または編集メソッドを介して参照できます (以下を参照)。すべてのレコードに同じフィールドが含まれ、使用されていないフィールドは空のままになるリレーショナル データベースとは異なり、上記の例では、どちらのドキュメント (レコード) にも空の「フィールド」はありません。このアプローチにより、データベース内の他のすべてのレコードが同じ構造を共有する必要なく、一部のレコードに新しい情報を追加できます。

ドキュメント データベースは通常、ドキュメント コンテンツに関連付けられ、ドキュメント コンテンツとともに保存される追加のメタデータを提供します。そのメタデータは、ドキュメントの整理、セキュリティの提供、またはその他の実装固有の機能のためにデータストアが提供する機能に関連している場合があります。

ドキュメント指向データベースがドキュメントに対してサポートするコア操作は他のデータベースと同様であり、用語は完全に標準化されていませんが、ほとんどの実務者はそれをCRUDとして認識します。

• 作成（または挿入）
• 検索（またはクエリ、検索、読み取り、または検索）
• 更新（または編集）
• 削除（または除去）

ドキュメントは、そのドキュメントを表す一意のキーによってデータベース内でアドレス指定されます。このキーは単純な識別子(または ID) で、通常は文字列、URI、またはパスです。キーを使用して、データベースからドキュメントを取得できます。通常、データベースは、ドキュメントの取得を高速化するためにキーのインデックスを保持しており、場合によっては、ドキュメントをデータベースに作成または挿入するためにキーが必要になります。

ドキュメント指向データベースのもう 1 つの特徴は、ドキュメントを取得するために使用できる単純なキーからドキュメントへの検索を超えて、データベースが、コンテンツ (またはメタデータ) に基づいてユーザーがドキュメントを取得できるようにする API またはクエリ言語を提供していることです。たとえば、特定のフィールドが特定の値に設定されているすべてのドキュメントを取得するクエリが必要な場合があります。使用可能なクエリ API またはクエリ言語機能のセット、およびクエリの予想されるパフォーマンスは、実装ごとに大きく異なります。同様に、使用可能なインデックス作成オプションと構成の特定のセットも、実装ごとに大きく異なります。

ドキュメント ストアがキーバリュー ストアと最も異なるのは、この点です。理論上、キーバリュー ストアの値はストアに対して不透明であり、本質的にブラック ボックスです。ドキュメント ストアと同様の検索システムを提供する場合もありますが、コンテンツの構成に関する理解度は低い可能性があります。ドキュメント ストアは、ドキュメント内のメタデータを使用してコンテンツを分類し、たとえば、ある数字列は電話番号で、別の数字列は郵便番号であることを理解できるようにします。これにより、たとえば、555 を含むすべての電話番号を検索できますが、郵便番号 55555 は無視されます。

ドキュメント データベースは通常、ドキュメント全体またはドキュメントの個々の構造部分の置き換えを可能にすることによって、ドキュメントのコンテンツ (またはメタデータ) を更新または編集するための何らかのメカニズムを提供します。

ドキュメントデータベースの実装では、ドキュメントを整理するためのさまざまな方法が提供されており、

• コレクション: ドキュメントのグループ。実装に応じて、ドキュメントは 1 つのコレクション内に存在するように強制される場合もあれば、複数のコレクションに存在することが許可される場合もあります。
• タグと非表示のメタデータ: ドキュメントコンテンツ外の追加データ
• ディレクトリ階層: 通常はパスまたは URI に基づいてツリー構造に整理されたドキュメントのグループ

場合によっては、これらの組織的概念は、論理的表現と物理的表現（ディスク上またはメモリ内など）の程度が異なります。

ドキュメント指向データベースは、特殊なキー値ストアであり、それ自体が別の NoSQL データベース カテゴリです。単純なキー値ストアでは、ドキュメント コンテンツは不透明です。ドキュメント指向データベースは、ドキュメントの内部構造に基づいてクエリまたは更新する機能を公開する API またはクエリ/更新言語を提供します。この違いは、ドキュメント データベースで通常提供されるより豊富なクエリ、取得、または編集 API を必要としないユーザーにとっては、小さなものかもしれません。最新のキー値ストアには、メタデータを操作する機能が含まれていることが多く、ドキュメント ストア間の境界があいまいになっています。

Apache SolrやElasticsearchなどの一部の検索エンジン (別名、情報検索) システムは、ドキュメント指向データベースの定義に適合するのに十分なドキュメントのコア操作を提供します。

リレーショナル データベースでは、まずデータがいくつかの定義済みタイプに分類され、各タイプの個々のエントリ、つまりレコードを保持するためのテーブルが作成されます。テーブルは各レコードのフィールド内のデータを定義します。つまり、テーブル内のすべてのレコードは全体的に同じ形式になります。管理者はテーブル間の関係も定義し、検索に最もよく使用されると思われる特定のフィールドを選択して、それらのインデックスを定義します。リレーショナル設計の重要な概念は、繰り返される可能性のあるデータは通常、独自のテーブルに配置され、これらのインスタンスが互いに関連している場合は、それらをグループ化するための列 (外部キー)が選択されることです。この設計は、データベースの正規化として知られています。^[3]

たとえば、アドレス帳アプリケーションでは、通常、連絡先の名前、オプションの画像、1 つ以上の電話番号、1 つ以上の郵送先住所、および 1 つ以上の電子メール アドレスを保存する必要があります。標準的なリレーショナル データベースでは、各行にテーブルが作成され、各データ ビットごとに定義済みのフィールドが含まれます。CONTACT テーブルには、FIRST_NAME、LAST_NAME、および IMAGE 列が含まれ、PHONE_NUMBER テーブルには、COUNTRY_CODE、AREA_CODE、PHONE_NUMBER、および TYPE (自宅、勤務先など) が含まれます。PHONE_NUMBER テーブルには、外部キー列 "CONTACT_ID" も含まれ、この列には連絡先の作成時に割り当てられた一意の ID 番号が保持されます。元の連絡先を再作成するために、データベース エンジンは外部キーを使用して、テーブルのグループ全体で関連項目を検索し、元のデータを再構築します。

対照的に、ドキュメント指向データベースでは、テーブルの概念に直接マップされる内部構造が存在しない可能性があり、フィールドと関係は一般に定義済みの概念として存在しません。代わりに、オブジェクトのすべてのデータが 1 つのドキュメントに配置され、1 つのエントリとしてデータベースに保存されます。アドレス帳の例では、ドキュメントには連絡先の名前、画像、および連絡先情報がすべて 1 つのレコードに含まれています。そのエントリにはキーを通じてアクセスされ、データベースはドキュメントを取得してアプリケーションに返すことができます。関連データを取得するために追加の作業は必要ありません。これらすべてが 1 つのオブジェクトで返されます。

ドキュメント指向モデルとリレーショナル モデルの主な違いは、ドキュメントの場合、データ形式が事前に定義されていないことです。ほとんどの場合、あらゆる種類のドキュメントを任意のデータベースに保存でき、それらのドキュメントの種類と形式はいつでも変更できます。CONTACT に COUNTRY_FLAG を追加する場合、このフィールドは新しいドキュメントが挿入されるときに追加できます。これは、データベースまたは既に保存されている既存のドキュメントには影響しません。データベースからの情報の検索を容易にするために、ドキュメント指向システムでは通常、管理者がデータベースにヒントを提供して特定の種類の情報を検索できるようにします。これらは、リレーショナルの場合のインデックスと同様に機能します。また、ほとんどのシステムでは、ドキュメント自体のコンテンツ以外のメタデータを追加する機能も提供されています。たとえば、エントリをアドレス帳の一部としてタグ付けすると、プログラマーは「すべてのアドレス帳エントリ」などの関連する種類の情報を取得できます。これにより、テーブルに似た機能が提供されますが、概念 (データのカテゴリ) とその物理的な実装 (テーブル) が分離されます。

古典的な正規化されたリレーショナルモデルでは、データベース内のオブジェクトは、取得時に与えられた構造以外に固有の構造を持たない個別のデータ行として表されます。これにより、プログラミングオブジェクトを関連するデータベース行に変換したり、データベース行から変換したりするときに問題が発生します。これは、オブジェクトリレーショナルインピーダンスミスマッチと呼ばれる問題です。 ^{[4]ドキュメントストアは、より密接に、または場合によっては直接、プログラミングオブジェクトをストアにマッピングします。これらは、多くの場合、} NoSQLという用語を使用して販売されています。

ほとんどの XML データベースはドキュメント指向のデータベースです。

• データベース理論
• データ階層
• データ分析
• 全文検索
• インメモリデータベース
• インターネット メッセージ アクセス プロトコル(IMAP)
• 機械可読文書
• マルチモデルデータベース
• ノーSQL
• オブジェクトデータベース
• オンラインデータベース
• リアルタイムデータベース
• リレーショナルデータベース
• コンテンツ管理システム

• Assaf Arkin (2007 年 9 月 20 日)。「読み取り一貫性: ダム データベース、スマート サービス」

• DB-Engines ドキュメントストアの人気ランキング（毎月更新）