ドキュメントデータベースとは何ですか？

はじめに

独自の機能により、NoSQLデータベースはリレーショナルデータベースモデルに見られる制約を克服します。 NoSQLは、NoSQLデータベースの4つの主要なサブセットの総称です。

キーバリューデータベース
列データベース
グラフデータベース
ドキュメントデータベース

この記事では、ドキュメントデータベースとは何かを説明し、その長所と短所を説明し、例を示します。

ドキュメントデータベースの定義

ドキュメントデータベースは、データを列や行ではなくJSONドキュメントとして保存するNoSQLデータベースの一種です。 JSONは、データの保存とクエリの両方に使用される母国語です。これらのドキュメントをコレクションにグループ化して、データベースシステムを形成できます。

各ドキュメントは、いくつかのキーと値のペアで構成されています。 4つのキーと値のペアで構成されるドキュメントの例を次に示します。

{
"ID" : "001",
"Book" : "Java: The Complete Reference",
"Genre" : "Reference work",
"Author" : "Herbert Schildt",
}

JSONを使用すると、アプリ開発者は、アプリのコードを整理するために使用するのと同じドキュメントモデル形式でデータを保存およびクエリできます。オブジェクトモデルは、JSON、BSON、XMLなどの他の形式に変換できます。

リレーショナルvsドキュメントデータベース

リレーショナルデータベース管理システム（RDBMS）は、構造化照会言語（SQL）に依存しています。 NoSQLはそうではありません。

RDBMSは、データを保存および読み取るためのファイル間の関係の作成に重点を置いています。ドキュメントデータベースはデータ自体に焦点を合わせており、関係はネストされたデータで表されます。

リレーショナルデータベースとドキュメントデータベースの主な比較：

RDBMS	ドキュメントデータベースシステム
関係の概念を中心に構成されています。	データに焦点を当てる人間関係ではなく。
データをタプルに編成します（または行）。	ドキュメントにはプロパティがあります行ではなく、理論的な定義なし。
制約と外部キーを介してデータを定義（関係を形成）（たとえば、子テーブルはそのIDを介してマスターテーブルを参照します）。	スキーマを定義するためのDDL言語はありません。
DDL（データ定義言語）を使用して関係を作成します。	ネストされたデータを介して表される関係、外部キーではありません（どのドキュメントにも、その中にネストされた他のドキュメントが含まれている可能性があり、2つのドキュメントエンティティ間にN：1または1：Nの関係が生じます）。
非常に一貫性のあるを提供します、デイリーバンキングなどの一部のユースケースでは重要です。	オファー結果整合性一貫性のない期間があります。

ドキュメントデータベースの機能

ドキュメントデータベースは、高速クエリ、ビッグデータの処理に適した構造、柔軟なインデックス作成、およびデータベースを維持するための簡素化された方法を提供します。 Webアプリに効率的であり、Amazonなどの大規模なIT企業によって完全に統合されています。

SQLデータベースは優れた安定性と垂直方向の能力を備えていますが、超大規模なデータベースには苦労しています。ヘルスケアアプリなど、データへの即時アクセスを必要とするユースケースは、ドキュメントデータベースにより適しています。ドキュメントデータベースを使用すると、アプリケーションのコーディングに使用したものと同じドキュメントモデルを使用してデータを簡単にクエリできます。

ドキュメントデータベースのユースケース

一般的なユースケース
ユーザープロファイル	リアルタイムのビッグデータの抽出
本のデータベース	さまざまな構造のデータ
コンテンツ管理	カタログ
患者のデータ

上記のユースケースのいくつかについては、次のセクションで詳しく説明します。

本のデータベース

リレーショナルドキュメントシステムとNoSQLドキュメントシステムの両方を使用して、本のデータベースを形成しますが、方法は異なります。

リレーショナルアプローチは、 IDのテーブルを介して本と著者の関係を表します。 –作成者 テーブルと本テーブル。 null値を禁止することにより、各作成者がBooksテーブルに少なくとも1つのエントリを持つように強制します。

比較すると、ドキュメントモデルではネストが可能です。各作成者のドキュメントにプロパティがあることを確認することで、関係をより自然かつ簡単に示します。本と呼ばれます、プロパティ内の関連する書籍ドキュメントの配列。著者を検索すると、書籍コレクション全体が表示されます。

コンテンツ管理

開発者はドキュメントデータベースを使用して、ビデオストリーミングプラットフォーム、ブログ、および同様のサービスを作成します。各ファイルは単一のドキュメントとして保存され、サービスが時間の経過とともに進化するにつれて、データベースの保守が容易になります。データモデルの変更などの重要なデータ変更では、スキーマの更新が必要ないため、ダウンタイムは必要ありません。

カタログ

カタログファイルの保存と読み取りに関しては、ドキュメントデータベースはリレーショナルデータベースよりもはるかに効率的です。カタログには何千もの属性が保存されている場合があり、ドキュメントデータベースは高速な読み取り時間を提供します。ドキュメントデータベースでは、単一の製品に関連する属性が単一のドキュメントに保存されます。 1つの製品の属性を変更しても、他のドキュメントには影響しません。

ドキュメントデータベースの長所と短所

以下はいくつかの重要な利点ですおよび不利な点 ドキュメントデータベースの数：

ドキュメントデータベースの利点	ドキュメントデータベースの短所
スキーマレス	一貫性-制限の確認
より迅速な作成とケア	アトミシティの弱点
外部キーなし	セキュリティ
オープンフォーマット
組み込みのバージョン管理

長所と短所については、以下のセクションで詳しく説明します。

利点

