검색 API와 Apache Solr 검색

내가 사용하고 아파치 SOLR 검색 드루팔 6 모듈과에서 찾고 검색 API 설치할 드루팔 7. 나는 여기서 약간의 토론을 보았지만 하나를 선택 해야하는 이유를 찾고 있습니다.

다른 것을 선택해야 할 이유가 있습니까? 그렇다면 왜 또는 왜 안됩니까? Search API에 복잡성 문제 및 / 또는 성능 문제가있을 수 있다고 들었습니다. 이것이 사실입니까?

2015 년 현재 Search API와 Apache Solr Search 모듈을 숫자와 비교할 수 있습니다.

                   | Apache Solr Search  | Search API
Posted in:         | 2007                | 2010
Downloads:         | >2k                 | >20k
Reported installs: | >21k                | >64k
Total bugs:        | >1200               | >600
Active bugs:       | >200                | >170
Commits:           | >1.3k               | >1.5k

명확한 선택을 나타냅니다. Search API는 3 년 후에 개발되었으며 경쟁 업체를 활용할 수있었습니다.

더욱이 Search API는 매우 다양하고 유연한 아키텍처를 제공하며 더욱 적극적으로 유지 관리되고 있습니다. 더 중요한 것은 Apachesolr에없는 최신 Drupal 8 및 Solr 5.x를 이미 지원한다는 것입니다 .

Search API는 새롭게 시작되었으며 Views 지원 (Apachesolr의 경우 추가 모듈이 필요함)을 포함하여 구성이 더 유연합니다. 기능을 확장하는 많은 모듈도 있습니다.

둘째, 이러한 모듈의 아키텍처 차이로 인해 커뮤니티가 두 번 해결하는 문제를 피하기 위해 현재 두 프로젝트 사이에 다음과 같은 결합 된 노력이 있습니다.

• 패싯 API (필터라고도 함) 를 통해 패싯 블록을 표시하는 일반적인 방법 작성
• 공통 스키마 및 solrconfig.xml 구성 파일
• 두 관리자가 함께 작업하여 연결 클래스를 Apache Solr Search 모듈에서 Search API로 마이그레이션했습니다.

^{출처 : Acquia의 Drupal 8 에서 Search & Solr을위한 Battleplan}

동일한 환경에서 두 모듈을 모두 사용하지 않는 것이 좋습니다.

차이점에 대한 추가 기술 분석은 아래 세부 정보를 확인하십시오.

검색 API

API 개요 :

• 손쉬운 검색을위한 프레임 워크
• 데이터 소스 및 백엔드 구현의 요약
• 확장 기능이있는 대규모 에코 시스템 (예 : 백엔드)
• 패싯 API 통합

• 엔터티 API를 기반으로

  • 메타 데이터 제공
  • 인덱스 및 서버 구성에 사용

확장 기능 :

• 검색 API 자동 완성
• 첨부
• 저장된 검색
• 위치
• 예쁜 패싯 경로
• 슬라이더 (검색 API 범위)
• 그리고 더 많은.

기본 구조 :

색인 기능 :

• 다른 데이터 소스
• 하나의 데이터 소스 : 엔티티

• 엔터티 API를 기반으로 :

  • 각 속성을 색인 할 수 있습니다
  • 관련 엔터티의 속성을 인덱싱 할 수 있습니다

색인-필드를 구성하는 방법 :

검색 API 뷰 :

• 전체 뷰 지원
• 엔터티의 속성 표시
• 색인화 된 필드를 필터, 인수 또는 정렬로 사용하십시오.
• Entity API의 뷰 통합을 기반으로하는 대부분의 코드

• 기본적으로 : 엔티티로드를 통해 검색된 데이터

  • 무시 가능 (서버의 "Solr에서 데이터 검색"설정)
• 대안 : 검색 API 페이지

검색 API 레시피 :

• 인덱스 및 서버를위한 CRUD 후크

• 추가 고리

  • 데이터 소스
  • 백엔드
  • 데이터 변경
  • 프로세서

