검색 엔진. 전체 텍스트 검색 엔진 비교. 검색 및 순위 매기기 메커니즘

효과적인 검색 엔진을 만드는 기술적인 복잡성을 보여주는 예입니다.

예

이 사이트는 웹 디자인 전용입니다. 주요 초점은 웹사이트 제작 및 재설계입니다. 사이트에 "웹사이트 제작"이라는 문구가 여러번 등장하지만, "웹사이트 제작"이나 "웹사이트 개발"이라는 문구는 없습니다.

사이트에 검색 엔진을 포함해야 합니다. 엔진의 검색 알고리즘은 사이트 텍스트 색인을 기반으로 합니다.검색은 키워드와 핵심 문구, 색인화된 파일의 텍스트에 포함되어 있습니다. 관련성 평가의 기본 원칙 텍스트 정보: 키워드 및 구문의 발생 빈도입니다.

"웹사이트 개발"이나 "웹사이트 제작"을 요청하시면 검색엔진에서는 어떤 결과도 반환하지 않습니다. 결국 사이트에는 그러한 문구가 없습니다. 실망한 방문자는 필요한 정보를 찾지 못한 채 사이트를 떠날 것입니다.

검색 엔진의 작동을 개선할 수 있습니다. 그러나 이를 위해서는 사이트 텍스트에 요청된 키워드나 문구가 포함되어 있지 않지만 의미가 유사한 다른 단어와 문구가 포함되어 있는 경우 링크를 제공해야 하는 페이지를 지정하여 검색 엔진을 수동으로 구성해야 합니다.

수천 개의 익명 FTP 사이트. 이 다양성에서는 사용자가 문제 해결에 적합한 프로그램을 찾는 것이 상당히 어려웠습니다.

더욱이 그들은 자신들이 찾고 있는 도구가 존재하는지 사전에 알지 못했습니다. 따라서 구조가 크게 다른 FTP 저장소를 수동으로 확인해야 했습니다. 핵심 측면 중 하나가 출현하게 된 것은 바로 이 문제였습니다. 현대 세계- 인터넷 검색.

창조의 역사

"FTP 사이트를 돌아다니면서 거기에 무엇이 있는지 알아내려고 시간을 낭비하는 대신, 저를 위해 그 일을 해 주는 스크립트를 작성했고 빠르게 해냈습니다."라고 Alan은 말합니다.

<поле>:<необязательный пробел><значение><необязательный пробел>
기록<поле>User-agent 또는 Disallow라는 두 가지 값을 사용할 수 있습니다. User-agent는 정책이 설명된 로봇의 이름을 지정했으며 Disallow는 액세스가 거부된 섹션을 결정했습니다.

예를 들어, 이러한 정보가 포함된 파일은 /cyberworld/map/, /tmp/ 또는 /foo.html이 포함된 URL에 대한 모든 로봇의 액세스를 거부합니다.

# http://www.example.com/에 대한 robots.txt User-agent: * Disallow: /cyberworld/map/ # 이것은 무한한 가상 URL 공간입니다. Disallow: /tmp/ # 곧 사라질 것입니다. Disallow: /foo. HTML
이 예에서는 Cybermapper를 제외한 모든 로봇의 /cyberworld/map에 대한 액세스를 차단합니다.

# robots.txt for http://www.example.com/ User-agent: * Disallow: /cyberworld/map/ # 이것은 무한한 가상 URL 공간입니다. # Cybermapper는 어디로 가야 할지 알고 있습니다. 사용자 에이전트: Cybermapper 허용하지 않음:
이 파일은 사이트의 정보에 액세스하려고 시도하는 모든 로봇을 "배포"합니다.

# 떠나세요 User-agent: * 허용하지 않음: /

불멸의 아치

Archie는 매우 오래된 검색 엔진이지만 여전히 매우 강력한 검색 기능을 제공합니다. 원하는 파일. 그러나 현대의 검색엔진에 비하면 극히 원시적이다. "검색 엔진"은 훨씬 앞서 있습니다. 원하는 검색어를 입력하기만 하면 시스템이 이미 검색 옵션을 제공합니다. 사용된 기계 학습 알고리즘은 말할 것도 없습니다.

오늘 기계 학습 Google이나 Yandex와 같은 검색 엔진의 주요 부분 중 하나입니다. 이 기술의 사용 예로는 검색 순위(컨텍스트 순위, 개인별 순위 등)가 있습니다. 이 경우 LTR(Learning to Rank) 시스템이 매우 자주 사용됩니다.

기계 학습을 통해 사용자가 입력한 쿼리를 "이해"할 수도 있습니다. 이 사이트는 독립적으로 철자를 수정하고, 동의어를 처리하고, 모호성 문제(사용자가 찾고자 하는 것, Eagles 그룹 또는 Eagles에 대한 정보) 문제를 해결합니다. 검색 엔진은 블로그, 뉴스 리소스, 포럼 등 URL과 사용자 자신을 기준으로 사이트를 분류하는 방법을 독립적으로 학습하여 개인화된 검색을 생성합니다.

검색엔진의 증조부

Alan Amtage는 부자가 될 기회를 놓쳤는지 묻는 질문에 어느 정도 겸손하게 대답했습니다. “물론 나는 부자가 되고 싶습니다.”라고 그는 말합니다. - 하지만 특허를 내더라도 억만장자가 되지는 못할 수도 있다. 설명을 부정확하게 만드는 것은 너무 쉽습니다. 때로는 먼저 승리하는 사람이 아니라 최고가 되는 사람이 되는 경우도 있습니다.”

Google과 다른 회사가 최초는 아니었지만 경쟁사보다 뛰어난 성과를 거두며 수십억 달러 규모의 산업을 창출했습니다.

Netpikov 작업자는 시간이 필요한 작업(예: Death Star 프로젝트 생성 또는 소형 상온 핵융합 장치 구축)에 직면할 때 먼저 이 작업을 자동화하는 방법에 대해 생각합니다. 우리는 우리 웹사이트의 특별 페이지에서 그러한 성찰의 결과를 수집합니다. 오늘은 Netpeak 에이전시 내부에서 새롭고 유용한 서비스가 어떻게 탄생하는지에 대해 이야기하겠습니다.

오래 전, 머나먼 은하계에서 우리는 자연 검색에서 페이지의 가시성을 높이기 위해 클라이언트 사이트의 검색 엔진을 변경하기로 결정했습니다.

일

우리가 작업해야 했던 클라이언트 프로젝트의 검색 엔진이 생성되었습니다. 별도의 페이지모든 요청에 ​​대해. 쿼리에 오타가 포함되는 경우가 있기 때문에 올바른 페이지와 오류가 있는 페이지가 산더미처럼 쌓여 있습니다. 일반적으로 200만 페이지 이상: 러시아어와 동일 영어로. 오류가 있는 페이지가 색인화되어 결과가 막혔습니다.

우리의 임무는 모든 쿼리 옵션(올바른 옵션과 오류가 있는 옵션 모두)이 하나의 페이지로 연결되도록 하는 것이었습니다. 예를 들어, 야구, basaball, baaeball, baselball에 대한 각 검색어에는 자체 페이지가 있지만 모든 옵션이 올바른 검색어인 야구를 사용하여 한 페이지에 수렴되도록 해야 했습니다. 이 경우 페이지는 올바른 요청 형식에 해당하며 검색 결과에서 쓰레기를 제거할 수 있습니다.

그룹의 예:

대행사가 웹 사이트 엔진의 변경 사항을 구현하는 데 항상 신뢰받는 것은 아니라는 점은 주목할 가치가 있습니다. 따라서 우리는 이 프로젝트를 실행할 수 있는 기회를 주신 고객에게 감사드립니다.

표적

오류가 있는 문구 페이지에서 올바른 문구가 있는 클라이언트 사이트의 페이지로 리디렉션을 배치하기 위한 명확한 작업 메커니즘을 만듭니다.

