MongoDB開発者会議が先日、パリのシャンゼリゼの素敵な会場で開かれました。多くのMongoDBファンだけでなく、NoSQLとMongoDBの能力を発掘しようと関心を寄せる人が出会う絶好の機会となりました。9時間に及ぶ会議では、一日中熱心な参加者であふれかえる会場に、実り豊かなコンテンツが提供されました！
パリのMongoDBデーで得られた注目すべきアイデアがあります。
WiredTiger
話題のひとつとして、WiredTigerストレージエンジンに焦点が合わせられました。この機能は、MongoDB 3.0ではオプションですが、バージョン3.2では初期設定されることになっています。MMAPV1ストレージを超えるWiredTigerの主なメリットは、書き込み操作のパフォーマンス向上を可能にする優れた同時管理戦略（ドキュメントレベル）であるように思われます。
最近、Nuxeo PlatformとMongoDBを使用してベンチマークを設定しました。
このような最近設定したベンチマークでテストも実施して、2つのストレージエンジンMMAPv1とWiredTigerを比較しました。
テスト結果：
- 読み出し性能はほぼ同じ。
- 書き込み機能については、WiredTigerの方がMMAPV1の最大2.5倍の速さだった（SQLの5倍の速さ）。
Ops Manager
MongoDBの構成と管理のほとんどは、コマンドラインシェルを通過します。開発者としては、非常に使い勝手が良く、DevOpsも相性がいいと思います。ただし、大きなクラスタを管理する場合は、これが悩みの種となります。
Ops Managerは、Web管理UIを持ち、正しい順序で10の異なるシェルに対して数百のコマンドラインを実行することを回避するためには最適なソリューションであるように思われます。このプレゼンテーションでは、クラスタ内部のノードのローリングアップグレードを実行したいときに、どのようにOps Managerが役立つか的確に説明されています。
Nuxeoでは、同様の懸念があります。nuxeoctlとNuxeo Shellを使用して多くのことが可能ですが、クラスタを管理する場合は、異なるノードを調整するための中央管理ウェブUIがありません。
Ops Managerの設計原理 はシンプルですが素晴らしいので、Nuxeoクラスタマネージャを提供する同様のアーキテクチャの使用を検討していもよいでしょう。
MongoDB 3.2について
MongoDB 3.2のリリースでは、多くの新機能が導入される模様です。最も興味深い点についていくつか指摘しておきます。
ドキュメント検証
多くの人がMongoDBのスキーマのない特性を楽しみ、自由がある喜びを理解できるにしても、私の懸念は、オペレーション担当者がその特性にはそれほど満足していないという点にあります。
エンタープライズツールボックスが基本的にスキーマをリバースエンジニアリングするために、MongoDBのコンパスなどのツールを提供していることは、少なくとも運用の観点から、アプリケーションレベルで実際のスキーマ定義を持つことは意味があることを証明しています。「スキーマを考え出し」したら、ストレージレベルでいくつかの制約を定義できることは本当に意味があり、これが「ドキュメント検証」といえるものに思われます。
Nuxeo Platformを介してMongoDBを使用する人の場合、MongoDB上のリポジトリ層がすでに、UIまで適切に検証できるバリデーションロジックを処理しているため、あまり影響はないでしょう。 ただし、Nuxeo DBSの内部の観点は、スキーマレスデータベースにおけるスキーマ管理の向上に期待されるものです。
BIコネクタ&検索
開発ドキュメントですでに明らかなように、MongoDBは新しい$lookupを統合しました。これはコレクション間の一種の単純結合であり、MongoDBのクエリと集約フレームワーク内のSQLを変換すべきBIコネクタの基礎になるでしょう。
Nuxeoでは、1つのリポジトリのデータがすべて単一のコレクションにアクセスできるので、この結合は必ずしも必要ではありません。しかし：
- MongoDBに格納されているNuxeoデータにSQLアクセスができる場合には、意味があります。
- コレクション間の単純な結合によって、Nuxeo PlatformはMongoDBに監査データを格納することができますが、リポジトリと監査データに基づいて分析を実行することはできます。
したがって、Nuxeo PlatformでMongoDB3.2のテストを早急に開始する必要があります！