一般的なインデックス作成の問題に対する永続的なソリューション


23

私たちは、大きなインベントリレコードを持ついくつかのmagentoプロジェクトを開発し、フラットテーブルの切り捨てや、CLIを使用したcronの設定など、日々のインデックス作成の問題を解決するためにインターネット上で見つかったすべてのことを試してみました。インデックス作成ですが、これはインデックス作成の問題に直面している私たちの日々の頭痛です。

毎日製品を更新したり、他のフィードから製品を毎日インポートしたりするなど、さまざまなシナリオがあるプロジェクトに取り組んでいる間、この問題に対する永続的なソリューションを探しています。

これまたはいくつかの回避策でいくつかのベストプラクティスをお持ちの方は、非常に高く評価されるそれらを共有してください。


Magentoとその拡張機能、そして非常に非効率的でばかげたデータアーキテクチャで1年を無駄にしました。これらすべての警告は、Magento CEを表示し始めた人に与えられるべきでした。Magentoのオンワーは、数千人の時間を無駄にするために法廷に連れて行かなければなりません。データベースにインデックス付けをさせるだけで、データベースの仕事はしません。私は、専用サーバーにお金を浪費してから、一晩中眠れない労働時間を無駄にするのではなく、ホストされたeコマースプラットフォームまたはMS SQLサーバーを使用するオープンソースに移行することをお勧めします。
semiprecious.com

適切な拡張機能や適切なサーバー構成が見つからなかったと考えたことはありますか?一部のソフトウェアがニーズに合わない場合、必ずしもそれが役に立たないことを意味しません。過去5年以上、Magentoからパン(およびビール)を手に入れており、満足しているお客様もたくさんいました。10k以上のカタログを持つもの。
マリウス

CEの動作方法により、データメンテナンスは数十から数十万スカスの問題です。EEは、彼らが行ったインデックスの更新により優れていますが、それは100万ドルの収益企業のためです。あなたはそれでホスティングを投げることができますが、あなたのROIを負に変えるでしょう。私たちが使用するソリューションは、SAPとWalmartの使用などのソリューションに似た非常に専門的なデルタプロセスアップロードであり、インデックス付けの問題(fxとインラインマージン/属性の再計算)をバイパスする特別な価格設定ソリューション(ATG-esque)を組み合わせたものです。ホスティング。いいえ、Magentoは最適に設計されていません。

回答:


31

どのインデックスが遅いのか、そしてその理由を理解することが重要です

カタログの複雑さと最終的なストアアーキテクチャにより、インデックスの再構築にかかる時間と、基盤となるインフラストラクチャの組み合わせが決まります。

  • 50,000個の製品と10個のストアビューがある場合、数百万行のcatalog_url_rewrite処理に時間がかかることを保証できます。

  • あなたは100個の製品が、5000の属性を持っている場合は、保証することができcatalog_attributesたりcatalog_product_flat、テーブルを再構築するために年齢を取るか、だろうのフラットをその顔に

  • 1,000個の製品があり、500個の検索可能な属性がある場合、catalog_fulltext_search完了するには再び年齢がかかります

あなたが直面するそれぞれの問題に対する解決策はすべてに適合するサイズではありません。それはあなたの店を適切に設計することです。それをサポートする適切なインフラストラクチャを用意し、コンテンツの最新性とパフォーマンスをサポートする再インデックスの頻度/戦略を使用します。

  • フロントエンドキャッシュを追加してもまったく役に立ちません
  • その状況でより多くのハードウェアを投げると
  • カタログのサイズ/複雑さに対処すると役立ちます
  • サードパーティのインデックス作成ツールを使用すると役立ちます
  • 特定のインデックスの外部化(例:検索> SOLR)が役立ちます

特定のインデックスが必要かどうかを評価する場合もあります。フラットな製品/カテゴリを使用しても、すべての店舗が常に高速になるとは限りません。店舗がかなり遅くなるのを見てきました。そのため、前後にパフォーマンスをテストした後、それらは考慮事項ではないことに気付くかもしれません。


8

tl; dr

特効薬のソリューションはありません。いくつかの回避策がありますが、それはSonassi_Fastsearchindexカタログ検索専用です。