スキーマレス 。データストレージの形式と構造に制限はありません。これは、特に継続的に変換されるシステムで、既存のデータを大量かつさまざまな構造状態で保持するのに適しています。
より迅速な作成と車 e。ドキュメントを作成したら、最小限のメンテナンスが必要です。これは、複雑なオブジェクトを1回追加するのと同じくらい簡単です。
外部キーなし 。この動的な関係がないため、ドキュメントは互いに独立している可能性があります。
オープンフォーマット 。 XML、JSON、およびその他の派生物を使用してドキュメントを記述するクリーンなビルドプロセス。
組み込みのバージョン管理 。ドキュメントのサイズが大きくなると、複雑さも増す可能性があります。バージョン管理により競合が減少します。

短所

一貫性-チェックの制限 。上記の本データベースのユースケースの例では、存在しない著者の本を検索することができます。書籍コレクションを検索して、著者コレクションに接続されていないドキュメントを見つけることができます。
各リストは、各本の著者情報を複製する場合もあります。これらの不整合は、一部のコンテキストでは重要ではありませんが、RDB整合性監査の上位標準では、データベースのパフォーマンスを大幅に阻害します。
アトミシティの弱点 。リレーショナルシステムでは、JOINを必要とせずに1か所からデータを変更することもできます。すべての新しい読み取りクエリは、単一のコマンド（行の更新や削除など）を介してデータに加えられた変更を継承します。
ドキュメントデータベースの場合、2つのコレクションを含む変更では、（コレクションごとに）2つの別々のクエリを実行する必要があります。これは原子性の要件を破ります。
セキュリティ 。今日のWebアプリケーションのほぼ半数は、機密データを積極的に漏洩しています。したがって、NoSQLデータベースの所有者は、Webアプリの脆弱性に注意を払う必要があります。

最高のドキュメントデータベース

Amazon DocumentDB

機能：

MongoDB互換
完全に管理
低レイテンシのクエリによる高性能
強力なコンプライアンスとセキュリティ
高可用性

用途：

アマゾンの 開発チーム全体がAmazonDocumentDBを使用して、敏捷性と生産性を向上させます。完全に管理されたプロセスを備えた、ネストされたインデックス、集計、およびアドホッククエリが必要でした。
BBC 複数のデータストリームからのデータのクエリと保存、および単一の顧客フィードへのコンパイルに使用します。高可用性、耐久性、デフォルトのバックアップを備えたフルマネージドサービスのメリットを享受するために、AmazonDocumentDBに移行しました。
ラッピ コーディング時間を短縮するためにAmazonDocumentDBに切り替えました。ダウジョーンズ 操作とSamsungを簡素化するため大きなログをより柔軟に処理するため。

MongoDB

機能：

アドホッククエリ
クエリ用に最適化されたインデックス作成
シャーディング
負荷分散

用途：

フォーブス ビルド時間が58％短縮され、新機能の構築が迅速化され、組み込みが簡単になり、ますます多様化するデータタイプの処理が改善されたため、サブスクリプションが28％増加しました。
トヨタ 開発者が自然なJSONドキュメントを使用して高速で作業する方がはるかに簡単であることがわかりました。データモデリングではなく、ビジネス価値の構築により多くの時間が費やされます。

Cosmos DB

機能：

任意のスケールの高速読み取り
99,999％の可用性
完全に管理
NoSQL/ネイティブコアAPI
サーバーレス、費用対効果の高い/即時の拡張

用途：

コカコーラ 洞察を数分で提供し、グローバルなスケーリングを促進します。 Cosmos DBに移行するまでには、数時間かかりました。
ASOS 1億人を超える世界中の小売顧客を処理するために、柔軟かつシームレスに拡張できる分散データベースが必要でした。

ArangoDB

機能：

スキームの検証
多様なインデックス作成
高速分散クラスター
効率的なv大規模なデータセット
複数のNoSQLデータモデルをサポートします
モデルを1つのクエリに結合する

用途：

オックスフォード大学 心肺疾患のウェブベースの評価テストを開発することにより、入院を減らし、テスト結果を改善しました。
FlightStats 断片化されたフライトデータ（フライトステータス、天気、空港の遅延、参照データ）を1つの標準に変換し、正確で予測的な分析結果を実現します。

Couchbase Server

機能：

グローバル展開を管理する機能
卓越した敏捷性と柔軟性
大規模で高速
簡単なクラウド統合

用途：

BT Couchbaseの柔軟なデータモデルを使用して、需要の急増に合わせて簡単に拡張しながら、高性能でコンテンツを配信する能力を加速しました。
eBay より費用効果が高く、機能に適用可能なソリューション（Key-Valueストア/ドキュメントシステム）のためにOracleから移行しました。アプリのパフォーマンスと可用性は向上しましたが、開発者はSQLのノウハウを使用して、より柔軟なスキーマを介してCI/CDパイプラインを高速化できました。

CouchDB

機能：

ブラウザベースのGUI
最も単純な複製を提供します
ユーザー認証
ACIDプロパティ

用途：

Meebo、 ソーシャルプラットフォーム。WebベースのインターフェースとそのアプリケーションにCouchDBを使用しました。
BBC 動的コンテンツプラットフォームにCouchDBを使用しました。

選択方法

アプリの重要な要求によって、データの構造化方法が決まります。いくつかの重要な質問：

もっと読んだり書いたりしますか？リレーショナルシステムは、更新中の重複を回避するため、より多くの書き込みを行う場合に優れています。
同期はどのくらい重要ですか？ ACIDフレームワークにより、リレーショナルシステムはこれをより適切に実行します。
データベーススキーマは将来どのくらい変換する必要がありますか？多様なデータを大規模に処理し、最小限のメンテナンスで済む場合は、ドキュメントデータベースが最適です。

ドキュメントもSQLも、他よりも厳密に優れているわけではありません。正しい選択は、ユースケースによって異なります。決定するときは、最も頻繁に実行される操作の種類を考慮してください。