MongoDBを始める前に知っておきたい14のこと

記事の翻訳は、コース「非リレーショナルデータベース」の開始前夜に作成されました。

---

ハイライト：

• MongoDBではオプションですが、スキーマを設計することは非常に重要です。
• 同様に、インデックスはスキーマとアクセスパターンに一致する必要があります。
• 大きなオブジェクトや大きな配列の使用は避けてください。
• 特にセキュリティと信頼性に関しては、MongoDBの設定に注意してください。
• MongoDBにはクエリオプティマイザがないため、クエリ操作を実行するときは注意が必要です。

私は非常に長い間データベースを扱ってきましたが、MongoDBを発見したのはつい最近のことです。始める前に知りたいことがいくつかあります。人がすでに特定の分野での経験を持っているとき、彼らはデータベースとは何か、そして彼らが何をしているのかについて先入観を持っています。他の人が理解しやすいように、よくある間違いのリストを以下に示します。

認証なしでMongoDBサーバーを作成する

残念ながら、MongoDBはデフォルトで認証なしでインストールされます。ワークステーションがローカルでアクセスされるのは正常です。ただし、MongoDBは大量のメモリを使用するのが大好きなマルチユーザーシステムであるため、開発にのみ使用する場合でも、できるだけ多くのRAMを備えたサーバーに配置することをお勧めします。デフォルトのポートを介してサーバーにインストールすると、特にリクエストでjavascriptコードを実行できる場合（たとえば、インジェクションの$whereアイデアとして）、問題が発生する可能性があります。



認証方法はいくつかありますが、最も簡単なのはユーザーID /パスワードを設定することです。派手なLDAPベースの認証について考えるときは、この考えを取り入れてください。セキュリティの観点から、MongoDBを最新の状態に保ち、不正アクセスがないかログを常にチェックする必要があります。たとえば、デフォルトのポートとして別のポートを選択したいと思います。

攻撃面をMongoDBにバインドすることを忘れないでください

MongoDBセキュリティチェックリストには、ネットワークへの侵入やデータ漏洩のリスクを軽減するための優れたヒントが含まれています。それを却下して、開発サーバーは高レベルのセキュリティを必要としないと言うのは簡単です。ただし、状況はそれほど単純ではなく、これはすべてのMongoDBサーバーに当てはまります。具体的には、説得力のない限り、使用することに理由があるmapReduce、groupまたは$あなたが設定ファイルに書き込むことにより、任意のJavaScriptコードの使用を無効にする必要がありますが、javascriptEnabled:false。データファイルは標準のMongoDBで暗号化されていないため、完全なファイルアクセス権を持ち、アクセスが制限され、オペレーティングシステム独自のファイルアクセスコントロールを使用できる専用ユーザーでMongoDBを実行することは理にかなっています。

回路設計エラー

MongoDBはスキーマを使用しません。しかし、これは回路が必要ないという意味ではありません。一貫性のあるレイアウトなしでドキュメントを保存したいだけの場合、保存はすばやく簡単にできますが、後で取得するのは非常に困難です。



古典的な記事「MongoDBのスキーマ設計のための親指の6つのルールは」のような機能ながら、読む価値スキーマエクスプローラメーカー3Tのサードパーティ製のツールでは、通常のスキーマ検証のために使用して価値があります。

並べ替え順序を忘れないでください

並べ替え順序を忘れると、他の設定ミスの中で最もイライラし、無駄になる可能性があります。 MongoBDは、デフォルトでバイナリソートを使用します。しかし、それが誰にとっても役立つとは思えません。 1980年代には、ケースセンシティブ、ストレスセンシティブ、バイナリソートは、ビーズ、カフタン、巻き毛の口ひげとともに、奇妙な異時性と見なされていました。今ではそれらの使用は許されません。実生活では「モーターサイクル」は「モーターサイクル」と同じです。そして、「ブリテン」と「ブリテン」は同じ場所です。小文字は単に大文字に相当する大文字です。そして、私にdiacriticalsortingについて話させないでください。 MongoDBでデータベースを作成するときは、大文字と小文字を区別しない照合を使用してくださいシステムのユーザーの言語と文化に対応するもの。これにより、文字列データの検索が大幅に簡素化されます。