おそらく、保存時にインデックスの更新を無効にする(夜間に実行するようにスケジュールする)ことで、多少の軽減が得られるでしょうか?さらに多くのキャッシング(memcached、Redis、APC)およびVarnish(CEを実行している場合)のようなフルページキャッシュを追加することと組み合わせることで、始めることができます。Varnishを使用する予定がある場合はNexcess_Turpentine、githubでクイックスタートを確認してください。

詳しくは

インデックス作成の問題-特にcatalog_url_rewrites-はよく知られ、コミュニティで文書化されています。Magentoは、これらが最も悪影響を受ける顧客であるため、Enterpriseバージョンでこれらを処理しました。多くのEE顧客は、1万以上の製品と複数のストアビュー、Webサイトなどを持っています。

ただし、大規模なカタログと多数の属性がある場合、インデックス作成に長時間かかるという状況に陥ることがあります。具体的には、catalog_url_rewrite、product_flatです。この場合、インデックスの実行時間を修正しないことをお勧めします。長さではなく、処理オフロードして、コンテンツを提供するのではなく、CPUサイクルのインデックス作成にボックスを使用できるようにします

自問する質問:

  • インデックス作成の問題でビジネスを失いますか?
  • 負けアムI 生産性を伴うインデックスの問題のために?
  • コンバージョンを失うリスクがありますか、またはコンバージョン率が低下していますか?
  • インデックスが同期していない直接の結果である在庫(在庫など)を顧客が購入するリスクがあるか
  • カタログ価格設定ルールはコアビジネスの一部であり、
  • オンサイト検索のコンバージョン率は標準(8〜10%)よりも高いので、インデックス作成のメリットがありますか?

この特定の問題に対する特効薬の解決策はありません。ソリューションプロバイダーとして、オーバーヘッドコストを低く抑えながら、売上とビジネスを改善する最適な意思決定を顧客が行えるようにする必要があります。

代替案

カタログ検索と階層化ナビゲーションをSolrにオフロードします。

水平方向に拡大縮小します。さらにApache / nginxサーバーを追加します。より多くのサーバー=より多くの同時スループット。これは1:1ではありません。Nexcessには、パフォーマンスとApacheの構成に関する素晴らしいホワイトペーパーがあります:http : //www.nexcess.net/magento-best-practices-whitepaper

そして、あなたがワニスと一緒に行くことを選択した場合-覚えている

ここに画像の説明を入力してください


小道具はありがたいですが、インデックスの再作成はフロントエンドキャッシュとは関係ありません。その完全なバックエンド操作。フロントエンドの負荷を軽減すると、インデックスの再作成に時間がかかることはありませんが、確かに速くなることはありません。
ベン・レッサーニ-ソナシ

私が得ているのは、ボックスに来るトラフィックを減らすことです。ここでの最終的な懸念は、インデックスの実行中にサイトが利用できなくなったり、ジョブの実行中に不明な期間ロックされたりすることです。一日の終わりに、インデックス作成がフロントエンドに悪影響を及ぼさない場合、ジョブの実行時間は関係ありません。インデックスの読み込み時間の修正や改善はありません。「有料版にアップグレードする」という答えは誰も欲しくないので、私の提案はフロントエンドの可用性を改善し、インデックスをオフピークで実行するようにスケジュールすることです。
-philwinkle

もちろん、私はそれを理解しました-しかし、可用性はウェブサイトにとって重要です。eコマースサイトには不十分です。インデックスがロックされているために実際に購入できない場合は、サイトもオフラインになっている可能性があります。
ベン・レッサーニ-ソナシ

数百の製品しかなく、Magento 1.7で簡単な製品を保存するのにまだ数分かかります。私は専用のRackspaceサーバーに月500ドル以上を支払います。どこから始めればいいのかわかりませんが、おそらくいくつかのインデックスが壊れているのではないかと思われます。誰もが優れたコンサルタントを推薦できますか?
マックスホッジズ

5

大規模なMagento Webショップのほとんどでは、Magentoバックエンドインデックス管理を機能させるのは非常に困難です。私はこの問題を頻繁に経験しました。開発者がシェルスクリプトを常に実行するのは多忙です。通常、私はこの問題を永久に修正します。

