co to jest mview w magento2?

Po pierwsze co wiem:

Zarządzanie indeksami jest przydatne w celu zwiększenia wydajności sklepu.

EAV ma jedną wadę. przechowuje dane w różnych tabelach. dlatego pobieranie danych jest czasochłonne.

Abyśmy mogli przechowywać dane w jednej tabeli. po zmianie danych zaktualizujemy tę pojedynczą tabelę (nic oprócz aktualizacji indeksowania)

mysql trigger: wykonaj niektóre działania zapytania w oparciu o wstawienie / aktualizację / usunięcie tabeli.

Tak więc magento używając wyzwalacza na przykład, gdy cena jest aktualizowana, zapisze się entity_idw tabeli zmian.

w devdocs znajduje się instrukcja implementacji wyzwalaczy magento2 Magento/Framework/Mview.

czy możesz wyjaśnić przepływ tej funkcji?

Mam na myśli to, co jest view, action, processoretc?

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_state
• mview_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 cronie
• indexer_update_all_views jest uruchamiany mview_state
• indexer_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ę.

mview.xmlJest używany wraz z indexer.xmldo indeksujących konfiguracji.

mview.xmlPlik deklaruje:

• identyfikator widoku indeksatora
• klasa indeksująca
• baza danych zawiera tabele śledzące indeksatora
• jakie dane kolumnowe są wysyłane do indeksu

indexer.xmlPlik deklaruje:

• identyfikator indeksatora
• nazwa klasy indeksującej
• tytuł indeksatora
• opis indeksatora
• identyfikator widoku indeksatora

Więcej informacji na temat deklaracji indeksatora niestandardowego można znaleźć tutaj: Indeksator niestandardowy na Magento2

Z tego, co zrozumiałem, są tutaj dwie różne rzeczy:

• Indeksator z Magento_Indexermodułu
• Widok, z Magento\Framework\Mviewktórego emuluje zmaterializowany widok MySQL przy użyciu wyzwalaczy.

Oto niektóre przelotne informacje z oficjalnej dokumentacji

Rodzaje indeksowania

Każdy indeks może wykonywać następujące typy operacji reindex:

• Pełny reindex, co oznacza przebudowanie wszystkich tabel baz danych związanych z indeksowaniem.

• Pełne reindeksowanie może być spowodowane różnymi czynnikami, w tym tworzeniem nowego sklepu internetowego lub nowej grupy klientów. Opcjonalnie możesz w pełni reindeksować w dowolnym momencie za pomocą wiersza poleceń.

• Częściowy reindeks, co oznacza przebudowanie tabel bazy danych tylko dla rzeczy, które uległy zmianie (na przykład zmiana atrybutu lub ceny pojedynczego produktu).

Rodzaj reindeksu wykonywany w każdym konkretnym przypadku zależy od rodzaju zmian wprowadzonych w słowniku lub w systemie. Ta zależność jest specyficzna dla każdego indeksatora.

Jeśli chodzi o przepływ pracy, tutaj chodzi o częściowe ponowne indeksowanie:

Referencje z dokumentu Magento już tu są, więc pomijam tę część.
Magento zaimplementowało zmaterializowany widok w 2.0, który śledzi zmiany dla wszystkich indeksatorów. Każdy indeksator ma _cltabelę, która pobiera entity_idi auto_increment version_iddodane z wyzwalaczy w tabelach głównych.
Po wykonaniu zadania cron indeksator pobiera ostatni version_iddla każdego widoku z mview_statetabeli i indeksuje kolejne dostępne elementy w _cltabeli.
Reindexing sprawiał ból głowy do 1.9.xx i przy dużym katalogu zawsze spowalniał system.
W programie Magento 2.0 indeksator aktualizuje tylko informacje o konkretnej jednostce w tabelach indeksatora zamiast reindeksować całe dane. Dzięki temu piłka toczy się bez spowolnienia serwera.
Uwaga: Widok zmaterializowany nie jest obsługiwany w mysql, więc w Magento jest zarządzany przez kod PHP i działa podobnie do widoku zmaterializowanego, który jest cechą DBMS na poziomie przedsiębiorstwa, jak Oracle.