교통량이 많은 웹 사이트에서 캐싱에 관한 질문

Question

소비자가 키워드를 입력하여 제품을 검색 할 수있는 전자 상거래 사이트를 구축한다고 가정 해 봅시다. 최대 200,000 개의 제품이 있으며이 시스템을 사용하는 수백만 명의 소비자가 있다고 가정 해 봅시다. 제품 테이블이 상당히 자주 업데이트되었다고 가정 해 봅시다. 제품의 수는 그다지 높지 않기 때문에 전체 제품 테이블을 메모리에 저장하고 데이터베이스를 치는 대신 검색 할 수 있습니다. 우리는 동일한 데이터를 저장하지만 다른 서버에 상주하는 분산 캐시를 생성하기를 희망하며 (고 가용성 및 성능 이유를 위해) 이러한 캐시 간의 데이터를 동기화하고 제품 테이블이 수정 될 때 캐시를 무효화 할 수 있어야합니다.

우리의 응용 프로그램은 ASP.NET MVC 및 NHibernate를 사용하여 구축되었습니다. Nhibernate의 Level-2 캐싱이 내 상황에 도움이 될지 이해하려고 노력하고 있습니다. 너희들이 이것에 대해 약간의 빛을 발할 수 있다면 정말 감사하겠습니다.

Level-2 캐싱이 캐시 쿼리 결과에 도움이되므로 두 명의 다른 사용자가 동일한 키워드를 사용하여 검색하는 경우 L2 캐시는 데이터베이스 대신 캐시에서 결과를 제공합니다. 그러나 제품 테이블이 자주 업데이트되고 캐시 된 결과가 오래되기 때문에 많은 도움이되지 않습니다. 내 질문은 L2 캐싱을 올바르게 이해하는 것입니다. 캐시를 관리하는 데 도움이되는 모든 것이 존재하는 것입니다 (여러 캐시, 동일한 데이터, 캐시 사이의 동기화 및 무효화 캐시). 모든 생각은 높이 평가됩니다.

Answer 1

두 번째 레벨 캐시 (Memcached Provider 사용)와 Nhibernate.search 애드온을 모두 사용하면 두 가지 모두에게 도움이 될 수 있습니다.

nhibernate.search 구성 요소는 Lucene.net에 따라 다르며 키워드 검색은 데이터베이스 IT 자체에서 분리됩니다. 클래스 맵핑 당 다른 인덱스 파일이 생성되며 속성을 사용하여 속성 레벨에서 최적화를 설정할 수 있으므로 추가 수준의 세분성을 제공합니다. 또한 Best Match 및 제안을 구현할 수 있습니다 (Lucene을 확인하거나 행동 중 최대 절전 모드 검색). 참고로, 인덱스 재건을 명시 적으로 요청하지 않는 한 지수를 유지할 필요가 없습니다. 구현은 무대 뒤에서 모든 것을 관리하지만, 원한다면 인덱스를 조작 할 수 있습니다. 따라서 제품을 추가/삭제/업데이트하면 자동으로 해당 인덱스가 업데이트됩니다.

두 번째 레벨 캐시의 경우 즉각적인 성능 향상을 얻습니다. 약 2 MIL 행의 데이터 세트가있는 테스트 환경에서는 매우 낮은 요청 카운트에서도 20% 이상 개선되었습니다. 요청 수가 증가함에 따라 성능 향상이 점차 커집니다. 응용 프로그램은 먼저 2 레벨 캐시를 치고 찾지 못하면 DB를 치고 필요한 행을 가져와 향후 쿼리를 위해 캐시에 삽입합니다. 다시 캐시 지속 시간 및 기타 구성 설정과 같은 항목을 관리 할 수있을뿐만 아니라 캐시 (모두, 모든 항목, 일부 또는 특정 항목)를 명시 적으로 지우고 싶을 수 있습니다. 캐시 상태는 저장/업데이트/삭제 중 응용 프로그램에서 관리합니다.

파기 성 * 2 차 캐시는 제공자에 따라 다릅니다 (즉, Memcached는 성능이 높고 확장 가능하며 분산 인스턴스를 지원합니다). * Lucene.net/nhibernate.search의 경우 인덱스가 상주하는 특정 장소를 설정해야하며 모든 웹 응용 프로그램에 의해 읽기/쓰기를 위해 액세스 할 수 있어야합니다. 여기서 민감한 링크는 I/O 및 파일 경합이므로 라이트 파일 시스템보다 빠르게 기계를 설정하면 발생하지 못하게됩니다 (초당 수천 개의 검색 요청이있는 시나리오에 대해 말하고 있습니다).

부수적으로 Nhibernate.search는 쿼리보다 매우 빠르며 응용 프로그램 내에서 SQL-Server의 전체 텍스트 검색을 구현하는 것보다 사용하기 쉽기 때문에 검색을 적극 권장합니다.

Answer 2

두 번째 레벨 캐시가 도움이되는지 여부는 캐시 히트와 관련하여 제품 테이블이 얼마나 자주 업데이트되는지 정확히 달라집니다. 1 시간에 100 개의 신제품을 추가하지만 시간당 10,000 쿼리를 받으면 10% 캐시 적중률만으로도 큰 차이가 생길 것입니다. 요금이 반전되면 2 단계 캐시의 가치가 거의 없습니다.

생산 환경에 근접한 스트레스 테스트 환경을 설정하고 다양한 2 단계 캐시 제공 업체에서 벤치마킹을 수행하는 것이 좋습니다.

또한 업데이트가 많은 시나리오에 대해 DB가 올바르게 구성되어 있는지 확인하십시오.

Answer 3

사용하는 것이 좋습니다 nhibernate.search 루센 w/. 2 레벨 캐시와 함께 작동합니다. Lucene은 정교한 텍스트 검색을 빠르게 검색 한 다음 엔티티 키를 뒤로 돌려 Nhibernate로 돌아가서 전체 엔티티를 2 레벨 캐시에서 끌어 당깁니다. nhibernate.search 확장은 Lucene 지수를 동기화하는 작업을 수행합니다.

Tekpub 제품 설명 검색의 정확한 시나리오에 대한 최근 에피소드를 수행했습니다. 이 에피소드는 nhibernate 쿼리, SQL Full-Text Indexing 및 Lucene w/ nhibernate.search를 비교합니다.