일반적인 색인 문제에 대한 영구 솔루션


23

우리는 큰 재고 기록을 가진 일부 마 젠토 프로젝트를 개발했으며 항상 평평한 테이블을 자르고 CLI를 사용하여 색인을 다시 작성하고 인덱싱이지만 인덱싱 문제가 발생하는 일상적인 두통입니다.

우리는이 문제에 대한 영구적 인 해결책을 찾고 있습니다. 프로젝트를 수행하는 동안 매일 제품을 업데이트하거나 매일 다른 피드에서 제품을 가져 오는 것과 같은 다른 시나리오가 있습니다.

이 방법이나 일부 해결 방법으로 모범 사례를 가진 사람은 많은 사람들에게 감사의 말을 전하십시오.


나는 Magento와 그 확장 및 매우 비효율적이고 바보 같은 데이터 아키텍처에서 1 년을 낭비했으며 10K 플러스 제품만으로 전자 상거래 사이트를 만들었습니다. 이 모든 경고는 Magento CE를보기 시작한 사람에게 제공되어야합니다. 마 젠토 선수들은 수천 시간의 노동 시간을 낭비하기 위해 법원에 가져 가야합니다. 데이터베이스가 색인 작업을 수행하도록하고 데이터베이스 작업을 수행하지 마십시오. 나는 전용 서버에 돈을 낭비한 다음, 밤새 잠을자는 일없이 많은 시간을 들이지 않고 호스팅 된 전자 상거래 플랫폼이나 MS SQL 서버를 사용하는 오픈 소스로 옮기는 것이 좋습니다.
semiprecious.com

올바른 확장 또는 올바른 서버 구성을 찾지 못했다고 생각한 적이 있습니까? 일부 소프트웨어가 귀하의 요구에 맞지 않는다고해서 반드시 쓸모없는 것은 아닙니다. 지난 5 년 동안 Magento에서 빵 (맥주)을 얻었으며 많은 고객도 만족했습니다. 10k가 넘는 카탈로그가있는 일부.
Marius

CE가 작동하는 방식으로 인해 데이터 유지 관리는 10 ~ 100 만 skus의 문제입니다. EE는 인덱싱 업데이트로 인해 더 나아졌지 만 그것은 수백만 달러의 수익 회사를위한 것입니다. 당신은 그것에 호스팅을 던질 수 있지만 ROI를 부정적으로 바꿀 것입니다. 우리가 사용하는 솔루션은 SAP 및 Walmart와 같은 솔루션과 유사한 매우 전문적이고 델타 프로세스 업로드이며 인덱싱 문제 (fx 및 인라인 마진 / 속성 재 계산)를 우회하는 특수 가격 결정 솔루션 (ATG-esque)과 결합되어 클러스터와 결합됩니다. 호스팅. 간단한 대답 아니오, 마 젠토는 최적으로 설계되지 않았습니다.

답변:


31

어떤 인덱스가 느리고 왜 그런지 이해하는 것이 중요합니다

카탈로그 복잡성과 궁극적으로 상점 아키텍처는 기본 인프라와 결합하여 재 색인에 걸리는 시간을 결정합니다.

  • 50,000 개의 제품과 10 개의 상점보기가있는 경우 몇 백만 개의 행 catalog_url_rewrite을 처리하는 데 시간이 걸리는 것을 보장 할 수 있습니다 .

  • 제품이 100 개이지만 속성이 5,000 개인 경우 catalog_attributes또는 catalog_product_flat테이블을 다시 작성하는 데 시간이 걸리거나 얼굴 평평 해질 수 있습니다.

  • 1,000 개의 제품이 있지만 500 개의 검색 가능한 속성 catalog_fulltext_search이있는 경우 다시 완료하는 데 시간이 걸립니다