이는 크롤링과 색인 생성을 개선하는 데 필요합니다. 방문 페이지검색 엔진 및 구축을 위한 의미론적 핵심개발에 사용하고 새로운 구조대지. 물론 쿼리가 입력된 언어의 총 개수는 알 수 없었지만, 구문의 대부분이 러시아어와 영어로 되어 있었기 때문에 이 언어들에 집중했습니다.

새로운 방식은 어떻게 탄생했나

즉시 떠오르는 가장 간단한 해결책은 Google에 검색어를 입력하는 것입니다. 그러면 Google이 이를 정직하게 수정해 드립니다. 그러나 그러한 침투를 조직하는 것은 다소 비용이 많이 드는 일입니다. 그러므로 나와 동지들은 다른 길을 택했습니다. 우리의 분석 수학자는 (갑자기!) 언어적 접근 방식을 사용하고 언어 모델을 구축하기로 결정했습니다.

무슨 뜻이에요? 우리는 언어에서 단어를 만날 확률을 결정하고 각 단어에 대해 해당 단어가 포함될 확률을 찾습니다. 다양한 오류. 모든 것이 괜찮을 것이고 여기에 있는 이론은 아름답습니다. 그러나 그러한 통계를 수집하려면 각 언어에 대해 거대한 마크업 텍스트 코퍼스가 필요합니다(다시 말하지만 검색 엔진이 이에 가장 가깝습니다). 당연히 이를 수행하는 방법과 이 모든 것을 코드에서 누가 구현할 것인지에 대한 질문이 생겼습니다. 이전에는 누구도 이런 일을 해본 적이 없었기 때문에(사례를 알고 있다면 댓글에 링크를 게시하세요), 방법론은 처음부터 개발되었습니다. 여러 가지 아이디어가 있었지만 어느 것이 더 나은지는 사전에 명확하지 않았습니다. 따라서 개발은 아이디어 준비, 구현, 테스트, 품질 평가, 아이디어 개발 여부 결정 등을 순환적으로 수행할 것으로 예상했습니다.

기술의 구현은 세 단계로 나눌 수 있습니다. 각각에 대해 자세히 읽어보세요.

1단계. 문제의 형성. 첫 번째 갈퀴

주목!이 줄 뒤에는 가능한 한 간단한 언어로 설명하려고 노력한 많은 용어가 있습니다.

추가적인 정보(사전, 빈도, 로그)가 없기 때문에 우리가 가지고 있는 자원으로 문제를 해결하려는 시도가 있었습니다. 우리는 시도했다 다양한 방법클러스터링. 주요 아이디어는 같은 그룹의 단어가 너무 많이 다르지 않아야 한다는 것입니다.

클러스터링- 개체 샘플에 대한 정보가 포함된 데이터를 수집한 다음 개체를 비교적 동질적인 그룹으로 배열하는 절차입니다.

레벤슈타인 거리무엇을 보여줍니다 최소한의 금액라인 A를 변경(삭제, 삽입 및 교체)해야 라인 B를 얻을 수 있습니다.

• 기호 대체: sh[e]res — sh[i]res, sh[o]res;
• 기호 삽입: sheres - s[p]heres;
• 제거: 골[d][f] - 골프, 금.

각 예에서 철자가 틀린 단어와 올바른 형식 사이의 거리는 1 수정입니다.

바이그램 및 트라이그램의 Jaccard 계수얼마나 많은지 알아내는 데 도움이됩니다. 일반적인 조합 A행과 B행에는 2자 또는 3자의 음절이 있습니다.

예: A = 스노우보드, B = 경계선을 생각해 보겠습니다. 일반식바이그램 계수의 형식은 다음과 같습니다.

J = (A와 B에 대한 동일한 바이그램 수) / (A와 B에 있는 총 바이그램 수)

라인을 바이그램으로 분할해 보겠습니다.

A에 대한 바이그램 = ( sn, no, ow, wb, bo+, oa, ar, rd+ ) - 8개; B에 대한 바이그램 = ( bo+, or, rd+, de, er ) - 5개; 더하기 기호(bo 및 rd)가 표시된 두 개의 동일한 바이그램이 있습니다.

트라이그램의 경우 유사하며 두 글자 대신 세 글자만 사용됩니다. 이에 대한 Jaccard 계수는 다음과 같습니다.

더 유사한 단어의 예:

A = 야구, B = baaeball ( ba+, as, se, eb+, ba+, al+, ll+ ) ( ba+, aa, ae, eb+, ba+, al+, ll+ ) J = 5 / (7 + 7 - 5) = 0.56

Jaccard 계수는 더 빠르게 작동하지만 단어의 음절 순서를 고려하지 않습니다. 따라서 Levenshtein 거리와의 비교를 위해 주로 사용되었다. 이론적으로는 모든 것이 간단했습니다. 작은 데이터에 대한 클러스터링 기술은 해결하기 매우 쉽지만 실제로 분석을 완료하려면 컴퓨팅 파워또는 수년의 시간(이상적으로는 둘 다)입니다. 2주간의 작업 끝에 Python으로 스크립트가 작성되었습니다. 실행되면 파일의 문구를 읽고 그룹 목록을 다른 파일로 출력합니다. 동시에 다른 프로그램과 마찬가지로 이 스크립트는 프로세서를 로드하고 RAM을 사용했습니다.

테스트된 대부분의 방법에는 테라바이트의 메모리와 몇 주간의 CPU 시간이 필요했습니다. 우리는 프로그램에 2GB의 메모리와 1개의 코어가 필요하도록 방법을 조정했습니다. 그러나 약 4~5일 만에 백만 건의 요청이 처리되었습니다. 그래서 작업 완료 시간은 아직 아쉬운 점이 많습니다. 알고리즘의 결과는 작은 예를 사용하여 그래프 형태로 표시될 수 있습니다.

클라이언트 프로젝트에 적용하면 이는 동일한 클러스터의 요청과 일치하는 페이지가 301 리디렉션을 통해 함께 접착된다는 의미입니다. 우리의 목표는 오류가 있는 문구 페이지에서 올바른 문구가 있는 클라이언트 사이트 페이지로 리디렉션을 배치하기 위한 명확한 작업 메커니즘을 만드는 것이었습니다. 하지만 이 예에서도 단점은 분명합니다.

1. 그룹에서 찾는 방법이 명확하지 않습니다. 올바른 형태그리고 그들이 거기에 있는지 여부.
2. 어떤 오류 임계값을 사용해야 하는지는 알려져 있지 않습니다. 임계값이 크면(오류가 3개 이상) 그룹이 매우 크고 흩어지게 됩니다. 너무 작으면 각 단어가 자체 그룹을 형성하게 되는데 이는 역시 우리에게 적합하지 않습니다. 모든 집단이 수용할 수 있는 보편적인 의미를 찾는 것은 불가능합니다.
3. 동시에 여러 그룹으로 분류될 수 있는 단어를 어떻게 해야 할지 명확하지 않습니다.

2단계. 단순화. 새로운 희망

우리는 알고리즘을 재설계하여 기존의 기계적 문법 교정기에 더 가깝게 만들었습니다. 다행히도 충분합니다. Python 라이브러리 Enchant가 기본으로 선택되었습니다. 이 라이브러리에는 전 세계 거의 모든 언어에 대한 사전이 있으며 사용이 매우 간단하고 수정해야 할 사항에 대한 힌트를 얻을 수 있습니다. 이전 단계에서 우리는 쿼리 유형과 이러한 쿼리가 어떤 언어로 사용될 수 있는지에 대해 많은 것을 배웠습니다.

에서 오픈 액세스다음 사전이 수집되었습니다.

• 영어(영국);
• 영어(미국);
• 독일 사람;
• 프랑스 국민;
• 이탈리아 사람;
• 스페인의;
• 러시아인;
• 우크라이나 인.

