圧縮機能とレコードレベルロック機能に加え、MongoDBはWiredTigerによって、多重バージョン並行処理制御（MVCC）、マルチドキュメントトランザクション、そして挿入の頻度が高いワークロードに対応したログ構造化マージツリー（LSMツリー）のサポートが実現される。
「WiredTigerがデフォルトのエンジンではないのは、それが全く新しいものなので、人々をあまり驚かせたくないというだけのことだ。しかし、WiredTigerは完全にサポートされるし、ほとんど全てと言わないまでも、多くのユースケースで推奨されるようになるだろう」（Horowitz氏）
「MongoDBを起動すると、どのストレージエンジンを使いたいか聞かれる。Ops Manager経由の場合、希望のストレージエンジンを選ぶためのドロップダウンメニューが表示される。コマンドラインの場合、設定ファイルが使えるので、そこで選ぶことができる」（Horowitz氏）
「どちらのストレージエンジンも、同じバイナリで、同じビルドである。1つのビルドをダウンロードすると、両方を入手することになる。組み合わせて使うこともできるし、移行の最中は、実際に試してみるために、ノードによってエンジンを使い分けるようなデプロイメントも可能だ」（Horowitz氏）
Horowitz氏は、一方のエンジンからもう一方のエンジンへのローリング形式の移行は、レプリカセットを使えば比較的容易だとしている。
「ノードが3つのレプリカセットがあるとしよう。可能なのは、4つ目のノードを追加することだ。その4つ目のノードは、WiredTigerノードとする。そのノードの準備ができたら、他のノードの1つを取り除く。一時的にノードの数は3つになるので、そこで別のWiredTigerノードを追加し、最終的にWiredTigerノードが3つになったら完了だ」（Horowitz氏）
「しばらく両エンジンを組み合わせた状態にしておくことが可能だ。WiredTigerノードを1つ追加して、そのままの状態で1カ月間テストして、うまく機能するか確認したり、WiredTigerノードを1つ追加して、他のノードは従来のストレージエンジンに無期限に残しておき、いろいろと試したりすることもできる。納得したら、従来のエンジンは取り除くことができる」（Horowitz氏）
従来のストレージエンジンで満足だというユーザーも多いが、その従来のエンジンバージョンも3.0では改善されたと、Horowitz氏は述べている。
今回の新規リリースでは、レプリカセットのノード数が増え、レプリカセット自体のサイズも大きくなっている。これは、高可用性のためのレプリカセットの選択を高速化することを目的とするものだ。
「非常に多くのレプリカセットを持つことは以前から可能だったが、データのコピーを数多く必要とする人々や、配布用のレプリケーションファクタが非常に高い人々のために、1つのレプリカセットのノード数を12から50に増やしている」（Horowitz氏）
MongoDB 3.0はさらにセキュリティも向上しており、パスワード暗号化の強化や、すべてのcronオペレーションを監査する機能も備え、システムのあらゆるものを監査できる。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