당신이 직면하는 각각의 문제에 대한 해결책은 모든 규모에 맞지 않습니다. 이를 지원할 수있는 올바른 인프라를 구축하고 콘텐츠 최신 성 및 성능을 모두 지원하는 재색 인 빈도 / 전략을 사용합니다.

  • 프런트 엔드 캐싱을 추가해도 전혀 도움이되지 않습니다
  • 상황에서 더 많은 하드웨어를 던지면
  • 카탈로그 크기 / 복잡성을 해결하면 도움이 될 것입니다
  • 타사 인덱싱 도구를 사용하면 도움이됩니다.
  • 특정 색인 외부화 (예 : 검색> SOLR)

특정 인덱스가 필요한지 여부를 평가하는 경우도 있습니다. 플랫 제품 / 카테고리를 사용한다고해서 항상 모든 상점이 더 빨라지는 것은 아닙니다. 우리는 그것이 상점을 훨씬 느리게 만드는 것을 보았습니다. 따라서 성능 전후에 성능을 테스트 한 후에도 고려할 필요가 없습니다.


8

tl; dr

은 총알 솔루션이 없습니다. 몇 가지 해결 방법이 Sonassi_Fastsearchindex있지만 권장 사항은 카탈로그 검색입니다.

아마도 밤새 실행되도록 예약 할 때 인덱스 업데이트를 비활성화하면 약간의 도움이 될까요? memcached, Redis, APC와 같은 캐싱을 추가하고 Varnish (CE를 실행중인 경우)와 같은 전체 페이지 캐시를 추가하면 시작될 수 있습니다. Varnish를 사용하려면 Nexcess_Turpentinegithub에서 빠른 시작을 찾으십시오 .

더 많은 정보

색인 문제 (특히 catalog_url_rewrites)는 커뮤니티에서 잘 알려져 있으며 문서화되어 있습니다. Magento는 Enterprise 버전에서 이러한 문제를 가장 많이 처리 한 고객이므로이 버전을 처리했습니다. 많은 EE 고객은 10k + 이상의 제품과 여러 상점보기, 웹 사이트 등을 보유하고 있습니다.

그러나 큰 카탈로그와 많은 수의 속성이 있으면 인덱싱에 오랜 시간이 걸리는 위치, 특히 catalog_url_rewrite, product_flat이있을 수 있습니다.이 경우 내 제안은 인덱스 런타임을 수정하지 않는 것입니다. 길이가 아니라 일부 처리오프로드하여 상자가 컨텐츠를 제공하는 대신 인덱싱하는 CPU주기를 소비 할 수 있도록합니다 .

스스로에게 물어볼 질문들 :

  • 인덱싱 문제로 인해 비즈니스가 손실됩니까?
  • 나는 잃는 건가요 생산성 으로 인해 문제가 색인에?
  • 전환이 손실 될 위험이 있습니까?
  • 고객이 재고가 부족한 품목을 구매할 위험이 있습니까 (인벤토리 등)
  • 카탈로그 가격 책정 규칙이 핵심 비즈니스의 일부입니까?
  • 내 사이트 검색 전환율이 표준 (8-10 %)보다 높으므로 색인 생성 기능이 향상됩니까?

이 특정 문제에 대한 실버 총알 솔루션은 없습니다. 솔루션 제공 업체는 고객이 매출과 비즈니스를 가장 효과적으로 개선하고 간접비를 낮추는 결정을 내릴 수 있도록 도와야합니다.

대안

카탈로그 검색 및 계층화 된 탐색을 Solr로 오프로드하십시오.

가로로 크기를 조정하십시오. Apache / nginx 서버를 더 추가하십시오. 더 많은 서버 = 더 많은 동시 처리량. 이것은 1 : 1이 아닙니다. Nexcess에는 성능 및 Apache 구성에 대한 훌륭한 백서가 있습니다. http://www.nexcess.net/magento-best-practices-whitepaper

그리고 니스와 함께하기로 결정했다면 다음을 기억하십시오.

여기에 이미지 설명을 입력하십시오


우리는 그 제안에 감사하지만, 재 인덱싱은 프론트 엔드 캐싱과 관련이 없습니다. 완전히 백엔드 작업입니다. 프런트 엔드로드를 완화하면 재 색인에 시간이 오래 걸리지 않지만 확실히 빨라지지는 않습니다.
Ben Lessani-Sonassi

