1

私は新しい仕事を始めたばかりで、さまざまなバージョンのマグニートーがいくつかインストールされています！

今では、最初にすべてをアップグレードしてから、1回のマグネトインストールと1つのデータベースを使用してすべてを取得する必要があるように思われます。

これを行うための（一般的な用語での）最良の方法は何ですか。1回のインストールでサイトを再作成し、製品をインポートすることも可能ですか、それとも最善の策です。

異なるインストールの下でそれらを持っていることはパフォーマンスに役立つという仲間の開発者によるいくつかの話があります。これは本当ですか？

それらをすべて1つのインストールにまとめたら、在庫管理や注文、複数のサイトへの製品の配置なども非常に簡単になります。正しいですか？

私たちはかなりの数の店が約15ishと言っており、かなりの数の製品が4000以上だと言っています。

4

3 に答える 3

8

私の最初の提案は、すべての Magento インスタンスを 1 つのインストールに移動する必要がある理由を検討することです。理由はあなたの質問からは明らかではありません。したがって、開発者の最善のアドバイスは、「それは機能しますか? それなら触らないでください」です:)

特に理由がなければ、そのままにしておいたほうがいいでしょう。ソフトウェア システムのすべての再編成プロセス (アップグレード、インフラストラクチャの構成、アクセスのセットアップなど) は困難で、費用がかかり、時間がかかり、エラーが発生しやすく、通常、ビジネスの観点からはあまり価値がなく、少し退屈です。これは Magento 固有のものではなく、あらゆるソフトウェアの一般的な特徴です。

また、ホリデーシーズンであることにも注意してください。なので、1月中旬まではECストアは何もしない方がいいです。

Magento ストアの再編成に価値があると思われる場合は、ストアごとに段階的に (段階的に) 行うのが最善の方法です。

  1. 最も複雑なストアを考えてみましょう。後続のステップに必要なものをすべて準備します。つまり、ツールを準備し、自動スクリプトを作成し、テスト サーバーでそのコピーを使用してプロセスを実行します。機能テストのセットを作成して、少なくともスモーク テストでカバーします。ストアが機能しているように見えることを確認するには、このような簡単なチェックを何度も繰り返す必要があります。自動テストは時間を大幅に節約します。したがって、これらすべての準備により、ダウンタイムが短縮されます。
  2. ストアへのパブリック アクセスを閉じます。
  3. ストアを Magento バージョンにアップグレードする必要があります。それを新しいインフラストラクチャに移動します。
  4. すべてのユーザー シナリオを手動および自動テストで検証します。問題がある場合は修正します。
  5. ストアへの公開アクセスを開きます。ログを監視し、サーバー マシンでレポートを読み込みます。問題があれば修正します。
  6. 次の店舗を取ります (NextStore と呼びましょう)。サンドボックス サーバーでコピーを作成します。
  7. サンドボックス サーバーで、既に変換されたストア (ConvertedStore と呼びましょう) のコピーを作成します。
  8. NextStore のコピーからすべてのデータをエクスポートし、ConvertedStore のコピーにインポートします。これを行うには、Magento Dataflow または Import/Export モジュールを使用できます。これらのモジュールですべてのデータをインポート/エクスポートできるわけではありません - カタログ、注文、顧客のみです。必要に応じて、他のエンティティをインポート/エクスポートするカスタム スクリプトを開発する必要があります。
  9. 結果を手動で検証し、自動テストと手動で検証します。見つかった問題を修正する自動スクリプトを作成します。これらのスクリプトは、後で実際の変換プロセス中に必要になります。
  10. NextStore を閉じます。
  11. 準備済みの手順とスクリプトを使用して、新しいインフラストラクチャに移行します。変換プロセス中に ConvertedStore を閉じるかどうかを検討する必要があります。開けて良いかどうかは気分次第です。安全上の理由から、それを閉じることをお勧めします。
  12. すべてが正常に機能することを確認します。ログ、レポートを監視します。
  13. 問題があれば修正します。
  14. 残りのストアを続行します。

それは手順に関する私の（完全に個人的な）見解です。

仲間の開発者による、それらを異なるインストールの下に置くとパフォーマンスが向上するという話があります。これは本当ですか？

はい、あなたの友人は正しいです。Magento (実際には、この世界のあらゆるもの) を小さなインスタンスに分割すると、処理が軽くなります。パフォーマンスの違いは非常に小さいですが (4000 製品のインスタンスの場合)、避けられません。インスタンスを組み合わせた後 (それぞれ 400 個の製品を持つ 10 個のインスタンスがあるとします)、10 倍の顧客、レポート、製品、店舗などのデータを処理することになると考えてください。製品、データを返すため。もちろん、検索に 0.00001 秒かかっても問題ありません。結合されたインスタンスの場合は 0.0001 秒でも問題ありません。ただし、セットの並べ替えやマッチングなど、非線形に成長するものもあります。しかし、前述のように、4000 個の製品では大きな違いは見られません。

それらすべてを 1 つのインストールの下に置くと、在庫管理や注文、複数のサイトへの製品の配置なども非常に簡単になります。正しいですか?

その通りです。複数の店舗を統合した後、注文、在庫、顧客の処理はよりシンプルで簡単になります。

幸運を！:)

于 2012-11-26T21:49:27.867 に答える
1

考慮すべき最も重要なことは、これらすべてのサイトを 1 つの Magento「インスタンス」に配置することで、どのような問題を解決できるかということです。ビジネス/チームにとって、これらのサイトで製品と在庫を共有することと、これらのサイトを個別に変更できる柔軟性を持つことのどちらがより重要ですか? ダウンタイムや可用性への影響は、すべてのサイトに影響を与える可能性があります。

追加の質問/調査領域: 製品階層 (カテゴリと属性) はどの程度異なりますか? 料金は各サイトで同じですか、それとも異なりますか? これらのサイトのいずれかがマルチリージョンであり、各リージョンの料金はどのように処理されますか?

プラットフォーム内に荒削りな部分があっても、1 つの Magento インスタンスで複数のサイトを実行することは確かに可能です。

于 2012-11-26T21:38:10.320 に答える
0

Magento にはすべてのエンティティをエクスポートする方法がないため、ストアをマージする機能はありません。カスタム コードを作成する必要があります。古いストアからすべてのレコードを取得し、参照整合性を維持しながら新しい ID を割り当てて、新しいストアに挿入する必要があります (これは「製品のインポート」が行うことですが、カテゴリ、注文、顧客などにはありません)。

私の意見では、そのために作成するコードの量は、最初からやり直すよりもほとんど時間がかかります。あなたは基本的に、Magento に欠けている機能を書いていることになります。それが簡単なら、彼らはすでにそれをやっているでしょう。

ただし、DB で一意の識別子を再割り当てすることを心配する必要がないため、2 つのストアを別々に分割するのは非常に簡単です。

于 2013-10-04T14:19:53.833 に答える