magentoでのインデックス作成の仕組み

1. Magentoでのインデックス作成の仕組み
2. 正確に何をしますか？
3. なぜ必要なのですか？

Magentoにはさまざまな種類のインデックスがあります。
すべてのインデクサーは、処理を高速化するためにあります。
ここではそれらのほんの一部を取り上げます。

フラットインデックス
このようなインデックスは2つあります。1つはカテゴリ用で、もう1つは製品用です。
デフォルトでは、カテゴリと製品のエンティティ（および顧客と顧客の住所ですが、この状況では重要ではありません）はEAVエンティティです。これは拡張性にとって非常に便利です。ただし、すべての属性のすべての値を取得するには、多くの結合または複数のクエリが必要になるため、パフォーマンスが大幅に低下します。
ここで、フラットインデクサーが役立ちます。
EAV構造をフラット構造に変換します。つまり、属性に対応する1つの列を持つテーブル（Magentoのストアビューごとに1つ）を作成します。これにより、選択が高速になります。カテゴリの場合、すべての属性はテーブル列に変換されます。製品については、「製品リストで使用」とマークした製品のみが、属性が異なるすべてのタイプの製品を販売でき、数十億の列を持つ1つのテーブルを作成できないためです。
また、一部の製品は無効になっているか、特定のWebサイトに属していない可能性があり、検索するエントリにそれらを含める必要はありません。それらはインデクサーによって除外されます。
生成されたフラットテーブルは、フロントエンドでデータを読み取るために使用されます。バックエンドは引き続きEAV構造を使用します。

カタログ検索インデックス
多くの属性値で製品を検索できます。それらの一部は、フラットインデクサーによって生成されたフラットテーブルに含まれない場合があります。このインデックスは、製品の検索可能な属性値でテーブルを埋めるので、キーワードに基づいてそれらを簡単に検索できます。すべての情報を1つのテーブル（または1つのフィールド）に保持すると、全文検索を使用して関連する結果を取得できます。

製品価格。
製品の価格は多くの変数の影響を受ける可能性があります。たとえば、顧客グループ、ウェブサイト、カタログ割引ルール。
上記と同じように、価格で製品を取得すると、多くの結合または複数の選択が必要になります。さらに、バンドル製品には奇妙な価格設定システムがあります。このインデクサーは、いくつかのテーブル（catalog_product_index_price_*）のデータを集約し、選択（ソートとフィルター）をはるかに簡単にします。

カタログURL書き換え
これは、どのURLがどの製品またはカテゴリに対応するかを設定することにより、URL書き換えルールをクリーンアップします。この方法により、URL管理内部システムは、非標準のURLを呼び出すときに表示するページを決定しやすくなります。すべての製品およびカテゴリのURLキーを検索する代わりに、1つのテーブルで検索するだけです。

カテゴリ製品
Magentoでは、「Is Anchor」という名前のカテゴリ属性をtrueまたはfalseに設定できます。それが本当なら、それは問題のカテゴリーがその子カテゴリーのすべての製品をリストすることを意味します。繰り返しますが、このリアルタイムを決定するには、1つのテーブルを読み取るだけではなく、より多くのリソースが必要になります。このインデクサーは、バックエンドで設定した関連付けとカテゴリの「アンカー」フラグに基づいて、製品とカテゴリ間の関連付けを作成します。

在庫状況
シンプルな製品の場合、簡単です。それらは在庫がある場合と在庫がない場合がありますが、構成可能、グループ化、およびバンドルの場合はそれほど簡単ではありません。それらは、メイン製品に関連付けられた子製品に応じて、在庫がある場合と在庫がない場合があります。繰り返しますが（ここで自分のことを繰り返しています）、リアルタイムでステータスを取得することは、多くのクエリを意味します。

製品の属性。
これは、同じ理由で階層化ナビゲーションで使用できるすべての属性を収集します。より速く読むためにそれらをすべて1か所にまとめる。

タグの集約
これが何をするのかわかりません。実際のライブプロジェクトでタグを使用したことはありません。

https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detailの元の投稿から取られているため、これを信用することはできません

Magentoのインデックス作成は、データベースレベルのインデックス作成にのみ似ています。アントンが述べているように、それはサイトのより速い操作を可能にする非正規化のプロセスです。Magentoデータベース構造の背後にあるいくつかの考え方と、高速で動作するためにインデックス作成が必要になる理由を説明してみましょう。

より「典型的な」MySQLデータベースでは、カタログ製品を保存するためのテーブルは次のように構成されます。

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

これは取得が高速ですが、eコマースソフトウェアに根本的な問題が残ります。属性を追加したい場合はどうしますか？おもちゃを販売し、サイズの列ではなくage_rangeが必要な場合はどうでしょうか？別の列を追加することもできますが、大規模なストア（たとえば、Walmartなど）では、これにより行が90％空になり、新しい属性を維持しようとすることはほとんど不可能であることは明らかです。

この問題に対処するため、Magentoはテーブルを小さな単位に分割します。この回答ではEAVシステム全体を再作成したくないので、この単純化されたモデルを受け入れてください。

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

新しい値をproduct_attributesに入力し、隣接するレコードをproduct_attribute_valuesに入れることで、属性を自由に追加できるようになりました。これは基本的にMagentoが行うことです（ここで表示したものよりもデータ型を少し重視しています）。実際、2つの製品がまったく同じフィールドを持つ理由はないため、異なる属性セットを持つ製品タイプ全体を作成できます。

ただし、この柔軟性には代償が伴います。私のシステムでシャツの色を見つけたい場合（簡単な例）、私は見つける必要があります：

1. アイテムのproduct_id（productテーブル内）
2. 色のattribute_id（属性テーブル内）
3. 最後に、実際の値（attribute_valuesテーブル内）

Magentoは以前はこのように動作していましたが、完全に遅いものでした。そのため、パフォーマンスを向上させるために妥協しました。ショップのオーナーが必要な属性を定義したら、最初から大きなテーブルを生成します。何かが変わったら、それを宇宙から消して、もう一度生成します。この方法では、データは主に優れた柔軟な形式で保存されますが、単一のテーブルからクエリが実行されます。

これらの結果のルックアップテーブルは、Magentoの「インデックス」です。インデックスを再作成すると、古いテーブルが爆発し、再び生成されます。

物事が少し明確になることを願っています！

Magentoは非常に強力で複雑なシステムです。大量のデータを扱うことができますが、データベースが大量のレコードで過負荷になると、重くなり遅くなります。Magentoはインデックスを使用してこの問題を解決します。インデックスは、フラットデータを含む追加のデータベーステーブルであり、データベースからの高速応答を整理できます。

デフォルトでは、コアシステムは各アイテムの保存時にインデックスを更新します。しかし、場合によっては、たとえばいくつかの種類の一括アクションなど、手動で行う必要があります。管理バックエンドからいつでもインデックスを更新できます（Admin-> System-> Index Management）。しかし、時には問題を引き起こします。

たとえば、10,000個以上の製品と多くのカテゴリがある場合、「カタログURL書き換え」インデックスの再構築には数時間かかる場合があります。それから、PHPスクリプトはmax_execution_timeを超えているために壊れる可能性があります。コマンドラインからインデックス再作成プロセスを実行することにより、いくつかの問題を解決する方法があります。