magento2のmviewとは何ですか？

まず、私が知っていること：

インデックス管理は、ストアのパフォーマンスを向上させるのに役立ちます。

EAV データを別のテーブルに保存するため、データの取得に時間がかかります。

そのため、データを単一のテーブルに保存します。データが変更された場合、この単一のテーブルを更新します（インデックス作成の更新のみ）

mysql trigger：テーブルの挿入/更新/削除に基づいてクエリアクションを実行します。

そのため、たとえば価格の更新時にトリガーを使用するmagentoはentity_id、変更ログテーブルに保存します。

を使用してmagento2トリガーを実装するためのdevdocsのステートメントがありますMagento/Framework/Mview。

この機能の流れについて説明してください。

私は何であるかを意味しview、action、processorなど？

公式ドキュメント： https ://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.htmlには次の記事があります。

`Allows tracking database changes for a certain entity (product, category and so on) and running change handler.
Emulates the materialized view technology for MySQL using triggers and separate materialization process (provides executing PHP code instead of SQL queries, which allows materializing multiple queries).`

MViewは、ある時点でのデータベースのスナップショットであるマテリアライズドビューの略です。 https://en.wikipedia.org/wiki/Materialized_view テーブルを複製する必要があるのはなぜですか。特にカテゴリページにトラフィックがあり、顧客が注文し、管理者が製品を節約する場合、インデクサーの実行にはコストがかかります。製品の保存時に、キャッシュは無効になります（トピック外）。ストックインデクサーの場合、実行を終了する前に、影響を受けるエンティティIDをクリーンアップするキャッシュタグとして送信します（フルページキャッシュタイプ）。Magento 2.0カテゴリでは、購入した製品のIDが送信されます。Magento 2.1では、製品IDが送信されます。

インデクサーコードとステータスを保持する2つのMySQLテーブルがあります。

• indexer_state
• mview_state

