InnoDB를 사용한 전문 검색

InnoDB를 사용한 전문 검색

저는 대용량 웹 애플리케이션을 개발하고 있으며, 그 중 일부는 토론 게시물의 MySQL 데이터베이스이며, 20M 이상의 행으로 원활하게 확장해야 합니다.

원래 테이블(내장 풀텍스트 검색 기능)에 MyISAM을 사용할 예정이었지만, 1회의 기입 조작에 의해 테이블 전체가 잠겨 버리는 것을 생각하면 마음이 놓입니다.행 레벨의 잠금이 훨씬 더 타당합니다(InnoDB가 큰 테이블을 다룰 때 갖는 다른 속도 이점은 말할 것도 없습니다).그래서 저는 InnoDB를 사용하기로 결심했습니다.

문제는...InnoDB에는 풀텍스트 검색 기능이 내장되어 있지 않습니다.

서드파티 검색 시스템으로 해야 하나요?루센(c++) / 스핑크스처럼?데이터베이스 닌자 중에 제안이나 지침이 있는 사람이 있나요?Linked In의 zoie(Lucene을 기반으로 함)는 현시점에서는 최선의 옵션인 것 같습니다.실시간 기능을 중심으로 구축되어 있습니다(이것은 제 애플리케이션에 매우 중요합니다).아직 어떤 통찰력 없이 헌신하기는 좀 망설여지는데...

(참고: PHP를 사용하여 프런트엔드에 서비스를 제공하는 고메모리 리그를 갖춘 EC2에 탑재할 예정

MyISAM의 일반적인 단계적 종료와 더불어 InnoDB FTS(Full-Text Search)는 MySQL 5.6.4 릴리즈에서 드디어 사용할 수 있게 되었습니다.

자세한 내용은 https://dev.mysql.com/doc/refman/5.6/en/innodb-fulltext-index.html에서 확인할 수 있습니다.

다른 엔진에는 다양한 기능이 있지만, 이 엔진은 InnoDB이기 때문에 네이티브(업그레이드 경로가 있음)이기 때문에 가치 있는 옵션입니다.

MyISAM 풀텍스트가 나쁜 옵션임을 보증할 수 있습니다.일반적으로 MyISAM 테이블의 여러 가지 문제는 차치하고라도 풀텍스트가 탈선하여 스스로 파손되어 MySQL이 정기적으로 크래시되는 것을 보았습니다.

전용 검색 엔진은 분명 가장 유연한 옵션이 될 것입니다. 즉, 포스트 데이터를 MySQL/innodb에 저장하고 텍스트를 검색 엔진으로 내보냅니다.정기적인 전체 인덱스 빌드/게시를 매우 쉽게 설정할 수 있으며, 필요한 경우 실시간 인덱스 업데이트를 추가할 수 있습니다.

루센과 스핑크스도 좋고 가벼운 자피안도 좋습니다.만약 당신이 Lucene의 길을 간다면, 비록 당신이 Java와 씨름하고 싶지 않더라도 Clucene이 더 나을 것이라고 생각하지 마세요. 하지만 저는 둘 다의 장단점을 논할 자격이 없습니다.

한 시간 정도 시간을 들여 스핑크스와 루센의 설치와 시승 과정을 거쳐야 합니다.데이터 업데이트와 관련하여 둘 중 하나가 고객의 요구를 충족하는지 확인하십시오.

Sphinx의 아쉬운 점 중 하나는 증분 삽입을 잘 지원하지 않는다는 것입니다.즉, 삽입 후 인덱스를 다시 작성하는 것은 매우 비용이 많이 들고, 데이터를 오래된 변경되지 않은 행과 새로운 휘발성 행으로 분할하는 것이 권장됩니다.따라서 앱에서 수행하는 모든 검색은 두 번 검색해야 합니다. 즉, 이전 행의 경우 큰 인덱스에서 한 번, 최근 행의 경우 작은 인덱스에서 한 번 검색해야 합니다.이것이 사용 패턴과 통합되지 않는 경우, 이 스핑크스는 (적어도 현재 구현에서는) 좋은 솔루션이 아닙니다.

생각할 수 있는 또 다른 해결책을 지적하고 싶습니다.Google Custom Searchoogle Custom Search 。웹 응용 프로그램에 SEO를 적용할 수 있다면 인덱싱 및 검색 기능을 Google에 아웃소싱하고 Google 검색 텍스트 필드를 사이트에 포함시키십시오.가장 경제적이고 확장성이 뛰어난 방법으로 사이트를 검색할 수 있습니다.

MySQL의 FT를 너무 빨리 해제하지 않는 것이 좋을지도 모릅니다.크레이그리스트가 쓰곤 했지

MySQL의 속도와 풀텍스트 검색으로 Craigslist는 사용자에게 서비스를 제공할 수 있게 되었습니다.Craigslist는 MySQL을 사용하여 초당 최대 60개의 검색 속도로 매달 약 5,000만 개의 검색을 처리합니다."

편집하다

아래 코멘트처럼 Craigslist는 2009년 초에 스핑크스로 전환한 것으로 보입니다.

스핑크스는 당신이 지적한대로 이 물건에는 꽤 좋은 물건입니다.모든 작업은 구성 파일에 있습니다.문자열이 있는 테이블에 고유한 정수 ID 키가 있는지 확인하십시오. 그러면 문제가 없습니다.

이거 먹어봐

ROUND((LENGTH(text) - LENGTH(REPLACE(text, 'serchtext', ''))) / LENGTH('serchtext'),0)!=0

스핑크스 좀 보세요.시도해 볼 가치가 있다.인덱싱이 매우 빠르고 배포됩니다.이 웹미나(http://www.percona.com/webinars/2012-08-22-full-text-search-throwdown))를 참조해 주세요.검색에 대해 설명하고 몇 가지 명확한 벤치마크를 가지고 있습니다.도움이 될 거예요.

다른 모든 것이 실패했을 경우 soundex_match가 항상 존재하지만, 안타깝게도 정확한 속도는 아닙니다.

InnoDB가 Fulltext 검색을 지원하지 않는 MySQL/MariaDB의 이전 버전(CentOS 사용자)을 사용하는 경우, InnoDB 테이블을 사용할 때 내가 검색하고 싶은 것에 대해 별도의 MyISAM 테이블을 만드는 것이 나의 해결책이었다.

예를 들어, 나의 주요 InnoDB 테이블은products다양한 키와 참조 무결성을 제공합니다.그런 다음 MyISAM 테이블을 만들었습니다.product_search두 개의 필드를 포함합니다.product_id그리고.product_name여기서 후자는 a로 설정되었다.FULLTEXT두 필드 모두 주(主)에 있는 내용을 효과적으로 복사한 것입니다.product테이블.

그런 다음 풀텍스트를 사용하여 MyISAM 테이블에서 검색하여 InnoDB 테이블로 내부 조인백합니다.

MyISAM 테이블의 내용은 트리거 또는 애플리케이션 모델을 통해 최신 상태로 유지할 수 있습니다.

전체 텍스트가 필요한 테이블이 여러 개 있는 경우에는 권장하지 않지만, 단일 테이블에서는 업그레이드할 수 있을 때까지 충분한 해결 방법인 것 같습니다.

언급URL : https://stackoverflow.com/questions/1381186/fulltext-search-with-innodb