アプリケーションとデータベースモデルを開発した後（環境を本番環境に移行するとき）、最初に実行する必要のあることがいくつかあります。多くの場合、開発者は、データベースを本番環境にデプロイする前に、追加の重要なMongoDBステップを考慮に入れていません。その結果、本番モードでは、開発モードでは提示されない根本的な挫折に遭遇することになります。手遅れになることもあれば、災害が発生した場合に大量のデータが失われることもあります。さらに、ここで説明する手順のいくつかにより、データベースの状態を測定し、災害が発生する前に必要な対策を計画することができます。
一般的に、どのテクノロジーの最新バージョンでも、基盤となる機能に関して、以前のバージョンよりも機能が改善されています。 MongoDBの最新バージョンは、パフォーマンス、スケーラビリティ、メモリ容量の点で、以前のバージョンよりも堅牢で改善されています。関連するドライバについても同じことが当てはまります。これらのドライバはコアデータベースエンジニアによって開発されており、データベース自体よりも頻繁に更新されるためです。
ご使用の言語用にインストールされたネイティブ拡張機能は、新しいドライバーをテスト、承認、およびアップグレードするための迅速で標準的な手順のためのプラットフォームを簡単に構築できます。 Ansible、Puppet、SaltStack、Chefなどの自動車用ソフトウェアもあります。これらのソフトウェアを使用すると、専門的な費用や時間をかけずに、すべてのノードでMongoDBを簡単にアップグレードできます。
WiredTigerストレージエンジンの使用も検討してください。WiredTigerストレージエンジンは、最新のデータベースの期待に合った最新の機能を備えて開発されているためです。
MongoDBメーリングリストに登録して、新しいバージョンとドライバーの変更、およびバグ修正に関する最新情報を入手して、最新の状態に保ちます。
64ビットシステムを使用してMongoDBを実行する
32ビットシステムでは、データベースがパフォーマンスのためにメモリマップトファイルを使用するため、MongoDBプロセスは約2.5GBのデータに制限されます。これは、クラッシュにつながる境界を超える可能性のあるプロセスの制限になります。主な影響は次のとおりです。エラーが発生した場合、データを削除するか、データベースを64ビットなどの上位システムに移行するまでサーバーを再起動できないため、アプリケーションのダウンタイムが長くなります。
32ビットシステムを使い続ける必要がある場合は、スループット操作のバグ数とレイテンシを減らすために、コーディングを非常に簡単にする必要があります。
ただし、集計パイプラインやジオデータなどのコードが複雑な場合は、64ビットシステムを使用することをお勧めします。
ドキュメントが16MBのサイズに制限されていることを確認する
MongoDBドキュメントは16MBのサイズに制限されていますが、パフォーマンスの低下を招くため、この制限に近づく必要はありません。実際には、ドキュメントのサイズはほとんどKB以下です。ドキュメントのサイズは、埋め込みと参照の間のデータモデリング戦略に依存します。ドキュメントのサイズが大きくなることが予想されない場合は、埋め込みをお勧めします。たとえば、ユーザーが投稿するソーシャルメディアアプリケーションがあり、コメントが含まれている場合、ベストプラクティスは、投稿情報を保持するための2つのコレクションを用意することです。
{
_id:1,
post: 'What is in your mind?',
datePosted: '12-06-2019',
postedBy:'xyz',
likes: 10,
comments: 30
} {
_id: ObjectId('2434k23k4'),
postId: 1,
dateCommented: '12-06-2019',
commentedBy:'ABCD',
comment: 'When will we get better again',
}このようなデータモデルを使用することで、コメントは投稿とは異なるコレクションに保存されます。これにより、コメントが非常に多い場合に備えて、ポストコレクション内のドキュメントが範囲外に拡大するのを防ぎます。ドキュメントが無制限に成長する可能性のあるアプリケーションパターンを回避するようにしてください。
データベースが仮想メモリ（RAM）からのデータの読み取りに失敗し、ページフォールトが発生する場合があります。ページフォールトにより、データベースは物理ディスクからデータを読み取るように強制され、レイテンシが増加し、その結果、アプリケーション全体のパフォーマンスが低下します。ページフォールトは、メモリに収まらない大きなセットでの作業が原因で発生します。これは、一部のドキュメントのサイズに制限がないか、シャーディング戦略が不十分であることが原因である可能性があります。ページフォールトの解決策は次のとおりです。
- スループット操作の対象となるドキュメントの数を制限する最適なシャーディングキーを選択することにより、適切なシャーディング戦略を確保します。
- より多くの作業セットに対応するために、MongoDBインスタンスのサイズを増やします。
データベースの世界では、大惨事が発生する可能性があるため、単一のデータベースに依存することは理想的ではありません。さらに、データベースへのユーザー数の増加が予想されるため、データの高可用性を確保する必要があります。レプリケーションは、フェイルオーバーの場合に高可用性を確保するための重要なアプローチです。 MongoDBには、地理的にデータを提供する機能があります。つまり、リクエストのレイテンシーを削減する1つの方法として、さまざまな場所のユーザーが最も近いクラウドホストからサービスを受けます。
プライマリノードに障害が発生した場合、セカンダリノードは、フェイルオーバー中にアプリケーションがダウンタイムを起こすのではなく、書き込み操作に対応するために新しいノードを選択できます。実際、レプリケーションに非常に配慮している一部のクラウドホスティングプラットフォームは、本番環境でレプリケートされていないMongoDBをサポートしていません。
ジャーナリングはパフォーマンスの低下を意味しますが、それも重要です。ジャーナリングは、先行書き込み操作を強化します。つまり、データベースが更新の実行中に失敗した場合、更新はどこかに保存され、再び有効になったときにプロセスを完了することができます。ジャーナルはクラッシュリカバリを簡単に容易にすることができるため、デフォルトでオンにする必要があります。
多くの企業は、バックアップシステムがないか不十分なために、データが失われた後も継続できません。データベースを本番環境にデプロイする前に、次のいずれかのバックアップ戦略を使用していることを確認してください。
- モンゴダンプ ：小規模な展開や、特定のニーズに基づいてフィルタリングされたバックアップを作成する場合に最適です。
- 基になるコピー ：大規模な展開に最適であり、完全バックアップを作成して復元するための効率的なアプローチ。
- MongoDB管理サービス（MMS） ：フルマネージドサービスとしてMongoDBの継続的なオンラインバックアップを提供します。シャーディングされたクラスターとレプリカセットに最適です。
バックアップファイルも、データベースの同じホストプロバイダーに保存しないでください。 BackupNinjaはこれに使用できるサービスです。
データがほとんど含まれていないため、開発環境で遅いクエリを実現することはほとんどできません。ただし、多くのユーザーがいることや、多くのデータが関係することを考えると、これは本番環境には当てはまらない可能性があります。インデックスの使用に失敗した場合、または最適ではないインデックスキーを使用した場合は、クエリが遅くなる可能性があります。それでも、クエリが遅い理由を示す方法を見つける必要があります。
したがって、MongoDBクエリプロファイラーを有効にすることを決意します。これによりパフォーマンスが低下する可能性がある限り、プロファイラーはパフォーマンスの問題を明らかにするのに役立ちます。データベースをデプロイする前に、クエリが遅いと思われるコレクション、特に多くの埋め込みを含むドキュメントを含むコレクションに対してプロファイラーを有効にする必要があります。
容量計画は、MongoDBで非常に重要な作業です。また、いつでもデータベースの状態を知る必要があります。便宜上、データベースを監視ツールに接続すると、時間の経過とともにデータベースを改善するために必要なことを理解するための時間を節約できます。たとえば、クエリの増加の結果としてCPUのパフォーマンスが低下していることを示すグラフィック表現では、システムにハードウェアリソースを追加するように指示されます。
監視ツールには、メールや短いメッセージを介したアラートシステムもあり、問題が大惨事になる前に、いくつかの問題について簡単に更新できます。したがって、本番環境では、データベースが監視ツールに接続されていることを確認してください。
ClusterControlは、CommunityEditionで無料のMongoDBモニタリングを提供します。
データベースのセキュリティは、厳密に考慮する必要があるもう1つの重要な機能です。実稼働前のセキュリティチェックリストに準拠していることを確認して、実稼働中のMongoDBインストールを保護する必要があります。考慮事項のいくつかは次のとおりです。
- 着信および発信接続の暗号化（TLS / SSL）
安全な構成オプションを使用してMongoDBを実行することにより、外部からの注入を回避します。たとえば、mapReduceや$ whereなどのJavaScriptサーバー側の操作を使用していない場合は、サーバー側のスクリプトを無効にします。マングースなどのいくつかのモジュールを介してコレクションデータにJSONバリデーターを使用し、保存されているすべてのドキュメントが有効なBSON形式であることを確認します。
MongoDBは、必要なコモディティハードウェアを十分に考慮して明示的に設計されているため、ハードウェアの前提条件はほとんどありません。以下は、本番環境にデプロイする前に検討する必要があるMongoDBの主なハードウェアの検討事項です。
- WiredTigerストレージエンジンを使用します。ファイルシステムキャッシュとWiredTiger内部キャッシュを使用するように設計されているため、パフォーマンスが向上します。たとえば、4 GBのRAMのシステムで動作する場合、WiredTigerキャッシュは1.5 GBのRAM（0.5 *（4 GB -1 GB）=1.5 GB）を使用しますが、1.2GBのRAMを搭載したシステムは256MBしか使用しません。
- NUMAハードウェア。パフォーマンスの低下やシステムプロセスの使用率の高さなど、運用上の問題が多数あるため、メモリインターリーブポリシーの構成を検討する必要があります。
- ディスクとストレージシステム：ソリッドステートディスク（SSD）を使用：MongoDBは、SATASSDでより優れた価格性能比を示します
本番環境のデータベースは、ビジネスの円滑な運営を確保するために非常に重要であるため、多くの考慮事項を考慮して処理する必要があります。エラーを減らすのに役立つ、またはむしろこれらのエラーを見つける簡単な方法を提供することができるいくつかの手順を定める必要があります。さらに、大惨事を軽減する前に、容量の計画と問題の検出のために、データベースの状態を時間とともに示すアラートシステムを設定することをお勧めします。