우선 내가 아는 것 :
인덱스 관리는 상점 성능을 높이는 데 유용합니다.
EAV 데이터를 다른 테이블에 저장하므로 데이터를 검색하는 데 시간이 오래 걸립니다.
데이터를 단일 테이블에 저장합니다. 데이터가 변경되면이 단일 테이블을 업데이트합니다 (인덱싱 업데이트 제외).
mysql trigger: 일부 테이블 삽입 / 업데이트 / 삭제를 기반으로 일부 쿼리 작업을 수행합니다.
따라서 가격이 업데이트 될 때 트리거를 사용하는 magento는 entity_idchangelog 테이블에 저장 됩니다.
devdocs에는를 사용하여 magento2 트리거를 구현하는 명령문이 Magento/Framework/Mview있습니다.
이 기능의 흐름을 설명 할 수있는 사람이 있습니까?
내가 무엇을 의미 view, action, processor등?
답변:
공식 문서 : https://devdocs.magento.com/guides/v2.3/extension-dev-guide/indexing.html 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는 특정 시점의 데이터베이스 스냅 샷 인 구체화 된보기를 나타냅니다. https://en.wikipedia.org/wiki/Materialized_view 왜 테이블을 복제해야합니까? 인덱서는 특히 카테고리 페이지에 트래픽이있는 경우 고객이 주문을하고 관리자가 제품을 저장하는 경우 비용이 많이 듭니다. 제품 저장시 캐시가 무효화됩니다 (주제 외). 주식 인덱서의 경우 실행을 끝내기 전에 정리할 캐시 태그로 영향을받는 엔티티 ID를 전송합니다 (전체 페이지 캐시 유형). Magento 2.0 카테고리에서는 구매 한 제품의 id가 전송됩니다. Magento 2.1에서는 제품 ID가 전송됩니다.
인덱서 코드와 상태를 유지하는 2 개의 MySQL 테이블이 있습니다.
indexer_statemview_statemview_stateUpdate by Schedule관리자> 시스템> 인덱서 관리에서 작동
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_stateindexer_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테이블을.
캐시 무효화와 인덱서 사이의 링크는 무엇입니까? 카테고리 페이지는 이제 전체 페이지 캐시 (내장 전체 페이지 캐시 또는 바니시를 통해)됩니다.
있습니다 \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);
}그리고 그것은 MView가 사용하는 '정상적인'인덱서 클래스의 execute` 메소드로 되돌아가는 것처럼 보입니다.
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의 경우 새 수량이에서 빼면 SubtractQuoteInventoryObserverMySQL 트리거 (Mview 용으로 생성)가에 행을 삽입하여 cataloginventory_stock_cl구매 한 제품 ID 에 재색 인 (재고 및 전체 텍스트)을 수행해야 함을 표시합니다. Mview를 위해 생성 된 많은 MySQL 트리거가 있습니다. 로 모두 확인하십시오 SHOW TRIGGERS;.
결제 후 제품의 재고가 부족하면 해당 테이블에 2 개의 행이 삽입 된 것을 볼 수 있습니다 (Magento는이 두 관찰자에 재고 항목을 2 배 절약합니다).
cron이 Mview 모드에서 주식 인덱서를 실행할 때 영향을받는 제품 ID (M2.1) 또는 카테고리 ID (M2.0)는 캐시 태그로 캐시를 깨끗하게 캐시하기 위해 전송됩니다. 캐시는 전체 페이지 캐시 유형을 의미합니다. 예 : catalog_product_99또는 마 젠토 버전에 따른 기타 캐시 태그 형식. 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 실행 Admin > Stores > Configuration > Advanced > System > Cron configuration options for group: index이 1 분 이상으로 설정되어야한다고 생각합니다 .
mview.xml과 함께 사용indexer.xml 설정 인덱서합니다.
mview.xml파일 선언
indexer.xml파일 선언
사용자 정의 인덱서 선언에 대한 자세한 내용은 다음을 참조하십시오. Magento2의 사용자 정의 인덱서
내가 이해 한 바에 따르면 두 가지 다른 점이 있습니다.
Magento_Indexer모듈 의 인덱서Magento\Framework\Mview트리거를 사용하여 MySQL의 구체화 된 뷰를 에뮬레이트합니다.각 색인은 다음 유형의 재색 인 작업을 수행 할 수 있습니다.
전체 재 인덱싱-모든 인덱싱 관련 데이터베이스 테이블을 다시 작성해야합니다.
전체 재색 인화는 새 웹 스토어 또는 새 고객 그룹 작성을 포함하여 다양한 요인으로 인해 발생할 수 있습니다. 명령 행을 사용하여 언제든지 선택적으로 전체 색인을 다시 작성할 수 있습니다.
부분 재 인덱싱-변경된 사항 (예 : 단일 제품 속성 또는 가격 변경)에 대해서만 데이터베이스 테이블을 다시 작성하는 것을 의미합니다.
각각의 특정 경우에 수행되는 재색 인 유형은 사전 또는 시스템의 변경 유형에 따라 다릅니다. 이 종속성은 각 인덱서에 따라 다릅니다.
워크 플로와 관련하여 다음은 부분 재 인덱싱을위한 것입니다.
Magento 문서의 참조가 이미 여기 있으므로 해당 부분을 건너 뜁니다.
Magento는 2.0에서 구체화 된 뷰를 구현하여 모든 인덱서의 변경 사항을 추적합니다. 각 인덱서에는 기본 테이블에 추가 된 트리거 와 _cl가져 오는 테이블이 있습니다.
크론 작업이 실행될 때 인덱서는 테이블 에서 각 뷰에 대해 마지막 으로 가져오고 테이블에서 사용 가능한 다음 엔티티를 인덱스 합니다.
참고 : 구체화 된보기는 mysql에서 지원되지 않으므로 Magento에서는 PHP 코드로 관리되며 oracle과 같은 엔터프라이즈 수준의 DBMS의 기능인 구체화 된보기와 유사하게 작동합니다.entity_idauto_increment version_idversion_idmview_state_cl
재색 인화는 1.9.xx까지 골치 거리였으며 카탈로그가 크면 항상 시스템 속도가 느려졌습니다.
Magento 2.0 인덱서는 전체 데이터를 다시 인덱싱하지 않고 인덱서 테이블의 특정 엔티티 정보 만 업데이트합니다. 이렇게하면 서버 속도가 느려지지 않고 볼이 계속 굴러갑니다.
Mview참조 하십시오 .