MongoDB保守サポート＆ソリューション｜OSSサポートのOpenStandia™【NRI】

なぜMongoDBなのか？「選ばれる理由」

MongoDBは、RDBMSの不得意領域をカバーする新しいアーキテクチャのDBです。

スキーマレスデータの格納

RDBMSでは取り扱いが困難なスキーマレスデータの取り扱いが得意
ビックデータ格納

スケールアウトしやすいため、低コストで高スループットを実現
開発の容易性
- インストール・設定・管理が容易
- RDBMSと類似した機能群を持ち、RDBMS技術者が理解しやすい
- 開発を進めながらデータ構造を変更しやすい

RDBMSがビックデータやスキーマレスデータに適さない理由

RDBMSではビックデータ処理が高コスト

近年のモバイル・ソーシャル対応や IOT（Internet of Things）対応のために、DBに対するアクセス量やデータ量が増加し、RDBMSのスケールアップでは処理の限界を迎えることが多くなってきています。
一方で、RDBMSをスケールアウト（水平分散）させるのは困難で高コストになる傾向にあります。

RDBMSではスキーマレスデータの扱いが困難

近年、生成されるデータの80%以上がスキーマレスデータであるといわれています。
スキーマ定義が必須であるRDBMSでは、複雑な階層構造のデータ、データ構造の追加・変更が頻繁に発生するようなスキーマレスデータの格納や取り扱いが難しいと言えます。

ビックデータ処理、スキーマレスデータ処理が得意なNoSQL

RDBMSの不得意領域をカバーする、NoSQL（Not Only SQL）という新しい考え方のDBが登場

代表的なNoSQL

MongoDB
Couchbase
HBase
Redis
membase
riak
Apache Cassandra
Neo4j

NoSQLの特徴

コストの安いIAサーバや仮想マシンを多く並べて、スケールアウトして処理することにより、低コストで高スループットを実現可能
スキーマレスデータを取り扱いできる
一般的にトランザクションや、データの整合性を取る機能は弱い傾向にある（そのため、用途によってRDBMSとNoSQLを使い分けることが重要）

名称	水平分散	スキーマレスデータ	トランザクション	データの整合性
RDBMS	△	×	◎	◎
NoSQL	◎	◎	△	△

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

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

データを階層構造のドキュメント（≒JSON）で扱う

■JSONとは

ハッシュと配列をネストして使うことができる
XMLよりシンプルに表現できる
読みやすく直観的

■JSONの例

MongoDBの特徴

リッチなデータ

KVSと比較して、ドキュメント(JSON)はリッチなデータ構造であり、複雑なデータを扱いやすい

柔軟なクエリ

動的なクエリ　SQLライクなクエリで扱いやすい
例）コレクションpersonに、“name”が“watanabe”で、“age”が30のドキュメントを3つだけ取得したい
RDBMSと同様に、動的にクエリを作成可能で事前に定義が不要
単純な条件検索だけでなく、集計等の高度なクエリも利用可能

RDBMSと同等な、多様なインデックス

セカンダリインデックス：主キー以外でインデックスを作成可能
複合キーインデックス：複数のキーでインデックスを作成可能
マルチキーインデックス：配列の要素に対してインデックス作成可能

水平分散

水平分散（シャーディング）が実現しやすい
キーによってデータをノードに分散することが可能で、ノードを動的に追加し、データを自動バランシングする機能もある

レプリケーション

複製（レプリケーション）が容易
- 簡単なコマンドで、マスタースレーブ型のレプリケーションを構築可能
- シャーディングと組み合わせることも可能
- MongoDBドライバが自動的に書き込み先を切り替えるため、仮想IPなどを用意しなくてもフェイルオーバが可能（≒クラスタソフトウェアが不要）
レプリケーションとシャーディングを組み合わせて、負荷分散と冗長化を両立

スキーマレス

スキーマレスデータを取り扱える
テーブル定義など無しに、すぐにデータをCRUDできる

利用しやすい

インストールが非常に容易
- OS毎にバイナリがあるため、ライブラリの追加インストールが不要
- 起動までわずか 3ステップ
  - OS毎のバイナリをダウンロード
  - データディレクトリを作成
  - 起動
