2

소비자가 키워드를 입력하여 제품을 검색 할 수있는 전자 상거래 사이트를 구축한다고 가정합니다. 최대 200,000 개의 제품이 있으며 시스템을 사용하는 수백만 명의 소비자가 있다고 가정 해보십시오. 제품 테이블이 자주 업데이트된다고 가정 해 봅시다. 제품 수는 그다지 많지 않으므로 아마도 데이터베이스에 도달하는 대신 전체 제품 테이블을 메모리에 저장하고 검색 할 수 있습니다. 동일한 데이터를 저장하지만 고 가용성 및 성능상의 이유에서 다른 서버에 상주하는 분산 캐시를 생성하기를 원하며 제품 테이블이 수정 될 때 이러한 캐시간에 데이터를 동기화하고 캐시를 무효화 할 수 있어야합니다.트래픽이 많은 웹 사이트에서의 캐싱에 대한 질문

우리의 응용 프로그램은 ASP.NET MVC와 NHibernate를 사용하여 만들어졌습니다. 나는 NHibernate의 레벨 2 캐싱이 내 상황에 도움이되는지 이해하려고 노력하고있다. 너희들이 이것에 대해 밝힐 수 있다면 정말 고마워.

레벨 2 캐싱은 쿼리 결과를 캐시하는 데 도움이되므로 두 명의 다른 사용자가 동일한 키워드를 사용하여 검색하는 경우 L2 캐시는 데이터베이스가 아닌 캐시의 결과를 제공합니다. 하지만 제품 테이블이 자주 업데이트되고 캐시 된 결과가 오래되어 도움이되지는 않습니다. 제 질문은 제가 L2 캐싱을 올바르게 이해하고 있으며, 여러 가지 캐시, 동일한 데이터, 캐시 간 동기화 및 캐시 무효화와 같은 방식으로 캐시를 관리하는 데 도움이되는 것이 있습니다. 어떤 생각을 높게 평가됩니다.

답변

2

2 차 수준 캐시 (memcached 공급자 사용)와 NHibernate.Search 추가 기능을 모두 사용하면 두 가지 모두에서 혜택을 볼 수 있습니다.

NHibernate.Search 구성 요소는 Lucene.Net에 따라 다르며 키워드 검색은 데이터베이스 자체에서 분리됩니다. 맵핑 된 클래스마다 다른 인덱스 파일이 생성되고 특성을 사용하여 속성 수준에서 최적화를 설정할 수 있으므로 추가 수준의 세분화가 가능합니다. 또한 최상의 일치 및 제안을 구현할 수 있습니다 (Lucene 작동 및/또는 Hibernate Search 작동 확인). 참고로 명시 적으로 인덱스 재 작성을 요청하지 않는 한 인덱스를 유지할 필요가 없습니다. 구현은 원하는 경우 인덱스를 조작 할 수 있지만 장면 뒤의 모든 것을 관리합니다. 따라서 제품 추가/삭제/업데이트는 해당 색인을 자동으로 업데이트합니다.

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

확대/축소 가능 * 2 수준 캐시는 공급자에 따라 다릅니다 (예 : memcached는 뛰어난 성능과 확장 성을 제공하며 분산 인스턴스를 지원합니다). * Lucene.Net/NHibernate.Search의 경우 인덱스가 상주 할 특정 위치를 설정해야하며 모든 웹 응용 프로그램 인스턴스에서 읽기/쓰기 액세스가 가능해야합니다. 여기에 민감한 링크는 I/O 및 파일 경합이므로 라이트 파일 시스템보다 빠른 시스템을 설정하면 발생하지 않습니다. (초당 수천 건의 검색 요청으로 시나리오를 말합니다)

사이드 노트로 NHibernate.Search는 LIKE 쿼리보다 매우 빠르며 SQL Server의 FullText 검색을 어플리케이션 내부에서 구현하는 것보다 사용하기 쉽기 때문에 NHibernate.Search를 적극 권장합니다.

+0

재규어이 유용한 정보를 제공해 주셔서 감사합니다! 나는 NHibernate.Search와 Lucene.NET을 연구 중이지만 Oren Eini의 블로그에있는 리소스 외에 많은 리소스를 찾을 수 없었다. 다른 유용한 링크를 아는 경우, 정말로 전달해 주시면 고맙겠습니다. 캐시 또는 DB가 업데이트 될 때 Lucene.NET에 의해 색인이 생성 된 문서가 캐시 또는 DB와 어떻게 동기화되는지 궁금한 다른 질문이 있습니까? 게시물에서 L2 캐시처럼 보이고 NHibernate.Search/Lucene.NET이 잘 작동하는 것 같습니다. – mwong

+0

글쎄, 나는 Hibernate Search (http://www.manning.com/bernard/)의 일부를 읽었으며 사용상의 차이점은 거의 같다. 또한 Lucene이 무엇인지, 그리고 Lucene이 어떻게 작동하는지에 대해 강하게 파악하려면 Lucene in Action (http://www.manning.com/hatcher2/)을 강력하게 권장합니다. 두 번째 질문에서 캐시는 항상 db를 나타냅니다. lucene 인덱스는 db 항목과 동기화되며 예는 제대로 작동합니다. – Jaguar

2

두 번째 레벨 캐시가 도움이되는지 여부는 캐시 히트와 관련하여 제품 테이블이 업데이트되는 빈도에 따라 달라집니다. 한 시간에 100 개의 신제품을 추가하지만 한 시간에 10,000 개의 쿼리를 수신하면 10 %의 캐시 적중률로도 큰 차이가납니다. 비율이 반대로되면 두 번째 레벨 캐시는 거의 가치가 없습니다.

프로덕션 환경에 매우 근접한 스트레스 테스트 환경을 설정하고 다양한 2 차 수준 캐시 공급자에서 벤치마킹을 수행하는 것이 좋습니다.

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

1

나는 Lucene을 사용하여 NHibernate.Search을 사용하는 것이 좋습니다. 2 차 수준 캐시와 함께 작동합니다. Lucene은 정교한 텍스트 검색을 빠르게 수행 한 다음 엔티티 키를 NHibernate로 되돌려 보내서 NHibernate로 되돌아 가서 전체 엔티티를 2 차 수준 캐시에서 끌어옵니다. NHibernate.Search 확장 기능은 Lucene 색인을 동기화 상태로 유지하는 작업을 수행합니다.

TekPub 정확한 제품 설명 검색 시나리오에 대한 최근 에피소드를 작성했습니다. 에피소드는 NHibernate 쿼리, SQL 전체 텍스트 인덱싱 및 NHibernate.Search가있는 Lucene을 비교합니다.

+0

왜이 답변에 -1입니까? – mwong

+0

전체 텍스트 인덱싱은 이와 같은 용도로 사용됩니다. 와일드 카드 'like'가 포함 된 SQL 쿼리는 잘못된 접근 방식입니다. –

관련 문제