shell / indexer.phpの新しいコピーを作成します> shell / myindexer.php

shell / myindexer.phpを154行目付近にカスタマイズします

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

そして、このチェックを166行目に追加します

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

そして、新しいシェルスクリプトをcpanel cronに追加して、5分ごとに実行します

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

上記のシェルスクリプトは5分ごとに実行され、再インデックス付けが必要なプロセスのみを再インデックス付けするため、サーバーCPUに大きな負荷がかかるリスクが軽減され、再インデックス付けのプロセス全体が非常に高速になります。再インデックス付けが必要なプロセスがない場合、単に再インデックス付けプロセスは実行されません。また、インデックス管理ページで再保存モードを「保存時に更新」に設定することを忘れないでください。わからない場合は、[送信]ボタンの横にある[アクション]> [インデックスモードの変更]でこのオプションを取得できます。


@changeling、どういたしまして。価値があるとうれしいです。
rbncha

誰でも重宝した場合に、私は、私のスクリプトにこれを組み入れました:gist.github.com/steverobbins/...
スティーブ・ロビンス

4

より多くのデータ(在庫サイズ、訪問者、マシン)を提供できると言う方が簡単ですが、可能性は次のとおりです。

  • Sonassi_Fastsearchindexカタログ検索インデックスに拡張機能を使用します。タイトル、説明、およびsku(私は気づいたと思います)のインデックスを作成するだけですが、うまく機能し、カタログ検索インデクサーの時間を短縮します。
  • ほとんどの場合、実行する必要のないインデクサー(タグや製品属性など)があります。定期的に価格、製品フラット、カテゴリー製品、カタログ検索のみを行えば十分な場合があり、その他は毎日行う場合があります。
  • 2時間ごとに製品を外部システムと同期し、その間、phpスクリプトでインデックスを作成します。そのため、特定の時間に実行する各インデクサーのcronjobを用意し、このcronにスクリプトを実行させます。これは、サーバーが実行できることと最新の製品データの間の最適な中間手段のようです。

これは、Magento CE 1.7.0.2で実行されています。それでも痛みはあります;)


通常、製品フラットの問題に直面しています。他のすべてのインデックスは問題ありません。
-ravisoni

3

Dnd_Patchindexurlを使用して、catalog_url_rewriteの再インデックス時間を約70%に短縮できました。

無効な製品や表示されない製品を除外して、URLを無料で作成することは良い解決策だと思います!

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

後:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

1.9.1.1にインストールし、非常にうまく動作しました!

Connect経由でもインストールできますhttp://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/


1

EE 1.13にアップグレードします。このバージョンでは、インデクサーが大幅に改善されました。


2
しかし、ほとんどのクライアントはコミュニティバージョンを好みます。
-ravisoni

1
同意した。1.8は2週間以内にリリースされますが、インデクサーの最適化は含まれない可能性が高いでしょう。私もそれは好きではありませんが、これはあなたのインデクサーを実行させる最も簡単で、安全で、そしておそらく最も安い方法です。
ポールグリゴルタ

これは永続的な解決策を見つけることは不可能です。
ravisoni

ほとんどの場合、誰かが非常に多くのSKUを持っており、既存のCE 1.7インデクサーを使用して実際にレンガの壁にぶつかる場合、EE 1.13を使用する必要があります。これらのCE 1.7およびEE 1.12インデクサーには、10〜25kのSKUを備えたサイトが多数あり、スムーズに稼働しています。重要なことは、ほとんどをワークフローレベルで適切に管理し、適切なインフラストラクチャを確保することです。
-davidalger

CEは完全に適切な選択です。EE 1.13 の機能バグ修正であり、コミュニティはとにかくCEに移行しました。それに関係なく、CEを使用するかEEを使用するかにかかわらず、インデックス作成時間は常にカタログの複雑さ、サーバー構成、訪問者の同時実行性、およびインデックス再作成の頻度に完全に依存します。EEは魔法の弾丸ではなく、アーキテクチャ関連の問題に対する適切なソリューションではありません。
ベン・レッサーニ-ソナシ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.