마 젠토에서 인덱싱 작동 방식

1. 마 젠토에서 인덱싱 작동 방식
2. 정확히 무엇입니까?
3. 왜 필요한가요?

마 젠토에는 여러 종류의 색인이 있습니다.
모든 인덱서는 작업 속도를 높이기 위해 존재합니다.
여기서는 몇 가지만 다루겠습니다.

플랫 인덱스
이러한 인덱스는 2 가지가 있습니다. 하나는 범주와 하나는 제품입니다.
기본적으로 범주 및 제품 엔터티 (및 고객 및 고객 주소는이 상황에서 중요하지 않음)는 EAV 엔터티입니다. 이것은 확장성에 매우 좋습니다. 그러나 모든 속성에 대한 모든 값을 얻으려면 많은 조인이나 여러 쿼리가 필요하기 때문에 성능이 저하됩니다.
플랫 인덱서가 등장하는 곳입니다.
. EAV 구조를 플랫 구조로 변환합니다. 속성에 해당하는 하나의 열이있는 테이블 (마젠 토의 각 상점보기마다 하나씩)을 작성한다는 의미입니다. 이렇게하면 선택 속도가 빨라집니다. 범주의 경우 모든 특성이 테이블 열로 변환됩니다. 제품의 경우 속성이 다른 모든 유형의 제품을 판매 할 수 있고 가질 리언 열이있는 하나의 테이블을 만들 수 없기 때문에 '제품 목록에 사용됨'으로 표시 한 제품 만 가능하지 않을 수 있습니다.
또한 일부 제품이 비활성화되었거나 특정 웹 사이트에 속하지 않을 수 있으며 검색 할 항목에 해당 제품을 포함시킬 필요가 없습니다. 인덱서에서 제외됩니다.
생성 된 플랫 테이블은 프론트 엔드에서 데이터를 읽는 데 사용됩니다. 백엔드는 여전히 EAV 구조를 사용합니다.

카탈로그 검색 색인
많은 속성 값으로 제품을 검색 할 수 있습니다. 플랫 인덱서에서 생성 된 플랫 테이블에는 일부가 포함되지 않을 수 있습니다. 이 색인은 제품의 검색 가능한 속성 값으로 테이블을 채우므로 키워드를 기반으로 쉽게 찾을 수 있습니다. 하나의 테이블 (또는 하나의 필드)에 모든 정보가 있으면 전체 텍스트 검색을 사용하고 관련 결과를 얻을 수 있습니다.

제품 가격 .
제품 가격은 많은 변수의 영향을받을 수 있습니다. 예를 들어, 고객 그룹, 웹 사이트, 카탈로그 할인 규칙.
위와 동일하게 가격이 책정 된 제품을 얻는 것은 많은 조인 또는 여러 선택을 의미합니다. 또한 번들 제품에는 이상한 가격 시스템이 있습니다. 이 인덱서는 일부 테이블 ( catalog_product_index_price_*) 의 데이터를 집계하고 선택 (정렬 및 필터링)을 훨씬 쉽게 만듭니다.

카탈로그 URL 다시 쓰기
이것은 어떤 URL이 어떤 제품 또는 카테고리에 해당하는지 설정하여 URL 다시 쓰기 규칙을 정리합니다. URL 관리 내부 시스템이 비표준 URL을 호출 할 때 볼 페이지를 결정하는 것이 더 쉬운 방법입니다. 모든 제품 및 카테고리 URL 키를 검색하는 대신 하나의 테이블에서 검색합니다.

카테고리 제품
Magento에서 'Is Anchor'라는 카테고리 속성을 true 또는 false로 설정할 수 있습니다. 사실 인 경우 해당 카테고리에 하위 카테고리의 모든 제품이 나열됨을 의미합니다. 다시이 실시간을 결정하면 하나의 테이블을 읽는 것보다 더 많은 리소스가 필요합니다. 이 인덱서는 백엔드에서 설정 한 연관 및 카테고리의 'Is Anchor'플래그를 기반으로 제품과 카테고리 간의 연관을 작성합니다.

재고 상태
간단한 제품의 경우 쉽습니다. 재고가 있거나 재고가 없을 수 있지만 구성 가능한 그룹화 및 번들은 쉽지 않습니다. 주 제품과 관련된 하위 제품에 따라 재고가 있거나 재고가 없을 수 있습니다. 다시 말하지만 (여기서 스스로 반복하고 있습니다) 실시간으로 상태를 얻는 것은 많은 쿼리를 의미합니다.

제품 속성 .
이것은 동일한 이유로 계층 탐색에 사용될 수있는 모든 속성을 수집합니다. 더 빨리 읽을 수 있도록 한 곳에 보관하십시오.

태그 집계이 기능
이 무엇인지 잘 모르겠습니다. 실제 라이브 프로젝트에서 태그를 사용한 적이 없습니다.

