Was ist mview in Magento2?

Zuallererst, was ich weiß:

Die Indexverwaltung ist nützlich, um die Leistung des Geschäfts zu steigern.

EAV hat einen Nachteil. Es werden Daten in verschiedenen Tabellen gespeichert, so dass das Abrufen von Daten zeitaufwändig ist.

Damit speichern wir die Daten in einer einzigen Tabelle. Wenn Daten geändert werden, aktualisieren wir diese einzelne Tabelle (nichts als die Aktualisierung der Indizierung).

mysql trigger: Einige Abfrageaktionen basierend auf einer Tabelle Einfügen / Aktualisieren / Löschen ausführen.

So wird Magento, das den Trigger verwendet, wenn beispielsweise der Preis aktualisiert wird, entity_idin der Changelog-Tabelle gespeichert .

In devdocs gibt es eine Anweisung zum Implementieren von Triggern, die magento2 verwendet Magento/Framework/Mview.

Kannst du jemandem den Ablauf dieser Funktionalität erklären?

Ich meine , was ist view, action, processoretc?

In der offiziellen Dokumentation: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html gibt es folgende Informationen:

`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 steht für Materialized View und ist eine Momentaufnahme der Datenbank zu einem bestimmten Zeitpunkt. https://en.wikipedia.org/wiki/Materialized_view Warum müssen wir Tabellen duplizieren? Die Ausführung von Indexern ist kostspielig, insbesondere wenn auf Kategorieseiten Zugriffe auftreten, Kunden Bestellungen aufgeben und Administratoren Produkte speichern. Beim Speichern des Produkts wird der Cache ungültig (Off Topic). Bei einem Aktienindexer werden die betroffenen Entitäts-IDs vor Beendigung der Ausführung als zu bereinigende Cache-Tags gesendet (ganzseitiger Cache-Typ). In Magento 2.0-Kategorien werden IDs gekaufter Produkte gesendet. In Magento 2.1 werden die Produkt-IDs gesendet.

Es gibt 2 MySQL-Tabellen, in denen Indexer-Codes und -Status gespeichert sind:

• indexer_state
• mview_state

mview_statefunktioniert mit Update by Schedulein Admin> System> Indexer-Verwaltung

Update by Schedule Lässt die Indexer in Cron laufen.

Es gibt 3 Einträge in 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_invalidläuft weiter indexer_state. Es gibt immer noch die Notwendigkeit, "normale" Indexer in Cron auszuführen
• indexer_update_all_views läuft weiter mview_state
• indexer_clean_all_changelogs - löscht Änderungsprotokolle, die von verwendet werden mview_state

Beachten Sie, dass cron Indexer Gruppenaufgaben in einem separaten PHP - Prozess ausgeführt werden , wie es in deklariert etc/contab_groups.xml: <use_separate_process>1</use_separate_process>.

Changelog-Tabellen sind: [indexer name]_cl(mit einem Suffix versehen _cl). zB cataloginventory_stock_cl. Wenn Sie über Indexer verfügen Update by Schedule, die ein Produkt in admin festlegen und speichern, sehen Sie das entity_idProdukt in dieser Tabelle. Es ist ein großer Kreis, ich denke, eine Bestellung aufzugeben oder eine Lieferung zu erstellen, wird auch hier einen Eintrag hinzufügen.

Jemand hat in der offiziellen Dokumentation ein Beispiel angegeben, wie neue materialisierte Ansichten erstellt werden und welche Schnittstellenmethoden erforderlich sind.

<?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
}

Dies ist sinnvoll: //public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode } Wobei der $idsParameter die Entitäts-IDs aus *_clTabellen enthält.

Was ist die Verbindung zwischen Cache-Invalidierung und Indexer. Kategorieseiten werden jetzt ganzseitig zwischengespeichert (integrierter ganzseitiger Cache oder durch Varnish).

Es gibt \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]);
    }
}

Zurück zu 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');
}

Darin app/etc/di.xmlist:

<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" />

Darin Magento\Framework\Mview\View::update()ist:

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

Wenn Sie im vendor/Verzeichnis nach Magento\Framework\Mview\ActionInterfacesuchen, finden Sie zum Beispiel Folgendes:

In \Magento\CatalogInventory\Model\Indexer:

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

In dieser Klasse gibt es:

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

Und es sieht so aus, als würde es auf die von MView verwendete "Execute" -Methode einer "normalen" Klasse von Indexern zurückgehen.

Informationen zur Cache-Bereinigung nach dem Stock Indexer. Wenn eine Bestellung aufgegeben wird, werden die Mengen mit diesem Beobachter abgezogen:\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver

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

Ein anderer Beobachter löst den Indexer aus (jedoch nicht direkt in Mview / Indexer nach Zeitplan): \Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver

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

Wenn in Mview die neuen Mengen abgezogen SubtractQuoteInventoryObserverwerden, fügt der MySQL-Trigger (für Mview erstellt) eine Zeile ein cataloginventory_stock_clund markiert damit, dass für diese gekauften Produkt-IDs ein Neuindex (Bestand & Volltext) durchgeführt werden muss. Es gibt viele MySQL-Trigger, die für Mview erstellt wurden. Sehen Sie sie alle mit SHOW TRIGGERS;.

Wenn ein Produkt nach dem Auschecken nicht mehr im Lager ist, werden 2 Zeilen in diese Tabelle eingefügt (Magento speichert 2-mal den Lagerbestand in diesen 2 Beobachtern).

Wenn cron den Aktienindexer im Mview-Modus ausführt, werden die betroffenen Produkt-IDs (in M2.1) oder Kategorien-IDs (in M2.0) als Cache-Tags an den Cache gesendet. Mit Cache meine ich den Ganzseiten-Cache-Typ. Beispiel: catalog_product_99oder ein anderes Cache-Tag-Format, abhängig von der Magento-Version. Das gleiche, wenn Mview nicht aktiviert ist.

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

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

Und Magento_PageCache hat einen Beobachter \Magento\PageCache\Observer\FlushCacheByTags, der den gesamten Seiten-Cache-Typ nach Tags bereinigt. Dies geschieht für den eingebauten Ganzseiten-Cache. Lackcode ist in \Magento\CacheInvalidate\Observer\InvalidateVarnishObserver.

Es gibt eine kostenlose Erweiterung, die nach dem Auschecken des Kunden den Cache für noch vorrätige Produkte leugnet:

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

Cache-Bereinigung nur für nicht vorrätige Produkte, nachdem die Kaufabwicklung in Magento 2.2.x eingeführt wurde. Sehen \Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner.

Ich denke, die Cron-Ausführung für den Indexer in Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexsollte auf viel mehr als 1 Minute eingestellt sein.

Das mview.xmlwird zusammen mit verwendet, indexer.xmlum Indexer einzurichten.

Die mview.xmlDatei erklärt:

• Indexer-Ansichts-ID
• Indexer-Klasse
• Die Datenbank enthält Tabellen, die der Indexer verfolgt
• Welche Spaltendaten werden an den Indexer gesendet?

Die indexer.xmlDatei erklärt:

• Indexer-ID
• Name der Indexer-Klasse
• Titel des Indexers
• Indexer Beschreibung
• Indexer-Ansichts-ID

Weitere Informationen zur Deklaration des benutzerdefinierten Indexers finden Sie hier: Benutzerdefinierter Indexer in Magento2

Soweit ich verstanden habe, gibt es hier zwei verschiedene Dinge:

• Der Indexer aus dem Magento_IndexerModul
• Die Mview, aus Magento\Framework\Mviewder die materialisierte Ansicht für MySQL mithilfe von Triggern emuliert wird.

Hier sind einige Informationen aus der offiziellen Dokumentation

Indizierungsarten

Jeder Index kann die folgenden Arten von Neuindexierungsvorgängen ausführen:

• Vollständige Neuindizierung. Dies bedeutet, dass alle indizierungsbezogenen Datenbanktabellen neu erstellt werden.

• Die vollständige Neuindizierung kann durch eine Reihe von Faktoren verursacht werden, darunter das Erstellen eines neuen Webshops oder einer neuen Kundengruppe. Sie können optional jederzeit eine vollständige Neuindizierung über die Befehlszeile durchführen.

• Teilweiser Neuindex, dh, die Datenbanktabellen werden nur für die geänderten Elemente neu erstellt (z. B. zum Ändern eines einzelnen Produktattributs oder Preises).

Die Art der jeweils durchgeführten Neuindizierung hängt von der Art der Änderungen ab, die im Wörterbuch oder im System vorgenommen wurden. Diese Abhängigkeit ist für jeden Indexer spezifisch.

In Bezug auf den Workflow handelt es sich hier um eine teilweise Neuindizierung:

Die Referenz aus dem Magento-Dokument ist bereits hier, daher überspringe ich diesen Teil.
Magento hat materialized view in 2.0 implementiert, das Änderungen für alle Indexer nachverfolgt. Jeder Indexer verfügt über eine _clTabelle, die abgerufen wird, entity_idund auto_increment version_idüber Auslöser, die den Haupttabellen hinzugefügt werden.
Wenn der Cron-Job ausgeführt wird, wird der Indexer version_idfür jede Ansicht von der mview_stateTabelle zuletzt abgerufen und die nächsten verfügbaren Entitäten in der _clTabelle indexiert .
Die Neuindizierung bereitete bis 1.9.xx Kopfzerbrechen und verlangsamte bei großen Katalogen immer das System.
In Magento 2.0 aktualisieren Indexer nur die einzelnen Entitätsinformationen in Indexertabellen, anstatt die gesamten Daten neu zu indizieren. Dies hält den Ball am Laufen, ohne den Server zu verlangsamen.
Hinweis: Materialized View wird in mysql nicht unterstützt, daher wird es in Magento von PHP-Code verwaltet und funktioniert ähnlich wie Materialized View, eine Funktion in DBMS auf Unternehmensebene wie Oracle.