「MongoDB」のドキュメントデータモデルとして、「NoSQLデータベースとは」「MongoDBのデータ階層構造」「MongoDBのドキュメントデータモデル」について紹介します。

「MongoDB」のドキュメントデータモデル

「MongoDB」のドキュメントデータモデルとして、「NoSQLデータベースとは」「MongoDBのデータ階層構造」「MongoDBのドキュメントデータモデル」について紹介します。

■関連する比較ページ

「MongoDB」のドキュメントデータモデル

■NoSQLデータベースとは

NoSQLデータベースは、リレーショナルデータベースと比較すると、一般的に「高いスケーラビリティ」と「優れたパフォーマンス」を提供します。

高価なモノリシックアーキテクチャではなく、地理的に分散したスケールアウトアーキテクチャに対応します。

動的スキーマ

NoSQLデータベースは、あらかじめ定義されたスキーマなしでデータを格納できるように構築されています。

サービスを中断することなく、アプリケーションの大幅な変更をリアルタイムで簡単に行うことができ、「開発高速化」「コード統合の信頼性向上」「データベース管理コスト削減」などのメリットを得られます。

データモデル

NoSQLデータベースのデータモデルは、リレーショナルモデルでは対処できないいくつかの問題を解決できます。
・急速に変化する大量の「構造化データ」「半構造化データ」「非構造化データ」
・アジャイルスプリント
・頻繁なスキーマ反復とコードプッシュ など。

データガバナンスを強化

従来のリレーショナルデータベース環境において、エンジニアは「フィールド定義」「データ型設定」「許容値設定」など、アプリケーション側にデータ品質管理のためのコードを追加する必要がありました。

それに対して、NoSQLデータベースでは、データベース内に検証ルールを適用できるため、ユーザーは動的スキーマの俊敏性を維持しながら、データ全体のガバナンスを強化できます。

■MongoDBのデータ階層構造

MongoDBは「①データベース」「②コレクション」「③ドキュメント」の3階層構造になっています。

階層①データベース

MongoDBの最上位要素は、RDBと同じように「データベース」です。複数のデータベースを作成できます。

「①データベース」には複数の「②コレクション」が格納されます。

階層②コレクション

「②コレクション」は「RDBのテーブル」に該当し、複数のJSON形式構造体「③ドキュメント」を格納します。

RDBのテーブルのようにスキーマ定義はなく、どのような構造のJSON形式構造体でも格納できます。読み取り時にはJSON構造を把握する必要があるため、JSON形式構造体の定義管理は必要です。

このため、データベースに登録するデータの構成が変化しても、柔軟な対応が可能です。

階層③ドキュメント

「③ドキュメント」は「RDBのレコード」に該当し、JSON(JavaScript Object Notation)オブジェクトに似ている構造体です。

内部的には、JSONバイナリ形式「BSON」で格納されます。BSONエンコーディングは、一般的なJSON表現を拡張したもので、1つ以上のフィールドがあり、「フィールド」と「値」のペアで構成されるデータ構造です。

値には以下のような種類があります。
・基本データ型(int、long、date、浮動小数点、decimal128)
・バイナリデータ
・サブドキュメント(他のドキュメント)
・配列 など

■MongoDBのドキュメントデータモデル

MongoDBは、データを柔軟なJSONライクなドキュメントに保存するため、あらゆる構造のデータを永続化に格納できます。

RDBでは「テーブルに格納されているすべてのレコードが同じカラムを有する」に対して、MongoDBでは「階層③のドキュメントごとに自由なフィールドを定義できる」点が特徴です。

データはスキーマレスなドキュメントとして格納されます。ORM(オブジェクトリレーショナルマッピング)を行うことなく直接格納できます。任意のタイミングでJSONフィールド単位での追加/更新を行えるため、フレキシブルな運用を行えます。

開発者は「アプリケーション内データ」と「ドキュメント」の間のマッピングを簡単かつ迅速にモデル化でき、「スキーマガバナンスコントロール」「データアクセス」「複雑な集計」「豊富なインデックス機能」を活用して、簡単にデータを操作できます。扱うデータ特性によっては、RDBMSよりも容易かつ迅速に開発を行えます。

ドキュメントに関するその他の利点

・多くのプログラミング言語のネイティブデータ型に対応
・動的スキーマであるため多態性をサポートできる
・結合の必要性を低減できる
・複雑な要件に対応しやすい
・ダウンタイムなしでスキーマの動的変更が可能
・複雑な階層構造を持たせることができる
・データの追加/更新/削除が可能
・高速クエリ
・フィールドを指定したクエリやインデックス生成が容易
・JSONライクであるため開発者の学習コストが低い

  • Zabbixカンファレンス2019
  • OSSNEWSに広告を掲載しませんか?

facebook

twitter