mview_stateで動作しますUpdate by Schedule[管理]> [システム]> [インデクサーの管理に

Update by Schedule インデクサーをcronで実行します。

次の3つのエントリがありますMagento_Indexer/etc/contab.xml。

<group id="index">
    <job name="indexer_reindex_all_invalid" instance="Magento\Indexer\Cron\ReindexAllInvalid" method="execute">
        <schedule>* * * * *</schedule>
    </job>
    <job name="indexer_update_all_views" instance="Magento\Indexer\Cron\UpdateMview" method="execute">
        <schedule>* * * * *</schedule>
    </job>
    <job name="indexer_clean_all_changelogs" instance="Magento\Indexer\Cron\ClearChangelog" method="execute">
        <schedule>0 * * * *</schedule>
    </job>
</group>

• indexer_reindex_all_invalidで実行されindexer_stateます。まだcronで「通常の」インデクサーを実行する必要があります
• indexer_update_all_views で実行されます mview_state
• indexer_clean_all_changelogs -によって使用される変更ログをクリアします mview_state

で宣言されているのcronインデクサグループタスクは、個別のPHPプロセスで実行することに注意してくださいetc/contab_groups.xml： <use_separate_process>1</use_separate_process>。

変更ログの表は次のとおりです [indexer name]_cl（接尾辞_cl）。例えばcataloginventory_stock_cl。インデクサーを設定しUpdate by Scheduleて管理者に製品を保存している場合はentity_id、この表にその製品が表示されます。これは大きな円です。注文するか、出荷を作成すると、ここにもエントリが追加されると考えています。

誰かが公式のdevdocで、新しいマテリアライズドビューの作成方法と、必要なインターフェイスメソッドについての例を提供しました（上記のスニペットの注文に関する説明は無視してください）。

<?php
<VendorName>\Merchandizing\Model\Indexer;
class Popular implements \Magento\Framework\Indexer\ActionInterface,   \Magento\Framework\Mview\ActionInterface
{
public function executeFull(); //Should take into account all placed orders in the system
public function executeList($ids); //Works with a set of placed orders (mass actions and so on)
public function executeRow($id); //Works in runtime for a single order using plugins
public function execute($ids); //Used by mview, allows you to process multiple placed orders in the "Update on schedule" mode
}

：これは、意味になります パラメータは実体からのid持つテーブルを。//public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode }$ids*_cl

キャッシュの無効化とインデクサー間のリンクは何ですか。カテゴリページはフルページキャッシュになりました（ビルトインフルページキャッシュまたはVarnishを使用）。

あります\Magento\Indexer\Model\Processor\InvalidateCache::afterUpdateMview：

/**
 * Update indexer views
 *
 * @param \Magento\Indexer\Model\Processor $subject
 * @return void
 * @SuppressWarnings(PHPMD.UnusedFormalParameter)
 */
public function afterUpdateMview(\Magento\Indexer\Model\Processor $subject)
{
    if ($this->moduleManager->isEnabled('Magento_PageCache')) {
        $this->eventManager->dispatch('clean_cache_after_reindex', ['object' => $this->context]);
    }
}

に戻るMagento\Indexer\Cron\UpdateMview::execute()：

/**
 * Regenerate indexes for all invalid indexers
 *
 * @return void
 */
public function execute()
{
    $this->processor->updateMview();
}

Magento\Indexer\Model\Processor::updateMview()：

/**
 * Update indexer views
 *
 * @return void
 */
public function updateMview()
{
    $this->mviewProcessor->update('indexer');
}

でapp/etc/di.xmlあります。

<preference for="Magento\Framework\Mview\ProcessorInterface" type="Magento\Framework\Mview\Processor" />


/**
 * Materialize all views by group (all views if empty)
 *
 * @param string $group
 * @return void
 */
public function update($group = '')
{
    foreach ($this->getViewsByGroup($group) as $view) {
        $view->update();
    }
}

Magento\Framework\Mview\ViewInterface

/**
 * Materialize view by IDs in changelog
 *
 * @return void
 * @throws \Exception
 */
public function update();

app/etc/di.xml

 <preference for="Magento\Framework\Mview\ViewInterface" type="Magento\Framework\Mview\View" />

でMagento\Framework\Mview\View::update()あります。

$action = $this->actionFactory->get($this->getActionClass());
$this->getState()->setStatus(View\StateInterface::STATUS_WORKING)->save();
..
$action->execute($ids);
..

vendor/ディレクトリを検索するとMagento\Framework\Mview\ActionInterface、たとえば次のようになります。

で\Magento\CatalogInventory\Model\Indexer：

class Stock implements \Magento\Framework\Indexer\ActionInterface, \Magento\Framework\Mview\ActionInterface

このクラスには次のものがあります。

/**
 * Execute materialization on ids entities
 *
 * @param int[] $ids
 *
 * @return void
 */
public function execute($ids)
{
    $this->_productStockIndexerRows->execute($ids);
}

また、MViewで使用される「通常の」インデクサークラスのexecute`メソッドに戻るようです。

Stock Indexer後のキャッシュクリーニングについて。チェックアウト時に注文が行われると、このオブザーバーを使用して数量が差し引かれます。\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver

$itemsForReindex = $this->stockManagement->registerProductsSale(
    $items,
    $quote->getStore()->getWebsiteId()
);

さらに、別のオブザーバーがインデクサーをトリガーします（ただし、スケジュールによってMview / Indexerに直接ではありません）。 \Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver

if ($productIds) {
    $this->stockIndexerProcessor->reindexList($productIds);
}

Mviewの場合、新しい数量がで減算されるSubtractQuoteInventoryObserverと、MySQLトリガー（Mview用に作成された）がに行を挿入し、cataloginventory_stock_clそれらの購入された製品ID に対して再インデックス（ストックおよびフルテキスト）を行う必要があることをマークします。Mview用に作成された多くのMySQLトリガーがあります。ですべてを参照してくださいSHOW TRIGGERS;。

チェックアウト後に製品の在庫がなくなると、そのテーブルに2つの行が挿入されます（Magentoはこれら2つのオブザーバーで2倍の在庫アイテムを保存します）。

cronがMviewモードでストックインデクサーを実行すると、影響を受ける製品ID（M2.1）またはカテゴリID（M2.0）がキャッシュタグとしてキャッシュにクリーンに送信されます。キャッシュとは、フルページキャッシュタイプを意味します。例：catalog_product_99またはMagentoのバージョンに応じた他のキャッシュタグ形式。Mviewが有効になっていない場合も同じです。

\Magento\CatalogInventory\Model\Indexer\Stock\AbstractAction::_reindexRows

...
$this->eventManager->dispatch('clean_cache_by_tags', ['object' => $this->cacheContext]);

また、Magento_PageCacheには\Magento\PageCache\Observer\FlushCacheByTags、タグによってページキャッシュタイプ全体をクリーニングするオブザーバーがあります。組み込みのフルページキャッシュに対して実行します。ニス関連のコードはにあり\Magento\CacheInvalidate\Observer\InvalidateVarnishObserverます。

顧客のチェックアウト後にまだ在庫のある製品のキャッシュクリーンを拒否する無料の拡張機能があります。

https://github.com/daniel-ifrim/innovo-cache-improve

デフォルトのMagento 2.2.xでチェックアウトが導入された後、在庫切れの製品でのみキャッシュクリーニングが行われます。をご覧ください\Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner。

インデクサーのcron実行をAdmin > Stores > Configuration > Advanced > System > Cron configuration options for group: index1分以上に設定する必要があると考えています。

mview.xml一緒に使用されているindexer.xmlセットアップインデクサへ。

mview.xmlファイルには、宣言しています。

• インデクサービューID
• インデクサークラス
• インデクサーが追跡するデータベーステーブル
• インデクサーに送信される列データ

indexer.xmlファイルには、宣言しています。

• インデクサーID
• インデクサークラス名
• インデクサーのタイトル
• インデクサーの説明
• インデクサービューID

カスタムインデクサー宣言の詳細については、Magento2のカスタムインデクサーを参照してください。

私が理解したことから、ここには2つの異なることがあります：

• Magento_Indexerモジュールのインデクサー
• Magento\Framework\Mviewトリガーを使用してMySQLのマテリアライズドビューをエミュレートするMview 。

公式ドキュメントから得られたいくつかの情報を紹介します

インデックスの種類

各インデックスは、次の種類のインデックス再作成操作を実行できます。

• 完全なインデックス再作成。これは、インデックス作成に関連するすべてのデータベーステーブルを再構築することを意味します。

• 完全なインデックスの再作成は、新しいWebストアや新しい顧客グループの作成など、さまざまな原因で発生する可能性があります。オプションで、コマンドラインを使用して、いつでも完全に再インデックスを作成できます。

• 部分的な再インデックス。変更されたもの（たとえば、単一の製品属性または価格の変更）についてのみデータベーステーブルを再構築します。

特定の各ケースで実行されるインデックス再作成のタイプは、辞書またはシステムで行われた変更のタイプによって異なります。この依存関係は、各インデクサーに固有です。

ワークフローに関しては、ここでは部分的な再インデックス付けのためのものです。

Magentoドキュメントからの参照は既にここにあるので、その部分はスキップします。
Magentoは、すべてのインデクサーの変更を追跡するマテリアライズドビューを2.0で実装しました。各インデクサーには、メインテーブルに追加されたトリガーとトリガー_clを取得するテーブルがentity_idありauto_increment version_idます。
cronジョブが実行されると、インデクサーはテーブルversion_idから各ビューに対して最後に取得し、mview_stateテーブル内で次に使用可能なエンティティにインデックスを付け_clます。
1.9.xxまでインデックスの再作成は頭痛の種でしたが、巨大なカタログでは常にシステムの速度が低下しました。
Magento 2.0のインデクサーでは、データ全体のインデックスを再作成するのではなく、インデクサーテーブルの特定のエンティティ情報のみを更新します。これにより、サーバーを遅くすることなくボールが転がり続けます。
注：マテリアライズドビューはmysqlではサポートされていないため、MagentoではPHPコードで管理され、oracleのようなエンタープライズレベルDBMSの機能であるマテリアライズドビューと同様に機能します。