o que é mview no magento2?

Primeiro de tudo o que eu sei:

O gerenciamento de índice é útil para aumentar o desempenho da loja.

EAV tem uma desvantagem. ele armazenará dados em tabelas diferentes. para que a recuperação de dados consuma tempo.

Para que possamos armazenar dados em uma única tabela. quando os dados forem alterados, atualizaremos esta tabela única (nada além de atualização de indexação)

mysql trigger: execute algumas ações de consulta com base em alguma inserção / atualização / exclusão de tabela.

Então, o magento usando trigger, por exemplo, quando o preço está atualizando, será armazenado entity_idna tabela de registros de alterações.

existe uma declaração no devdocs para implementar gatilhos usando o magento2 Magento/Framework/Mview.

você pode explicar o fluxo dessa funcionalidade?

eu quero dizer o que é view, action, processoretc?

Na documentação oficial: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html , está o seguinte:

`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 significa Materialized View, que é um instantâneo do banco de dados em um determinado momento. https://en.wikipedia.org/wiki/Materialized_view Por que precisamos duplicar tabelas. Os indexadores são caros para executar, especialmente quando há tráfego nas páginas de categorias, os clientes fazem pedidos e os administradores salvam produtos. No produto salvo, o cache é invalidado (fora do tópico). No caso do indexador de ações, antes de finalizar a execução, ele envia os IDs da entidade afetados como tags de cache a serem limpos (tipo de cache de página inteira). Nas categorias Magento 2.0, os IDs dos produtos comprados são enviados. No Magento 2.1, os IDs do produto são enviados.

Existem 2 tabelas MySQL que mantêm códigos e status do indexador:

• indexer_state
• mview_state

mview_statetrabalha com Update by Scheduleem Admin> Sistema> Gerenciamento do Indexador

Update by Schedule faz com que os indexadores sejam executados no cron.

Existem 3 entradas em 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é executado indexer_state. Ainda há a necessidade de executar indexadores 'normais' no cron
• indexer_update_all_views é executado em mview_state
• indexer_clean_all_changelogs - limpa os registros de alterações usados ​​por mview_state

Note-se que as tarefas de grupo cron indexador executado em um processo php separado, conforme declarado em etc/contab_groups.xml: <use_separate_process>1</use_separate_process>.

As tabelas de alterações são: [indexer name]_cl(com o sufixo _cl). por exemplo cataloginventory_stock_cl. Se você tiver indexadores definidos para Update by Schedulee salvar um produto no administrador, verá o entity_idproduto nessa tabela. É um grande círculo, estou pensando que fazer um pedido ou criar uma remessa também adicionará uma entrada aqui.

Alguém forneceu um exemplo no devdoc oficial sobre como criar novas visualizações materializadas e quais são os métodos de interface necessários (desconsidere a declaração acima sobre pedidos no snippet abaixo):

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

Isso fará sentido: //public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode } Onde o $idsparâmetro possui os IDs de entidades das *_cltabelas.

Qual é o link entre a invalidação de cache e os indexadores. As páginas de categorias agora estão em cache de página inteira (cache de página inteira interno ou através do Varnish).

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

Voltar para 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');
}

Em app/etc/di.xmlexiste:

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

Em Magento\Framework\Mview\View::update()existe:

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

Se você pesquisar no vendor/diretório, Magento\Framework\Mview\ActionInterfaceencontrará, por exemplo, o seguinte:

Em \Magento\CatalogInventory\Model\Indexer:

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

Nesta classe há:

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

E parece que ele volta à classe 'normal' de indexadores 'execute` método que é usado pelo MView.

Sobre a limpeza do cache após o Stock Indexer. Quando um pedido é feito no check-out, as quantidades são subtraídas usando este observador:\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver

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

Além disso, outro observador aciona o indexador (mas não diretamente no Mview / Indexer por Schedule): \Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver

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

No caso do Mview, quando as novas quantidades forem subtraídas SubtractQuoteInventoryObserver, o gatilho MySQL (criado para o Mview) inserirá uma linha cataloginventory_stock_cl, marcando que uma reindexação (estoque e texto completo) precisa ser feita com os IDs de produtos adquiridos. Existem muitos gatilhos MySQL criados para o Mview. Veja todos eles com SHOW TRIGGERS;.

