0

わかりました、私は初心者ではないと言い始めますが、最善の解決策を探しています.

簡単にするために、私は4方向の関係を持っています:

Busines
{
 bid: unique,
 name: string
}

Client
{
 cid: unique,
 name: string
}

Product
{
 pid: unique,
 name: string
}

Order
{
 oid: unique,
 bid: FK,
 cid: FK,
 pid: FK
}

Mongoでこれを構築する最良の方法は何ですか?

同じクライアントが多くの企業や同じ製品に存在する可能性があることに注意してください。

そのため、クライアントのすべての注文で選択を行う必要がある場合があり、データをビジネスごとにグループ化したり、製品ごとにグループ化したりする必要があります。

4

2 に答える 2

1

あなたのコメントを考慮して：

私は同意しますが、問題は速度にあり、MongoDB のシャーディング/レプリケーションは、たとえば MySQL よりも優れています...そして、小さな注文要素 (数百万単位) がたくさんあり、ここで RDBS には欠点があります。 .. :(

あなたはこれを間違って見ていると思います。MongoDB は、高速化するような方法でシナリオに適合する場合にのみ、RDBMS よりも高速になります。

数百万の行は、ほとんどのデータベースでシャードに値するものではなく、コモディティ サーバーでさえ、少なくとも数テラバイトの情報を処理できます。シャーディングは、必ずしもデータのサイズからではなく、RDBMS テクノロジの場合と同様に、書き込み容量を増やす必要があるためです。

ただし、スキーマの質問に答えると、注文を削除してクライアント内で置き換えることを除いて、現時点ではそのままにしておきます。

{
    _id: ObjectId(),
    name: 'sammaye',
    orders: [
        {oid:{},bid:{},cid:{},pid:{}},
        { //etc }
    ]
}

これは小さくて貧弱なオブジェクトであり、あまり多くの問題を引き起こすことはなく、毎日 100 ほど増加することはないため、重くて即時の断片化を引き起こすことはありません。

トラフィックと注文率で断片化が発生することがわかった場合は、いつでも 2 のべき乗のサイズ割り当て ( http://docs.mongodb.org/manual/reference/command/collMod/ ) を使用して解決できますが、私はすべきです。これは実際には短期的にはパフォーマンスが低下するため、このオプションを必要とせずに適用しないでください。

つまり、あなたが私たちに与えた情報で。そのスキーマをどのように設計するか。

于 2013-02-26T11:10:58.693 に答える
0

別のアプローチを提供するにはClients、別のコレクションとして保持し、(少なくとも一部の)Product情報をOrder.

通常、注文を受けた時点で顧客が何を注文したか (および支払った価格、通貨など) を知ることが重要です。製品への参照は引き続き保持されますが、注文履歴を表示して、顧客がその時点で何を購入したかを実際に確認できることを意味します。製品の詳細は、時間の経過とともに合法的に変化します。

これは依然として高速読み取りを意味します。ビジネスコレクションはクライアントよりもはるかに小さいと想定しているため、アプリケーションレベルで処理できるものがあるかもしれません（つまり、ビジネスをキャッシュして、データベースでそれぞれを検索しません）

私が話している情報の多くは、現在製品ドキュメントにはありませんが、考えるべきことかもしれません。

もちろん、ドキュメントのサイズには制限があり、製品情報 (またはその一部) を非正規化していて、1 人の顧客が多くの企業に注文を出す可能性がある場合は、この情報を顧客コレクションに保持する範囲があることを確認する必要がありますが、注文数やサイズなどによって異なります。

とにかく、パフォーマンスの専門性などを扱ったいくつかの良い答えがすでにありましたが、私は別の意見を提供したいと思いました。

于 2013-02-27T08:54:44.337 に答える