RDBMSを使っていた人が使いやすいように作られている
- データベース＞テーブル(コレクション)＞ドキュメントというデータ構造
- SQLとMongoクエリ言語の大部分はマッピングが可能
- インデックスもSQLと同様の宣言が可能
豊富なドキュメント・ノウハウ
- 英語ではあるが、他のNoSQLに比べて公式ドキュメントは豊富
- 多くの人が使っているため、ノウハウが豊富。日本語のノウハウも多い

多機能

他にも数多くの便利な機能が豊富

分類	機能	説明	ユースケース
機能	GridFS	大容量ファイル（16MB以上）を扱うことができる大容量ファイルをドキュメントに分割して格納し、アプリケーションには等価的なAPIを提供	大容量ファイルの管理
	地理空間インデックス	2Dや3Dのデータを格納し、それに対して交点や近傍などの検索をかけることができるアプリでの作りこみが不要	地理アプリのデータベース
	キャップ付き・期限付きコレクション	サイズや期間を指定したコレクションを作り、自動的に古いドキュメントを引き落とせる	ログ保管
	集計機能	SQLグループ関数のように集計できるまた、map/reduceによる集計も可能	データ集計
耐障害性	ジャーナリング	単一ドキュメントに対して、書き込みの一貫性が保持できる	突然の電源停止等に対応したい
運用性	各種機能コマンド	さまざまなサーバの統計情報を取得するツールや、JSON形式で出力するコマンドがある	運用監視ツールとの対応障害対応効率化
運用性	MMS(MongoDB Management Service)	MongoDBの監視やアラート、自動バックアップ、ポイントインタイムリカバリ等ができるサービス	運用監視の仕組みを簡単に作りたい

MongoDBを使う上での注意点

トランザクションが無い

MongoDBが複数のドキュメントを一貫性をもって更新することができない
ミッションクリティカルで複数のテーブルの更新を保証しなければならないようなシステムでは、利用してはならない
ただしバージョン4.0にて複数ドキュメントに対するトランザクション機能が追加されました

外部キー・結合が無い

他のドキュメントへの参照はアプリケーションで実装する必要がある
当然ながら、外部キー制約もないため、テーブル間の整合性が重要なシステムには向いていない
複数のドキュメントの内容を結合して取得することはできない

スキーマが無い

格納されているデータのキー名やデータ型が分からない
データ登録の際に不具合があってもエラーが発生しない
設計書を厳格に管理しないと、格納データの内容が分からなくなり、保守性の低下を招く恐れがある

NoSQLならば、MongoDBから

世界には数多くのNoSQLがあります。いずれも独自のノウハウが必要となり、習得期間とコストを要します。
その中で、OpenStandiaでは「MongoDB」を推奨しています。

NoSQLの中では多機能で、敷居が低い

他のNoSQLと比較して機能が豊富である
RDBMSと類似した機能群を持ち、RDBMS技術者が理解しやすい
導入が非常に容易で、すぐに開発を始められる
開発を進めながらデータ構造を変更しやすく、生産性が高い

NoSQLの標準になりつつある

最も人気のあるNoSQLであり、米国ではNoSQLの標準になりつつある。
開発元のMongoDB,Inc. は、2013年10月に150M$（約150億円）の投資を受け、NoSQL企業の中でも企業活動が活発である。
[参考]米MongoDB、1億5000万ドルの資金調達「Oracleに追いつく成熟度を目指す」
- http://internet.watch.impress.co.jp/docs/news/20131007_618340.html
[参考]solid IT社の提供する「DB-Engines Ranking」で、MongoDBがNoSQL部門で人気No.1
- http://db-engines.com/en/ranking
[参考]ZDNet Japan DB人気ランキング--NoSQLなど注目されるも従来型RDBMSが支配的
- http://japan.zdnet.com/datacenter/analysis/35052519/
[参考]MongoDB社サイト Google Search、LinkedIn Job SkillsなどのMongoDB人気度を紹介
- http://db-engines.com/en/ranking

豊富な導入実績がある

600社以上の導入実績がある。
IT企業のほか、金融や保険業界での活用事例も出てきている。
- MetLife
- SAP
- eBay
- McAfee
- Cisco など多数
[参考]MongoDB社サイトビッグデータ導入事例
- http://www.mongodb.com/use-cases/big-data
[参考]MongoDB社サイト Internet of Things導入事例
- http://www.mongodb.com/use-cases/internet-of-things

利用シーン(1)　スキーマレスデータ処理

