W oficjalnej dokumentacji:
https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html
jest opis:
`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 oznacza widok zmaterializowany, który jest migawką bazy danych w danym momencie.
https://en.wikipedia.org/wiki/Materialized_view
Dlaczego mielibyśmy powielać tabele. Uruchomienie indeksatorów jest kosztowne, zwłaszcza gdy na stronach kategorii występuje ruch, klienci składają zamówienia, a administratorzy zapisują produkty. Przy zapisywaniu produktu pamięć podręczna zostaje unieważniona (nie na temat). W przypadku indeksatora zapasów, przed zakończeniem wykonywania, wysyła identyfikatory encji, których dotyczy, jako znaczniki pamięci podręcznej do wyczyszczenia (typ pamięci podręcznej pełnej strony). W kategoriach Magento 2.0 wysyłane są identyfikatory zakupionych produktów. W Magento 2.1 wysyłane są identyfikatory produktów.
Istnieją 2 tabele MySQL, które przechowują kody indeksujące i statusy:
indexer_statemview_state
mview_statewspółpracuje z Update by ScheduleAdmin> System> Zarządzanie indeksatorem
Update by Schedule sprawia, że indeksatory mają być uruchamiane w cronie.
Istnieją 3 wpisy w 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_invalidjest uruchamiany indexer_state. Nadal istnieje potrzeba uruchamiania „normalnych” indeksatorów w cronieindexer_update_all_views jest uruchamiany mview_stateindexer_clean_all_changelogs - czyści dzienniki zmian używane przez mview_state
Należy zauważyć, że zadania grupowe cron Indexer uruchamiane w osobnym procesie php, jak oświadczył w etc/contab_groups.xml:
<use_separate_process>1</use_separate_process>.
Tabele zmian są:
[indexer name]_cl(z przyrostkiem _cl). np cataloginventory_stock_cl. Jeśli masz indeksatory ustawione Update by Schedulei zapisujące produkt w adminie, zobaczysz entity_idten produkt w tej tabeli. To duże koło, myślę, że złożenie zamówienia lub utworzenie przesyłki doda tutaj również wpis.
Ktoś podał przykład w oficjalnym devdoc, jak tworzyć nowe zmaterializowane widoki i jakie są wymagane metody interfejsu (zignoruj powyższe stwierdzenie o rozkazach w poniższym fragmencie):
<?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
}
Ma to sens:
//public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode
}
gdzie $idsparametr ma identyfikatory encji z *_cltabel.
Jaki jest związek między unieważnieniem pamięci podręcznej a indeksatorami. Strony kategorii są teraz buforowane na całej stronie (wbudowana pamięć podręczna na pełną stronę lub przez Varnish).
Jest \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]);
}
}
Powrót do 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');
}
W app/etc/di.xmlhotelu znajduje się:
<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" />
W Magento\Framework\Mview\View::update()hotelu znajduje się:
$action = $this->actionFactory->get($this->getActionClass());
$this->getState()->setStatus(View\StateInterface::STATUS_WORKING)->save();
..
$action->execute($ids);
..
Jeśli szukasz w vendor/katalogu Magento\Framework\Mview\ActionInterface, znajdziesz na przykład:
W \Magento\CatalogInventory\Model\Indexer:
class Stock implements \Magento\Framework\Indexer\ActionInterface, \Magento\Framework\Mview\ActionInterface
W tej klasie jest:
/**
* Execute materialization on ids entities
*
* @param int[] $ids
*
* @return void
*/
public function execute($ids)
{
$this->_productStockIndexerRows->execute($ids);
}
I wygląda na to, że wraca do „normalnej” klasy indeksującej metody „wykonaj”, która jest używana przez MView.
O czyszczeniu pamięci podręcznej po indeksatorze giełdowym. Kiedy zamówienie jest składane przy kasie, ilości są odejmowane za pomocą tego obserwatora:\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver
$itemsForReindex = $this->stockManagement->registerProductsSale(
$items,
$quote->getStore()->getWebsiteId()
);
Ponadto inny obserwator wyzwala indeksatora (ale nie bezpośrednio w Mview / Indexer według harmonogramu):
\Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver
if ($productIds) {
$this->stockIndexerProcessor->reindexList($productIds);
}
W przypadku Mview, gdy odejmowane są nowe ilości SubtractQuoteInventoryObserver, wyzwalacz MySQL (stworzony dla Mview) wstawi wiersz cataloginventory_stock_cl, oznaczając, że należy dokonać reindeksu (zapas i pełny tekst) dla identyfikatorów zakupionych produktów. Istnieje wiele wyzwalaczy MySQL utworzonych dla Mview. Zobacz je wszystkie z SHOW TRIGGERS;.
Kiedy produkt zostanie wyczerpany z magazynu po przejściu do kasy, zobaczysz 2 wiersze wstawione do tej tabeli (Magento zapisuje 2 razy pozycję w magazynie w tych 2 obserwatorach).
Gdy cron uruchamia indeksatora giełdowego w trybie Mview, identyfikatory produktu, którego dotyczy problem (w M2.1) lub identyfikatory kategorii (w M2.0), są wysyłane do bufora czystego jako znaczniki bufora. Przez pamięć podręczną rozumiem typ pamięci podręcznej pełnej strony. Przykład: catalog_product_99lub inny format tagu pamięci podręcznej w zależności od wersji Magento. To samo, gdy Mview nie jest włączony.
\Magento\CatalogInventory\Model\Indexer\Stock\AbstractAction::_reindexRows
...
$this->eventManager->dispatch('clean_cache_by_tags', ['object' => $this->cacheContext]);
A Magento_PageCache ma obserwatora \Magento\PageCache\Observer\FlushCacheByTags, który wyczyści pełny typ pamięci podręcznej stron według tagów. Robi to dla wbudowanej pamięci podręcznej pełnej strony. Kod związany z lakierem jest w \Magento\CacheInvalidate\Observer\InvalidateVarnishObserver.
Istnieje bezpłatne rozszerzenie, które odmówi czyszczenia pamięci podręcznej dla wciąż dostępnych produktów po kasie:
https://github.com/daniel-ifrim/innovo-cache-improve
Czyszczenie pamięci podręcznej tylko w produktach niedostępnych po wprowadzeniu kasy w domyślnym Magento 2.2.x. Zobaczyć \Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner.
Uważam, że wykonanie crona dla indeksu Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexpowinno być ustawione na znacznie więcej niż 1 minutę.
Mviewodnosi się do zmaterializowanych widoków , którymi są tabele indeksu.