最終試験は検証のために送信されました。MongoDBの長所と短所について話すために、コースの印象と受け取った情報を共有したいと思います。
コースの一般的な印象
DBAと開発者のために、一度に2つのコースにサインアップしました。 一般に、負荷はそれほど大きくありません。ビデオを見るのに週に3〜4時間かかり、宿題に非常にゆったりとしたペースで1〜2時間かかりました。 必要に応じて、時間コストを半分に削減できると思います。
一般的に、印象はポジティブです。 コースで提示される情報のほとんどは公式ドキュメントから収集できるという事実にもかかわらず、コースを通して資料をマスターすることは非常に興味深いです。 以前にMongoDBについて聞いたことがあり、それが何回か「感じ」ましたが、コースの後、このデータベースの機能と範囲についてのより深い理解が現れます。 最初はいくつかのオーバーレイがありました。 質問の文言にはいくつかの点が関連しており、曖昧な回答を暗示していましたが、おそらく英語の理解に問題がありました。 その後、結果のゼロ化にいくつかの問題があり、ハリケーンサンディによるオーバーレイがいくつかありました。 「Mission Impossible」と呼ばれる楽しい質問があり、3つの可能な答えの1つを選択する必要がありました。 この場合、通常、質問に答えるために3回試行されます。
強み
レプリケーション（ 手動 ）
レプリケーションの構成は簡単です。サーバーはレプリカの名前で起動され、構成が構成され、レプリカの参加者がPRIMARYサーバーを選択し、残りはSECONDARYサーバーになります。 この場合、各サーバーに優先順位を設定でき、一般的にサーバーがプライマリになるのを防ぐことができます。 PRIMARYサーバーでは、SECONDARYサーバーから読み取り/書き込み操作のみを行うことができます。
サーバーがクラッシュすると、SECONDARYサーバーまたはPRIMARYサーバーがクラッシュしたかどうか、PRIMARYサーバーが利用できなくなって新しいPRIMARYサーバーが選択された後にレコードがあったかどうかなど、多くの微妙な違いがあります。 ただし、一般に、ほとんどの場合、レプリカの復旧は自動化されており、サーバーの障害を起こさない限り、手動での介入は不要です。
シャーディング（ 手動 ）
コレクションに大量のデータがあり、1つのサーバーに収まらない場合-複数のサーバーに分散できますが、アプリケーションレベルでこのコレクションを操作する場合、変更は不要です。 シャーディングのキーが選択され、各シャードのこのシャードに範囲が作成されます。 さらに、正しく覚えていれば、範囲を変更する際のリシャーディングはホットモードで自動的に発生します。 同時に、ニュアンスがあります。コレクションがサーバーに分散された後、自動モードでシャーディングのキーを変更することはできません。
地理的指標（ マニュアル ）
現在、多くのスタートアップやソーシャルサービス。 ネットワークは次のような機能を使用します。ユーザーからX km以内の何かを見つけます。 ここで、MongoDBのこのような機能には、地理インデックスを使用できます。
スキーマレス
私の意見では、MongoDBにスキーマがないため、プロジェクトの開発をスピードアップできます。 初期段階でデータベース構造を詳細に作成し、関係の実装を処理し、プロジェクトが拡大し、より詳細になったら、データ移行計画などを作成する必要はありません。 逆に、MongoDBでは、「プロトタイプ」段階で、プロジェクトを迅速に起動し、データベースを混乱させて巻き込み、プロジェクトが成長し始めると、より具体的な形になり、データベースをより正規化した形にする必要が生じます。
上限付きコレクション（ マニュアル ）
そのようなコレクションを作成する場合、コレクションに保存できるレコードの数を指定する必要があります。 貼り付けるときに、コレクションが既にいっぱいになっている場合、最も古いレコードが書き換えられます。 特定の数のセグメントがある円を時計回りに記録することと比較できます。 最新の関連情報や古い情報を保存する必要がある場合、有用なコレクションは興味がありません。
集約フレームワーク（ マニュアル ）
このフレームワークを使用すると、ソースデータからサンプルを作成し、グループ化、集計、レコードのカウントなどを行うことができます。 本質的に、これはGROUP BY、COUNT、HAVINGなどの実装です。 SQLの構造。 ソースデータは、いわゆるパイプの配列を通過し、データを変換して次のパイプに転送します。 次のようなコンソールコマンドに非常に似ています： "cat file | grepおっぱい| grep -v small。」
Map-Reduce（ マニュアル ）
Aggregation Frameworkの機能が十分でない場合は、MapReduce機能を使用できます。 データは関数のマップ入力に提供され、関数は変換され、reduce関数の入力に送られます。
落とし穴
複合インデックスの制約
次のようなエントリがある場合：{a：[1、2]、b：[1、2]}-インデックスの作成{a：1、b：1}は失敗します。 実際には、インデックスが付けられたフィールドを持つ同様のレコードを挿入するようなものです。 詳細については、「複合マルチキーインデックスには1つの配列フィールドのみが含まれる」を参照してください。
スパースインデックスと一意性（ 手動 、スパースインデックス）
コレクションにエントリがあるとしましょう：
{「_id」：ObjectId（「50caeec479705c3852e9e61b」）、「a」：「1」}
{「_id」：ObjectId（「50caeeeb79705c3852e9e61d」）、「a」：「2」、「b」：1}
{「_id」：ObjectId（「50caefb179705c3852e9e621」）、「a」：「3」}
また、ドキュメントの「b」プロパティを一意にする必要があります。 通常の一意のインデックスを作成することはできません。1番目と3番目のレコードはb：nullと見なされ、一意性に違反します。
ただし、一意のスパースインデックスを作成することはできますが、「b」を持たないレコードはこのインデックスに含まれません。 すべてがうまくいき、インデックスが作成され、一意性があるように見えます。 しかし！ 許可する場合、コレクションからすべてのレコードを選択し、フィールドbでソートするように依頼します。MongoDBは、作成したスパースインデックスを使用します。このインデックスには「b」のないレコードはありません。 その結果、1つのエントリのみが取得されます。
アプリケーションインターフェイスの依存関係
このコースは、MongoDBでは出力に使用されるため、ドキュメントを保存するのが便利であることを繰り返し指摘しています。 ブログがあるとしましょう。コメントがあります。 作成者の名前とメールがコメントの横に表示されます。 便利なことに、コメントを保存するオブジェクトには、作成者に関する情報も保存されます。 したがって、計画で何かが変更された場合、データの保存場所を変更する必要が生じる可能性があります。 原則として、これは大きな落とし穴ではなく、そのような開発の可能性は小さいですが、私はこの声明で何かが特に好きではありませんでした。
シャードキーは変更できません
コレクションの投稿後、キーの変更は自動的に機能しません。 したがって、キーを選択することは非常に重要な操作です。 docs.mongodb.org/manual/faq/sharding/#faq-change-shard-keyをもっと読む
複数のドキュメント内にトランザクションはありません
1つのドキュメントに対する操作はアトミックですが、いくつかのドキュメントでは、アプリケーションレベルでトランザクションを使用することが提案されていますdocs.mongodb.org/manual/tutorial/perform-two-phase-commits
おわりに
素晴らしいコース。 MongoDBはその柔軟性とシンプルさに魅了されており、さまざまな状況での使用は非常に正当化されています。
誰かがコースを受講したい場合は、1月21日にコースが再開されます。 また、2月25日に、Java開発者向けのコースが開始されます。 https://education.10gen.com/