NuxeoとMongoDBMongoDB開発者会議が先日、パリのシャンゼリゼの素敵な会場で開かれました。多くのMongoDBファンだけでなく、NoSQLとMongoDBの能力を発掘しようと関心を寄せる人が出会う絶好の機会となりました。9時間に及ぶ会議では、一日中熱心な参加者であふれかえる会場に、実り豊かなコンテンツが提供されました!

パリのMongoDBデーで得られた注目すべきアイデアがあります。

WiredTiger


話題のひとつとして、WiredTigerストレージエンジンに焦点が合わせられました。この機能は、MongoDB 3.0ではオプションですが、バージョン3.2では初期設定されることになっています。MMAPV1ストレージを超えるWiredTigerの主なメリットは、書き込み操作のパフォーマンス向上を可能にする優れた同時管理戦略(ドキュメントレベル)であるように思われます。

最近、Nuxeo PlatformとMongoDBを使用してベンチマークを設定しました。

Nuxeo MongoDBベンチマーク

このような最近設定したベンチマークでテストも実施して、2つのストレージエンジンMMAPv1とWiredTigerを比較しました。

テスト結果:


マスインポートのベンチマーク

Ops Manager


MongoDBの構成と管理のほとんどは、コマンドラインシェルを通過します。開発者としては、非常に使い勝手が良く、DevOpsも相性がいいと思います。ただし、大きなクラスタを管理する場合は、これが悩みの種となります。

Ops Managerは、Web管理UIを持ち、正しい順序で10の異なるシェルに対して数百のコマンドラインを実行することを回避するためには最適なソリューションであるように思われます。このプレゼンテーションでは、クラスタ内部のノードのローリングアップグレードを実行したいときに、どのようにOps Managerが役立つか的確に説明されています。

Nuxeoでは、同様の懸念があります。nuxeoctlとNuxeo Shellを使用して多くのことが可能ですが、クラスタを管理する場合は、異なるノードを調整するための中央管理ウェブUIがありません。

Ops Managerの設計原理はシンプルですが素晴らしいので、Nuxeoクラスタマネージャを提供する同様のアーキテクチャの使用を検討していもよいでしょう。

NuxeoとMongoDB


なぜNuxeo Platform内部でMongoDBを統合することにしたのか、その統合をどのように達成したのか、またその統合からどのようなメリットが得られるのか、短いプレゼンテーションを行いました。スライドは、オンラインでご覧になれます。他のMongoDBデーでは、その簡略版のプレゼンテーションを行います。

MongoDB 3.2について


MongoDB 3.2のリリースでは、多くの新機能が導入される模様です。最も興味深い点についていくつか指摘しておきます。

ドキュメント検証


多くの人がMongoDBのスキーマのない特性を楽しみ、自由がある喜びを理解できるにしても、私の懸念は、オペレーション担当者がその特性にはそれほど満足していないという点にあります。

エンタープライズツールボックスが基本的にスキーマをリバースエンジニアリングするために、MongoDBのコンパスなどのツールを提供していることは、少なくとも運用の観点から、アプリケーションレベルで実際のスキーマ定義を持つことは意味があることを証明しています。「スキーマを考え出し」したら、ストレージレベルでいくつかの制約を定義できることは本当に意味があり、これが「ドキュメント検証」といえるものに思われます。

Nuxeo Platformを介してMongoDBを使用する人の場合、MongoDB上のリポジトリ層がすでに、UIまで適切に検証できるバリデーションロジックを処理しているため、あまり影響はないでしょう。 ただし、Nuxeo DBSの内部の観点は、スキーマレスデータベースにおけるスキーマ管理の向上に期待されるものです。
<!--

インメモリストレージエンジン


実際にインメモリストレージエンジンがあれば、ハイエンドのパフォーマンスを提供できる可能性が高くなります。ただし、データ永続性がない場合、使用事例には制限ができてきます。ストレージエンジンのプラグインの可能性の美点として、同じレプリカセット内部に別々のストレージエンジンを持つことが可能になります。つまり、マスターは「インメモリ」のストレージを使用して、驚くほど高速なパフォーマンスを提供するのに対して、レプリカセットの他のメンバーはWiredTigerを使用して、「結果整合性」を維持することができます。.

ある意味で、これはRedisで行うものに近いのです。インメモリRedisを使用して、キャッシュの格納とクエリの保存を行いますが、「メモリ内のデータをバックアップする」ためにRedisの整合性 を維持します。
-->

BIコネクタ&検索


開発ドキュメントですでに明らかなように、MongoDBは新しい$lookupを統合しました。これはコレクション間の一種の単純結合であり、MongoDBのクエリと集約フレームワーク内のSQLを変換すべきBIコネクタの基礎になるでしょう。

Nuxeoでは、1つのリポジトリのデータがすべて単一のコレクションにアクセスできるので、この結合は必ずしも必要ではありません。しかし:


  • MongoDBに格納されているNuxeoデータにSQLアクセスができる場合には、意味があります。

  • コレクション間の単純な結合によって、Nuxeo PlatformはMongoDBに監査データを格納することができますが、リポジトリと監査データに基づいて分析を実行することはできます。


したがって、Nuxeo PlatformでMongoDB3.2のテストを早急に開始する必要があります!