상점이 있으며 항상 모든 색인이 유효하지 않습니다. 색인이 무효화 될 때 단서가 없다는 것을 알았습니다.
이 인덱스 중 하나 이상이 유효하지 않게 만드는 "모든"이벤트 목록을 제공해 주시겠습니까?
- 제품 속성
- 제품 가격
- 카탈로그 URL 재 작성
- 제품 플랫 데이터
- 카테고리 제품
- 카탈로그 검색 색인
- 태그 집계 데이터
- 재고 상태
상점이 있으며 항상 모든 색인이 유효하지 않습니다. 색인이 무효화 될 때 단서가 없다는 것을 알았습니다.
이 인덱스 중 하나 이상이 유효하지 않게 만드는 "모든"이벤트 목록을 제공해 주시겠습니까?
답변:
코드 디렉토리에서 grep을 수행하면 무효화를 트리거하는 파일 목록이 표시됩니다.
grep -Ri '::STATUS_REQUIRE_REINDEX' .
다음 코어 파일은 무효화를 트리거합니다
./core/Mage/CatalogSearch/Model/Indexer/Fulltext.php
./core/Mage/Catalog/Model/Product/Indexer/Flat.php
./core/Mage/Catalog/Model/Product/Indexer/Price.php
./core/Mage/Catalog/Model/Category/Indexer/Flat.php
./core/Mage/Catalog/Model/Category/Indexer/Product.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Product/Flat.php
./core/Mage/Catalog/Model/System/Config/Backend/Catalog/Category/Flat.php
./core/Mage/Catalog/Model/Indexer/Url.php
./core/Mage/Backup/Helper/Data.php
./core/Mage/CatalogInventory/Model/Indexer/Stock.php
./core/Mage/ImportExport/Model/Import.php
Magento CE 코어의 기본 이벤트는 다음과 같습니다.
제품 속성
플랫 카탈로그 제품이 사용 가능한 경우 특정 저장 속성 (플랫 제품의 일부 임), store, store_group
제품 가격
구성 설정 확인 (예 : 가격 범위). 또는 제품 저장, 웹 사이트 생성 / 삭제
카탈로그 URL 재 작성
특정 무효화 없음
제품 플랫 데이터
플랫 카탈로그 제품이 사용 가능한 경우 특정 저장 속성 (플랫 제품의 일부 임), 플랫 제품 사용 후
카테고리 플랫 데이터
플랫 카탈로그 카테고리가 사용 가능하고 특정 저장 카테고리가 있는지 확인하십시오. 플랫 카테고리를 사용한 후
카테고리 제품
플랫 카탈로그 카테고리가 사용 가능하고 특정 저장 카테고리가 있는지 확인하십시오.
카탈로그 검색 색인
플랫 카탈로그 제품이 사용 가능한 경우 특정 저장 속성 (검색 가능한 속성의 일부 임), store, store_group
태그 집계 데이터
아래에 언급 된 일반적인 조건을 제외하고는 무효화되지 않습니다
재고 상태
인벤토리 탭의 특정 시스템> 구성 설정 저장, 예를 들어 재고가없는 제품 표시
System > Tools > Backup제품에서 데이터 흐름 가져 오기를 실행 한 후 catalog_product_price, catalog_category_product, catalogsearch_fulltext, catalog_product_flat 은 백업에서 롤백 후 웹 사이트, 상점 및 상점보기 에서 작성, 삭제 또는 이동 후 모두 무효화됩니다.
플랫 데이터 및 URL 인덱서와 같은 여러 인덱서도 core_config_data값 을 저장하여 무효화되는 것으로 보입니다 .
이 사이트의 임시 재 작성을 작성하는 것이 좋습니다.
Mage_Index_Model_Resource_Process
그런 다음 다음과 같이하십시오.
<?php
class YourNamespace_YourModule_Model_Resource_Process
extends Mage_Index_Model_Resource_Process
{
public function updateStatus($process, $status)
{
if ($status === Mage_Index_Model_Process::STATUS_REQUIRE_REINDEX) {
Mage::log(sprintf('Indexer %s was invalidated.', $process->getIndexer()->getName()), null, 'invalid_index.log', true);
foreach (debug_backtrace() as $db) {
Mage::log(sprintf('%s::%s', $db['class'], $db['function']), null, 'invalid_index.log', true);
}
}
return parent::updateStatus($process, $status);
}
}
인덱서가 무효화되는 시점과이를 담당하는 호출 추적을 쉽게 찾아 낼 수 있습니다.
다른 사람들이 이미 귀하의 질문에 구체적으로 답변했기 때문에. 인덱싱이 왜 필요한지, 그리고 그것이 Magento와 어떻게 관련이 있는지 그리고 현대 데이터베이스와의 관계를 설명하는 것이 더 나을 것이라고 생각했습니다 .
색인 : 이름, 주제 등의 알파벳순 목록으로, 일반적으로 책 끝에서 발견되는 장소를 참조합니다.
그렇다면 데이터베이스 측면에서 인덱스는 정확히 무엇 입니까?
인덱스는 하나 이상의 필드에서 여러 레코드를 정렬하고 데이터 검색 속도를 높이는 데이터 구조입니다. 이는 데이터베이스를 검색 할 때 테이블에 걸쳐있는 디스크 블록을 통한 스캔을 피하기위한 것입니다.
그리고 마젠 토의 관점에서 인덱싱이란 무엇 입니까? EAV (Entity Attribute Value)의 부산물은 데이터베이스 내의 데이터베이스입니다. 조회 테이블이 여러 개인 경우 인덱스로 플래그가 지정된 모든 속성을 수집하여 모든 조회 테이블의 하나의 플랫 테이블로 결합하여 쿼리 속도를 높이고 I / O 및 CPU주기를 줄입니다.
Magento를 처음 개발할 때 우선 순위 목록에서 유연성이 높았 기 때문에 EAV 데이터 모델을 사용하기로 선택한 이유를 이해할 수 있습니다. 그러나 궁극적으로 이러한 유연성의 비용은 성능 비용으로 발생했으며 처음부터 Magento를 괴롭 혔습니다.
일반적으로 Magento 엔지니어는 가장 유연하고 사용자 정의 가능한 시스템을 구축하고 나중에 성능에 대해 걱정해야합니다. 마 젠토가 왜 이렇게 느린가요?
EAV는 데이터웨어 하우징에는 적합하지만 트랜잭션에는 끔찍합니다. 그렇다면 왜 인덱스가 필요합니까? 관계형 모델에 대한 동일한 접근 방식이 다시 구현되었으므로 이제 Magento는 MySQL 자체에서 내부적으로 수행하는 모든 작업을 처리해야합니다. MySQL 테이블에 이미 존재하는 인덱스와 같이 고려해야 할 사항 이를 염두에두고 지금 EAV 데이터 모델을 고려하십시오.
동일하게 다시 구현해야하는데 이는 매우 "반 패턴"IMO입니다.
또한,이 같은 이유는 찾을 var/locks하는 인덱서가 사용하는 잠금 인덱싱 프로세스를. 데이터베이스에 행 / 테이블 잠금이있는 동일한 이유.
이제 레코드가 변경되면 제품 값이 변경되었다고 말 flat table하거나 index(MySQL에서 참조하는 것과 같이) 여러 레코드를 스캔하지 않고 새로 변경된 데이터에 대한 쿼리를 신속하고 효율적으로 찾을 수 있도록 업데이트해야합니다. 플랫 테이블은 책과 같은 인덱스없이 MySQL이 가지고있는 것과 동일한 이유로 사용되므로 레코드를 검색하기 위해 전체 테이블 스캔이 필요합니다. 이는 요청 된 데이터를 찾기위한 CPU주기뿐만 아니라 디스크 및 메모리 모두에 대한 막대한 양의 I / O를 의미하며 이는 성능이 매우 나쁩니다.
Magento는 EAV 데이터 모델을 사용하기 때문에 요청 된 데이터를 찾기 위해 모든 데이터를한데 모으기 위해 스캔해야하는 수많은 조회 테이블이 있습니다. 이는 Flat 카탈로그를 사용하지 않는 경우에 발생합니다. MySQL과 마찬가지로, 레코드를 스캔하고 인덱스 (플랫 테이블)를 사용하여 소중한 I / O주기를 유지하면서 레코드를 신속하게 찾을 수 있습니다. 테이블을 생성하고 인덱스를 추가하지 않는 것은 magento에서 플랫 테이블을 사용하지 않는 것과 같습니다. 이 두 시나리오는 서로 다른 시나리오에서 잘 작동 할 수 있지만 이 질문에 대한 Sonassi의 훌륭한 답변 인 Ben을 참조하십시오 . (데이터 범위를 이해하는 것과 관련이 있습니다.)
귀하의 질문에 대한 직접적인 대답은 아니지만 움직이는 부분을 이해하고 더 잘 준비하면 색인 작성과 함께 발생하는 두통을 완화하는 데 도움이됩니다. " 증상보다는 문제를 치료하십시오. "
최신 데이터베이스 시스템의 내부를 자세히 살펴보면 인덱싱이 필요한 방법과 이유 및 이것이 어떻게 Magento의 인덱싱과 어떤 관련이 있는지 이해하는 데 도움이 될 수 있습니다.
요약 : 솔루션을 맹목적으로 적용하기 전에 문제 범위를 이해하십시오. 모든 데이터 비트가 정확히 동일하지는 않으며 솔루션을 계획하고 구현 한 후에 는 문제에 대한 이해가 충분합니다. 데이터베이스 최적화는 변경 관리에 큰 도움이 될 수 있습니다. 공포를 예방하는 등 DEADLOCKS.
Manual사용량이 적은 시간에 (관리자가 부재 할 때) 인덱스를 다시 작성하기 위해 모든 인덱서를 설정하고 대체 프로세스를 설정하는 것이 좋습니다. 만 Product Prices및 Stock Status설정해야합니다 Update on Save.
이제 기술적 인 관점에서 인덱싱 작동 방식을 고려하십시오. 메인 모듈은 인덱싱을 담당합니다 Mage_Index. 인덱서의 기본 모델 : Indexer, Process, Event.
Mage_Index_Model_Indexer인덱서, 다른 모듈 모듈과의 모든 상호 작용은 Mage_Index이 서비스를 통해 발생합니다. 다음과 같은 방법이 있습니다.
processEntityAction() 이벤트를 생성 및 등록하고 인덱싱 프로세스를 시작합니다logEvent() 이벤트를 작성하고 후속 색인 작성을 위해 등록하십시오.indexEvent() 인덱싱 이벤트를 실행합니다.getProcessesCollection()제품 속성, 제품 가격, 카탈로그 URL 재 작성 등과 같은 모든 프로세스의 콜렉션을 리턴합니다. 일반적으로 메소드와 같은 본질을 변경 한 후 _afterSave또는 _afterCommit부분 재 인덱싱을 수행합니다.Mage_Index_Model_Process또는 프로세스는 인덱서의 본질이다 저장하는 상태, 마지막 실행 작업. 모든 프로세스는 테이블에 저장됩니다 index_process. 이 프로그램에는 getIndexer()모델의 인덱스를 반환 하는 메소드 가 있습니다. 인덱스 모델 프로세스에서 위임 한 대부분의 작업
Mage_Index_Model_Event발생한 이벤트에 대한 정보를 저장합니다. 예를 들어, 우리는 제품을 저장하고 저장 한 후 새로운 이벤트를 생성하고 방금 저장 한 엔티티 유형에 대해 어떤 ID가 정신을 가지고 있으며이 물질에 대해 수행 한 조치에 대한 정보를 저장합니다.
무효화가 발생하는 일반적인시기 목록 :
config.xml트랜잭션 저장시 모듈에 색인이 등록 된 모든 자원 모델 . afterCommitCallback()접두사로 호출됩니다. 트랜잭션이 완료 되었기 때문에 인덱스 이벤트가 기록되는 위치입니다.
... 그리고 Eagent가 여전히 Magento 2에 있다는 것은 슬프다.
참고 문헌 :