第1回目となる今回は，まずMongoDBの概要と特徴的な機能を解説し，どのようなケースで有効に使えるかを紹介します。

NoSQLへの流れ

過去20年間でCPUの処理能力は数十倍になり，ディスクの1バイトあたりの金額は1000分の1になりました。開発環境はクラウドに移行し，扱うデータ量とWebサイトのアクセス数は大幅に増加しました。このような環境の変化から，データストアへ求められるものが変化してきています。

RDBでは，高トラフィックなWebシステムのバックエンドという箇所では，性能の限界があると考えられるようになってきました。その結果，RDBでは性能に限界がある適用箇所にNoSQLを補完することによって補おう，という流れが出てきたと考えています。

NoSQLの分類

現在NoSQLと呼ばれているものは，大きく分けて3つに分類されます。

1．KVS（Key-Value Store）

• データをKeyとValueのHash形式で持つ
• 基本的にはKeyでの完全一致検索でしかデータを取得できないが，高速に動作する
• 代表的なプロダクト：Memcached，Redisなど

2．ドキュメント指向データベース

• スキーマを定義しなくても使用できるスキーマレスである
• 複雑な検索条件でデータを取得することが可能
• 代表的なプロダクト：MongoDB，CouchDBなど

3．列指向データベース

• RDBのような行単位ではなく，列単位での処理に特化している
• 代表的なプロダクト：Cassandra，HBaseなど

この連載ではNoSQLのひとつでありドキュメント指向データベースに分類されるMongoDBについて紹介していきます。

MongoDBが目指すもの

MongoDBは，NoSQLの高パフォーマンス／スケーラビリティを保持しつつ，RDBライクな機能をバランスよく組み込むことを目指して開発されているドキュメント指向データベースです。従来のRDBが備えている一部の機能を制限することにより，KVSに近いパフォーマンスを実現させています。逆に言うと，KVSのパフォーマンスを多少犠牲にして，慣れ親しんだRDBの機能を実装しているという見方もできます。では，MongoDBは何を制限して，どんな機能を実装しているのでしょうか。

RDBと比較してMongoDBが実装しなかった機能は，トランザクションとリレーショナル（JOIN）です。これらの機能は場合によってはコストが高く，パフォーマンスを著しく劣化させる原因となると判断しました。また，開発者がデッドロックについて考えないで良いようなシンプルでわかりやすいシステムにしたいという目的もありました。MongoDBが目指す軽く速いデータベースのため，トランザクション・リレーショナル（JOIN）というRDBの代表的な機能を排除する選択をしました。

※ ただし，1つのドキュメントに対するAtomicな操作はサポートしています。

次にKVSと比較してMongoDBが備えている機能です。代表的なものに"RDBライクな検索クエリ"があります。memcachedなどに代表されるKVSは，基本的にkeyでの完全一致検索しかできません。MongoDBでは，RDBでいうwhere,likeを使った複雑な検索が可能です。またv2.2から集計処理に関する機能が追加され，SUM, AVGなどをgroup by, having, order byに相当するクエリと組み合わせて使用することが可能になりました。

上記の機能に加えて，インストールのしやすさ，主要なOS用バイナリの提供，多くのプログラミング言語用ドライバの充実から，他のKVSと比較して適用範囲が広く，導入しやすくなっています。つまり，あなたがMongoDBを使いたいと思ったら，すぐに使い始めることができます。

このように，RDBの一部機能を制限してKVSに近いパフォーマンス・スケーラビリティを実現していることを公式ドキュメントでは以下のような図で表しています