データベースの更新には、パフォーマンス、セキュリティの改善された機能、および新しい統合機能が付属しています。新しいバージョンを本番環境にデプロイする前にテストして、ニーズに適合し、クラッシュの可能性がないことを確認することを常にお勧めします。
多くの製品を考慮すると、新しいメジャーバージョンの最初のマイナーバージョンより前の製品には、最も重要な修正があります。たとえば、バージョン4.2.0の場合よりも、リリースの数日後にMongoDBバージョン4.2.1を本番環境で使用したいと思います。
このブログでは、MongoDBバージョン4.2に含まれているものと、どのような改善が行われたかについて説明します。
MongoDB4.2の新機能
トランザクションは、データの一貫性と整合性を保証する重要なデータベース機能であり、特にACID手順を保証する機能です。 MongoDBバージョン4.2は、分散トランザクションアプローチを通じて、レプリカセットとシャードクラスターでのマルチドキュメントトランザクションをサポートするようになりました。トランザクションを使用するための同じ構文が、以前の4.0バージョンと同じように維持されています。
ただし、クライアントドライバーの仕様が少し変更されたため、MongoDB 4.2でトランザクションを使用する場合は、ドライバーを4.2サーバーと互換性のあるバージョンにアップグレードする必要があります。
このバージョンは、メモリ使用量に関してトランザクションのサイズを制限しませんが、ハードウェアのサイズとハードウェア処理機能にのみ依存します。
バージョン4.2で、グローバルクラスターロケールの再割り当てが可能になりました。つまり、ジオゾーンシャーディングの実装では、リージョンAに住むユーザーがリージョンBに移動した場合、ロケーションフィールドの値を変更することで、トランザクションを通じてデータをリージョンAからBに自動的に移動できます。
シャーディングシステムでは、以前のバージョンとは逆にシャードキーを変更できるようになりました。文字通り、シャードキーが変更された場合、それはドキュメントを別のシャードに移動することと同じです。このバージョンでは、MongoDBがこの更新をラップし、ドキュメントをあるシャードから別のシャードに移動する必要がある場合、更新はトランザクション内でバックグラウンドで実行されます。
トランザクションを使用することは、特に複数回発生する場合にデータベースのパフォーマンスを低下させるため、お勧めできません。トランザクション期間中、影響を受けるドキュメントに書き込みを行うときに競合を引き起こす可能性のある操作のウィンドウが拡張されます。トランザクションを再試行できる限り、この再試行の前にドキュメントが更新される可能性があり、再試行が発生するたびに、最新のドキュメントバージョンではなく古いバージョンが処理される可能性があります。再試行は、待ち時間の増加によってアプリケーションのダウンタイムを増加させるだけでなく、明らかに処理コストを増加させます。
- Opが遅くならないようにする方法として、トランザクション内でインデックス付けされていないクエリを使用することは避けてください。
MongoDB動的スキーマ形式と埋め込み機能を使用すると、最初の手段としてトランザクションを使用する必要がないように、すべてのフィールドを同じコレクションに配置することを選択できます。
ワイルドカードインデックスは、MongoDBバージョン4.2で導入され、ドキュメント全体またはサブドキュメントにインデックスを付けることで、任意のフィールドまたは名前が事前にわからないフィールドに対するクエリを強化します。これらは、ワークロードベースのインデックスを置き換えることを目的としたものではありません。しかし、多形パターンを含むデータでの作業に適しています。多形パターンとは、コレクション内のすべてのドキュメントが類似しているが、同じ構造を持っていない場合です。多形データパターンは、製品カタログまたはソーシャルデータを含むアプリケーションから生成できます。以下は、ポリモーフィックコレクションデータの例です
{
Sport: ‘Chess’,
playerName: ‘John Mah’,
Career_earning: {amount: NumberDecimal(“3000”), currency: “EUR”},
gamesPlayed:25,
career_titles:10
},
{
Sport: Tennis,
playerName: ‘Semenya Jones,
Career_earning: {amount: NumberDecimal(“34545”), currency: “USD”},
Event: {
name:”Olympics”,
career_titles:10,
career_tournaments:14
}ワイルドカードインデックスを使用してドキュメント全体にインデックスを付けることにより、任意のフィールドをインデックスとして使用してクエリを実行できます。
$db.collection.createIndex({“fieldA.$**”: 1})選択したフィールドがネストされたドキュメントまたは配列の場合、ワイルドカードインデックスはドキュメントに再帰し、ドキュメントまたは配列のすべてのフィールドの値を格納します。
通常、データベースでネットワークの一時的な停止が頻繁に発生し、クエリが部分的または完全に実行されなくなる可能性があります。これらのネットワークエラーはそれほど深刻ではない可能性があるため、再接続するとこれらのクエリを再試行する機会があります。 MongoDB 4.2以降、再試行構成はデフォルトで有効になっています。 MongoDBドライバーは、マイナーなネットワークエラーが発生した場合、またはシャーディングされたクラスター/レプリカセットで正常なプライマリを見つけることができない場合に、特定のトランザクションの失敗した読み取りと書き込みを再試行できます。ただし、再試行可能な書き込みが必要ない場合は、構成で明示的に無効にすることができますが、無効にする必要がある理由はわかりません。
この機能は、MongoDBインフラストラクチャが変更された場合でも、アプリケーションコードが影響を受けないようにするためのものです。 MongoDBの共同創設者であるEliotHorowitzが、20の異なるデータベース操作を行うWebページについて、全体をリロードしたり、Webページ全体を何らかのループでラップしたりする代わりに、ドライバーが隠蔽していると説明した例について説明します。操作を再試行することを決定できます。書き込みが失敗すると、自動的に再試行され、サーバーと契約を結び、すべての書き込みが1回だけ行われることを保証します。
再試行可能な書き込みは、レプリカセットの選択と一時的なネットワークエラーに対処するのに役立つ1回の再試行のみを行いますが、永続的なネットワークエラーには対処しません。
再試行可能な書き込みは、フェイルオーバー期間がパラメーター構成のserverSelectionTimoutMs値を超えるインスタンスには対応しません。
このMongoDBバージョンでは、トランザクション内または再試行可能な書き込みとして単一ドキュメントのfindAndModify / update操作を発行することで、ドキュメントのシャードキー値を更新できます（シャードキーが不変の_idフィールドである場合を除く）。 。
MongoDBバージョン4.2は、単一ドキュメントのアップサート操作（つまり、アップサート：trueおよびマルチ：false）を再試行できるようになりました。これは、操作が次のキー条件を満たしている場合、重複キーエラーが原因で失敗した可能性があります。
>- ターゲットコレクションに、重複キーエラーを引き起こした一意のインデックスが含まれています。
- 更新操作は、クエリ述語のどのフィールドも変更しません。
- 更新一致条件は、単一の等式述語{field：“ value”}または等式述語の論理積{filed：“ value”、field0：“ value0”}
- 一意のインデックスキーパターンのフィールドのセットは、更新クエリ述語のフィールドのセットと一致します。
MongoDBバージョン4.2には、自動クライアント側フィールドレベル暗号化（CSFLE）が付属しています。これは、開発者がサーバーに送信する前に、クライアント側でドキュメントの個々のフィールドを選択的に暗号化できる機能です。したがって、暗号化されたデータは、データベースをホストしているプロバイダーや、データベースに直接アクセスできる可能性のあるすべてのユーザーからプライベートに保たれます。
正しい暗号化キーにアクセスできるアプリケーションのみが、保護されたデータを復号化して読み取ることができます。暗号化キーが削除されると、暗号化されたすべてのデータが読み取り不能になります。
注：この機能は、MongoDBエンタープライズでのみ使用できます。
MongoDBバージョン4.2は、以前のバージョンよりも豊富なクエリ言語を提供します。地理ベースの検索、グラフ検索、テキスト検索に沿った集計と最新のユースケース操作をサポートするようになりました。サードパーティの検索エンジンが統合されているため、検索エンジンが別のプロセス/サーバーで実行されていることを考慮して、検索を高速化できます。これは一般に、検索エンジンがインデックスを再作成するたびにデータベース操作のレイテンシーを不安定にするmongodプロセスに対してすべての検索が行われた場合とは対照的に、データベースのパフォーマンスを向上させます。
このバージョンでは、配列を処理したり、合計やその他の数学演算を更新ステートメントから直接実行したりできるようになりました。
MongoDBのデータ集約パイプラインフレームワークは、ドキュメントを目的の状態に変換するさまざまな段階を備えた優れた機能です。 MongoDBバージョン4.2では、新しいステージ$ mergeが導入されています。これにより、コレクションに格納する必要のある最終出力での作業にかかる時間を節約できたと言えます。最初に、$ outステージでは、集計に基づいて新しいコレクションを作成し、取得した結果をコレクションに入力できます。コレクションがすでに存在する場合、コレクションを完全に置き換えるのではなく、パイプラインの結果を既存の出力に組み込むだけの$ mergeステージとは異なり、コレクションを新しい結果で上書きします。 $ outステージで毎回コレクション全体を再生成すると、多くのCPUとIOが消費され、データベースのパフォーマンスが低下する可能性があります。したがって、出力コンテンツはタイムリーに更新され、ユーザーはオンデマンドのマテリアライズドビューを作成できます
開発者は、高可用性、クラウド管理のバックアップ戦略を強化し、監視能力とアラートシステムを改善する統合機能を備えた、MongoDBバージョン4.2で優れた運用体験を得ることができます。 MongoDBAtlasとMongoDBOpsManagerは、これらの機能を提供するプラットフォームです。後者は、企業でMongoDBを実行するのに最適であるとラベル付けされています。また、プライベートクラウドに移行するオンプレミスユーザー向けにKubernetesオペレーターと統合されています。このインターフェースにより、OpsManagerを直接制御できます。
MongoDBバージョン4.2には、次のような内部変更が加えられています。
- MMAPv1ストレージエンジンの削除。
- WiredTigerデータファイルの修復の改善。
- mongosノードの自動分割スレッドが削除されました。
MongoDBバージョン4.2には、セキュリティとデータベースのパフォーマンスに沿っていくつかの改善が加えられています。これには、データがクライアントの角度から保護されることを保証する自動クライアント側フィールドレベル暗号化が含まれています。サードパーティの検索エンジンや集約フレームワークに$mergeステージを含めるなどの機能により、データベースのパフォーマンスがいくらか向上します。このバージョンを本番環境に移行する前に、すべてのニーズが完全に満たされていることを確認してください。