私はお店とすべての時間持っているすべてのインデックスが無効であると。インデックスが無効にされたとき、私は見当もつかないことに気付きました。
これらのインデックスの1つ以上を無効にする「すべて」のイベントのリストを教えてください。
- 製品の属性
- 製品価格
- カタログURLの書き換え
- 製品フラットデータ
- カテゴリー製品
- カタログ検索インデックス
- タグ集約データ
- 在庫状況
私はお店とすべての時間持っているすべてのインデックスが無効であると。インデックスが無効にされたとき、私は見当もつかないことに気付きました。
これらのインデックスの1つ以上を無効にする「すべて」のイベントのリストを教えてください。
回答:
コードディレクトリでgrepを実行すると、無効化をトリガーするファイルのリストが取得されます。
grep -Ri '::STATUS_REQUIRE_REINDEX' .
次のコアファイルは無効化をトリガーします
./core/Mage/CatalogSearch/Model/Indexer/Fulltext.php
./core/Mage/Catalog/Model/Product/Indexer/Flat.php
./core/Mage/Catalog/Model/Product/Indexer/Price.php
./core/Mage/Catalog/Model/Category/Indexer/Flat.php
./core/Mage/Catalog/Model/Category/Indexer/Product.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Product/Flat.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Category/Flat.php
./core/Mage/Catalog/Model/Indexer/Url.php
./core/Mage/Backup/Helper/Data.php
./core/Mage/CatalogInventory/Model/Indexer/Stock.php
./core/Mage/ImportExport/Model/Import.phpMagento CEコアの基本的なイベントは次のとおりです。
製品の属性
特定の保存属性（フラット製品の一部）、ストア、フラットカタログ製品が有効な場合はstore_group
製品価格
構成設定の保存を確認します（価格範囲など）。または製品の保存、ウェブサイトの作成/削除
カタログURLの書き換え
特定の無効化なし
製品フラットデータ
特定の保存属性（フラット製品の一部）、フラットカタログ製品が有効な場合、フラット製品を有効にした後
カテゴリーフラットデータ
フラットカタログカテゴリが有効で、特定の保存カテゴリがチェックされている、フラットカテゴリを有効にした後
カテゴリー製品
チェックはフラットカタログカテゴリが有効で、特定の保存カテゴリです
カタログ検索インデックス
特定の保存属性（検索可能な属性の一部）、ストア、フラットカタログ製品が有効な場合はstore_group
タグ集約データ
下記の一般的な条件を除き、無効化されることはありません
在庫状況
[在庫]タブの特定の[システム]> [構成設定]保存、たとえば在庫切れの製品の表示
それらのすべてはSystem > Tools > Backup、Webサイト、ストア、およびストアビューからのバックアップのロールバックおよび作成、削除、または移動後に無効になります。製品のデータフローインポートを実行した後、次が無効になります。
フラットデータやURLインデクサーなどのいくつかのインデクサーも、core_config_data値を保存することで無効になっているようです。
たぶん、一時的にこのサイトの書き換えを作成することを考えています
Mage_Index_Model_Resource_Process
次に、次のようなことをします：
<?php
class YourNamespace_YourModule_Model_Resource_Process
extends Mage_Index_Model_Resource_Process
{
public function updateStatus($process, $status)
{
if ($status === Mage_Index_Model_Process::STATUS_REQUIRE_REINDEX) {
Mage::log(sprintf('Indexer %s was invalidated.', $process->getIndexer()->getName()), null, 'invalid_index.log', true);
foreach (debug_backtrace() as $db) {
Mage::log(sprintf('%s::%s', $db['class'], $db['function']), null, 'invalid_index.log', true);
}
}
return parent::updateStatus($process, $status);
}
}インデクサーが無効になったときと、インデクサーの原因となった呼び出しトレースを簡単に特定する必要があります。
他の人はすでにあなたの質問の詳細に答えているので。なぜ索引付けが必要なのか、それがMagentoおよび現代のデータベースとの関係にどのように関係するのかを説明する方が良いと思いました。
索引：名前、主題などのアルファベット順のリスト。それらが出現する場所への参照を持ち、通常は本の最後にあります。
それでは、データベースに関してインデックスとは正確には何ですか？
インデックスは、1つまたは複数のフィールドで多数のレコードをソートし、データ取得を高速化するデータ構造です。これは、データベースを検索するときに、テーブルがまたがるディスクブロックをスキャンすることを避けるためです。
そして、Magentoに関してインデックスとは何ですか？データベース内のデータベースであるEAV（エンティティ属性値）の副産物。複数のルックアップテーブルを使用して、インデックス付きのフラグが付けられたすべての属性を収集し、すべてのルックアップテーブルの1つのフラットテーブルに結合して、クエリを高速化し、I / OおよびCPUサイクルを削減します。
Magentoが最初に開発されたとき、優先度リストで柔軟性が高かったという言及を思い出します。しかし最終的には、このような柔軟性のコストはパフォーマンスを犠牲にし、Magentoを最初から悩ませてきました。
一般的に、Magentoのエンジニアは何よりもまず、可能な限り最も柔軟でカスタマイズ可能なシステムを構築し、後でパフォーマンスを心配するという任務を負っていました。なぜMagentoはとても遅いのですか？
EAVはデータウェアハウジングには適していますが、トランザクション処理にはひどいです。それでは、なぜインデックスが必要なのでしょうか？リレーショナルモデルの同じアプローチが再実装されたため、MagentoはMySQL自体が内部で行うすべてのことを処理する必要があります。MySQLテーブルにすでに存在するインデックスなど、考慮すべき事項がいくつかあります。それを念頭に置いて、今すぐEAVデータモデルを検討してください。
同じものを再実装する必要があります。これは非常に「アンチパターン」なIMOです。
また、これは、インデックス作成プロセスをロックするvar/locksためにインデクサーが使用するのと同じ理由です。データベースに行/テーブルのロックがある同じ理由。
さてレコードは、言う製品の値が変更されたとき、flat tableまたはindex（MySQLはとしてそれを参照してどうなるかのように）多数のレコードをスキャンせずに迅速かつ効率的に発見される新たに変更されたデータに対してクエリに反映されるように更新する必要があります。フラットテーブルは、MySQLが使用しているのとまったく同じ理由で使用されているように存在します。そのようなインデックス（本のような）がなければ、レコードを取得するためにフルテーブルスキャンが必要です。これは、要求されたデータを見つけるためのCPUサイクルだけでなく、ディスクとメモリの両方の大量のI / Oを意味します。これはパフォーマンスにとって非常に悪いです。
MagentoはEAVデータモデルを使用しているため、要求されたデータを見つけるためにすべてのデータをつなぎ合わせるためにスキャンする必要のある多数のルックアップテーブルがあります。これは、フラットカタログを無効にすると発生します。MySQLと同様に、貴重なI / Oサイクルを保持しながらレコードをすばやく検索するために利用されるインデックス（フラットテーブル）を使用して、レコードをスキャンします。テーブルを作成してインデックスを追加しないことは、magentoでフラットテーブルを使用しないことと同じです。これら2つのシナリオはさまざまなシナリオでうまく機能しますが、この質問に対するBen at Sonassiの非常に良い答えをご覧ください。（ヒントには、データの範囲を理解することが含まれます。）
それはあなたの質問に対する直接的な答えではありませんが、可動部分を理解し、それらに対してよりよく準備することは、インデックス付けに伴う頭痛のいくつかを軽減するのに役立つはずです。「症状ではなく問題を扱います。」
最新のデータベースシステムの内部をさらに調査することで、インデックス作成が必要な方法と理由、およびそれがMagentoのインデックス作成と（ある程度）関連する方法をよりよく理解できます。
要約すると、盲目的にソリューションを適用する前に、問題の範囲を理解してください。ないように、データのすべてのビットはまったく同じと計画とソリューションを実装するだろうAFTERあなたは問題の良い/完全に理解を持っています。データベースの最適化は、変更管理にとって非常に有益です。恐ろしいを防ぐなどDEADLOCKS。
また、すべてのインデクサーの設定を検討しManual、代替プロセスをセットアップして、オフピーク時間（管理者が不在のとき）にインデックスを再構築することもできます。のみProduct PricesとStock Statusに設定する必要がありますUpdate on Save。
次に、技術的な観点からインデックス作成の仕組みを検討します。メインモジュールはインデックス作成を担当しMage_Indexます。インデクサーの基本モデル：Indexer、Process、Event。
Mage_Index_Model_Indexerインデクサーであり、他のモジュールとのすべての相互作用はMage_Indexこのサービスを介して行われます。次のメソッドが含まれています。
processEntityAction() イベントを作成して登録し、インデックス作成プロセスを開始しますlogEvent() イベントを作成し、後続のインデックス作成用に登録します。indexEvent() インデックスイベントを実行します。getProcessesCollection()製品属性、製品価格、カタログURLの書き換えなど、すべてのプロセスのコレクションを返します。通常、メソッドなどのエッセンスを変更した後、_afterSaveまたは_afterCommit部分的な再インデックスを実行します。Mage_Index_Model_Processまたはプロセスは、ステータス、最後に実行された操作を格納し、あなたのインデクサの本質です。すべてのプロセスはテーブルに保存されますindex_process。プログラムにはgetIndexer()、モデルのインデックスを返すメソッドがあります。インデックスモデルのプロセスによって委任されたタスクのほとんど。
Mage_Index_Model_Event発生したイベントに関する情報を保存します。たとえば、製品を保存し、保存後、新しいイベントを作成し、保存したばかりのエンティティのタイプに関する情報と、この実体に対して実行したIDと実行したアクションに関する情報を保存します。
無効化が発生する一般的なリスト：
config.xmlトランザクションの保存時に、モジュールのに登録されたインデックスを持つリソースモデル。 afterCommitCallback()プレフィックス付きで呼び出されます。これは、成功したトランザクションの最後にあるため、インデックスイベントがログに記録される場所です。
...そして、Magento 2にEAVがまだ残っているのは悲しいことです。
参照：