내가 얻는 것은 상자에 들어오는 트래픽을 줄이는 것입니다. 여기서 가장 큰 관심사는 작업 중에 인덱스가 생성되는 동안 사이트를 사용할 수 없거나 알 수없는 시간 동안 사이트가 잠기는 것입니다. 하루가 끝날 때 인덱싱이 프런트 엔드에 부정적인 영향을 미치지 않으면 작업 실행 시간은 중요하지 않습니다. 인덱싱로드 시간을 수정하거나 개선하지 않았습니다. 아무도 "유료 버전으로 업그레이드"답변을 원하지 않습니다. 따라서 제 제안은 프론트 엔드 가용성을 개선하고 인덱스가 피크를 벗어나지 않도록 예약하는 것입니다.
philwinkle

당연히, 나는 이해하지만 웹 사이트에는 가용성이 중요하다. 전자 상거래 사이트로는 충분하지 않습니다. 인덱스가 잠겨 실제로 구매할 수없는 경우 사이트가 오프라인 일 수도 있습니다.
Ben Lessani-Sonassi

우리는 수백 개의 제품 만 가지고 있으며 Magento 1.7에서 간단한 제품을 저장하는 데 몇 분이 걸리며 전용 랙 스페이스 서버에 대해 한 달에 500 달러 이상을 지불합니다. 어디서부터 시작해야할지 모르겠지만 일부 색인이 손상되었을 수 있습니다. 누구든지 좋은 마 젠토 컨설턴트를 추천 할 수 있습니까?
Max Hodges

5

대부분의 Magento 웹숍에서는 Magento 백엔드 인덱스 관리를 사용하기가 매우 어려웠습니다. 이 문제가 자주 발생했습니다. 개발자가 쉘 스크립트를 항상 실행하는 것은 종종 바쁜 일입니다. 일반적 으로이 문제를 영구적으로 수정합니다.

shell / indexer.php> shell / myindexer.php의 새 복사본을 만듭니다.

154 줄에서 shell / myindexer.php를 사용자 정의하십시오.

} else if ($this->getArg('reindex') || $this->getArg('reindexall')) {

} else if ($this->getArg('reindex') || $this->getArg('reindexall')  || $this->getArg('reindexallrequired') ) {

166 행에이 검사를 추가하십시오

//reindex only if required
if( $this->getArg('reindexallrequired') && $process->getStatus() == Mage_Index_Model_Process::STATUS_PENDING )
    continue;

전에

$startTime = microtime(true);
$process->reindexEverything();
$resultTime = microtime(true) - $startTime;
Mage::dispatchEvent($process->getIndexerCode() . '_shell_reindex_after');

그런 다음 새로운 쉘 스크립트를 cpanel cron에 추가하여 5 분마다 실행합니다.

/home/public_html/shell/indexer.php --reindexallrequired >/dev/null

위의 셸 스크립트는 5 분마다 실행되고 다시 인덱싱해야하는 프로세스 만 다시 인덱싱하므로 서버 CPU에 대한로드가 높아질뿐만 아니라 전체 인덱싱 프로세스는 매우 빠릅니다. 프로세스의 재색 인화가 필요하지 않은 경우 단순히 재색 인화 프로세스를 실행하지 않습니다. 또한 인덱스 관리 페이지에서 재 인덱싱 모드를 "저장시 업데이트"로 설정해야합니다. 모르는 경우 제출 단추 옆에있는 조치> 색인 모드 변경에서이 옵션을 사용할 수 있습니다.


@changeling, 천만에요. 그만한 가치가있어 다행입니다.
rbncha 2016 년

나는 케이스의 사람의 발견에, 내 스크립트에이를 통합 한 것이 유용 : gist.github.com/steverobbins/...
스티브 로빈스

4

더 많은 데이터 (인벤토리 크기, 방문자, 기계)를 제공 할 수 있는지 말하기는 쉽지만 다음과 같은 가능성이 있습니다.

  • Sonassi_Fastsearchindex카탈로그 검색 색인에 확장을 사용 합니다. 제목, 설명 및 sku를 색인화하지만 (내가 생각한 것 같지만) 카탈로그 검색 색인 작성기 시간을 줄입니다.
  • 태그 나 제품 속성 등 실행할 필요가없는 인덱서가있을 수 있습니다. 가격, 제품 플랫, 카테고리 제품 및 카탈로그 검색 만 정기적으로 수행하고 나머지는 매일 수행하는 것으로 충분합니다.
  • 2 시간마다 외부 시스템과 제품을 동기화하고 그 동안 PHP 스크립트로 색인을 생성합니다. 따라서 특정 시간에 실행하려는 각 인덱서마다 cronjob이 있으며이 cron이 스크립트를 실행하도록합니다. 이는 서버가 수행 할 수있는 작업과 최신 제품 데이터 사이의 가장 좋은 중간에있는 것으로 보입니다.

Magento CE 1.7.0.2에서 실행 중입니다. 그래도 여전히 고통입니다.)