1. 그것이 정확하다면(사전 중 하나에 있음) 그대로 둡니다.
2. 그것이 틀리면 단서 목록을 얻고 가장 먼저 나오는 단서를 선택합니다.
3. 우리는 모든 단어를 다시 한 문구로 합쳤습니다. 이전에 그러한 문구를 본 적이 없다면 해당 문구에 대한 그룹을 만듭니다. 문구의 수정된 형태가 "중심"이 됩니다. 만약 그렇다면, 이 문구는 이미 자신의 그룹을 가지고 있다는 것을 의미하며 거기에 새로운 잘못된 형태를 추가합니다.

그 결과, 우리는 그룹의 중심과 이 그룹으로부터 단어 목록을 받았습니다. 물론 여기에서는 모든 것이 처음보다 나아졌지만 숨겨진 위협. 프로젝트의 특성상 쿼리에 고유명사가 많이 포함되어 있습니다. 사람의 성과 이름, 도시, 조직, 지리적 영역, 심지어 공룡의 라틴어 이름까지 있습니다. 이 외에도 음역이 잘못된 단어를 발견했습니다. 그래서 우리는 문제를 해결할 수 있는 방법을 계속해서 모색했습니다.

3단계. 보충제와 깨어난 포스

음역 문제는 아주 간단하고 전통적으로 해결되었습니다. 먼저, 우리는 키릴 문자와 라틴 문자 사이의 대응 사전을 만들었습니다.

이에 따라 검사 대상 단어의 각 문자를 변환하고 결과 단어에 대한 사전 수정이 있는지 확인했습니다. 음역 옵션에 오류가 가장 적은 경우 이를 올바른 것으로 선택했습니다. 하지만 고유명사는 좀 까다롭습니다. 제일 간단한 옵션보충 사전은 Wikipedia 덤프에서 가져온 단어 모음인 것으로 밝혀졌습니다. 그러나 Wiki에는 자체적인 약점. 거기에는 철자가 틀린 단어가 꽤 많고, 이를 필터링하는 방법은 아직 이상적이지 않습니다. 우리는 다음으로 시작하는 단어의 데이터베이스를 편집했습니다. 대문자, 앞에 구두점이 없습니다. 이 단어들은 고유명사의 후보가 되었습니다. 예를 들어, 이러한 텍스트를 처리한 후 밑줄 친 단어가 사전에 추가되었습니다.

알고리즘을 구현해 보면 인챈트의 증강사전에서 단서를 찾는 데 가끔 단어당 3초 이상이 소요되는 것으로 나타났다. 이 프로세스의 속도를 높이기 위해 Levenshtein 자동 장치 구현 중 하나가 사용되었습니다.

간단히 말해서, 기계의 아이디어는 기존 사전을 사용하여 전환 방식을 구축한다는 것입니다. 동시에 우리는 얼마나 많은 단어 수정이 허용되는지 미리 알고 있습니다. 각 전환은 단어의 문자에 대해 일종의 변형을 수행한다는 것을 의미합니다. 문자를 그대로 두거나 삭제, 대체 또는 삽입과 같은 수정 유형 중 하나를 적용합니다. 그리고 각 정점은 단어를 변경하는 옵션 중 하나입니다.

이제 확인하고 싶은 단어가 있다고 가정해 보겠습니다. 거기에 오류가 있으면 우리에게 맞는 모든 형태의 수정을 찾아야 합니다. 일관되게 우리는 확인되는 단어의 글자를 통해 계획에 따라 이동하기 시작합니다. 글자가 다 떨어지면 하나 이상의 꼭지점에 도달하게 되고 올바른 단어에 대한 옵션이 표시됩니다.

이미지는 가능한 두 가지 오류가 모두 포함된 food라는 단어를 입력하는 기계를 보여줍니다. 위쪽 화살표는 현재 위치에 문자를 삽입하는 것을 의미합니다. 별표가 있는 대각선 화살표는 대체를 의미하고 엡실론이 있는 화살표는 삭제를 의미하며 가로 화살표는 문자가 변경되지 않음을 의미합니다. fxood라는 단어를 사용하겠습니다. 이는 기계 00-10-11-21-31-41의 경로에 해당합니다. 이는 단어 food에 f 뒤에 문자 x를 삽입하는 것과 같습니다.

또한, 우리는 추가 업무수집된 기본 사전을 확장하려면 사전이 아닌 문구(제품 모델명 및 다른 식별자) V 자동 모드, 추가 사전에서 음역 및 검색을 도입했습니다.

결과는 무엇입니까?

우리는 여전히 알고리즘을 업그레이드하기 위해 노력하고 있지만 이미 이 단계에서개발 과정에서 우리는 태그 클라우드와 같은 쓰레기를 정리하고 301 리디렉션을 병합할 수 있는 도구를 얻었습니다. 불필요한 페이지. 이러한 도구는 소수의 철자가 틀린 단어에 특히 효과적이지만 대규모 배열에서도 상당히 만족스러운 결과를 보여줍니다. 연결 블록을 형성하기 위해 스크립트의 중간 버전이 클라이언트로 전송되었습니다. 이 블록에서 수집이 가능합니다 추가 정보쿼리 수정에 대해 우리는 아직 스크립트 품질을 개선하기 위해 노력하고 있기 때문에 구현을 위해 스크립트의 전체 결과를 보내지 않았습니다.

수학자이자 분석가가 코드를 작성하고 테스트하는 데 총 40시간이 걸렸습니다. 결론: 언젠가 약 200만 개의 요청을 처리해야 한다면 절망하지 마십시오. 이러한 작업은 자동화될 수 있습니다. 100% 정확도를 달성하는 것은 매우 어렵다는 것은 분명하지만, 정보의 최소 95%를 정확하게 처리하는 것은 가능합니다.

• 인덱스는 MyISAM 테이블의 필드에서만 생성될 수 있습니다.
• 인덱스 크기는 데이터 크기의 약 절반입니다. 그러나 텍스트 자체 저장을 비활성화할 수는 없으므로 이 50%에 100%를 추가해야 합니다. 즉, 데이터가 저장됩니다.
• 인덱싱 속도는 순수 형태에서 약 1.5MB/s로 괜찮습니다. 여전히 형태소 분석기를 통해 실행해야 한다는 것이 분명합니다. 동일한 데이터베이스에서 데이터를 즉시 가져와서 러시아 Snowball 형태소 분석기의 Perl 포트를 통해 실행하여 인덱스를 채우면 314KB/s를 얻게 됩니다. 실제로 MySQL에는 형태소 분석기를 플러그인("전체 텍스트 파서 플러그인")과 연결하기 위한 아키텍처가 있지만 어쩐지 플러그인 자체가 없습니다... :)
• 내장형 형태소 분석기가 없고 영어 불용어가 내장되어 있으며 직접 추가할 수 없습니다. 기본적으로 부울 검색은 "OR"이므로 "AND"를 사용하여 검색하려면 각 단어를 "+단어"로 바꿔야 합니다.
• 부울 검색과 일반("자연어") 검색이라는 두 가지 모드가 있습니다. 부울 검색은 문서에 단어가 있는지 확인하고 부울, 구문 및 접두사 검색을 지원하지만 관련성 점수(0 또는 1만)를 반환하지 않습니다. 일반검색관련성을 수행할 수 있지만 연산자는 수행할 수 없습니다. 따라서 두 가지를 모두 지원하려면 두 가지 모드에서 동일한 요청을 실행해야 합니다.
  • MySQL의 접두사 검색 매혹적인느린. 몇 단어를 접두사로 확장하면 쉽게 15~40초가 걸릴 수 있습니다. 따라서 전혀 사용할 필요가 없습니다.
• 동시에 여러 필드에서 검색할 수 없습니다. 즉, MATCH() 구문에서는 이를 허용하지만 검색 최적화는 발생하지 않지만 전체 검색이 발생합니다. 따라서 (select id where match(field1) ...) UNION (select id where match(field2) ...) 이라고 쓰는 것이 좋습니다.
• 무작위 버그 제목에서 가져온 쿼리에 대한 검색 속도는 1000개로 제한됩니다.
  • 3개 단어의 5개 스레드 - 평균 175ms, 최대 3.46초.
  • 3개의 단어에 대한 5개의 스레드에서 처음 10개의 결과는 동일합니다.
  • 2개 단어의 5개 스레드 - 평균 210ms, 최대 3.1초.
  • 3 단어의 1 스레드 - 평균 63ms, 최대 764ms.
  • 주로 발견된 수량에 따라 다릅니다.
