1

数百万の製品を扱う e コマース Web サイトがあり、1 日に数百万のページビューがあり、主に製品の詳細ページであるとします。

私は現在、リレーショナル DB にすべてのデータを持っているとしましょう。

クエリを実行し、製品を集約およびフィルタリングするためにリレーショナル DB にデータを保持することの長所と短所は何でしょうか...ただし、製品の詳細にはフラット json ファイルを使用しますか?

したがって、1 つの製品ごとに 1 つのファイルがあり、すべての詳細が json にシリアル化されています。これらのファイルは、高性能 cdn の下に配置され、地理的に分散されます。ユーザーが

www.mysite.com/prods/00123

サーバー (またはクライアント) は、レイアウトのテンプレート ファイルを読み込み、cdn.mysite.com/prods/00123.json などから読み取ったデータを入力します。

したがって、この場合、基本的にクエリを実行する必要はありません。製品 ID にちなんで名付けられたファイルに直接ジャンプします。私はそれが非常に速いはずだと思いますが、独自の（高価で維持が難しい）分散データベースサーバーを構築する代わりに、スケーラビリティ/キャッシング/地理的分散を外部の強力なパートナー（akamai、amazonなどのcdn）に委任しますか？

私はあなたの提案/フィードバックを楽しみにしています...特にそれが現実世界の経験になる場合:)

ありがとう！

4

1 に答える 1

2

ご要望に応じて、

製品の説明は、MongoDB のようなスキーマのないデータベースに保存することをお勧めします。これは、製品が属性 (および対応するフィールド) の数が大きく異なる非常に異なるフィールドを持つ可能性があるためです。また、そのような情報は、読み取られるよりもはるかに少ない頻度で書き込まれます。MongoDB にはコレクション レベルの書き込みロックがあり、一貫性のある書き込みを行いたい場合、負荷の高いアプリケーションの書き込みを抑止します。ただし、結合を行ったり、EAV スキーマ テーブルからフィールド値を取得したりする必要がないため、MongoDB での読み取りは非常に高速です。言うまでもなく、データ ボリュームのシャーディングとレプリケーションに基づいて、運用環境で実行する必要があります。

MongoDB の読み取りパフォーマンスは、メモリにマップされたファイルにより非常に優れており、レプリケーション/シャーディングも取得できるため、フラット ファイルに格納するよりも優れています。

ただし、ファイルシステム (またはファイルシステムネットワーク) が、データベースによって提供されるセキュリティ、速度、およびアクセシビリティを提供する場合、ファイルシステムにデータを保存することは悪い考えではありません。フラット ファイルが効率的な方法で提供されるように構成されている場合、従来の db vs flat-file 引数は当てはまりません。

ただし、ショッピング カート、チェックアウト トランザクションなどの情報を MongoDB に保存しないでください。ACID トランザクションがなく、「一貫性を持った」頻繁な書き込みと更新は MongoDB の得意分野ではないためです。

于 2013-07-19T13:59:13.077 に答える