Apa yang dimaksud dengan mview di magento2?

Pertama-tama yang saya tahu:

Manajemen indeks berguna untuk meningkatkan kinerja toko.

EAV memiliki satu kelemahan. itu akan menyimpan data ke dalam tabel yang berbeda. sehingga pengambilan data memakan waktu.

Sehingga kami akan menyimpan data ke dalam satu tabel. ketika data diubah, kami akan memperbarui tabel tunggal ini (tidak lain dari pembaruan pengindeksan)

mysql trigger: melakukan beberapa tindakan kueri berdasarkan beberapa tabel sisipkan / perbarui / hapus.

Jadi magento menggunakan pemicu misalnya ketika harga memperbarui itu akan menyimpan entity_idke tabel changelog.

ada pernyataan di devdocs untuk menerapkan pemicu penggunaan magento2 Magento/Framework/Mview.

dapatkah Anda menjelaskan aliran fungsi ini?

Maksudku apa view, action, processordll?

Dalam dokumentasi resmi: https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html ada stement:

`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 adalah singkatan dari Materialized View yang merupakan snapshot dari database pada suatu titik waktu. https://en.wikipedia.org/wiki/Materialized_view Mengapa kita perlu menduplikasi tabel. Pengindeks mahal untuk dijalankan, terutama ketika ada lalu lintas pada halaman kategori, pelanggan memesan dan admin menyimpan produk. Pada produk, menyimpan cache menjadi tidak valid (di luar topik). Dalam hal pengindeks stok, sebelum mengakhiri eksekusi, ia akan mengirim id entitas yang terpengaruh sebagai tag cache untuk dibersihkan (tipe cache halaman penuh). Di Magento 2.0 kategori id produk yang dibeli dikirim. Di Magento 2.1 id produk dikirim.

Ada 2 tabel MySQL yang menyimpan kode dan status pengindeks:

• indexer_state
• mview_state

mview_stateberfungsi dengan Update by Scheduledi Admin> Sistem> Manajemen Pengindeks

Update by Schedule membuat pengindeks dijalankan di cron.

Ada 3 entri di 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_invaliddijalankan indexer_state. Masih ada kebutuhan untuk menjalankan pengindeks 'normal' di cron
• indexer_update_all_views dijalankan mview_state
• indexer_clean_all_changelogs - Menghapus changelog yang digunakan oleh mview_state

Perhatikan bahwa tugas-tugas kelompok cron pengindeks berjalan dalam proses php terpisah, sebagaimana dinyatakan dalam etc/contab_groups.xml: <use_separate_process>1</use_separate_process>.

Tabel changelog adalah: [indexer name]_cl(diakhiri dengan _cl). mis cataloginventory_stock_cl. Jika Anda memiliki pengindeks diatur ke Update by Scheduledan menyimpan produk di admin Anda akan melihat entity_idproduk itu dalam tabel ini. Ini lingkaran besar, saya pikir pesanan tempat atau membuat pengiriman akan menambahkan entri di sini juga.

Seseorang memberikan contoh di devdoc resmi tentang cara membuat tampilan terwujud baru dan apa saja metode antarmuka yang diperlukan (abaikan pernyataan di atas tentang pesanan dalam snippet di bawah):

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

Ini masuk akal: //public function execute($ids); Used by mview, allows you to process multiple **entities** in the "Update on schedule" mode } Di mana $idsparameter memiliki id entitas dari *_cltabel.

Apa hubungan antara pembatalan cache dan pengindeks. Halaman kategori sekarang di-cache halaman penuh (cache halaman penuh built-in atau melalui Varnish).

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

Kembali ke 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');
}

Di app/etc/di.xmlsana ada:

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

Di Magento\Framework\Mview\View::update()sana ada:

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

Jika Anda mencari di vendor/direktori untuk Magento\Framework\Mview\ActionInterfaceAnda akan menemukan misalnya ini:

Di \Magento\CatalogInventory\Model\Indexer:

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

Di kelas ini ada:

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

Dan sepertinya kembali ke metode 'eksekusi' kelas 'pengindeks' yang digunakan oleh MView.

Tentang pembersihan cache setelah Stock Indexer. Ketika pesanan dilakukan pada checkout, jumlah dikurangi menggunakan pengamat ini:\Magento\CatalogInventory\Observer\SubtractQuoteInventoryObserver

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

Lebih lanjut, pengamat lain memicu pengindeks (tetapi tidak secara langsung pada Mview / Pengindeks berdasarkan Jadwal): \Magento\CatalogInventory\Observer\ReindexQuoteInventoryObserver

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

Dalam kasus Mview, ketika jumlah baru dikurangi SubtractQuoteInventoryObserver, pemicu MySQL (dibuat untuk Mview) akan memasukkan baris cataloginventory_stock_cl, menandai bahwa pengindeksan ulang (stok & teks lengkap) perlu dilakukan untuk id produk yang dibeli. Ada banyak pemicu MySQL yang dibuat untuk Mview. Lihat semuanya SHOW TRIGGERS;.

Ketika suatu produk kehabisan stok setelah checkout Anda akan melihat 2 baris dimasukkan dalam tabel itu (Magento menyimpan 2 kali stok item dalam 2 pengamat ini).

Ketika cron menjalankan stock indexer dalam mode Mview, id produk yang terpengaruh (dalam M2.1) atau id kategori (dalam M2.0) dikirim ke cache bersih sebagai tag cache. Yang saya maksud dengan cache adalah jenis cache halaman penuh. Contoh: catalog_product_99atau format tag cache lainnya tergantung pada versi Magento. Sama ketika Mview tidak diaktifkan.

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

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

Dan Magento_PageCache memiliki pengamat \Magento\PageCache\Observer\FlushCacheByTagsyang akan membersihkan jenis cache halaman penuh dengan tag. Itu melakukannya untuk buil-in cache halaman penuh. Kode terkait pernis ada di \Magento\CacheInvalidate\Observer\InvalidateVarnishObserver.

Ada ekstensi gratis yang akan menolak pembersihan cache dari masih dalam stok produk setelah checkout pelanggan:

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

Pembersihan cache hanya pada produk yang tidak tersedia setelah checkout diperkenalkan di Magento 2.2.x default Lihat \Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner.

Saya pikir eksekusi cron untuk pengindeks Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: indexharus diatur lebih dari 1 menit.

The mview.xmldigunakan bersama dengan indexer.xmlke pengindeks setup.

The mview.xmlFile menyatakan:

• ID tampilan pengindeks
• kelas pengindeks
• database tabel trek pengindeks
• data kolom apa yang dikirim ke pengindeks

The indexer.xmlFile menyatakan:

• ID pengindeks
• nama kelas pengindeks
• judul pengindeks
• deskripsi pengindeks
• ID tampilan pengindeks

Anda dapat menemukan informasi lebih lanjut tentang deklarasi pengindeksan kustom di sini: Custom indexer di Magento2

Dari apa yang saya mengerti, ada dua hal berbeda di sini:

• Pengindeks dari Magento_Indexermodul
• Mview Magento\Framework\Mviewyang mengemulasi tampilan terwujud untuk MySQL menggunakan pemicu.

Berikut adalah beberapa info terukir dari dokumentasi resmi

Jenis pengindeksan

Setiap indeks dapat melakukan jenis operasi pengindeksan berikut:

• Reindex penuh, yang berarti membangun kembali semua tabel basis data terkait pengindeksan.

• Pengindeksan ulang penuh dapat disebabkan oleh berbagai hal, termasuk membuat toko web baru atau grup pelanggan baru. Secara opsional Anda dapat mengindeks ulang sepenuhnya kapan saja menggunakan baris perintah.

• Reindex parsial, yang berarti membangun kembali tabel database hanya untuk hal-hal yang berubah (misalnya, mengubah atribut atau harga produk tunggal).

Jenis indeks yang dilakukan dalam setiap kasus tergantung pada jenis perubahan yang dibuat dalam kamus atau dalam sistem. Ketergantungan ini khusus untuk setiap pengindeks.

Mengenai Alur Kerja, ini dia untuk pengindeksan ulang sebagian:

Referensi dari dokumen Magento sudah ada di sini jadi saya melewatkan bagian itu.
Magento mengimplementasikan tampilan terwujud dalam 2.0 yang melacak perubahan untuk semua pengindeks. Setiap pengindeks memiliki _cltabel yang mendapat entity_iddan auto_increment version_iddari pemicu ditambahkan pada tabel utama.
Ketika cron job dijalankan, indexer menjadi yang terakhir version_iduntuk setiap tampilan dari mview_statetabel dan mengindeks entitas yang tersedia berikutnya dalam _cltabel.
Reindexing adalah sakit kepala sampai 1.9.xx dan dengan katalog besar itu selalu memperlambat sistem.
Dalam pengindeks Magento 2.0 hanya memperbarui informasi entitas tertentu pada tabel pengindeks daripada mengindeks ulang seluruh data. Ini membuat bola terus bergulir tanpa memperlambat server.
Catatan: Tampilan Terwujud tidak didukung di mysql jadi di Magento, ini dikelola oleh kode PHP dan bekerja mirip dengan tampilan Terwujud yang merupakan fitur dalam DBMS tingkat perusahaan seperti oracle.