大きなドキュメントでコレクションを作成する

MongoDBは、最大16MBのサイズの大きなドキュメントをコレクションでホストできます。GridFSは、16MBを超える大きなドキュメント用に設計されています。しかし、大きなドキュメントをそこに配置できるという理由だけで、それらをそこに保持することはお勧めできません。MongoDBは、個々のドキュメントを数キロバイトのサイズで保存し、幅の広いSQLテーブルの行のように扱う場合に最適に機能します。大きなドキュメントはパフォーマンスの問題の原因になります。

大きな配列でドキュメントを作成する

ドキュメントには配列を含めることができます。配列内の要素の数が4桁の数から離れている場合に最適です。要素が配列に頻繁に追加されると、それを含むドキュメントよりも大きくなり、移動する必要があります。つまり、インデックスを更新する必要があります。大きな配列を使用してドキュメントのインデックスを再作成すると、要素ごとにインデックスを格納するエントリがあるため、インデックスが上書きされることがよくあります。このインデックスの再作成は、ドキュメントが挿入または削除されたときにも発生します。



MongoDBには、この問題を最小限に抑えるためにドキュメントを拡張するためのスペースを提供する、いわゆる「フィルファクター」があります。

配列にインデックスを付けなくてもできると思うかもしれません。残念ながら、インデックスがないため、他の問題が発生する可能性があります。ドキュメントは最初から最後までスキャンされるため、配列の最後にある要素を見つけるのに時間がかかり、そのようなドキュメントに関連するほとんどの操作は遅くなります。

集計事項の段階の順序を忘れないでください

クエリオプティマイザデータベースシステムでは、作成するクエリは取得したいものの説明であり、取得方法ではありません。このメカニズムは、レストランでの注文と同様に機能します。通常、料理を注文するだけで、シェフに詳細な指示を与えることはありません。



MongoDBでは、料理人に指示します。たとえば、データが通過することを確認する必要がありますreduce使用してパイプラインで可能な限り早期に$matchと$project、ソート後にのみ発生しreduce、そしてそれは、検索は、あなたがそれを必要とする正確に順番に起こります。不要な作業を排除し、ステージを最適に編成し、接続のタイプを選択するクエリオプティマイザがあると、台無しになる可能性があります。 MongoDBでは、利便性を犠牲にしてより詳細に制御できます。



のようなツールStudio 3Tを使用すると、MongoDBで集計クエリを簡単に作成できます。Aggregation Editorを使用すると、パイプラインステートメントを一度に1ステップずつ適用できるだけでなく、各ステップで入力データと出力データを検証して、デバッグを簡素化できます。

クイックレコーディングの使用

MongoDB書き込みパラメータを高速で信頼性の低いものに設定しないでください。この「ファイルアンドフォーゲット」モードは、書き込みが行われる前にコマンドが戻るため、高速に見えます。データがディスクに書き込まれる前にシステムがクラッシュすると、データは失われ、一貫性のない状態になります。幸い、64ビットのMongoDBではロギングが有効になっています。



ストレージエンジンMMAPv1とWiredTigerはこれを防ぐためにロギングを使用しますが、ロギングが無効になっている場合、WiredTigerは最後に一致したチェックポイントに回復できます。



ジャーナル処理により、データベースはリカバリ後に一貫した状態になり、ジャーナルに書き込まれるまですべてのデータが保持されます。エントリの頻度は、パラメータを使用して設定されますcommitIntervalMs。



レコードを確認するには、構成ファイルでロギングが有効になっている(storage.journal.enabled)こと、およびレコードの頻度が、失う可能性のある情報の量に対して適切であることを確認してください。

インデックスなしの並べ替え

検索および集計する場合、多くの場合、データを並べ替える必要があります。うまくいけば、これは、ソートされるデータの量を減らすために結果をフィルタリングした後、最終段階の1つで行われます。それでも、並べ替えるにはインデックスが必要です。単一または複数のインデックスを使用できます。