• 가장 큰 장점은 "스파크" 검색이 가능하다는 것입니다.

스핑크스(2.0.1-베타)

• 분리된 검색 서버. 다양한 언어에 대한 인터페이스 라이브러리가 있습니다. 0.9.9에서는 "네이티브" 인터페이스 외에도 SphinxQL이 나타났습니다. 이는 MySQL 프로토콜, 즉 일반 MySQL 클라이언트를 사용하는 Sphinx에 대한 SQL 인터페이스입니다.
• 처음에는 Sphinx에 업데이트된(실시간) 인덱스가 없었습니다. Sphinx가 할 수 있는 유일한 일은 전체 인덱스를 구축한 다음 검색하는 것이었습니다.
• 여전히 인덱스의 문서를 올바르게 업데이트/삭제하는 방법을 모르고 정상적으로 추가만 합니다. 제거는 "를 확인하여 수행됩니다. 오래된 게시물”를 선택한 다음 매번 모든 검색 결과에서 해당 항목을 제거합니다.
• 실시간 인덱스는 모든 것을 지원하지 않습니다. 예를 들어 접두어/중위어 및 MVA를 지원하지 않습니다.
• 인터페이스와 기능이 약간 혼란스럽습니다. SphinxQL을 통해서만 실시간 인덱스를 업데이트합니다. 검색 구문은 세 가지 인터페이스(일반, SphinxQL, SphinxSE) 모두에서 다릅니다. 5개의 검색 모드 중 4개는 더 이상 사용되지 않습니다. 인덱서는 실시간 인덱스를 다시 작성할 수 없습니다. SphinxQL을 사용하여 인덱스를 TRUNCATE하는 것은 불가능하며 인덱스에 얼마나 많은 레코드가 있는지 확인할 수 없습니다.
• 이것이 단점이 끝나는 곳입니다. 자체 프로토콜이나 MySQL 프로토콜을 사용하여 통신할 수 있는 검색 서버가 있습니다. 다양한 가능성, 매우 빠르게 인덱스 및 검색을 수행하며 인덱스 크기는 데이터의 약 1/3입니다. 정확한 단어 형태의 색인을 활성화하면 2배로 증가할 수 있습니다.
• 내장된 러시아어, 영어, 체코어 형태소 분석기, Soundex 및 Metaphone 전처리기(영어 단어를 소리별로 비교하기 위해). 다른 언어의 형태소 분석기도 연결할 수 있으며 --with-libstemmer 키를 사용하여 빌드하기만 하면 됩니다. 물론 불용어에 대한 지원도 있습니다. 동의어도 있고 일반적인 동의어도 있으며 특수 문자를 포함할 수 있는 "토큰화 예외"도 있습니다. 또한 "blend_chars"(예를 들어 "AT&T"가 "AT", "T" 및 "AT&T"라는 단어가 되도록 구분 기호이자 단어의 일부로 간주되는 문자)도 있습니다.
• 멋지고 특이한 기능 중에는 중위 검색(하위 문자열로 빠르게 검색하려는 사용자를 위한), 다중 값 필드(MVA), 단락 및 문장별 색인, 심지어 사전 정의된 HTML 태그의 내용별 색인도 가능합니다. 또한 따옴표 등으로 검색된 단어를 강조 표시할 수도 있습니다. 그러나 업데이트된 인덱스에서는 MVA 및 중위가 지원되지 않습니다(아직?).
• 인덱싱은 매우 빠릅니다. 실시간 인덱스의 순 속도는 6.7MB/s(SQL 덤프 다운로드)이고 일반 인덱스의 경우 일반적으로 12MB/s(xmlpipe2 덤프 다운로드)입니다. "불결한" 속도(Perl에서, MySQL에서 즉시 데이터를 읽는 경우) - 4.5MB/s. 중위를 사용하면 모든 것이 자연스럽게 많이 느려집니다. 440KB/s, I/O 힙은 10.5GB, 330MB 데이터에 대한 인덱스 크기는 3GB입니다.
• 검색은 일반적으로 반응적입니다.
  • 3개 단어의 5개 스레드 - 평균 7ms, 최대 75ms.
  • 2개 단어의 5개 스레드 - 평균 7ms, 최대 81ms.
  • 3개 단어의 5개 스레드에서 처음 10개의 결과는 평균 5ms, 최대 57ms입니다.
  • 3 단어의 1 스레드 - 평균 2ms, 최대 35ms.

사피안(1.2.6)

• 도서관, 준비된 서버검색이 없습니다. C++ API는 꽤 제정신입니다. 경쟁적인 작품(많은 독자, 1명의 작가)을 지원하는 것 같습니다.
• 사용 가능한 바인딩이 많이 있습니다. 다른 언어들: C++, 자바, Perl, Python, PHP, Tcl, C#, Ruby, Lua.
• 인덱스는 역 B-트리 기반 인덱스입니다.
• 멋진 점은 Xapian이 특별히 전체 텍스트 인덱스로 사용될 필요가 없다는 것입니다. 사실 Xapian은 "단어"에 제한이 없기 때문에 원하는 대로 사용할 수 있는 반전된 인덱스를 구현한 것일 뿐입니다. 245바이트의 길이 제한을 제외하고 문서에 포함되어 있습니다. 이론적으로는 데이터베이스로 사용할 수 있습니다.
• 솔직히 형편없는 문서입니다. 아직 모든 것을 포함하지 않는 일종의 정보 모음입니다. 몇 가지 사항을 이해하려면 어리석게도 코드에 접근해야 합니다. 나는 뻔뻔스러워서 이 주제에 버그 564를 추가했습니다. 글쎄요, 사실입니다. 엔진이 꽤 좋아 보이지만 이에 대해 아는 사람은 거의 없습니다.
• 테스트를 시작했을 때 이상한 버그, 즉 Image::Magick이 병렬로 로드되는 경우 데이터베이스 생성을 허용하지 않는 libuuid의 segfault를 발견했다는 것이 재밌습니다. 이것은 심지어 ImageMagick 버그도 아닌 것으로 밝혀졌습니다. 그러나 더욱 심각한 것은 libc6 버그였습니다! 2.12와 2.13에서는 라이브러리의 동적 로딩 중 스레드 로컬 저장소의 초기화가 깨졌습니다. 2.14에서 수정되었지만 데비안은 여전히 ​​2.13입니다. 나는 데비안에 버그 637239를 추가했습니다(젠투와 libc 자체의 버그에 대한 링크도 있습니다).
• Perl 바인딩은 백엔드를 선택할 수 있으려면 마무리가 필요하며 기본적으로 최신 Brass가 아니라 안정적인 Chert입니다. 마무리는 쉽습니다. 나는 또한 그들에게 이 주제에 대한 버그(버그 565)를 제공했습니다.
• 색인의 다른 필드에 대한 지원은 없는 것 같지만 각 단어의 시작 부분에 접두사를 추가하면 됩니다: http://xapian.org/docs/omega/termprefixes.html
  • 이것이 "공식적인 접근 방식"입니다. Xapian은 접두사만 지정하면 자체적으로 수행할 수 있습니다.
  • 이 접근 방식에는 최소한 한 가지 작은 단점이 있습니다. 기본적으로 쿼리는 모든 필드를 검색하지 않으며, 모두 검색하려면 수동으로 쿼리에 OR을 삽입해야 합니다.
  • 예, 문서가 다시 불완전하고 올바른 위치에 있지 않습니다. Xapian 매뉴얼에 있어야 하지만 이미 만들어진 간단한 CGI 검색 엔진인 Omega 매뉴얼에 있습니다.
  • 불쾌한 순간 - 빨리 발견됨 벌레쿼리 파서에서 - 필드(접두사가 있는)에서 단어 어간을 검색하기 위해 용어를 잘못 생성합니다. 인덱서는 시작 부분의 모든 어간에 접두사 "Z"를 할당합니다. 즉, 제목에 있는 단어 "idea"(예: 접두사 T)의 어간은 "ZTide"로 인덱싱됩니다. 그리고 쿼리 파서는 "Tida"로 검색을 시도하지만 당연히 아무것도 찾지 못합니다. 나는 이 주제에 대해 그들에게 버그 562를 주었다. 실제로 한 줄로 수정되었습니다.