Quando um produto fica fora de estoque após o checkout, você vê 2 linhas inseridas nessa tabela (o Magento economiza 2 vezes o item em estoque nesses 2 observadores).

Quando o cron executa o indexador de ações no modo Mview, os IDs de produtos afetados (em M2.1) ou de categorias (em M2.0) são enviados para o cache limpo como tags de cache. Por cache, quero dizer o tipo de cache de página inteira. Exemplo: catalog_product_99ou outro formato de tag de cache, dependendo da versão do Magento. O mesmo quando o Mview não está ativado.

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

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

E o Magento_PageCache possui um observador \Magento\PageCache\Observer\FlushCacheByTagsque limpará o tipo de cache de página inteira por tags. Faz isso para armazenar em cache de página inteira. O código relacionado ao verniz está em \Magento\CacheInvalidate\Observer\InvalidateVarnishObserver.

Existe uma extensão gratuita que negará que o cache seja limpo em produtos ainda em estoque após o checkout do cliente:

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

Limpeza de cache apenas em produtos fora de estoque após a introdução do checkout no Magento 2.2.x padrão. Veja \Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner.

Eu estou pensando que a execução cron para indexador em Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexdeve ser definida para muito mais de 1 minuto.

O mview.xmlé usado junto com indexer.xmlpara configurar indexadores.

O mview.xmlarquivo declara:

• ID da visualização do indexador
• classe de indexador
• as tabelas de banco de dados que o indexador rastreia
• quais dados da coluna são enviados para o indexador

O indexer.xmlarquivo declara:

• ID do indexador
• nome da classe do indexador
• título do indexador
• descrição do indexador
• ID da visualização do indexador

Você pode encontrar mais informações sobre a declaração do indexador personalizado aqui: Indexador personalizado no Magento2

Pelo que entendi, há duas coisas diferentes aqui:

• O indexador do Magento_Indexermódulo
• O Mview a partir do Magento\Framework\Mviewqual emula a visão materializada do MySQL usando gatilhos.

Aqui estão algumas informações publicadas na documentação oficial

Tipos de indexação

Cada índice pode executar os seguintes tipos de operações de reindexação:

• Reindexação completa, o que significa reconstruir todas as tabelas de banco de dados relacionadas à indexação.

• A reindexação total pode ser causada por uma variedade de coisas, incluindo a criação de uma nova loja virtual ou novo grupo de clientes. Você pode opcionalmente reindexar totalmente a qualquer momento usando a linha de comando.

• Reindexação parcial, que significa reconstruir as tabelas do banco de dados apenas para as coisas que mudaram (por exemplo, alterar um único atributo ou preço do produto).

O tipo de reindexação realizado em cada caso específico depende do tipo de alterações feitas no dicionário ou no sistema. Essa dependência é específica para cada indexador.

Em relação ao fluxo de trabalho, aqui está a reindexação parcial:

A referência do documento Magento já está aqui, então estou pulando essa parte.
O Magento implementou a visualização materializada na versão 2.0, que rastreia as alterações para todos os indexadores. Cada indexador possui uma _cltabela que recebe entity_ide um auto_increment version_iddos gatilhos adicionados nas tabelas principais.
Quando a tarefa cron é executada, o indexador fica em último version_idpara cada visualização da mview_statetabela e indexa as próximas entidades disponíveis na _cltabela.
Reindexar foi uma dor de cabeça até 1.9.xx e com um catálogo enorme, sempre diminuiu a velocidade do sistema.
No indexador Magento 2.0, atualize apenas as informações da entidade específica nas tabelas do indexador, em vez de reindexar os dados inteiros. Isso mantém a bola rolando sem diminuir a velocidade do servidor.
Nota: O Materialized View não é suportado no mysql, portanto, no Magento, ele é gerenciado pelo código PHP e funciona de forma semelhante ao Materialized view, que é um recurso no DBMS de nível empresarial, como o Oracle.