MongoDBのデータモデル
ドキュメント型データ
MongoDBは、データをドキュメントと呼ばれるデータ形式をバイナリーで表記するBSON(Binary JSON)という方式で記録します。共通の構造をもつドキュメントは、コレクション、と呼ばれる構造でまとめられます。コレクションはRDBの世界ではテーブルに相当するもの、と考えれば理解しやすいと思います。同様に、コレクションは行、フィールドは列に相当します。
MongoDBドキュメントは通常レコードに含まれるデータを全て一つのドキュメントに記録します。RDBののように複数のテーブルに分散してレコードを管理する方法と異なり、データの一元化が基本です。
このデータ一元化の特徴を、ブログアプリを例にとって説明します。ブログアプリをRDBで開発するとき、データモデルは通常、カテゴリー、タグ、ユーザ名、コメント、記事、等それぞれの項目毎にテーブルを生成する形をとります。MongoDBの場合は、これを2つのコレクションで管理します：ユーザ情報のコレクションと、ブログ記事情報のコレクションです。ブログ記事一つ一つに、複数のコメント、タグ、カテゴリーがつきますが、それらは、ブログ記事のドキュメント内に配列として記録する方式をとります。
ドキュメント 型データの利点：開発者には使いやすさ
ユーザには性能
ドキュメントモデルを導入する事により、MongoDBで管理されるデータは局所化され、テーブルのJOINが必要なくなります。この利点だけでも、データベースに対するドキュメントの読み込みの大幅な性能アップに寄与します。
さらに、MongoDBのドキュメントは、開発言語のオブジェクトに非常に近い構造を持ってます。この構造によって、アプリケーションがどのようにデータを扱うのか、そのマッピングが非常に楽になります。
動的なスキーマ
MongoDBのドキュメントは様々な構造を持つ事ができます。例えば、ユーザ情報を保有するドキュメントは全てシステムのユーザIDとログインした最終日を情報として持つかもしれませんが、幾つかのドキュメントは、他のアプリケーションのID情報を持たせる事ができます。
フィールド構造もドキュメント毎の変える事もできます。システムに対してドキュメントの構造を宣言する必要が有りません。新しいフィールドが発生したとしても、他のシステムカタログや、他のドキュメントに影響を与える事なく追加する事ができます。
MongoDBは、開発者に対して、
スキーマ設計のアジャイルな手法を提供します。
開発者はコードを書きながら、オブジェクトの定義を行う事ができ、そして機能が追加されていくと共に、MongoDBは新しいオブジェクトも同時に管理する事ができます。その際に、ALTER_TABLEや、スキーマの変更などの面倒な処理を行う必要が一切ありません。
下記の表が、MongoDBのデータモデルと、RDBとKVSとを比較したものです。
| MongoDB | RDB | KVS | |
|---|---|---|---|
| Rich Data Model | |||
| Dynamic Schema | |||
| Typed Data | |||
| Data Locality | |||
| Field Updates | |||
| プログラマへの負担の軽減 |
※複雑なデータモデルの場合
MongoDBのQueryモデル
言語ドライバー
柔軟なドキュメントデータモデル、動的なスキーマ、
そして言語ドライバーサポートを兼ね備えたMongoDBをもって、
アプリケーション開発、ひいては市場への投入を早める事ができます。
クエリータイプ
- キー・バリュー クエリー
- ドキュメント内の任意のフィールドをリターンする。
- レンジ クエリー
- 範囲を指定したバリューをリターンするクエリー(例：以上、以下、範囲、など）
- 位置情報クエリー
- 位置検索を行うクエリーで、点／線／円／ポリゴンによる範囲を指定し、範囲内の要素をリターンする検索
- テキストサーチクエリー
- ブーリアンオペレータ(例：AND, OR, NOT)を使って、テキストでの検索を行う。
- アグリゲーションフレームワーククエリー
- 指定したクエリー結果(例：count, min, max, average, SQL GROUP BY句と同等)の集約をリターンする。.
- MapReduceクエリー
- JavaScriptで表記した複雑なデータ処理をデータベースに渡って実行するクエリー。
他のNoSQLデータベースと異なり、MongoDBは一つの単一のキーバリュー処理に限定される事なく、複雑なクエリー、セカンダリーインデックスなどの高度なクエリー機能を使い、構造型データ／非構造型データに限らずその価値を引き出しアプリケーションの開発に寄与できる魅力をもっている。
また、アナリティクス機能、テキスト検索、位置情報機能等の機能に加え、インメモリ処理による高速演算により、広い範囲のリアルタイムアプリケーションをこの一つの技術を通して実現する事が可能になります。”
インデックス機能
- コンパウンド、ユニーク、アレイ（配列）、TTL、位置情報、スパース、ハッシュ、テキスト等のインデックスを定義する事ができ、複数クエリーパターン、複合データタイプに対してクエリーを最適化できます。
- MongoDBのQuery Optimizer機能はクエリーを分析し、最も適した実行プランを自動的に選択します。開発者はこのプランを、Explainコマンドとインデックスフィルター機能でレビューの上、最適化する事ができます。
- ライタイム時にアドホッククエリーを最適化するために、MongoDBで2つ以上のインデックス利用が可能になるインデックスインターセクション機能があります。
MongoDBのクエリーとインデックスモデルとRDBとKVSとの比較をした表です。
| MongoDB | RDB | KVS | |
|---|---|---|---|
| Key-Value クエリー | |||
| セカンダリ インデックス | |||
| Index Intersection | |||
| Range Queries | |||
| 位置情報 | 高額なアドオン | ||
| テキスト検索 | 高額なアドオン | ||
| Aggregation | |||
| MapReduce | |||
| 多様なドライバーサポート |
MongoDBのデータ管理
スケーラビリティのための自動シャーディング
MongoDBは、シャーディングと呼ばれるアプリケーションには透過な機能を通して、低価格汎用サーバ上のスケールアウト型のデータベース機能を提供します。シャーディングは、シャード、と呼ばれる単位で複数の物理パーティションにデータを分散管理します。また、アプリケーションには一切手を入れずに、単体ハードウェア上にMongoDBを実装した際のRAMやディスクI/Oによる性能限界を解消する事もできます。クラスターにおけるデータ量の増減についても、MongoDBがクラスター内のシャードのサイズを自動的に調整します。
シャーディングはアプリケーションにとって透過的に機能します。
シャードの数が1個であろうと100個であろうと、
MongoDBをアクセスするアプリには違いが見えません。
RDBと異なり、MongoDBのシャーディングはデータベースに組み込まれていて、自動的に起動できます。アプリ開発者はアプリコードに複雑なシャーディングロジックを書く事もないし、当然ながらシャードの移行に合わせてアップデートする必要もありません。オプレーションチームもプロセス管理やデータの分散化管理を行うソフトウェアを導入する必要もありません。
また、他のNoSQLデータベースと異なり、MongoDBは複数のシャーディングポシリー（ハッシュベース、レンジベース、ロケーションベース）を提供します。この多様性により、クエリーパターンやデータローカリティに基づいたデータの分散管理を行う事ができます。この多様性が広い範囲のアプリケーションに対するスケーラビリティを提供します。
- レンジベースシャーディング
- シャードキーの値に基づいてドキュメントは複数シャード間でパーティションされます。近い値のシャードキーを 持つドキュメント同士は同じシャードにて管理される可能性が高いため、このアプローチは一定の範囲の値を持つ クエリーをかけるアプリケーションに向いています。
- ハッシュベースシャーディング
- ドキュメントはシャードキーにMD5ハッシュをかけた値をベースにパーティションされます。この方法はシャード間に 等しくデータを分散させる方法として適しているが、レンジベースでの検索には必ずも向いていない。
- ロケーションベースシャーディング
- ドキュメントはユーザが指定した設定により、特定のシャードキーのレンジを特定のシャード、もしくはハードウェア に結びつける事が可能です。ユーザは常にドキュメントの物理的な管理場所（例えば特定のデータセンタ、ストレージ システム、等）を管理する事が可能で、その場所も変更が可能です。
MongoDBのスケーリング機能をRDBやKVSと比較した表です。
| MongoDB | RDB | KVS | |
|---|---|---|---|
| 汎用ハードウェアへのスケールアウト | |||
| 自動シャーディング | |||
| ハッシュ シャーディング | マニュアル | ||
| レンジ シャーディング | マニュアル | ||
| ロケーション シャーディング | マニュアル | ||
| 自動データバランシング | マニュアル | 限定 |
MongoDBは、強力なスケーリング機能を提供します。データ量、性能、複数データセンタ運用であったとしてもMongoDBのスケーリング機能は能力を発揮します。
アプリケーションの柔軟性を強化するプラガブルなストレージアーキテクチャ
MongoDBは次の2つの技術トレンドをサポートします。
- 新規アプリケーション
- 企業は、ビジネスに適用できるアプリケーションの範囲を広げている。
- 技術の合理化
- CIOは戦略的に特定のベンダーを採用し、より合理的にその技術をビジネスに活用しようとしている。
MongoDBによって、企業は広い範囲のアプリケーションニーズ、ハードウェアリソース、アプリの実装デザインを適用することができます。特に、MongoDBのプラガブルストレージアーキテクチャにより、MongoDBは特定のハードウェアアーキテクチャを最適化できる様、機能拡張が可能になってます。アプリケーションの様々なニーズに応えるために、複数のデータベースシステムを採用しなければいけない要件に対してこのアーキテクチャはその開発コストを期間を大幅に短縮する事に寄与します。開発者は、MongoDBのクエリー言語、データモデル、スケーリング機能、セキュリティ、運用ツールを通して、別々のストレージエンジンを採用する個々のアプリケーションを統合的にサポートする事ができます。
MongoDB 3.0は現在、次の2つのストレージエンジンを組み込んでます。
- MMAPv1 (Memory Mapped Version 1)エンジン
- 過去のMongoDBで使用されていたエンジンをさらにエンハンスしたもの。
- WiredTigerストーレジエンジン
- 高いコンカレンシーと圧縮率を提供するストレージエンジン。
両エンジンは、一つのMongoDBレプリカセット内に共存させる事も可能で、ストレージエンジン間の性能比較やデータ移行が容易です。また、上記以外にも、イン–メモリ型のストレージエンジンも実験的に提供されており、さらに新規のストレージエンジンはMongoDB、もしくはエコシステム内で開発されています。
データ圧縮によるストレージ効率
MongoDBは、WiredTigerストレージエンジンを採用した際には、データ圧縮がサポートされており、物理的なストレージ容量を80%まで削減する事ができます。またそれにより、データの圧縮によるI/Oスケーラビリティの向上が実現し、圧縮手法も、コレクション、インデックス、ジャーナルに対して個々に細かく設定する事ができます。
MongoDBのデータ整合性と可用性
トランザクションモデル
MongoDBは、ドキュメントレベルでACID特性を保証します。一つ、もしくは複数のフィールドに対して書き込み処理が一つ行われる際、サブドキュメント、もしくは配列内の要素がアップデートされます。MongoDBのACID特性は、このドキュメントに対するアップデートの処理の隔離を保証し、ドキュメント内容の一貫性の保持するために処理のロールバックもサポートされます。
開発者は、MongoDBのWrite Concern機能を使い、ディスク上のジャーナルファイルへの書き込みが完了したのちにアプリケーションに対して書き込み処理のコミットを行うように処理を設定することができます。この手法は、リレーショナルデータベースで採用されるデータ保証の方法と同じです。分散システムにおいては、MongoDBはさらに各々の要求されるSLAに基づいて設定を行うことができます。例えば、1つのデータセンタにおいて少なくとも2つのレプリカへの書き込み、さらに2つ目のデータセンタにおいて1つのレプリカセットの書き込みを完了するようなWrite Concern条件を設定することができます。
レプリカセット
MongoDBはデータの複製をレプリカセットと呼ぶ機能を通して管理します。レプリカセットは、データベースのダウンタイムを防止するためにデータを自動修復するためのシャード機能です。レプリカセットのフェイールオーバ（回復）は完全に自動化されていて、管理者による主導の管理操作は必要ありません。
MongoDBのレプリカセットないのレプリカの数は設定できます：レプリカの数が多ければデータの可用性が大きくなり、データベース障害に対する対応力が高まります（例：複数のマシン障害、ラック障害、データセンタ全体の障害、ネットワークパーティションの停止等）。また、設定を変えることにより、書き込み処理の完了を、すべてのレプリカへの書き込み終了後に定義することにより、データの同期を保証することも可能です。
”MongoDBのレプリカセットは、フォールトトレランスや障害回復の機能を提供します。この機能を複数データセンタ間で実装することにより、グローバルな拠点間でデータの配信や分離等を必要とする運用管理やデータ分析要件に利用できます。
レプリカセットはさらに、データベースをオフラインにすることなく、ハードウェアやソフトウェアをアップデートする運用方法も提供できます。”
インメモリ性能とディスク上のデータ運用管理
MongoDBはデータベース処理の高速化でシステムのもつRAMを活用します。メモリからのデータ読み込みは、ディスクから読み込みの約10万倍の速さです。MongoDBにおいては、データは全てMemory Mappedファイルとしてアクセスされます。アクセスされないデータはRAMにはロードされません。MongoDB自体がインメモリの高速処理を行うため、ほとんどのアプリケーションはデータベース用のキャッシングレイヤーの設定が必要なくなります。
より詳しい情報は、こちらのアーキテクチャガイド(英語)を参照しください。
セキュリティ
“接続性の高い今日において、データセキュリティとプライバシー保全は大変重要な要件です。ソーシャルメディア、ログ情報、モバイルデバイス、センサーネットワーク等の新しい情報源から収集したデータは従来のバックオフィスの生成するトランザクションデータと同様に機密性の高いデータとして扱う必要があります。
MongoDB Enterprise Advanced(英語)は、これらのデータに対する保護、監視、そしてアクセス制御を万全にする機能を提供します。”
- 認証
- データベースへのアクセスをシンプルにするために、MongoDBはLDAP、WIndows Active Directory、Kerberos、x.509 PKI証明書等の外部セキュリティ機能との統合をサポートします。
- 認可
- システム管理者にとって、ユーザの役割を指定する機能はアプリケーションのアクセス権の細かい運用に必要な機能です。さらに、フィールドレベルの編集機能は、ミドルウェアと組み合わることにより、ドキュメント内の個々のフィールドへのアクセス管理を可能とし、複数のセキュリティレベルでデータのコロケーションを容易にする機能を提供します。
- 監査機能
- 様々な法令遵守のために、セキュリティ管理者はMongoDBの提供する監査ログ機能を使い、データベースへのアクセスや運用の記録を監視することができます。
- 暗号化
- MongoDBのデータは、ネットワーク上とディスク上で暗号化することができます。SSLもサポートされていて、暗号化されたチャネル間でクライアントとMongoDBとの間で通信ができます。
さらに詳細な情報はこちらをダウンロードしてください。MongoDBのセキュリティ参照アークテクチャ(英語)
運用とオペレーションについて
Ops Managerは、MongoDBのデプロイ、監視、バックアップ、スケール等の運用を行うのに最も簡単な方法を提供します。OpsManagerはMongoDBの開発者が作ったもので、MongoDB Enterprise Advancedの一部として提供されます。OpsManagerの機能の多くは、MongoDB Management Service (MMS)（MongoDBが提供するクラウドサービス）でも提供されます。両製品とも、MongoDBのデータベースのライフサイクルを統合的に管理するアプリケーションをセットで提供します。
- デプロイの自動化と管理
- クリックひとつでデプロイが可能で、アップグレードもダウンタイム無しで実行可能。
- 監視機能
- MongoDBシステムの100以上のメトリクスを監視し、MongoDBの性能状況の可視化、履歴、自動アラート等を提供します。
- 障害回復
- 定期的なバックアップと共に、任意のポイントでのリカバリ処理も提供されます。
下記に、もう少し詳しく説明します。
デプロイ操作とアップグレード
Ops Managerは、セルフサービス型のポータル、もしくは独自のRESTful APIを通してMongoDBの運用機能を提供します。MongoDBのデプロイメントは単純なMongoDのインスタンス、もしくはレプリカセット、シャーディングされたクラスターの立ち上げを行うことが出来、さらにそれをパブリッククラウド、もしくは企業内のデータセンタなど、どのようなホスティング環境においても展開することができます。
初期的なデプロイ操作に加えて、OpsManagerは運用中のシステムに対しても動的にシャードやレプリカセットメンバーの追加等の操作も行うことができます。さらに、Oplogのアップグレード、リザイズ等の運用処理もシステムを止めること無しに、簡単な操作でできます。
監視
Ops ManagerはMongoDBのサービスを開発者、管理者や運用チーム全体に可視化させてくれる事が特長です。様々なチャートやカスタマイズ可能なダッシュボードを通して、OpsManagerは100以上のデータベースやシステムに関する運用上のデータ（オペレーション数のカウント、メモリ／CPU利用率、レプリケーション状況、コネクションの状態、ノードの状態、等）を監視し、データ収集して表示します。
これらの運用データは暗号化されてOpsManagerに引き渡され、処理、分析が行われた後、ブラウザーを通してその結果や結果に伴うアラートが表示されます。これにより、システム管理者はリアルタイムにMongoDBの健康状態を管理する事ができます。履歴情報の分析も可能で、その情報に基づいて運用上のベースラインやシステム拡張の計画なども立てる事ができます。企業が利用している既存の監視ツールとの連携もOpsManagerのAPIを通して容易にできます。
”Ops Managerは、既存の運用管理ツールとの連携も含め、
MongoDBのリアルタイム監視、履歴分析ができる機能を提供します。”
“アラート機能により、MongoDBシステムの
効率の良い管理運用が実現できます。”
障害回復
データセンタでの火災や浸水、人為的ミス、アプリケーションの問題等、ミッションクリティカルなデータを損失する要因は多く、そのためのバックアップ／回復戦略は重要な要件になってます。この運用戦略をしっかり立てる事により、データ損失の可能性を減らし、コンプライアンス要件を満たす事が可能になります。
OpsManagerとMMSは、MongoDBの継続的なバックアップ、レプリカセットの任意の時点のリカバリ、シャードクラスタの継続的なスナップショット、等の様々なバックアップを提供する唯一のツールです。OpsManagerの生成するMongoDBデータのスナップショットはユーザの指定する管理方針に基づいて複数コピー保持する事ができます。
MongoDBの運用管理機能を他のRDBやKVSと比較した表は下記のとおりです。
| MongoDB | RDB | KVS | |
|---|---|---|---|
| 自動リカバリ／自動フェールオーバー | 追加のクラスタソフトウェアが必要 | N: マニュアルなフェールオーバーが必要 | |
| 別なキャッシイングレイヤーが必要 | |||
| データセンタ管理機能 | 高価なアドオン機能 | ||
| 自動プロビジョニング | |||
| 継続的なバックアップ／任意の時間のリカバリー | |||
| 高度なセキュリティ機能 | |||
| システム管理フレームワークとのAPI統合 |
MONGODBを外部の監視ソリューションと連携
Ops Manager APIは、MongoDBに関する監視データとそれを管理するOpsManagerの機能へのアクセスを外部の管理ツールに提供します。
OpsManagerの機能に加え、MongoDB Entepriseはシステム情報をSNMPトラップにレポートする機能もサポートしており、外部の監視ソリューションで他のシステムも含めた統合的な運用管理ソリューションも支援します。
オペレーションベストプラクティスについてより詳細に知りたい方はこちらをダウンロードしてください。MongoDBオペレーションガイド
コスト削減
MongoDBは従来のRDBのシステムによる開発／運用と比較して1／10のコストで実現する事ができます。コストセーブの要因は次のとおりです。:
- MongoDBの使いやすさとプログラミングが簡単である事。これがアプリケーションの開発と保守コストを大幅に削減します。
- MongoDBは安い、汎用サーバを使ってスケールする事ができる事
- MongoDBのコマーシャルサブスクリプションが安い事と、拡張機能が基本機能としてサポートされている事。
何よりも、MongoDBのこれらの特長は、企業にとっての重要な要件である、新規ソリューションの市場への早期投入と成長のニーズに応える事ができる、という点です。
さらに詳しい情報は、次のドキュメントをダウンロードしてください。Oracle and MongoDBのTCO比較