• 형태소 분석기는 평소와 같이 Snowball "a에서 생성된 15개 언어에 대해 내장되어 있습니다. 불용어(물론)와 동의어에 대한 지원이 있습니다. 훨씬 더 흥미로운 점은 사전을 사용하지 않고 오타를 수정할 수 있지만 색인된 데이터를 기반으로만 수정할 수 있다는 것입니다( 예를 들어 "Xapain"의 경우 "완료되지 않은 쿼리", 즉 문자로 쿼리 문자를 입력할 때 힌트를 검색하는 기능도 지원됩니다. 실제로 이것은 검색의 마지막 단어에 *를 추가하는 것일 뿐이지만 쿼리 구문의 뉘앙스를 고려합니다.
• "Faceted Search"도 있습니다 - 전체 또는 전체에 대한 집계 값 계산 거의 모든 사람문서를 찾았습니다(예: 10,000개 제한). 즉, 이 10,000개의 문서는 귀하에게 반환되지 않지만 확인되고 일부 집계 값이 계산됩니다. 예를 들어, 이런 방식으로 10개의 결과(페이지)를 반환하는 동시에 "문서가 어떤 카테고리에서 발견되었습니까?"라는 질문에 답할 수 있습니다.
• 버그 256개마다 인덱싱할 때 플러시()(커밋)를 수행하면 속도가 ~1.5MB/s에서 412KB/s로 감소하고 I/O 작업 수가 10-20만큼 크게 증가한다는 것은 형편없는 일입니다. 타임스. 원칙적으로 이것은 모든 반전된 인덱스에 대해 명시적이고 논리적입니다. 업데이트된 토큰 수가 증가하기 때문에 한 번에 하나씩 업데이트하려고 시도하는 것보다 변경 사항을 누적하는 것이 훨씬 더 최적입니다.
• 색인의 크기 - 그들은 데이터의 크기와 거의 같다고 기록하지만 실제로는 2배 더 큽니다. 문서에 단어 위치를 저장하지 않으면 2배 작아집니다. 하지만 실례합니다. Sphinx도 위치를 저장하며 인덱스는 데이터가 2배 적습니다. xapian-compact(데이터베이스 조각 모음)를 실행하면 - 예, 인덱스는 감소하지만 여전히 약 1.7배 더 많은 데이터가 남아 있습니다.
  • 네, 이유가 발견되었습니다. Xapian은 항상 기본 단어와 정확한 단어 형태를 모두 색인화합니다. 정확한 형식의 색인 생성을 비활성화하는 것은 불가능합니다. 안타깝지만 이 주제에 대한 버그 563을 제공했습니다.
• 빠르게 검색합니다. 나는 이것을 이런 식으로 테스트했습니다. STEM_ALL 모드에서 버그 제목에서 가져온 최소 2자 길이의 여러 인접 단어를 검색하고("OR"이 아닌 "AND"로 검색했습니다) 각 단어를 바꿨습니다. with (단어 OR 제목: 단어 OR 비공개: 단어), 즉 하나가 아닌 세 개의 필드에서 검색하면 결과 수가 1000개로 제한되었습니다.
  • 3개 단어의 5개 스레드 - 평균 14ms, 최대 135ms.
  • 2개 단어의 5개 스레드 - 평균 29ms, 최대 137ms.
  • 3개 단어의 5개 스레드에서 처음 10개의 결과는 평균 2ms, 최대 26ms입니다.
  • 3 단어의 1 스레드 - 평균 7ms, 최대 51ms.
  • 검색 속도는 주로 발견된 결과 수에 따라 달라집니다. 검색 결과가 많을수록 검색 시간이 길어집니다.

Xapian에는 최신 Flint, Chert 및 Brass 순으로 3개의 백엔드(색인 자체 구현)가 있습니다. Debian의 오래된 안정, 안정적, 테스트와 같습니다. 1.2.x의 기본 백엔드는 Chert입니다. 플린트 이전에는 석영이 있었습니다.

PostgreSQL 텍스트 검색(9.1)

• GIN(Generalized Inverted iNdex)을 기준으로 인덱스가 반전됩니다. 이전에는 Oleg Bartunov와 Fedor Sigaev가 만든 Tsearch2라고 했습니다.
• 내장형 형태소 분석기, 중지 단어 지원, 동의어, 동의어 사전(개념 사전과 같은 것으로 단어를 다른 "선호 단어"로 대체), ISpell 사전(초기화 중에 속도가 매우 느리다고 알려져 있음)이 있습니다.
• 색인을 생성할 때 각 어휘소에 "가중치"를 첨부할 수 있습니다. 이는 실제로 "가중치"가 아니지만 Xapian 접두사, 즉 어휘소가 나온 필드의 이름과 유사합니다. 이러한 "가중치"는 A, B, C, D의 4개만 있을 수 있으며 나중에 검색할 때 사용할 수 있습니다. "가중치"가 있는 두 필드에서 tsVector "a를 구성하는 예: setweight(to_tsVector(coalesce(title,""), "A") || setweight(to_tsVector(coalesce(keyword,"")), "B") .
• 먹다 분리된결과 순위를 매기고 인용문에서 검색된 단어를 강조 표시하는 기능입니다. 순위는 위의 ABCD "가중치"("필드")에 숫자 가중치를 할당하여 수행할 수 있습니다. 또한 기본적으로 가중치는 (0.1, 0.2, 0.4, 1.0)과 같습니다.
• 인덱스 데이터 유형을 tsVector(텍스트 검색 벡터)라고 합니다. PostgreSQL을 사용하면 기능적 인덱스를 생성할 수 있으며 기본 매뉴얼에서는 이러한 인덱스만 생성하도록 제안합니다. - CREATE INDEX i ON t USING gin(to_tsVector(<поле>)). 그래서 여기 있습니다: 그러지 마세요!그렇지 않으면 요청 속도에 매우 불쾌하게 놀라게 될 것입니다. tsVector 유형의 별도 열을 생성하고, 여기에 tsVector "를 추가하고, 해당 열에 인덱스를 생성하세요.
  • 그 이유를 설명하겠습니다. 결과 순위 지정 기능은 별개이며, tsVector "와도 작동합니다. 저장하지 않으면 각 문서에 대한 요청마다 즉시 계산해야 하며 이는 성능에 매우 나쁜 영향을 미칩니다. , 특히 쿼리에서 많은 문서를 찾은 경우, 즉 쿼리에 관련성에 따른 정렬을 어리석게 포함하는 경우 - ORDER BY ts_rank(to_tsVector(field), ) DESC - MySQL보다 훨씬 느립니다 :).
  • 동시에 최적화로서 디스크 공간, 저장할 수 없습니다 전문인덱스의 문서.
