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_statemview_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ührenindexer_update_all_views läuft weiter mview_stateindexer_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.
Mviewbeziehen sich jedoch auf materialisierte Ansichten , wie es die Indextabellen sind.