mongodbのschema設計方法

mongodbのschema設計方法
前言
mongodbはNoSQLの代表で、リレーショナル・データベース(MySQL)の使用から非リレーショナル・データベース(mongodb)の使用まで、その中のいくつかの以前の設計の思考慣性はいつも知らず知らずのうちに自分の決定に影響を与えている.設計の思想には共通点があり、大きな違いもある.mongodbの優位性は彼がデータを表す方法が非常に豊富であることにある.以下、いくつかの設計の原則と方法を総括する.
原則
schemaの設計で最も重要なのは、現在の設計の拡張性ではなく、設計の可読性、または元の設計の3つのパターンです.最も重要なのは、あなたのappが一般的に示しているデータがどのように構造されているか、どのように設計されているかです.取り出して使用します.例を挙げると、ブログのschemaを設計すると、元の方法で設計される可能性があります.

posts
{
  _id: ,
  title: ,
  body: ,
  author: ,
  date: 
}

comments
{
  _id: ,
  post_id: ,
  author: ,
  order: 
}

tags
{
  _id: ,
  tag: ,
  post_id:
}

しかし、より良いデザインは:

{
  _id: ,
  author: ,
  body: ,
  comments : [
    {
      body: ,
      email: ,
      author: ,
    },
    ...
    {
     ...
    }
  ],
  date: ,
  tags: [
    ...
  ],
  title: 
}

​
従来のデザインモデルの目標

データベースデータ修正の難易度をできるだけ減らす(データ冗長性を減らす)

データベース設計拡張の変更を最小化

データベースアクセス時の曖昧さを避ける

mongodbで:

デフォルトでは、データ冗長性を回避する

が設計されています.

このような問題は存在しません.mongoのschemaは非常に柔軟なので、いつでも

を変更することができます.

は、設計時にできるだけアプリケーションに必要なデータの形で設計し、取り出して使用するため、3番目の問題が発生する確率も

少ない.
制約がなければどうしますか?
mongoで最もよく考えられる問題は、外部キーがなくてどのようにデータの一致性を維持するかということです.上記のブログの最初の設計のように、あなたが新しいコメントを挿入したとき、データベースはあなたのpost_idが本当にpostsというcollectionの中に対応値があるかどうかを保証しません.
解決策は、第2の設計のようにpostsというcollectionに埋め込むことです.この時、コメントはすでにpostの一部なので、挿入されたコメントがブログの問題に対応していない心配はありません.
事務がなければどうしますか.
現在、mongodbではトランザクションはサポートされていません.つまり、1つのビジネスでいくつかのレコードを変更する必要がある場合は、1つのオペレーションが失敗した後に他のオペレーションをロールバックすることを保証することはできません.この場合、どうすればいいですか?
mongoはトランザクションを提供していませんが、彼は非常に豊富な原子操作を提供しています.私たちはそれを十分に利用する必要があります.リレーショナル・データベースでは、いくつかのテーブルを持っていて、joinでリンクする必要があります.だから、トランザクションは同時にいくつかのテーブルを修正する必要があります.しかし、mongoでは、設計時にprejoinを設計しています.(同じcollectionに埋め込まれています)post全体を直接変更するだけでトランザクションの効果を実現できます.
総じて言えば、解決策は3つあります.

設計を再構築し、原子操作で

を一度に修正できるようにします.

あなたのソフトウェアでロックを実現するメカニズムは、一連のテストを探して修正して書くことで実現されます.

大量のデータまたは厳密でないシーンにおいて、このようなエラーを許容する

.
典型的なデザインシーン
一対一の関係
例えば、応募者と履歴書の関係です.一緒に埋め込むと16 MB(mongoの制限)以上のデータが得られない限り、一緒に埋め込むべきです.少ない使用のものをよく食べるものに埋め込むことです.
一対多の関係
例えば都市と人の関係、ブログとコメント
都市と人との関係のように、1つの都市は実に多くの人に対応しています.人を都市に埋め込むのは、あまり適切ではありません.都市情報を人に埋め込むのはもっと適切ではありません.データの冗長性が大量に発生するので、情報の更新も特に煩わしいです.この場合、2つのcollectionを分けて、人のcollectionの中で1つにはcityフィールドがあり、都市collectionの1つに対応します.
ブログやコメントのような対応が特に多くない場合は、一番いいのは埋め込むことです
多対多の関係
例えば本と作者の関係、先生と学生の対応関係
本と著者のように、比較的少ない対応が比較的少ない場合、1つの実行可能な方法は2つのcollectionを分けることです.本collectionにはauthors配列が保存され、著者collectionにはbooks配列が保存され、互いに対応しています.この方法が悪いところは、データの手動で維持することと一致しています.もう1つの方法は、一緒に埋め込むことで、性能の向上があり、特に先生と学生のような関係では、先生を学生に埋め込まないほうがいいです.新しく来た先生がまだ学生がいない可能性が高いので、この先生をシステムに入れることはできません.
ツリー構造
1つの典型的なシーンはamazonのような電子商取引で、1つの商品の分類の下で多くのサブ分類がある可能性があります.
1つの方法は、分類されたcollectionを確立し、各分類にparent_idフィールドがありますが、すべての祖先を見つけるのに不便です.そのため、ancestersの配列フィールドを追加して、すべての祖先のidを記録すると、祖先と子孫を簡単に検索できます.
組み込みのメリット

は、読み取りの効率を向上させます.これは、データを取得するには、データベースを1回クエリーするだけでよいことを意味します.

大きなファイルの処理
データ量が特に大きい(16 Mより大きい)場合、例えば100 M以上のmp 4ファイルを読み込む場合、GRIDFSを使用する必要があります.原理は彼を小さなブロックに分割することです.