• 항목을 색인 할 때 발생하는 후크

• 검색을 실행할 때 훅 발생

아파치 솔

확장 기능 :

• 첨부 파일 (미디어 지원 없음, 다른 엔티티에 첨부하기위한 사용자 지정 코딩)
• 위치 (Apachesolr geo, Apachesolr 위치)

Apachesolr 레시피 :

• 오픈 소스 엔터프라이즈 검색 플랫폼
• 아파치 재단
• 전체 텍스트 검색, 강조 표시, 패싯 검색, 클러스터링, 풍부한 문서 처리
• 분산
• 복제 / 확장 가능
• 자바
• REST HTTP 및 XML / JSON 및 기타 응답
• 관계없는

출처 : 검색 API 및 Apachesolr 슬라이드 쇼

참조 :

• 핵심 Drupal 검색 모듈은 언제 사용할 가치가 있습니까?
• 핵심 검색 모듈보다 Apache Solr을 사용하면 어떤 이점이 있습니까?

나는 둘 다 사용해 보았고 이것을 말할 수 있습니다 : 그것은 당신의 상황에 달려 있습니다.

현재 ApacheSolr 통합 모듈의 안정적인 7 릴리스는 노드 만 색인 할 수 있습니다. 당신은 당신이 색인을 필요 비 노드 실체가 있다면 그래서, 당신은 진행에 여전히를 사용할 필요가 multientity의 그것을 위해 패치. ApacheSolr Integration은 올바르게 구성된 경우 많은 다른 컨텐츠 데이터를 저장할 수 있습니다.

검색 API는 엔터티를 색인화하고이를 위해 많은 훌륭한 자료를 작성합니다. 그러나 Search API는 검색중인 데이터의 ID 만 가져옵니다. 즉, ID 이외의 다른 데이터를로드하려면 entity_load가 필요하며 데이터베이스에 충돌하거나 배치 한 캐싱 계층이 필요합니다. 검색 량이 많은 사이트의 경우 이것이 가장 최적화 된 솔루션이 아닐 수 있습니다.

다음 은 drupalcon chicago에서 ApacheSolr Integration 모듈에 대한 훌륭한 프레젠테이션입니다. Search API에 대한 16 분입니다.

나는 당신이 정말로 두 가지를 모두 시도하고 정보에 근거한 결정을 내려야한다고 생각합니다. 그러나 apachesolr에는 여전히 Drupal 8 베타 버전이 없습니다.

Search API에서는 동일한 SearchAPI 색인에서 엔티티를 결합 할 수 없습니다. 따라서 프로파일, 사용자, 노드는 서로 다른 색인에 있습니다. 다중 인덱스 검색을 허용하는 모듈이 있지만 내 요구를 충족시키지 못했지만 YMMV입니다. 동일한 색인에 많은 컨텐츠 유형과 많은 필드가있는 경우 색인 정의가 상당히 어려워 질 수 있습니다. (다중 색인 검색을 지원하는 NB SearchAPI D8 보고서)

Apachesolr을 사용하면 컨텐츠별로 필드를 쉽게 편집 할 수 있지만 문서에 관련 컨텐츠를 추가 할 수는 없지만 실제로는 필드 콜렉션, 참조 및 기타 정보를 포함하는 사용자 정의 코드를 작성해야합니다. 전지. Apachesolr D7은 뷰를 사용하지 않는 한 ajax를 지원하지 않지만 뷰를 사용하면 패싯이 손실됩니다. 즉, 인덱스에 저장된 정보를 수정하는 것은 행복하게 코딩하면 행복합니다.

엔터티 ID를 검색 한 다음 각각을 개별적으로 렌더링 (두 모듈에서 모두 사용할 수 있음)하는 아이디어는 성능 악몽처럼 보이지만 엔터티 디스플레이를 캐시하면 solr 응답에서 렌더링하는 것보다 훨씬 효율적일 수 있습니다.