適切なインデックスがない場合、MongoDBはそれなしで実行します。並べ替え操作のすべてのドキュメントの合計サイズには32MBのメモリ制限があり、MongoDBがこの制限に達すると、エラーがスローされるか、空のレコードセットが返されます。

インデックスをサポートせずに検索

検索クエリは、SQLのJOIN操作と同様の機能を実行します。最高のパフォーマンスを得るには、外部キーとして使用されるキー値のインデックスが必要です。使用法はに反映されていないため、これは明らかではありませんexplain()。このようなインデックスは、インデックスに書かれたことに加えているexplain()順番にパイプライン演算子によって使用され、$matchそして$sort、彼らは、パイプラインの先頭で発生した場合、。インデックスは、集約パイプラインの任意の段階をカバーできるようになりました。

マルチアップデートの使用をオプトアウトする

このメソッドはdb.collection.update()、指定したパラメーターに応じて、既存のドキュメントの一部またはドキュメント全体を完全に置き換えるまで変更するために使用されますupdate。multiクエリ条件を満たすすべてのドキュメントを更新するオプションを設定するまで、コレクション内のすべてのドキュメントが処理されないことはそれほど明白ではありません。

ハッシュテーブル内のキーの順序の重要性を忘れないでください

JSONでは、オブジェクトは0個以上の名前と値のペアの順序付けられていないコレクションで構成されます。ここで、nameは文字列、valueは文字列、数値、ブール値、ゼロ、オブジェクト、または配列です。



残念ながら、BSONは検索時に順序を非常に重要視しています。MongoDBでは、インラインオブジェクト内のキーの順序が重要です。{ firstname: "Phil", surname: "factor" }と同じではありません{ { surname: "factor", firstname: "Phil" }。つまり、確実に見つけたい場合は、ドキュメント内の名前と値のペアの順序を維持する必要があります。

「null」と「undefined」を混同しないでください

値「undefined」は、JavaScriptで使用されている場合でも、公式のJSON標準（ECMA-404、セクション5）に従ってJSONで有効になることはありませんでした。さらに、BSONの場合、これは非推奨になり、に変換されます$null。これは必ずしも適切なソリューションではありません。MongoDBで「未定義」を使用することは避けてください。

$limit()なしで使用$sort()

多くの場合、MongoDBで開発しているときは、クエリまたは集計から返される結果のサンプルを確認すると便利です。これはこのタスク$limit()に役立ちますが、コードの前で使用しない限り、コードの最終バージョンに含めることはできません$sort。このメカニズムが必要なのは、そうしないと結果の順序を保証できず、データを確実に表示できないためです。結果の上部に、並べ替えに応じて異なるレコードが表示されます。確実に機能するには、クエリと集計が決定論的である必要があります。つまり、実行されるたびに同じ結果が生成されます。$limit()存在するが存在しないコードは$sort決定論的ではなく、その後、追跡が困難なエラーを引き起こす可能性があります。

結論

MongoDBに不満を感じる唯一の方法は、MongoDBをDBMSなどの別のタイプのデータベースと直接比較するか、MongoDBを使用するという特定の期待を抱くことです。オレンジとフォークを比較するようなものです。データベースシステムには特定の目標があります。これらの違いを自分で理解して理解するのが最善です。 MongoDB開発者にDBMSパスをたどらざるを得ないパスがあるため、圧力をかけるのは残念です。データの整合性を確保したり、悪意のあるユーザーによる障害や攻撃に強いデータシステムを構築したりするなど、古い問題を解決するための新しくてエキサイティングな方法を見たいと思っています。



MongoDBのACIDトランザクション性の4.0実装は、重要な改善がいかに革新されているかを示す良い例です。マルチドキュメントおよびマルチステートメントトランザクションはアトミックになりました。また、ロックの取得やハングしたトランザクションの完了にかかる時間を調整したり、分離レベルを変更したりすることも可能になりました。

続きを読む：

• GoogleBigQueryにデータをアップロードする方法