우리는 일반적으로 다른 모든 지수가 괜찮은 제품 플랫 문제에 직면하고 있습니다.
ravisoni

3

Dnd_Patchindexurl을 사용하여 catalog_url_rewrite 재색 인 시간을 거의 70 %로 줄일 수있었습니다.

사용 중지 된 제품을 제외하거나 눈에 띄지 않는 제품을 제외하여 URL을 만들지 않는 것이 좋은 해결책이라고 생각합니다.

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:11
Product Prices index was rebuilt successfully in 00:00:22
Catalog URL Rewrites index was rebuilt successfully in 00:08:49
Product Flat Data index was rebuilt successfully in 00:00:51
Category Products index was rebuilt successfully in 00:00:19
Catalog Search Index index was rebuilt successfully in 00:00:12
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

후:

$ php ./shell/indexer.php -reindexall
Product Attributes index was rebuilt successfully in 00:00:12
Product Prices index was rebuilt successfully in 00:00:24
Catalog URL Rewrites index was rebuilt successfully in 00:02:52
Product Flat Data index was rebuilt successfully in 00:00:57
Category Products index was rebuilt successfully in 00:00:25
Catalog Search Index index was rebuilt successfully in 00:00:13
Stock Status index was rebuilt successfully in 00:00:00
Tag Aggregation Data index was rebuilt successfully in 00:00:00

1.9.1.1에 설치했으며 매우 잘 작동했습니다!

Connect http://www.magentocommerce.com/magento-connect/catalog/product/view/id/15074/s/dn-d-patch-index-url-1364/category/12863/를 통해 설치할 수 있습니다


1

EE 1.13으로 업그레이드하십시오. 이 버전에서는 인덱서가 크게 향상되었습니다.


2
그러나 대부분의 고객은 커뮤니티 버전을 선호합니다.
ravisoni

1
동의했다. 1.8은 몇 주 후에 나올 것이지만 인덱서 최적화는 포함되지 않을 것입니다. 나도 마음에 들지는 않지만 인덱서의 성능을 얻는 가장 쉽고 안전하며 가장 저렴한 방법입니다.
Paul Grigoruta

영구적 인 해결책을 찾는 것은 불가능합니다.
ravisoni

대부분의 경우 누군가가 SKU가 너무 많아 기존 CE 1.7 인덱서가있는 벽돌 벽에 닿는 경우 EE 1.13을 사용해야합니다. 10-25k SKU를 가진 이러한 CE 1.7 및 EE 1.12 인덱서에는 원활하게 운영되는 사이트가 많이 있습니다. 핵심은 주로 워크 플로 수준에서 관리하고 올바른 인프라를 구축하는 것입니다.
davidalger

CE는 완벽한 선택입니다. EE 1.13 의 기능버그 수정으로 커뮤니티가 CE로 이동했습니다. 이를 무시하고 CE 또는 EE 사용 여부에 관계없이 인덱싱 시간은 항상 카탈로그 복잡성, 서버 구성, 방문자 동시성 및 재 인덱싱 빈도에 따라 달라집니다. EE는 마법의 총알이 아니며 아키텍처 관련 문제에 대한 적절한 솔루션이 아닙니다.
Ben Lessani-Sonassi
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.