https://stackoverflow.com/questions/4945307/can-someone-explain-magentos-indexing-feature-in-detail의 원래 게시물에서 가져 왔으므로 이에 대한 크레딧을받을 수 없습니다

Magento의 인덱싱은 데이터베이스 수준 인덱싱과 비슷합니다. Anton이 말했듯이 사이트를보다 빠르게 운영 할 수 있도록 비정규 화 프로세스입니다. Magento 데이터베이스 구조에 대한 몇 가지 생각과 왜 빠른 속도로 작동하기 위해 색인 생성이 필요한지 설명하겠습니다.

좀 더 "일반적인"MySQL 데이터베이스에서 카탈로그 제품을 저장하기위한 테이블은 다음과 같이 구성됩니다.

PRODUCT:
    product_id INT
    sku        VARCHAR
    name       VARCHAR
    size       VARCHAR
    longdesc   VARCHAR
    shortdesc  VARCHAR
    ... etc ...

검색 속도는 빠르지 만 전자 상거래 소프트웨어에는 근본적인 문제가 남아 있습니다. 속성을 더 추가하려면 어떻게해야합니까? 장난감을 판매하고 크기 열이 아닌 경우 age_range가 필요합니까? 글쎄, 다른 열을 추가 할 수는 있지만 큰 매장 (예 : Walmart)에서는 행이 90 % 비어 있고 새로운 속성을 유지하려고 시도하는 것이 거의 불가능하다는 것이 분명해야합니다.

이 문제를 해결하기 위해 Magento는 테이블을 더 작은 단위로 분할합니다. 이 답변에서 전체 EAV 시스템을 다시 만들고 싶지 않으므로이 단순화 된 모델을 수락하십시오.

PRODUCT:
    product_id INT
    sku        VARCHAR

PRODUCT_ATTRIBUTE_VALUES
    product_id   INT
    attribute_id INT
    value        MISC

PRODUCT_ATTRIBUTES
    attribute_id
    name

이제 product_attributes에 새 값을 입력 한 다음 인접한 레코드를 product_attribute_values에 넣어서 원하는대로 속성을 추가 할 수 있습니다. 이것은 기본적으로 Magento 가하는 것입니다 (여기에 표시된 것보다 데이터 유형에 약간의 관심이 있습니다). 실제로 두 제품이 동일한 필드를 가질 이유가 없으므로 속성 세트가 다른 전체 제품 유형을 만들 수 있습니다!

그러나이 유연성은 비용이 많이 듭니다. 내 시스템에서 셔츠의 색을 찾으려면 (사소한 예) 다음을 찾아야합니다.

1. 상품의 product_id (제품 표에 있음)
2. 색상의 attribute_id (속성 테이블에서)
3. 마지막으로 실제 값 (attribute_values ​​테이블)

마 젠토는 이런 식으로 작동했지만 느리게 죽었습니다. 따라서 더 나은 성능을 위해 타협점을 찾았습니다. 상점 소유자가 원하는 속성을 정의한 후에는 처음부터 큰 테이블을 생성하십시오. 무언가가 바뀌면 우주에서 핵무기를 만들어 다시 생성합니다. 이렇게하면 데이터가 기본적으로 유연한 형식으로 저장되지만 단일 테이블에서 쿼리됩니다.

이러한 결과 조회 테이블은 마 젠토 "인덱스"입니다. 색인을 다시 생성하면 이전 테이블이 불고 다시 생성됩니다.

그것이 약간의 내용을 명확히하기를 바랍니다!

마 젠토는 매우 강력하고 복잡한 시스템입니다. 방대한 양의 데이터로 작업 할 수 있지만 데이터베이스에 많은 레코드가 오버로드되면 무겁고 느려집니다. Magento는 색인을 사용하여이 문제를 해결합니다. 인덱스는 데이터가 평평한 추가 데이터베이스 테이블로, 데이터베이스에서 빠른 응답을 구성 할 수 있습니다.

기본적으로 핵심 시스템은 각 항목 저장시 인덱스를 업데이트합니다. 그러나 일부 유형의 대량 작업 등과 같이 일부 경우 수동으로 수행해야합니다. 관리자 백엔드 (관리자-> 시스템-> 인덱스 관리)에서 언제든지 인덱스를 업데이트 할 수 있습니다. 그러나 때때로 문제가 발생합니다.

예를 들어 10k + 이상의 제품과 많은 카테고리가있는 경우 '카탈로그 URL 다시 쓰기'색인을 다시 작성하는 데 몇 시간이 걸릴 수 있습니다. 그런 다음 max_execution_time 초과로 인해 PHP 스크립트가 중단 될 수 있습니다. 명령 행에서 재색 인 프로세스를 실행하여 여러 문제점을 해결하는 방법이 있습니다.