はじめに
昨今、AjaxやWebAPIは広く普及し、ほとんどのウェブサイトで使用されるようになりました。それを支えているのは、JavaScriptとJSONです。もちろん、今やAltJSやYAMLなど、多数の関連技術が生み出され利用されています。とはいえ、ベースとなっているのはJavaScriptとJSONですから、これからも基盤技術として長い間利用されることでしょう。
最近では、TwitterなどのSNSからWebAPIでデータを取得できることもあり、分析やシステムでの利用のために、JSONを保存する必要が出てきました。しかし、従来のRDB（リレーショナルデータベース）では、階層的なJSONのスキーマ定義をすることは困難です。また、WebAPIは仕様変更されることも多く、その度にスキーマを変更するのは大変です。
そこで、MongoDBなどのドキュメントDBが作られることになりました。ドキュメントDBはNoSQLデータベースの一種で、JSONをスキーマ定義なしで保存することができます。ビッグデータと一緒に語られることも多いですが、ビッグデータ以外で役に立たないわけではありません。
この記事では、MongoDBとRDBの違いを知りたい方のために、概要や構造、RDBとの使い分け方などをお伝えします。それでは、まずは概要から説明していきます。
MongoDBの概要
MongoDBは、クロスプラットフォーム対応のオープンソースドキュメントDBです。DBランキングサイトDB-Engines では、Oracle、MySQL、SQL Serverに続き、第4位になっており、最有力のNoSQLといえます（2016年4月現在）。JSONを、ドキュメントとしてそのまま保存することができ、ドキュメント全体のCRUDはもちろん、一部のみの更新も可能になっています。
RDBよりもスケーラビリティが高く、容易にスケールアウト（水平スケール）できるので、大量のデータを高速に処理することが可能です。一方、トランザクション機能がないため、厳密なデータ整合性が求められる用途には向いていません。NoSQLデータベースは決して万能ではなく、RDBとの使い分けが必要です。使い分けについては、後で説明します。
公式サイト：https://www.mongodb.org/
レポジトリ：https://github.com/mongodb/mongo
MongoDBのデータベース構造
データベース
RDBと同じく、MongoDBでも最上位の要素はデータベースです。まあ、データベースですから当たり前といえば当たり前なのですが。もちろん、複数のデータベースを作ることができますし、削除も簡単です。RDBと違うのは、”CREATE DATABASEコマンド”がなく、”USEコマンド”で自動生成されることです。
コレクション
RDBのテーブルに該当するものがコレクションになります。コレクションには、ドキュメント（JSON）を複数保存することができます。しかし、テーブルとは違いスキーマ定義はありません。このため、保存するのはどんな構造のJSONでもかまいません。とはいえ、読み取り時にはJSONの構造を把握していなければなりませんから、スキーマ（JSON）自体は管理する必要があります。また、コレクション同士の”JOIN”はできません。バージョン3.2からは、”LOOKUP”という機能が追加されていますが、完全にRDBの”JOIN”と同等のことができるわけではありません。
ドキュメント
RDBの行に該当するものがドキュメント（JSON）になります。内部的には、BSONというJSONのバイナリ形式で格納されています。JSONをそのまま挿入でき、フィールド単位の更新が可能です。ORM（オブジェクトリレーショナルマッピング）を行うことなく、直接JSONを保存できるのは便利ですね。
JSONを操作するためのクエリが豊富に用意されているので、基本的なCRUDはRDBと同様に行うことができます。しかし、RDBとは違い、データ型が決まっていないため、誤ったデータ型で更新してしまわないように注意する必要があります。また、上述の通りトランザクション機能がないため、必要な場合はアプリケーション側で実装することになります。
MongoDBを使ったほうがよい場合
データ整合性よりも速度が求められる場合
MongoDBは”結果整合性”という考え方のもと、厳密なデータ整合性を提供しない代わりに、スケーラビリティを高めています。つまり、スケールアウト（水平スケール）が容易に可能になり、RDBよりも高速なレスポンスが得られるようになります。また、加えてレプリケーションを構成することで障害耐性も高めることができ、フェールオーバーすることも可能です。
スキーマを事前に定義できない場合
多数のスキーマが混在している、または頻繁に変更される場合は、スキーマ定義なしでJSONを保存できるMongoDBの出番です。たとえば、アプリのログや仕様変更の多いWebAPIなどです。しかし、RDBよりもスキーマ管理に気を配っておかないと、どんなデータが保存されているのかわからなくなってしまいます（調べるのは面倒です）。どんな構造のJSONが保存されているのか、しっかりドキュメント化しておくとよいでしょう。
RDBを使ったほうがよい場合
リレーションが多い場合
MongoDBは、基本的にリレーションを持たず、”JOIN”も行えません。そのため、オブジェクト同士の関連が強いシステムは、従来通りのRDBの方が適しています。数がそれほど多くないのであれば問題ありませんが、あまり多すぎるとパフォーマンスに悪影響があります。または、リレーションに特化した、Neo4jなどのグラフDBを検討するのもよいでしょう。
トランザクション処理が多い場合
トランザクション処理を多用する、厳密なデータ整合性が求められるシステムには、”結果整合性（BASE）”を採用するMongoDBは向いていません。トランザクション処理を、アプリケーション側で実装することもできますが、余計なコストがかかりますし、バグを引き起こしがちです。やはり、こういったシステムでは素直にACID特性を持ったRDBを採用したほうがよいでしょう。
さいごに
いまや多くのサービスでMongoDBが使われており、野村総合研究所（NRI）などの国内企業でも商用サポートを受けることができます。登場から7年余り経ち、2回のメジャーバージョンアップを経て、かなり成熟してきました。現在も、日々開発が続けられています。RDBよりもMongoDBが有効な場面があれば、積極的に活用することを検討してみましょう！
本ブログは、Git / Subversion のクラウド型ホスティングサービス「tracpath(トラックパス)」を提供している株式会社オープングルーヴが運営しています。
開発の効率化をしたい！もっと便利なツールを使いたい！そんなお悩みをtracpathで解決！
「tracpath(トラックパス)」は、企業内の情報システム部門や、ソフトウェア開発・アプリケーション開発チームに対して、開発の効率化を支援し、品質向上を実現します。
さらに、システム運用の効率化・自動化支援サービスも提供しています。
”つくる情熱を支えるサービス”を提供し、まるで専属のインフラエンジニアのように、あなたのチームを支えていきます。
