что такое mview в magento2?

Прежде всего, что я знаю:

Управление индексами полезно для повышения производительности магазина.

EAV имеет один недостаток. он будет хранить данные в разных таблицах, так что получение данных занимает много времени.

Так что мы будем хранить данные в одной таблице. при изменении данных мы обновим эту таблицу (ничего, кроме обновления индексации)

mysql trigger: выполнить некоторые действия запроса, основанные на вставке / обновлении / удалении таблицы.

Таким образом, magento использует триггер, например, когда цена обновляется, он будет сохранен entity_idв таблице изменений.

в devdocs есть оператор для реализации триггеров с использованием magento2 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 расшифровывается как Materialized View, который представляет собой снимок базы данных в определенный момент времени. https://en.wikipedia.org/wiki/Materialized_view Зачем нам дублировать таблицы. Индексаторы обходятся дорого, особенно когда на страницах категорий есть трафик, клиенты размещают заказы, а администраторы сохраняют продукты. При сохранении продукта кеш становится недействительным (не по теме). В случае фондового индексатора, прежде чем он завершит выполнение, он отправляет идентификаторы сущностей, на которые влияют, как очищенные теги кэша (тип кэша полной страницы). В категории Magento 2.0 отправляются идентификаторы купленных продуктов. В Magento 2.1 отправляются идентификаторы продуктов.

Есть 2 таблицы MySQL, в которых хранятся коды и статусы индексатора:

• indexer_state
• mview_state

mview_stateработает Update by Scheduleв Admin> Система> Управление индексаторами

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

Обратите внимание , что групповые задания хрон индексатор запускается в отдельном процессе 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
}

Это будет иметь смысл: //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);
}

И похоже, что он восходит к «обычному» классу индексаторов - метод execute`, который используется MView.

О чистке кеша после 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, отмечая, что для этих идентификаторов приобретенного продукта необходимо выполнить переиндексацию (stock & fulltext). Для Mview создано множество триггеров MySQL. Увидеть их всех с SHOW TRIGGERS;.

Когда товара нет на складе после оформления заказа, вы увидите 2 строки, вставленные в эту таблицу (Magento сохраняет 2 товара на складе у этих 2 наблюдателей).

Когда cron запускает фондовый индексатор в режиме Mview, идентификаторы затронутых продуктов (в M2.1) или идентификаторы категорий (в 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 для indexer in Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexдолжно быть установлено на более чем 1 минуту.

mview.xmlИспользуется вместе с indexer.xmlдля установки индексаторами.

mview.xmlФайл объявляет:

• идентификатор представления индексатора
• класс индексатора
• таблица базы данных отслеживает индексатор
• какие данные столбца отправляются в индексатор

indexer.xmlФайл объявляет:

• идентификатор индексатора
• имя класса индексатора
• заголовок индексатора
• описание индексатора
• идентификатор представления индексатора

Вы можете найти больше информации о декларации пользовательского индексатора здесь: Пользовательский индексатор на Magento2

Из того, что я понял, здесь есть две разные вещи:

• Индексатор из Magento_Indexerмодуля
• Mview, из Magento\Framework\Mviewкоторого эмулируется материализованное представление для MySQL с использованием триггеров.

Вот небольшая информация из официальной документации

Типы индексации

Каждый индекс может выполнять следующие типы операций переиндексации:

• Полный переиндекс, что означает перестройку всех таблиц базы данных, связанных с индексированием.

• Полная переиндексация может быть вызвана различными причинами, включая создание нового интернет-магазина или новой группы клиентов. При желании вы можете в любой момент полностью переиндексировать с помощью командной строки.

• Частичная переиндексация, которая означает пересоздание таблиц базы данных только для вещей, которые изменились (например, изменение одного атрибута продукта или цены).

Тип переиндексации, выполняемой в каждом конкретном случае, зависит от типа изменений, внесенных в словаре или в системе. Эта зависимость специфична для каждого индексатора.

Что касается рабочего процесса, то здесь для частичной переиндексации:

Ссылка на документ 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.