データハブ

既存のレガシーデータの集約基盤として利用

スキーマレスであるため、様々なスキーマのRDBMSからデータを集約することが容易
集計したデータは、性能要件の高いモバイルアプリ等に提供

事例：MetLife

コストのかかる商用製品の代わりに、MongoDBをデータハブとして利用

事例：グローバル信託銀行 X社

RDBMSとMongoDBのハイブリッド

スキーマレスが向いているデータのみをMongoDBで処理

既存のシステムのスキーマレスデータをMongoDBに切り出すことにより、スキーマ変更の負荷軽減や、性能向上が可能
特に商品カタログ等の多様なフォーマットで更新頻度が多いデータを、MongoDBで扱うことが多い

事例：野村総合研究所

利用シーン(2)　ビックデータ処理

MongoDBを単体で使う

大量トラフィックのWebシステム/オンラインゲームでメインDBとして

ユーザの増加に合わせて横に並べればよい
リッチなデータ構造を扱えるので、複雑なアプリケーションにも対応

事例：McAfee

ログ格納

ログデータはスキーマレスであり、整合性について厳密な要件がないため最適
レプリケーションすることでデータロストの懸念もない

事例：野村総合研究所

既存データから統計情報を取得して、経営判断に役立てる

戦略的アプリのデータベースとして利用

利用シーン(3)　その他の使い方

高機能なレプリケーションをフル活用

従来のバッチ連携をMongoDBのレプリケーションに置き換え

リアルタイムに同期するため、連携時間を短縮
近い拠点からデータを取得するため、通信効率が良い

事例：グローバル信託銀行 X社

アジャイル開発で利用

頻繁にスキーマ変更が発生するアジャイル開発ではスキーマレスが生産性アップの秘訣

テーブル定義の管理が不要
すぐに使い始められる
JSONでのデータ出し入れが可能で、ライトウェイトなスクリプト言語との相性が良い

導入事例(1)　OracleRACからMongoDBへ移行

データハブ＆検索基盤＆分析基盤

[国内][不動産] 不動産情報物件検索サイト
Oracle RACからMongoDBへ移行、性能向上とコスト削減を実現

約4万社の不動産会社が使っている物件検索サイト
検索はSolrで行い、実態をMongoDBに格納する
APサーバに来る参照リクエスト量は毎分5000リクエスト。
更新は毎日20万～30万ドキュメント
物件データは700万ドキュメントで300GByte
オンラインリクエストを受け付けないhiddenレプリケーションノードを用意し、分析に用いる。
一日に一回バッチでHadoopクラスタに連携し、Hiveにてデータ分析を行う。用途として、MongoDBではインデックスがかからないような集計や、コレクションをまたいだ集計を行う。
MongoDBの監視およびバックアップにオンプレミス版MMS(MongoDB Management Service)を利用。
サーバのログはfluentdにて収集しMongoDBに格納。

課題	既存のOracle RACが検索パフォーマンス遅かった。物件データの構造が複雑であり、検索条件によっては多数のJOINが必要で、3秒から5秒程度かかっていた加えてOracle RACのライセンス料金とストレージが高額であった不動産情報のスキーマ変更があるたびに、DBの変更とアプリの変更があり、変更工数がかかった
選定理由	DBはOracle, MySQL, MongoDB、検索エンジンはSolr, sphinxを比較したが、SolrとMongoの組み合わせが以下の理由から最も最適と判断した。スキーマレスであるため、項目の追加・変更が容易 JOINがない分、MongoDBの方がOracleよりも若干性能がよかった将来的に今回実装するAPIを他のプロダクトに適用する場合、MongoDBの方がスケーラビリティが高いと判断した(Oracle RAC構成の場合、シェアードディスク方式であるため、スケーラビリティに限界があるため) ライセンスコストがMongoDBの方が安価であった
結果	2015年5月にリリースし、現在安定稼働中応答時間は従来数秒秒程度かかっていたものが、SolrとMongoDBの組み合わせで800ms程度になった。MongoDB自体の応答は数msであった。スキーマ変更の時にアプリだけ変更するだけで良くなり、変更工数が削減した。 MMSを採用したことによりMongo特有のメトリクスを使った監視やイベント検知が簡単に実現できた。加えて時刻指定でのリストアができるため、リカバリが必要になった際に心強い