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 つの経験則」 一読の価値があり、次のような機能があります スキーマエクスプローラー サードパーティ ツール Studio 3T では、回路の定期的なチェックに使用する価値があります。

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

並べ替え順序を忘れると、他の間違った構成よりもイライラが増し、より多くの時間を無駄にする可能性があります。 デフォルトでは、MongoBD は バイナリソート。 しかし、それが誰かの役に立つ可能性は低いです。 前世紀の 80 年代には、大文字と小文字、アクセントを区別するバイナリ ソートは、ビーズ、カフタン、巻き毛と同様に奇妙な時代錯誤と考えられていました。 今ではそれらの使用は許されません。 現実世界では、「オートバイ」は「オートバイ」と同じです。 そして「イギリス」と「イギリス」は同じ場所です。 小文字は単に大文字に相当するものです。 発音記号の並べ替えを始めさせないでください。 MongoDB でデータベースを作成する場合は、アクセントを区別しない照合順序を使用し、 登録、言語に対応し、 システムのユーザー文化。 これにより、文字列データの検索がはるかに簡単になります。

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

MongoDB は、コレクション内で最大 16 MB の大きなドキュメントを喜んでホストします。 グリッドFS 16 MB を超える大きなドキュメント用に設計されています。 しかし、大きな書類を置けるからといって、そこに保管するのは得策ではありません。 MongoDB は、サイズが数キロバイトの個々のドキュメントを保存し、それらを幅の広い SQL テーブル内の行のように扱う場合に最適に機能します。 大きなドキュメントは問題の原因になります。 生産性.

大規模な配列を含むドキュメントの作成

ドキュメントには配列を含めることができます。 配列内の要素の数が XNUMX 桁の数値から遠く離れている場合が最適です。 要素が頻繁に配列に追加されると、それを含むドキュメントのサイズを超えてしまうため、要素を配列に追加する必要があります。 動く、つまり必要になります。 インデックスも更新する。 大きな配列を含むドキュメントのインデックスを再作成すると、インデックスが上書きされることがよくあります。 記録、そのインデックスを保存します。 このインデックスの再作成は、ドキュメントが挿入または削除されたときにも行われます。

MongoDB には以下のものがあります。 「フィルファクター」これにより、この問題を最小限に抑えるためにドキュメントが拡大する余地が生まれます。
配列のインデックス付けなしでもできると思うかもしれません。 残念ながら、インデックスがないと他の問題が発生する可能性があります。 ドキュメントは最初から最後までスキャンされるため、配列の末尾の要素の検索に時間がかかり、そのようなドキュメントに関連するほとんどの操作は 遅い.

集約内のステージの順序が重要であることを忘れないでください

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

MongoDB では、クックに指示します。 たとえば、データが確実に通過するようにする必要があります。 reduce パイプラインのできるだけ早い段階で使用して、 $match и $project、並べ替えはその後にのみ行われます。 reduce、検索が希望どおりの順序で行われることを確認します。 不必要な作業を排除し、ステップを最適に順序付けし、結合タイプを選択するクエリ オプティマイザーを使用すると、無駄になる可能性があります。 MongoDB を使用すると、利便性を犠牲にしてさらに制御できるようになります。

のようなツール スタジオ3T での集計クエリの構築が簡素化されます。 MongoDBの。 集計エディター機能を使用すると、パイプライン ステートメントを一度に XNUMX ステージずつ適用し、各ステージで入力データと出力データを検査してデバッグを簡素化できます。

クイック録音を使用する

MongoDB の書き込みオプションを高速ではあるが信頼性が低いように設定しないでください。 このモード 「ファイルして忘れる」 書き込みが行われる前にコマンドが返されるため、高速に見えます。 データがディスクに書き込まれる前にシステムがクラッシュすると、データは失われ、不整合な状態になります。 幸いなことに、64 ビット MongoDB ではログ記録が有効になっています。

MMAPv1 および WiredTiger ストレージ エンジンはこれを防ぐためにログを使用しますが、WiredTiger は最後に一貫した状態に復元できます。 コントロールポイント、ロギングが無効になっている場合。

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

エントリを確認するには、構成ファイルでログが有効になっていることを確認してください。 (storage.journal.enabled)、記録の頻度は、損失しても許容できる情報量に対応します。

インデックスを使用しない並べ替え

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

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

インデックスをサポートしない検索

検索クエリは、SQL の JOIN 操作と同様の機能を実行します。 最適に機能するには、外部キーとして使用されるキーの値のインデックスが必要です。 使用法が反映されていないため、これは明らかではありません。 explain()。 このようなインデックスは、に書かれたインデックスに追加されます。 explain()、パイプライン オペレーターによって使用されます。 $match и $sort、パイプラインの先頭で出会うとき。 インデックスであらゆる段階をカバーできるようになりました 集約パイプライン.

複数のアップデートの使用をオプトアウトする

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

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

JSON では、オブジェクトは、サイズが XNUMX 個以上の名前と値のペアの順序なしのコレクションで構成されます。名前は文字列、値は文字列、数値、ブール値、null、オブジェクト、または配列です。

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

混同しないでください "ヌル" и "未定義"

値 "未定義" によると、JSONでは決して有効ではありませんでした 公式規格 JSON (ECMA-404 セクション 5) (JavaScript で使用される場合でも)。 さらに、BSON の場合は廃止され、次のように変換されます。 $null、これは常に良い解決策であるとは限りません。 使用を避ける "未定義" MongoDB で.

使用 $limit() без $sort()

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

まとめ

MongoDB に失望する唯一の方法は、MongoDB を DBMS などの別の種類のデータベースと直接比較するか、特定の期待に基づいて使用するようになるかです。 オレンジとフォークを比較するようなものです。 データベース システムは特定の目的に役立ちます。 これらの違いを自分自身で理解し、評価することが最善です。 MongoDB 開発者に DBMS の道を強制するような圧力をかけるのは残念なことです。 データの整合性を確保し、障害や悪意のある攻撃に強いデータ システムを作成するなど、古い問題を解決する新しくて興味深い方法を知りたいと考えています。

MongoDB のバージョン 4.0 での ACID トランザクション性の導入は、革新的な方法で重要な改善を導入した良い例です。 複数のドキュメントと複数のステートメントのトランザクションがアトミックになりました。 ロックの取得やスタックしたトランザクションの終了に必要な時間を調整したり、分離レベルを変更したりすることもできます。

続きを読む：

• Google BigQueryにデータを読み込む方法

出所： habr.com