• 검색 연산자에는 AND, OR, NOT 및 접두사 검색이 포함됩니다. 근처에 있는 단어, 정확한 형태, 문구에 대한 검색은 없습니다.
• 텍스트 자체는 저장되지 않고 tsVector "만 저장되는 경우 인덱스 크기는 데이터 크기의 약 150%입니다.
• 인덱싱 속도 - 데이터가 1.5MB/s로 적은 반면, 인덱스가 커짐에 따라 천천히 떨어지지만, 텍스트 자체가 저장되지 않으면 안정되는 것 같습니다. 모든 동일한 Bugzilla 데이터의 경우 결과는 평균 522KB/s였지만 인덱싱이 끝날 무렵에는 처음보다 적었습니다.
• 검색 속도:
  • 3개 단어의 5개 스레드 - 평균 28ms, 최대 2.1초.
  • 2개 단어의 5개 스레드 - 평균 54ms, 최대 2.3초.
  • 3개 단어의 5개 스레드에서 처음 10개의 결과는 평균 26ms, 최대 611ms입니다.
  • 3 단어의 1 스레드 - 평균 10ms, 최대 213ms.

루씬, 솔르(3.3)

• Lucene은 Java 검색 라이브러리(서버가 아님)이므로 완전히 검토하고 테스트하기가 매우 어렵습니다. 엔진은 검토된 모든 항목 중에서 가장 강력하지만 가장 괴물스럽습니다.
• 이것이 Java로 작성된 라이브러리라는 사실이 주요 단점입니다. 다른 언어에서 Java에 액세스하는 것이 어렵기 때문에 Lucene도 인터페이스에 문제가 있습니다. :(. Java의 성능도 다소 저하될 수 있지만 그럴 가능성이 높습니다. 매우 무비판적이다.
  • 언어 바인딩 중에는 완전히 살아있는 PyLucene만 있습니다. Lucene이 탑재된 JVM이 Python 프로세스에 추가되고 특정 JCC가 상호 작용을 보장합니다. 하지만 그런 조합을 사용할지는 강력히 고려해볼 생각입니다...
• 상황을 개선하기 위해 Solr이 있습니다. 결국 XML/JSON/CSV 인터페이스를 사용하여 웹 서비스로 구현된 검색 서버입니다. 실행하려면 서블릿 컨테이너(Tomcat 또는 더 간단하게 만들려면 Jetty)가 필요합니다. 이제 다양한 언어로 작업할 수 있습니다.
• Lucene의 인덱싱 속도는 20MB/s 이상으로 "매우 빠르다"고 명시되어 있지만 메모리가 거의 필요하지 않으며(1MB부터) 증분 인덱싱(문서 하나에 대해)도 그만큼 빠릅니다. 설정된 문서를 한 번에 색인화하는 것과 같습니다. 인덱스 크기는 데이터 크기의 20~30%로 명시되어 있습니다.
• Lucene은 확장성이 뛰어나므로 특히 Solr 및 기타 라이브러리와 결합할 때 다양한 기능과 장치가 있습니다.
  • 31개의 내장 형태소 분석기, 다양한 분석기 - 소리 처리(Soundex, Metaphone 및 변형), 약어, 불용어, 동의어, "보호 단어"(불용어의 반대), 구문, 대상 포진, 단어 분리(Wi-Fi) , WiFi -> Wi Fi), URL 등 많은 다양한 옵션쿼리 생성(예: FuzzyLikeThisQuery - "주어진 쿼리와 유사한 쿼리" 검색)
  • 인덱스 복제, 검색결과 자동 클러스터링(그룹화)(Carrot2), 검색 로봇(Nutch), Tika를 사용하여 바이너리 문서(Word, PDF 등) 구문 분석을 지원합니다.
  • 일반 순위(hello, SEO)에 관계없이 특정 검색어에 대해 특정 결과를 "상승"시키는 가젯도 있습니다.
  • 그리고 그게 전부는 아닙니다.
• 인덱스 크기는 완전히 Lucene과 유사합니다(데이터의 20%). 중간 커밋 없이 요청당 256개 문서에 대한 Solr의 인덱싱 속도는 2.75MB/s였으며 1024개 문서마다 커밋할 경우 2.3MB/s였습니다. 커밋하지 않으면 더 많은 메모리를 차지합니다. 커밋하면 상주 메모리가 약 110MB이고 커밋하면 55MB입니다.
• Solr 검색 속도:
  • 3개 단어의 5개 스레드 - 평균 25ms, 최대 212ms.
  • 2개 단어의 5개 스레드 - 평균 35ms, 최대 227ms.
  • 3개 단어의 5개 스레드에서 처음 10개의 결과는 평균 15ms, 최대 190ms입니다.
  • 3 단어의 1 스레드 - 평균 11ms, 최대 79ms.

2.3.3.4, 루씬++ 3.0.3.4

• Lucene은 Java로 작성되었으므로 다양한 언어로의 여러 포트가 있으며 그 중 가장 활발한 것은 C++ 및 C# 포트( , Lucene++ 및 Lucene.NET)입니다. 다른 포트도 있지만 (반)폐기되거나 불안정합니다.
• CLucene에서도 모든 것이 완벽하지는 않습니다.
  • Lucene은 더 느리게 개발되고 있습니다. Lucene은 이미 3.3이지만 CLucene stable(0.9.2.1)은 여전히 ​​Lucene 1.9에 해당하며 형태소 분석기도 없고 CLucene "테스트"는 Lucene 2.3입니다.
  • 예를 들어 Perl 바인딩은 0.9.2.1만 지원하는 등 언어 바인딩이 거의 없습니다. "쓰기"라고 합니다 너 스스로" 몇 시간을 보낸 후 패치를 적용하고(작성자에게 버그 제공) 스테머에 대한 지원도 추가했는데, 다행스럽게도 2.3에는 여전히 존재합니다. 일반적으로 이러한 바인딩은 약간 눅눅합니다. 이미 다른 세그폴트를 포착하여 패치했습니다.
  • 분명히 버그가 있고 인터넷의 문서는 오래되었으며(그러나 소스에서 doxygen을 사용하여 일반 문서를 생성할 수 있음) 모든 것이 느리고 슬픈 SourceForge에서 호스팅되며 버그 추적기가 때때로 버그를 닫습니다. (아무도 응답하지 않으면 O_O ).
• 기능면에서 대부분의 Lucene 기능은 포트에 있습니다. 당연히 Solr 기능은 없습니다.
• CLucene 인덱싱 속도 - 3.8MB/s를 얻었습니다. Lucene에서 선언한 20+는 아니지만 이것은 형태소 분석기와 Perl 인터페이스를 통해 이루어지기 때문에 꽤 좋습니다.
• Lucene/Solr와 같은 인덱스 크기는 데이터 크기의 약 20%로 나타났습니다. 이는 모든 엔진 중 기록이며 명시된 20-30%에 해당합니다!
• Lucene++는 다음과 같은 점에서 CLucene과 다릅니다.
  • 구현이 더욱 완전하고 최신입니다(3.0.3.4). 예를 들어 불용어가 내장된 다양한 언어에 대한 분석기가 있습니다.
  • 루씬++ 어디에나 shared_ptr(C++ 템플릿을 사용하여 객체에 대한 참조 자동 계산)을 사용합니다. 게다가 이는 컴파일하는 동안에도 CLucene에 비해 시간이 매우 오래 걸립니다.
  • 바인딩은 CLucene보다 훨씬 더 나쁩니다. Python용으로 SWIG에 의해 생성된 반쯤 죽은 바인딩만 있습니다. 즉, 아마도 개자식처럼 흐르고 작동하는지 여부는 일반적으로 알 수 없습니다. Perl을 이러한 shared_ptr에 정상적으로 바인딩하는 방법을 즉시 이해하십시오.
  • 버그 추적기에 버그가 9개만 있는 것으로 판단하면 Lucene++는 거의 사용되지 않는 것 같습니다.
• 검색 속도 - 단어를 논리합으로 바꾸는 대신 MultiFieldQueryParser만 사용하는 Xapian 측정과 유사한 측정:
  • 3개 단어의 5개 스레드에서 평균 10ms, 최대 212ms를 얻습니다.
  • 2개 단어의 5개 스레드 - 평균 19ms, 최대 201ms.
  • 3개 단어의 5개 스레드에서 처음 10개의 결과는 평균 3ms, 최대 26ms입니다.
  • 3 단어의 1 스레드 - 평균 4ms, 최대 39ms.
  • 다시 말하지만, 이는 주로 검색의 복잡성에 대한 참고 사항에 해당하는 발견된 수량에 따라 달라집니다.

