B2B2C eコマースプラットフォームを構築したい場合、バックグラウンドデータ統計を設定する際にどのような問題に注意する必要がありますか?特定の統計モジュールを設計するにはどうすればよいですか?
王玉平:
データベースを構築する前に、このステップの要件とプロセスを設計する必要があると思います。そのプロセスでどのようなデータが必要か、さらにはどのようなデータが得られるかがわかります。データ型。
たとえば、サプライヤー管理では、サプライヤーの会社の地域、電話番号、カテゴリなどを取得します。データ統計では、地域とカテゴリに関する統計を作成し、Cの対応するニーズに基づいて推奨事項を作成できます。 など
パームウォン:
ビジネスを理解することから始めることをお勧めします:
BBCプラットフォームは、まず3つのバックエンドに分割されます
マーチャントポータル+プラットフォーム運営ポータル+バイヤー個人ポータル
統計を作成する部分も 3 つあります:
1、消費者の個人的な観点から: 個人消費統計
2、プラットフォーム運営の観点から: プラットフォーム全体の運営に関する統計、加盟店の運営に関する統計
3、販売者の観点からの統計
BBCモールは実際には非常に複雑なビジネス システムであり、役割と機能の変化により、実際には多くのデータのやり取りが行われます。調整、統計、および権限管理には多くの例外があります。
Tmall のモードだけを見て目を閉じることはできません。
PHP+MySql を使用して、数千万のユーザーと訪問者を持つタオバオ モールのような B2C ウェブサイトを構築してみてはいかがでしょうか?
ディオン:
システムアーキテクチャは非常に重要です!
言語:
主流言語では問題ありません。 PHP、Java何でも構いません。
フロントエンドサーバー:
条件CDNがあれば最高です。そうでない場合は、フロントエンドの負荷パフォーマンスを必ず確保してください。一般的にはNginxをお勧めします。
アプリケーションサーバー:
クラスター。フロントエンドは負荷分散を担当します。クラスターの場合は、Sessionの問題に注意してください。他には何もありません。
データストレージ:
データ量が比較的大きい（数百万）場合は、MySQL + Memcachedを使用してクラスターを作成しても問題ありません。
データ量が多い場合は、NoSQLを検討してください。たとえば、FacebookはCassandraを使用し、AmazonはDynamoを使用します。
社会:
もっとシンプルにして、ユーザーがアクセスするデータの観点から見ることもできます
静的ファイル、には、頻繁に変更されない画像、HTM、JS、cssデータが含まれます。 別のドメインを与える http://static.xxxx.com など管理: nginx
フロントエンドとバックエンドを通じてリリースされる動的データは、次のタイプに分類されます:
データ読み取り:
1.注文など、ユーザーがクエリする必要があるビッグデータは、slaverのデータベースで確認できます
2.一部の商品情報やランキングなど、システム公開ページに表示されるデータはキャッシュから取得できます
データの書き込み者:
ユーザー情報の変更など、マスターデータベースに直接書き込まれる即時効果が必要です
リアルタイム要件が低い、または同時実行制限があるもの (Weibo の投稿、プライベート メッセージの送信など) 最初にキューに書き込み、非同期で読み取り、データベースに保存します
電子商取引プラットフォームにおける製品仕様設計の問題についてコメントしてもらえますか?
商品リスト（商品名、価格、在庫状況、その他商品基本情報）
例: 1、 携帯電話、100
仕様表(主キー、製品ID、仕様名)
例: 1 、1、演算子
製品仕様値テーブル(主キー、仕様ID、製品ID、仕様値ID、仕様値NAME)
例: 1、1、1、0、テレコムバージョン
2、1、1、1、モバイル版
仕様在庫表(製品ID、仕様値IDの組み合わせ、仕様値NAMEの組み合わせ、在庫数量、価格)
例: 1、1/0(オペレーター、テレコムバージョン)、オペレーター/テレコムバージョン100、 100 ブロック
問題の説明:
上記の方法では複数の仕様と複数のインベントリを実現できますが、合意された仕様順序を使用すると、プログラムを作成する後の段階で、システムが異なる仕様に関連するデータをカウントするのが困難になります。
そして、製品を作成するときは、仕様書を作成する前に製品を作成する必要があります。私は個人的にいくつかの大手電子商取引プラットフォームを参照しましたが、製品の作成は 1 回の送信で完了します。
必要なサポート:
製品作成のインタラクティブな設計を確実に簡素化しながら、プログラミングの複雑さを解決するには、問題の説明を組み合わせて、複数の仕様、複数の価格、および複数の在庫を備えた合理的な製品設計計画を提示する必要があります。
社会:
商品カテゴリ (タイプID,タイプ名,親ID)
商品一覧（商品名、価格、棚の有無などの商品基本情報、商品分類）
仕様表(主キー、仕様名 )
仕様値テーブル(仕様値ID、仕様id、ルール値の種類、仕様デフォルト値)
仕様-カテゴリ対応表(製品カテゴリid、仕様id)
製品-仕様関連付けテーブル(製品id、仕様id、仕様値ID、仕様実際の値)
在庫テーブル(アイテムID、数量、価格)
データベース ストレージはタオバオの商品詳細ページとどのように似ていますか?
1、各商品の写真の枚数や紹介文の数は決まっていません、はエディタhtmlで編集後に生成され、データベースに保存されますか？現実的ではありませんか？
2. データベースフィールドとして保存される場合、商品ごとの紹介文数は一定ではありません、上限が設定されている場合でも 、すると、多くのフィールドも無駄になります
3.クエリ、画像と紹介文が別々に保存されている場合、、クエリ後にページはどのように表示されますか 特定の画像とそれに関する紹介文を組み合わせます質問マッチ
劉伝祥:
全体1
。名前、価格、在庫、属性などの製品の構造化された情報がデータベースに保存されます。もちろん、それは単純なテーブルではありません。
2. 製品の非構造化情報は小さなファイルに保存され、写真や製品説明情報など、自社開発の大規模な小さなファイル システムに保存されます。
3。製品 id の画像ファイルは、データベースまたは他の種類のストレージに保存する必要があります。これは、必ずしも複数のフィールドを持つ必要はありません。製品のスケールを垂直方向に記録します。
4。ドキュメントを保存する前に、まず画像を保存し、ドキュメント内の画像srcのアドレスを小さなファイルシステムの画像パスに置き換えます
さらに、ストレージはデータベースとファイルシステムだけで理解することはできません。ストレージにはさまざまな種類があり、さまざまなファイルシステム、さまざまなRDBMS
、NoSqlストレージ...があります。
Zi Liu:
実際、何人かの同僚がすでに回答していますが、歴史的な観点から何か付け加えておきます。
このフィールドが実際にデータベースに配置された最も古いものは、html
のフラグメントを格納するclobフィールドでした。また、当時、このフィールドは商品タイトル、価格、販売者IDなどと同じテーブル内にあり、パフォーマンスにどの程度影響するかが考えられます。 そのため、この方法は長くは続かないでしょう。2005 年 では、このフィールドを別のテーブルに分割して保存しました。これにはあまり技術的な内容は含まれていませんでしたが、データベースへの大きな負担が軽減されました。当時はDBA
にとても感謝しています。2006年以降、タオバオは大規模にキャッシュを使用し始め、このフィールドもキャッシュに入れられるようになり、データベースへの負担が大幅に軽減されました(キャッシュにないデータのみが保存されます)。データベースに読み取り、読み取り後にキャッシュに入れます)。
に、タオバオは分散ファイルストレージシステムTFSを開発したため、このフィールドはトランザクションスナップショットなどの大きなフィールド情報とともにデータベースから完全に削除されました。
www.bkjia.com
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
