回答:
tl;dr ->「Magentoは1M製品を処理できますか？」という答えはイエスですが、いくつかの考慮事項があります。この規模では、この割合のカタログを商品化するためのインフラストラクチャと人員への適切な投資をサポートするためのボリュームがあると仮定します。
最初：
ご覧のとおり、Magento CEのサンプルデータには、さまざまなカテゴリの製品がほんの一握りしかありません。EEサンプルデータにはさらに多くのものがあり、ストアタイプごとに分けられています。
ここから CEサンプルデータをダウンロードできます。EEをお持ちの場合は、MagentoCommerce.comアカウント内からEEサンプルデータをダウンロードする必要があります。
ただし、これは数百または数千もの製品ではないことがわかります。製品をデータベースにインポートすることをお勧めします -このプロセスがどのように機能するかを把握するための良い練習です。これは、MagentoのデータフローまたはAPIインポートを介して実行できます。これを大規模に行う方法に関する情報は、インターネットで簡単に入手できます。
注意事項-データフローは非常に遅いため、要求したサイズのカタログをインポートするにはかなりの時間がかかる場合があります。私の知る限り、数十万または数百万の製品が存在するサンプルカタログはありません。
編集1/7/14：
Twitterの@ryaan_anthonyは、数十万もの製品を生成するMySQLストアドプロシージャをリリースしましたhttps://gist.github.com/ryaan-anthony/6290973
Magento APIとデータフローに関するいくつかの読書：
http://www.magentocommerce.com/knowledge-base/entry/introduction-to-magento-dataflow
http://www.magentocommerce.com/api/soap/catalog/catalog.html
第二：
このサイズのカタログを実行するときの主要な問題は、製品、URL書き換え、およびインベントリインデックス作成です。カタログ検索もかなり遅くなりますが、Apache Solr（EEにネイティブで提供される統合）を使用すると軽減できます。SolrにはCEプラグインがあります-Sonassiには1つがあり、他のプラグインはGoogleで見つけることができます。
私は700kの範囲でカタログを管理しましたが、これはまだ1M未満であり、インデックス作成には数時間かかることがあります。これは、Enterprise 1.13で対処されています。この規模でEnterprise Editionをよく見ることを強くお勧めします。これはCEで可能ですか？絶対に; しかし、EE 1.13のインデックス作成の改善は、特にこのような状況に合わせて調整されています。
第3：
マルチストアは Magentoにネイティブです。さまざまなトップレベルのカテゴリとウェブサイトを設定できます。それらはすべて同じカタログを共有する必要はありません。サイト間で共有する製品を選択するか、カタログを分離したままにすることができます。詳細はこちら：
http://www.magentocommerce.com/knowledge-base/entry/overview-how-multiple-websites-stores-work
Magentoにあるストア、ストアビューが多いほど、インデックスエントリが多くなり、フラットカタログが実際にパフォーマンスを低下させるほど膨れ上がる可能性があります。繰り返しになりますが、Sonassiには、Magento.SEとそのサイトでこれに関する多くの情報があります。製品管理のこの領域に入ると、Magentoの処理/スケーリングについて、Magento.SEでSonassiの回答を検索する必要があります。
個々のインストールはそれぞれ異なります。状況に応じて、カタログに最適な設定を見つけるために、常にテスト、調整、調整を行う必要があります。
過去にhttp://www.icecat.biz/en/を使用して、サンプルデータを読み込むための製品フィードを抽出しました。Magentoの拡張機能もいくつかありますが、それらは私たちのために機能しなかったため、ほとんどのインポートスクリプトを記述しました。
100万以上の製品をmagentoに取り込むために。さまざまな種類の製品タイプでmagmiサポート製品インポートCSVファイルを生成する単純なphpスクリプトを記述します。次に、magmiを使用してそれらをインポートします
http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
他の人がすでにあなたの質問のほとんどに対処しているように見えるので、完全な答えではありません。
1） ：私はこれが転がっ持っていた ほぼ1万人ランダムMagentoの製品を10 CSVをして ます。また、与えることができるhttp://beta.generatedata.com/を試してみます。
2） Philwinkleが既に述べたように、インデックス作成、データフロー、および検索は、このような大きなデータセットで克服する最大のハードルです。EE1.13は、このような大きなデータ（MySQLトリガー、すべての製品/カテゴリステータスなどを考慮）の処理に優れていますが、現時点ではまだ初期リリース（x.0.0）であることに注意してください。リリースして、他の人がバグ検出の負担を引き受けてから、実稼働環境で検討するようにします。インフラストラクチャと最適化が重要です。アップグレードALTER TABLE中に結合されず、DBでアップグレードを実行するのに数時間/日かかる可能性があるため、将来のアップグレードも考慮する必要があります。
大規模データベースでのインデックス作成のトピックに関する詳細な説明：
3） 2つのMagentoストア間でデータを共有する最も簡単な方法は、他社のMagento APIへのREST / SOAPリクエストを使用することです。別の方法は、ある会社からカタログを単にダンプし、他の会社がそれを選択して解析できるようにすることです。100万以上の製品でAPIを使用するよりもはるかに高速です。
私たちはmagento 1.7.xを使用して1.2m（属性なし、特に1つのストアビューのみ）製品を使用したプロジェクトに取り組みました。
実際に製品をインポートするのは非常にうまくいきます。最初のインポートには1.5時間かかりました
ディスクioのインデックスを再作成する際に非常に苦労する場合、解決策は大量のRAM（32GB RAM Amazon ssdインスタンス）を取得することでした。innodbプールのメモリ割り当てをデータベースのサイズより少し大きくするinnodb設定を最適化し、特に一時テーブルバッファーをデフォルトの16 mbから128 mbに変更することで、実際に再インデックスプロセスが節約されました。
キャッシュ、高速キャッシュにAPCキャッシュのみを使用し、低速キャッシュにファイルを使用し、不要なログとモジュールをフラットテーブルといくつかの他の最適化と共にオフにすると、サーバーは製品ページhtml（ページ全体ではなく）を200ミリ秒で配信します。ToDoリストにはニスキャッシュがあります。
多くのデッドロック問題（管理者の一部はまだ残っています）を戦い、殺す私たち、おそらく新しいバージョンのMagentoはフォーラムによるとこれらの問題を与えないでしょう。
1.2mの製品には本当に問題があると言いますが、適切なチームとリソースを用意せずに行うことはお勧めしませんが、時間があるならそれを機能させることができます。
他のプラットフォームがより良い仕事をするのか分からない。
これは常に良いことです。はい、Magento CEとEEは（提供されたデータセットを使用した理論ではなく経験から）できます。Magmiは問題ありませんが、初期ロードのインデックスを再作成すると、深刻な問題が発生します。それに加えて、製品の3％が毎日変わる場合、自動インデックスで30,000個の製品を更新する必要があるメンテナンスがあり、毎日の再インデックスを実行できません。これはすべて、クラスターホスティングとデルタ対応サプライヤーのオンボーディングという2つのことに帰着します。これらはエンタープライズ企業のドメインです。
人々は、製品がロードされるとジョブが終了すると考えるように見えますが、それはハードワークが開始されるときです。店舗や価格帯が多すぎる場合は、ホスティングを2倍にする必要があります。そのため、すべての意図と目的で95％に実装する機会はなく、99％に維持する機会はありません。何百万もの製品は中規模から大規模のエンタープライズに相当します。コンサルタントがこの経験を持たない場合、インフラストラクチャが中長期的に崩壊することを期待します。
Magmiは、大量の製品のインポートにも最適です。 http://sourceforge.net/apps/mediawiki/magmi/index.php?title=Magmi_Wiki
現在、Magmiを使用して最初のインポートが行われた220万SKUのクライアントの開発に取り組んでいます。