탱크에 있는 사람들을 위해

• 역색인은 문서를 단어 집합과 일치시키는 직접 색인과 달리 각 단어를 해당 단어가 나타나는 문서 집합과 일치시킵니다. 거의 모든 전체 텍스트 검색 엔진은 직접 색인보다 업데이트하기가 더 어렵지만 검색 속도가 빠르기 때문에 역색인을 사용합니다.
• Stemmer - 영어 단어 "stem"에서 유래 - 단어의 기초. 그는 단어의 어미를 깨물어 줄기로 만듭니다. "cat"이라는 단어가 "cats" 및 "cat" 등과 일치하도록 디자인되었습니다. Snowball - 형태소 분석기 작성을 위한 DSL입니다.
• 불용어는 매우 자주 사용되는 단어(전치사, 접속사 등)의 목록으로, 의미가 거의 없고 거의 모든 곳에서 발견되기 때문에 색인 생성에 의미가 없습니다.
• 위치 정보 - 문구 또는 단어를 추가로 검색하기 위해 인덱스에 저장된 문서의 단어 위치입니다.
• 접두사 검색(단어*) - 특정 단어로 시작하는 단어를 검색합니다(예: 고양이*). 와일드카드 검색이라고도 하지만 엄밀히 말하면 와일드카드 검색은 주어진 접두사로 시작하고 주어진 접미사로 끝나는 단어를 검색하는 것입니다(예: ko*a - "cat"과 "koala"라는 단어를 모두 찾습니다). .
• Bugzilla는 검색이 테스트된 콘텐츠에 대해 당사에서 사용되는 오픈 소스 버그 추적기입니다.

비교표

결과 순위 지정 및 다양한 필드별 정렬은 어디에서나 가능합니다.

추가로:

결론

가장 간단하고 빠른 엔진은 Sphinx입니다. 단점은 업데이트된 인덱스가 아직 그다지 유용하지 않다는 것입니다. 인덱스에서 아무것도 삭제하지 않는 경우에만 사용할 수 있습니다. 이 문제가 해결되면 선택 문제가 완전히 사라지고 Sphinx가 모든 작업을 수행합니다.

또한 빠르고 매우 기능이 풍부하며 효율적이고 확장 가능하지만 사용하기 가장 쉬운 엔진은 아닙니다 - Lucene. 인터페이스의 주요 문제는 Java 또는 C++ 포트와 바인딩 문제입니다. 즉, Java, C++, Python 또는 Perl로 작성하지 않는 경우 Solr를 사용해야 합니다. Solr는 이미 약간의 메모리를 소비하고 조금 더 느리게 색인화하고 검색합니다. 서블릿 컨테이너에 별도의 Java 서버를 두는 것은 불편할 수 있지만 엄청나게 다양한 기능을 갖추고 있습니다.

