ケース：MongoDBの設計
私はPOSシステムを開発していると私は、各レジ端末ごとの取引（商品等の情報、価格、数量など）を格納する必要があります。これはもちろん、トランザクション文書の数が時間の経過と共に増加することを意味します。
私の現在のソリューションは、以下の通りです：
「レジスタ」と「販売」と呼ばれる2つのコレクションがあります。販売伝票にはレジスターIDの参照がありますので、どの販売伝票がどのレジスターに属しているかわかります。トランザクションは、各販売文書内の配列に格納されます（1日ごとに約300の新しいトランザクション文書）。
既に大きなアレイを更新するときのパフォーマンスを向上させるために、各販売ドキュメントで小さな「キャッシュされた」アレイ（約50個のドキュメント - ほとんどの場合は小規模なアレイのみを更新する）を設計しました。完全に、私はそれらをメインのトランザクション配列に移動します。
MongoDBの文書の最大サイズが16MBに制限されているため、販売文書のカウント数を10000トランザクションに設定しました。トランザクション数がカウント制限を超えた場合は、販売伝票の注文を保存するために、レジスタ文書の配列にid参照を格納します。
私は非常に複雑なクエリを書く必要があったので、私は非常に満足していません。トランザクションがページングのために滞在する方法と、極端なケースを処理する方法で各クエリに対して約200トランザクションを取得する必要があったからです。
考察：
だから私は、その後、私は1つの山にすべてのキャッシュレジスタのすべてのトランザクションを投げるのと同じ「取引」と呼ばれる（常に成長）コレクション、ことを非常にBIG作ることを考えています各トランザクションは独自のレジスタID参照を持ちます。
質問：私はそれを行う必要がありますか？
アップデート：私はデータにアクセスする必要がどのように：
- 挿入と読み取り専用、決して既存のドキュメントを更新または削除
- 挿入最も頻度の高い操作
- ですを読むと、トランザクション番号に一致する文書の配列が返されます。 eまたは作成された時間の範囲で配列をソートする必要はありません）
- Read：ほとんどの場合、ほとんどの場合、最初の200個の最新のトランザクションのみを表示する必要があります。次に、ユーザーは必要に応じてさらにクエリを実行できます。
長所：
- 単純なクエリ（有効であればわからないが）、例えば
- 避ける不要な重複
- 一歩近づくアレイフリーデータベース
- 良好にシャーディング（？）
短所：
- あまりにも多くのインデックス（これは問題と考えられているインデックスのtrilionsは、これらの小さなのためにあった場合、それは問題でしょうか？ドキュメント？）
- 私はそれをやった後何が起こるか分かりません。理論的にはうまくいくはずです。しかし、現実には、我々はそれ
備考を知っているより多くの残酷である：
- たぶん私は一パイルコレクション上の配列を選んだ主な理由は、私はMongoDBを持つ任意の経験を持っていなかったということであったIとき開始しました。
- そして、ええ、私はトランザクションがオーダー
に滞在いくつかのビジュアルことを確認したかった：
MongoDBでは、アクセスする方法に応じてデータを保存する必要があります。データにアクセスする方法、フィールドを検索する方法、条件に基づいてデータを表示する方法、データを頻繁に更新または削除する必要がありますか？ 次に、どちらの方が良いかを提案することができます。 –