クラスター化されたデータベースのデプロイは1つのことですが、クラスター内でDBMを維持する方法は、アプリケーションを一貫して提供するための大きな作業になる可能性があります。発生する可能性のあるボトルネックを防ぐ方法として、何をアップグレードするか、またはむしろ変更するかについての手がかりを得るために、データベースのステータス、特に最も重要なメトリックを頻繁に更新する必要があります。
MongoDBに関しては、多くの考慮事項があります。特に、MongoDBのインストールと実行は、基本的なデータベース管理手法を無視する可能性が非常に高いという事実を考慮する必要があります。
多くの場合、開発者はデータベースの将来の成長と使用の増加を考慮に入れておらず、その結果、一貫性がないだけでなく、いくつかの整合性の問題を伴うアプリケーションまたはデータのクラッシュが発生します。
この記事では、アプリケーションの効率的なパフォーマンスのためにMongoDBクラスターに採用する必要のあるいくつかのベストプラクティスについて説明します。考慮すべき要素には次のものがあります...
- 最新バージョンへのアップグレード
- 適切なストレージエンジン
- ハードウェアリソースの割り当て
- レプリケーションとシャーディング
- サーバー構成ファイルは絶対に変更しないでください
- 優れたセキュリティ戦略
最新バージョンへのアップグレード
私は3.2より前のバージョンからMongoDBを使用してきましたが、正直なところ、当時は簡単ではありませんでした。すばらしい開発、修正されたバグ、新しく導入された機能を使用して、データベースを常に最新バージョンにアップグレードすることをお勧めします。たとえば、集約フレームワークの導入は、すでに存在していたMap-Reduceの概念に依存するよりも、パフォーマンスへの影響が大きくなりました。最新バージョン4.0では、マルチドキュメントトランザクション機能を利用できるようになりました。これにより、スループット操作が一般的に向上します。最新バージョンには、$ toInt、$ toString、$ trim、$toBoolなどの新しい型変換演算子もいくつか追加されています。この演算子は、データの検証に大いに役立つため、データの一貫性をある程度高めることができます。アップグレードするときは、ドキュメントを参照して、誤ってエスカレートする可能性のあるわずかなミスを回避できるようにしてください。
適切なストレージエンジンを選択する
MongoDBは、現在のところ、WiredTiger、In-Memory、およびMMAPv1ストレージエンジンの3つのストレージエンジンをサポートしています。これらのストレージエンジンにはそれぞれメリットと制限がありますが、どちらを選択するかは、アプリケーションの仕様とエンジンのコア機能によって異なります。ただし、私は個人的にWiredTigerストレージエンジンを好みます。どちらを使用するかわからない場合は、これをお勧めします。 WiredTigerストレージエンジンはほとんどのワークロードに最適であり、ドキュメントレベルの同時実行モデル、チェックポインティング、および圧縮を提供します。
ストレージエンジンの選択に関する考慮事項のいくつかは、この側面に依存しています。
- トランザクションとアトミック性： アプリケーションのすべての条件とステージが正常に実行された場合にのみコミットされる、挿入または更新中のデータの提供。したがって、操作は不変のユニットにまとめられます。これを使用すると、WiredTigerストレージエンジン用の最新バージョンのMongoDBに見られるように、マルチドキュメントトランザクションをサポートできます。
- ロックタイプ： これは、情報へのアクセスまたは更新に関する管理戦略です。ロック期間中、現在の操作が実行されるまで、他の操作は選択されたオブジェクトのデータを変更できません。その結果、この時点でクエリが影響を受けるため、クエリを監視し、データに最も適切なストレージエンジンを選択することで、ロックメカニズムの大部分を減らすことが重要です。
- インデックス作成： MongoDBのストレージエンジンは、保存しているデータ型に応じて異なるインデックス戦略を提供します。そのデータ構造の効率はワークロードに非常に適している必要があり、すべての追加のインデックスにパフォーマンスのオーバーヘッドがあると見なすことでこれを判断できます。書き込み最適化データ構造は、非書き込み最適化データ構造よりも、高挿入アプリケーション環境のすべてのインデックスのオーバーヘッドが低くなります。これは、特に多数のインデックスが関係し、不適切なストレージエンジンを選択した場合に、大きな後退になります。したがって、適切なストレージエンジンを選択すると、劇的な影響を与える可能性があります。
ハードウェアリソースの割り当て
新しいユーザーがアプリケーションにサインインすると、データベースは時間とともに増大し、新しいシャードが導入されます。ただし、展開段階で確立したハードウェアリソースに依存することはできません。これに対応してワークロードが増加するため、大規模なデータクラスターをサポートするには、CPUやRAMなどのより多くの処理リソースのプロビジョニングが必要になります。これは、MongoDBのキャパシティプランニングと呼ばれることがよくあります。キャパシティプランニングに関するベストプラクティスは次のとおりです。
- データベースを常に監視し、期待に応じて調整します。 前述のように、ユーザー数が増えると、特にインデックスを使用する場合に設定されるワークロードが増えて、今後さらにクエリがトリガーされます。時間の経過に伴う書き込みと読み取りの割合の変化の記録を開始すると、アプリケーション側でこの影響が発生し始める可能性があります。したがって、この問題に対処するには、ハードウェア構成を再構成する必要があります。 mongoperfとMMSツールを使用して、システムパフォーマンスパラメータの変更を検出します。
- パフォーマンス要件をすべて事前に文書化します。 同じ問題が発生した場合、少なくとも時間を節約できる参照ポイントがあります。記録には、保存するデータのサイズ、待機時間に関するクエリの分析、および特定の時間にアクセスするデータの量を含める必要があります。本番環境では、1秒あたりに処理するリクエストの数と、最後に許容するレイテンシを決定する必要があります。
- 概念実証をステージングします。 スキーマ/インデックスの設計を実行し、クエリパターンを理解してから、ワーキングセットサイズの見積もりを調整します。この構成を、アプリケーションの継続的なリビジョンでテストするための参照ポイントとして記録します。
- 実際のワークロードでテストを実行します。 概念実証の段階を実行した後、実際のデータとパフォーマンス要件を使用して実質的なテストを実行した後にのみ展開します。
レプリケーションとシャーディング
これらは、MongoDBクラスターでデータの高可用性と水平方向のスケーラビリティを向上させるための2つの主要な概念です。
シャーディングは基本的に、サーバー間でデータをシャードと呼ばれる小さな部分に分割します。シャード間でのデータのバランシングは自動的に行われ、データベースをオフラインにする必要なしにシャードを追加または削除できます。
もう一方の端のレプリケーションは、高可用性のためにデータの複数の冗長コピーを維持します。これはMongoDBに組み込まれている機能であり、特殊なネットワークを必要とせずに広域ネットワーク全体で機能します。クラスターのセットアップでは、少なくとも2つ以上のモンゴ、3つの構成サーバー、1つのシャードを用意し、シャードクラスターに関与するマシン間の接続を確保することをお勧めします。構成ではIPではなくDNS名を使用してください。
実稼働環境では、少なくとも3つのメンバーを含むレプリカセットを使用し、oplogサイズなどの構成変数を追加することを忘れないでください。
メンバーのmongodインスタンスを開始するときは、同じキーファイルを使用します。
シャードキーに関する考慮事項には、次のものが含まれます。
- キーと値は不変です
- シャードコレクションでインデックスを使用することを常に検討してください
- ドライバの更新コマンドにはシャードキーが含まれている必要があります
- シャードキーによって維持される一意の制約。
- シャードキーには特別なインデックスタイプを含めることはできず、512バイトを超えてはなりません。
サーバー構成ファイルを変更しない
最初の展開を行った後は、構成ファイル内の多くのパラメーターを変更しないことをお勧めします。変更しないと、特にシャードで問題が発生する可能性があります。シャーディングとの最も弱いリンクは構成サーバーです。これは、シャーディングが機能するためには、すべてのmongodインスタンスが実行されている必要があるということです。
優れたセキュリティ戦略
MongoDBは過去数年間、外部からの攻撃に対して脆弱でした。したがって、データベースがいくつかのセキュリティプロトコルを持つことは重要な取り組みです。異なるポートでプロセスを実行することに加えて、MongoDBデータベースを保護する5つの異なる方法の1つを少なくとも採用する必要があります。転送中と保存中の両方のデータを暗号化することでデフォルトでデータベースを保護するMongoDBAtlasなどのプラットフォームを検討できます。すべての着信接続と発信接続にTLS/SSLなどの戦略を使用できます。
結論
MongoDBクラスター制御は簡単な作業ではなく、多くの回避策が必要です。より多くのユーザーの結果としてデータベースが増大し、したがってワークロードセットが増加します。したがって、Onには、DBMのパフォーマンスがこの増加したユーザー数と一致していることを確認する義務があります。ベストプラクティスは、ハードウェアリソースを増やし、シャーディング、レプリケーション、インデックス作成などのMongoDBの概念を適用するだけではありません。ただし、発生する可能性のある不便の多くは、MongoDBバージョンをアップグレードすることで十分に対処できます。多くの場合、最新バージョンではバグが修正され、新機能のリクエストが統合されており、メジャーリビジョン番号があってもアップグレードへの悪影響はほとんどありません。