Xapian... 검색이 빠르고, 색인이 잘 안되고, 색인 자체가 너무 큽니다. 그 장점은 다양한 언어(C++, Java, Perl, Python, PHP, Tcl, C#, Ruby, Lua)에 대한 다양한 인터페이스입니다. 모드가 정확한 형식의 인덱싱을 비활성화하는 것으로 나타나면 인덱스 크기가 즉시 2배로 줄어듭니다.

이미 PostgreSQL을 사용하고 있고 매우 높지 않은 인덱싱 속도와 까다로운 검색 연산자가 전혀 없는 상황을 참을 의향이 있다면 Textsearch를 사용할 수 있습니다. 왜냐하면 MySQL보다 검색 속도가 빠르고 다른 것과 상당히 비슷하기 때문입니다. 그러나 인덱스는 to_tsVector() 표현식이 아닌 tsVector 유형의 실제 열에서 생성되어야 한다는 점을 기억해야 합니다.

MySQL FULLTEXT는 데이터베이스가 작은 간단한 경우에도 사용할 수 있습니다. 그러나 어떤 경우에도 MATCH(여러 필드)를 수행해서는 안 되며 어떤 경우에도 접두어 검색을 사용해서는 안 됩니다.

이 문서의 모든 편집 내용은 다음 복제 세션 중에 덮어쓰여집니다. 기사 본문에 대해 심각한 의견이 있는 경우 "토론" 섹션에 적어주세요.

디지털 카메라가 등장한 이후로 우리에게는 사진이 부족하지 않게 되었습니다. 실제로 야후! 2014년에는 8억 8천만 장의 디지털 사진을 받게 될 것으로 추산됩니다.

우리는 사진이 부족한 적이 없습니다. 반대로 이 광활한 바다에서 필요한 이미지를 정확히 찾는 것이 훨씬 더 어렵습니다.

물론 이는 찾고 있는 이미지 유형에 따라 달라질 수 있습니다. 컴퓨터, 책, 꽃 등 자주 사진을 찍는 것을 찾고 있다면 오래 찾을 필요가 없습니다. 마음대로 사용할 수 있는 좋은 사진이 수십 장 있습니다.

동시에 덜 일반적인 대상이나 추상적인 개념(예: 화창한 날이나 특정 유형의 꽃)을 요청해 보세요. 이것은 훨씬 더 어려울 수 있습니다. 어려움 중 하나는 완벽한 이미지가 존재하더라도 찾을 수 있는 방식으로 라벨을 붙일 수 없다는 사실에서 비롯됩니다.

이러한 경우, 무료 이미지를 찾기 위해 다양한 사이트를 검색하는 데 많은 시간을 소비하지만 여전히 아무것도 얻지 못할 수 있습니다. 오. 이것이 무료 이미지 사이트에 수많은 상업용 저장소가 광고되는 이유를 설명합니다. 검색 기능은 광고 비용을 지불할 가치가 있는 경우가 많습니다.

따라서 이를 방지하려면 무료 이미지 검색 서비스를 사용해 보세요.

무료 이미지 검색 엔진

이러한 무료 이미지 검색 엔진의 장점은 (이론적으로) 동시에 여러 무료 이미지 사이트를 검색한다는 것입니다. 그러나 실제로는 수십 개가 아닌 소수의 사이트만 존재하는 경우 몇 가지 문제가 있습니다. 어쨌든 아무것도 아닌 것 이상이지만 이러한 이미지 검색 서비스가 강력하기를 원한다면 좀 더 현실적인 관점을 취하는 것이 좋습니다.

이 기사에서 논의할 7개 검색 엔진의 품질을 비교하는 것은 상당히 어렵습니다. 먼저, 각각에서 동일한 쿼리를 실행하고 결과를 비교하고 싶었습니다.

그러나 몇 가지 매우 인기 있는 용어를 사용해본 결과 (특히 "컴퓨터") 일부 시스템에서는 수천 개의 결과를 받았지만, 덜 인기 있는 다른 시스템에서는 동시에 아무 것도 받지 못했습니다( 아마도 내가 잘못된 키워드를 사용했기 때문일 수도 있습니다.), 나는 그러한 테스트가 잘못된 결과를 초래할 수 있다고 결정했습니다.

더욱이 이러한 검색 엔진은 매일 새로운 이미지의 색인을 생성하므로 오늘 일부 시스템에 "맑은 날"이라는 검색어에 대한 이미지가 하나도 없더라도 내일 시스템이 이러한 이미지를 수십 개 추가할 수도 있습니다.

따라서 저는 이 7개 서비스의 검색 품질을 비교하지 않을 것입니다. 검색에 포함된 사진 수나 사이트 수와 같은 몇 가지 일반적인 사실뿐만 아니라 해당 서비스와 함께 작업한 소감을 말씀드리겠습니다. 색인.

검색 엔진 자체를 검토하기 전에 약간의 조언을 드립니다. 검색 결과 상업용 무료로 표시된 이미지가 반환되더라도 항상 소스 사이트 자체를 확인하여 최신 라이센스를 확인하세요.

한때 자유 소프트웨어로 라이센스가 부여된 이미지가 나중에 작성자의 마음이 바뀌었기 때문에 라이센스가 변경되었을 가능성이 있습니다. 따라서 이미지를 사용하기 전에 항상 라이선스를 확인하시기 바랍니다.

1. 구글 이미지

우리 중 많은 사람들에게 Google 이미지는 첫 번째( 그리고 종종 유일한 사람) 상업적 용도로도 승인된 로열티 프리 이미지를 검색하려면 선택하세요. Google 이미지를 통해 무료 이미지를 검색하려면 검색 필드에 키워드를 입력하고 Enter 키를 누른 다음 이미지 탭(1)을 선택하세요.

구글 이미지

그런 다음 버튼을 클릭하십시오. 검색 도구" (2) 검색 옵션 목록을 열고 "를 선택합니다. 사용권"(삼). 드롭다운 메뉴에서 귀하에게 적합한 라이선스를 선택하세요.

Google의 검색 선택은 일반적으로 좋습니다. 매우 인기 있는 용어의 경우 엄청난 수의 이미지를 찾을 수 있습니다. 운 좋게도 종종 하위 결과를 제공합니다. 예를 들어, 컴퓨터의 경우 검색 범위를 좁힐 수 있도록 Apple, 노트북, 사진, 배경화면, 부품, PNG 등과 같은 카테고리를 제공합니다.

덜 인기 있는 용어와 덜 제한적인 사용 권한의 경우 선택의 폭이 넓지 않습니다. 특히 변경 기능이 있든 없든 자유롭게 재사용할 수 있는 자료를 찾고 있는 경우 적합한 것을 찾지 못하는 경우가 매우 많습니다. 이런 경우에는 다른 이미지 검색 서비스를 이용해 보시기 바랍니다. 그 중 하나는 아래에서 설명하겠습니다. 시간이 많이 걸리지 않습니다.

2. CC 검색

CC 검색, ( 크리에이티브 커먼즈 검색(Creative Commons Search)의 약어)은 Creative Commons 라이선스에 따라 라이선스가 부여된 이미지에 대한 또 다른 주요 검색 엔진입니다.

그들이 말했듯이 기술적으로 검색 엔진은 아니지만 Europeans, Flickr, Google Images, Wikimedia Commons, Fotopedia, Open Clipart Gallery, Pixabay와 같은 다른 여러 사이트에서 검색 결과를 제공하는 것으로 보입니다.

문제는 CC 검색이 이러한 사이트를 모두 한꺼번에 검색하지 않는다는 점입니다. 대신 검색어를 입력하고 검색하려는 위치를 선택하세요. 그다지 편리하지는 않지만 이 모든 사이트에서 직접 검색하는 것보다 여전히 빠릅니다.

CC 검색은 이미지 외에도 음악, 비디오 및 기타 미디어에 대한 결과를 제공합니다.

찾고 있는 내용을 지정할 수 있습니다. 즉, 상업적 용도로 무료로 사용할 수 있는 자료, 수정, 조정 및 기본으로 사용할 수 있는 자료, 또는 둘 다 가능합니다.

CC Search가 마음에 들었고 정기적으로 사용할 계획이라면 브라우저 추가 기능( 적어도 Firefox의 경우), 이는 사이트 액세스 속도를 높이는 데 도움이 됩니다.

크리에이티브 커먼즈는 '크리에이티브 커먼즈'를 의미하지 않습니다. 모두에게 무료" 귀하는 본 라이센스의 사용에는 모든 링크, 인증 및 기타 이용 약관이 적용된다는 점을 이해해야 합니다.

3.사진핀

Flickr는 아마도 인터넷에서 가장 큰 무료 이미지 저장소이므로 여러 이미지 검색 서비스가 Flickr에만 초점을 맞추고 있다는 것은 놀라운 일이 아닙니다. 포토핀(Photo Pin)도 그 중 하나입니다. 사이트를 열고 쿼리를 입력하면 다음과 같은 내용이 표시됩니다.

왼쪽에서 필요한 라이센스 유형을 선택할 수 있습니다( 예를 들어, 상업 또는 비영리) 및 결과를 정렬하는 방법( 새로운 첫 번째, 관련성, 흥미로운).

물론, 고급 검색을 통해 Flickr에서 직접 크리에이티브 커먼즈 콘텐츠를 검색하지 말아야 할 이유가 없습니다. 그러나 Photo Pin은 두 가지 이점을 제공합니다.

첫째, 라이센스가 있는 콘텐츠에만 집중하면 더 쉽습니다. 둘째, Photo Pin을 사용하면 적절한 크기로 쉽게 다운로드할 수 있으며 라이센스 링크를 복사하여 붙여넣을 수 있는 쉬운 옵션도 제공됩니다.

정말 편리한 서비스.

4.사진 찾기

Flickr만 검색하더라도 스스로를 "검색 엔진"이라고 부르는 다른 많은 서비스와 달리 PicFindr은 더 야심적입니다. 다양한 라이선스에 걸쳐 10개 이상의 무료 이미지 사이트를 검색합니다( 크리에이티브 커먼즈, GNU 및 기타).

사이트 목록에는 DreamsTime과 같은 일부 이미지 사이트의 무료 하위 섹션이 포함되어 있어 이 검색 엔진이 특히 유용합니다. 검색어를 입력하면 다음과 같은 내용이 나옵니다.

또한 PicFindr에는 더욱 유용한 몇 가지 추가 검색 옵션이 있습니다.

검색에 포함된 사이트 중 일부는 잘 알려지지 않은 반면, 인기 있는 사이트 중 일부는 어떤 이유로 누락되었지만 전체적으로는 매우 좋은 검색 엔진입니다.

5.비즐

Flickr와 Wikimedia Commons를 모두 검색하는 다른 검색 엔진을 사용해 볼 준비가 되었다면 Veezzle을 확인하세요. 사이트를 방문하고 검색어를 입력하면 다음 스크린샷과 같이 검색어를 더 구체적으로 만들 수 있습니다.

검색 버튼을 클릭하면 Flickr와 Wikimedia Commons의 결과가 별도로 표시됩니다. 관련성, 인기도, 업로드 날짜 등 결과를 표시하는 방법을 선택할 수 있습니다.

Veezzle은 Flickr와 함께 작동하는 또 다른 검색 엔진이지만 실제로 사용해 보기 전에 이 옵션을 닫지 마십시오. Flickr는 매우 거대하고 다양하므로 검색 엔진마다 다른 결과가 제공될 수 있습니다. 따라서 Veezzle을 사용하면 귀하에게 꼭 맞는 이미지를 찾을 수 있습니다.

6. 모든 스톡 사진

선택할 수 있는 거의 2,300만 개의 무료 사진이 있는 Every Stock Photo는 정말 검색하기에 좋은 장소입니다. 이 서비스는 여러 사이트를 검색합니다. 다른 검색 엔진에서 다루는 Flickr 및 Wikimedia Commons 외에도 Every Stock Photo는 MorgueFile, SXU, NASA 및 Photi와 같은 다른 위치에서 검색합니다.

고급 옵션을 사용하면 검색을 최적화할 수 있습니다. 라이센스 유형, 소스 및 표시할 항목을 선택할 수 있습니다( 허가, 라이센스, 출처). 개인적으로 Every Stock Photo는 Google 이미지 다음으로 제가 두 번째로 좋아하는 이미지 검색 엔진입니다. 하지만 사람마다 취향이 다르기 때문에 반드시 모든 사람에게 적합한 것은 아닙니다.

7.보라

이미 나열된 검색 엔진이면 충분할 가능성이 높지만 여기에 마지막 검색 엔진이 있습니다. 일부 다른 검색 엔진과 비교할 때 Behold는 Flickr의 결과만 표시하므로 불쌍한 사촌처럼 보입니다. 그러나 동일한 검색 엔진과 달리 Behold는 매우 빠르며 이는 큰 장점입니다.