검색엔진에서 DBMS 대신 직접 색인 루틴을 구현해서 사용하면 더 빠른가요?

superkkt의 이미지

안녕하세요.

요즘 검색엔진에 대해서 기웃거리다가 루씬에 대한 책을 읽어보았습니다. 루씬은 자체적으로 색인 루틴을 구현해서(책에서는 최고의 색인 방법이라고 하더군요) 사용하더군요.

책을 보다가 색인 루틴을 직접 구현하지 않고 간편하게 DBMS를 이용하면 될것 같은데 왜 어렵게 색인 루틴을 직접 구현해서 쓸까하는 궁금증이 생겼습니다.

그냥 단순히 덩치 큰 DBMS와 연동해서 쓰기가 불편해서(범용성을 위해?)인가요? 아니면 직접 색인을 구현하는것이 DBMS의 색인 능력보다 훨씬 더 빠르게 구현될수 있어서인가요?

그리고 실제 검색엔진에서 색인을 직접 구현해서 파일로 저장한다고 하더라도 원문은 어디에 저장하나요?

-PS-
이것저것 혼자 생각하다보니 궁금한게 많이 생겼습니다. ^^ 내일 서점가서 검색엔진 관련 책을 사려고 하는데 추천해주실만한 책이 있으면 추천 부탁드립니다. 일단 저는 아래 두권을 구매할까 합니다.

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788986172942&orderClick=LAA

http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788972832805&orderClick=LAA

kalstein의 이미지

specialize 를 해놓으면...범용 DBMS보다는 아무래도 빠르겠지요 ^^;;;

오버헤드도 일정부분 줄일수 있을테니까요...

그냥 간단히 생각해봐도...범용 DBMS중 하나인 오라클의 경우를 봐도..

일단 모든 row는 rowid를 꽤 큰 비트로 가지고...이리저리 복잡한 인덱스 정책을 가져가지요.

하지만 검색엔진 딱 하나를 위한 DBMS를 만든다면...상당히 컴팩트해지고 그만큼 가벼우니까

빨라질수 있지않을까요? ^^

물론...제생각에는 직접 제작하느니...;; 차라리 메모리DB나, DB튜닝을 하는게 훨씬 나아보이긴

합니다만;; 똑같은 실력으로 DBMS를 제작한다면 전용 DBMS를 제작하면 아무래도 좋겠죠~


------------------------------------------
Let`s Smart Move!!
http://kalstein.tistory.com/

frenzy의 이미지

루씬의 경우 파일의 내용은 인덱스 파일에 포함됩니다. 기본값이 1메가로 알고 있습니다.(변경가능합니다.) 저장하는 크기는 작게할 수 있으나, 정확한 검색결과를 원한다면 파일의 내용전체를 저장하는 것이 좋다는 개인적인 생각입니다. (저는 다 저장하고 있습니다. 까짓 텍스트파일커봤자 얼마나 클것이냐라는 생각으로... ^^) -> 그래서 풀텍스트 검색엔진이 아닐까 하는 생각....

그리고, DBMS 보다 당연히 색인을 구현한 검색엔진이 상식적으로 더 빠르다고 생각합니다. (사실은 빠릅니다. 덩치가 커질수록) DBMS 의 경우 검색에 최적화된 인덱스를 가지고 있지 않지만, 검색엔진은 오로지 검색을 위한 인덱스를 생성합니다.

루씬의 경우 검색된 문서에 대한 포인트를 가지고 있습니다. 루씬책에 보면 포인트계산법이 있습니다.
(저는 그냥 그림이라고 생각합니다.. -_-) 포인트 정렬로 출력할 수 있다는 점은 가장 큰 매력입니다.
그외에 일반적인 검색엔진에서 가지고 있는 거의 모든기능을 가지고 있습니다.

1. 문서에서 단어색인을 생성한다.
2. 문서마다 아이디를 생성한다.
3. 색인된 단어에 문서아이디를 value 로 지정한다.
4. 각 문서의 내용을 저장한다. (저장시에 검색필드와 검색하지 않을 필드로 구분)

여기까지가 인덱스생성

1. 입력된 단어를 단어색인에서 찾는다.
2. 찾은 단어색인에 포함된 문서아이디의 내용을 원하는 대로 파싱해서 출력한다. (출력방식은 게시판과 다를바가 없습니다.)

여기까지가 검색.

정확한 것인지...
단지 제가 루씬을 사용해서 프로그램을 작성한 경험에 의거해서... 끄적거려봅니다... :-)

(누가 제가 질문한 내용에 답을 해주시면 소주한잔 사겠습니다...)

혼자놀기의 도사가 되리라...
http://geek.hanbiro.com
:-)

.
++++++++++++++++++++++++++++++++++++++++++++++
혼자놀기의 도사가 되리라... http://geeklife.co.kr

M.W.Park의 이미지

정확히 이야기하자면, 파일의 내용은 포함될 수도 있고 포함되지 않을 수도 있습니다.
대상 파일의 위치나 DB table의 primary key 값 정도만 저장하고 있다가 가지고 와서 처리하는 경우가 더 유리할 수도 있습니다.

또한, 검색의 정확성과 전체 파일 내용 저장은 관련성이 없습니다.
추출되는 단어(lucene의 경우 analyzer들의 조합이 만들어내는 term)에 따라 사람이 느끼는 검색의 정확도는 달라지게 됩니다.

참고:
http://en.wikipedia.org/wiki/Inverted_index
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂

-----
오늘 의 취미는 끝없는, 끝없는 인내다. 1973 法頂

frenzy의 이미지

그렇군요..
:-)

검토한 결과 루씬의 경우 검색어와 관련된 요약내용을 출력할때(구글과 같이) 전체 내용이 없으면, 출력하기가 난감하더군요.
그래서 결국 전체내용을 저장하는 것으로 결론지었습니다.

pdf 등은 문서가 워낙커서 저장하는 크기에 제한을 두기는 했습니다.
(10메가짜리 pdf 를 txt 로 변환하니 200메가 넘어가는데 맞는건지..)

혼자놀기의 도사가 되리라...
:-)

.
++++++++++++++++++++++++++++++++++++++++++++++
혼자놀기의 도사가 되리라... http://geeklife.co.kr

qprk의 이미지

검색의 가장 기본 적인 원리는 frenzy 님이 설명하신 내용이 맞구요..

색인 결과를 저장하기 위하여 dbms 를 사용하지는 않습니다.
dbms 는 data를 잘 저장하기 위한 구조이기 때문에 data를 보존하기 위하여 수많은 안전장치 등 작업을 동시에 합니다.
하지만 검색엔진은 단지 빨리 찾기위한 구조로 되어 있기 때문에 각종 안전장치는 최소한으로 합니다. 어차피 data에 오류가 발생하면 버리고 새로운 색인을 구축하면 됩니다.. 색인 구축 대상은 하늘이 두쪽이 나도 data를 잘 저장하고 있는 dbms 에 잘 저장되어 있으니까요..

실제로 이런 일들은 아주 빈번하게 일어납니다. 심지어 사소한 설정 변경때문에라도 모든 data를 다시 색인 해야 하는 경우가 아주 많습니다..

보통 검색엔진은 역파일 이라는 색인 집단을 생성합니다.. 루씬도 마찬가지이구요..
이 역파일의 주된 정보는
단어가 어떤 문서에서 발견되었나.. 를 저장하는 역할 입니다..
거기다가 각 문서에서 해당 단어가 얼마나 중요한가를 추측하여 '검색어' 에 대한 문서정확도를 계산하는 기본 정보를 저장하고 있습니다. (정확도는 루씬 책의 3장에 있내요 )

위의 이유가 dbms 를 사용하지 않는 가장 큰 이유입니다. 즉 속도가 느리다... 라는것입니다.
두번째 이유로는 역파일의 생성능력 또는 생성 방식에 따라 검색속도와 정확도가 차이가 나게 됩니다.. 이는 검색엔진의 핵심기술이기도 하기 때문에 공개되어 있지 않고.. 공개할 수 도 없는 내용이지요.. 이것을 일반 dbms 에 구축한다면 핵심 기술이 그대로 노출되는 결과가 나오겠내요..

두번째로 질문하신 원본 data 는 어디에 저장하는가? 하는것입니다..
앞서 조금 언급하였지만 원본 data는 dbms 가 잘 저장하고 있기 때문에 저장할 필요는 없습니다. 단 해당 dbms의 pk만 있으면 만사 해결됩니다.
하지만 dbms 에서 data를 가지고 있다고 하여도 실시간 랭킹 처리 부분과 각종 소트(날짜나 특정 값 제목 등)할경우는 dbms 를 사용하면 속도문제가 발생합니다. 그리고 요약문 등을 추출할 경우도 어느정도 속도 문제가 따르기 때문에 이부분에서는 필요할경우 간단한 dbms 형태를 사용합니다. 대학교 교육과정에 나오는 자료구조 정도로 구현하여 용도에 맞게 설계하여 사용합니다. (사실 이렇게 간단하진 않지만.. 이만큼 간단하게 만들어 사용합니다. - 어디가지나 원본 data는 dbms 가 잘 보전하고 있기 때문에 깨지면 복구하지 않고 새로 만들면 되거든요 ^^)

frenzy 님이 이야기 하신 내용중에 10메가짜리 pdf 가 txt로 변환되면 200메가를 넘긴다고 하셨는데 종종 그런 경우도 있습니다. 이런 문서는 색인과정에서 색인어만 추출하고 변환된 txt는 버립니다. 또는 해당 문서의 일부분을 추출하여 요약문으로 저장하기도 합니다.

즉 원본은 저장하긴 하는데 필요한 최소한의 data만 저장을 하게 됩니다. 본문 모두를 저장하지 않고 보통 요약문만 저장을 하는경우가 많구요.. 저장할때 해당 data를 압축하여 저장을 합니다.(txt 의 압축율은 엄청 높지요 ^^) 어차피 내부의 키워드는 이미 색인 과정에서 추출하였으니 본문 정보는 화면에 보여주기만 하면 되니까요.

-------------------------------------
멋진남자...

멋진남자...

kicom95의 이미지

다음 까페에 검색엔진 개발자 그룹이라고 있습니다

여기 가입하셔서 활동하시는게 좋을듯 합니다

그리고 위의 책 비추입니다 ^^

그리고 원문은 요즘 추세는 다 저장합니다. 색인파일에서 정보를 유지하면 좋긴한데...

색인및 검색시간이 더 들어갑니다 공간 활용도를 좋게하려다가... cpu time 만 잡아 먹습니다

압축해서 저장하며 bzip 이나 공개된 압축 알고리즘을 잘 씁니다...

가자 해외로 ~ .. 돈 벌러.

익명사용자의 이미지

저도 검색개발을 하고있지만.. 검색엔진이 db보다 빠르다고 말하는건 꼭 옳지만은않은 주장인 것 같습니다. 어차피 key에 대해 대상을 찾는데 hash나 btree및 그 변형을 사용할텐데 db보다 검색엔진이 특별히 빠르게 동작할리가 없습니다. 검색엔진에선 trie같은걸 쓰지만 검색대상의 양이 메모리에 다 올리지 못할정도로 커지면 특별히 많이 빠른것도 아니구요. 제가아는 외국계 모 검색엔진의 경우 형태소분석기가 프론트로 들어가고 역색인 정보를 그냥 db에 넣어버리기도 합니다.-_-;;
그러함에도 검색엔진이 필요한건 성능보다는 기능적인 요소인것같습니다. 2개이상의 matching되는 키워드가 있을때 근접도를 따져서 랭킹을 다시 준다거나 특정 키로 그룹을 지어준다거나 db에는 원래 포함되이있지 않은 형태소분석기들이 들어간다거나 등등의 요소때문에 검색엔진이 필요한게 아닐까 싶습니다...

ntwiz의 이미지

링크로 걸린, 위에 것은 비추이고.
아래 책은 지금 보다는 나중에 필요할듯하군요.

superkkt의 이미지

책은 이미 사내도서로 구매를 했습니다. 쩝.. 첫번째 책은 좀 거시기 하군요. 두번째는 ntwiz님 말씀대로 아직 볼 단계가 아닌것 같습니다. 우선은 전반적인 검색엔진의 구현원리 등을 먼저 파악해야 될듯 싶은데요.

여러분들의 자세한 답변과 인터넷 검색해서 모은 자료로 대충 어떻게 돌아가는구나 하는건 조금 이해를 했습니다. 이제 좀 더 자세한 내용에 대해서 공부를 하고 싶은데 괜찮은 책이 없을까요?

======================
BLOG : http://superkkt.com

======================
BLOG : http://superkkt.com

hedge의 이미지

검색과는 전혀 무관한 일을 하고 있지만... 기본적인 원리에 대해서 공부하시고자 한다면 "최신정보검색론 - 홍릉과학출판사"를 추천해드리고 싶습니다. 7년 전에 term project로 검색 엔진을 만들기 위해 봤던 책인데, 책 내용중에 한 절반 정도만 가려서 보시면 될 것 같고요, 책에 나오는 각종 수학 공식만 제대로 이해하시면 원리에 대해서 상당히 이해가 가능하리라 생각됩니다. 물론 원서 자체가 오래된 책이라 현재와는 차이가 많이 나겠지만 원리 이해에는 상당히 도움이 되었던 것 같습니다. 읽고 계신 한국어 형태소 분석 관련 서적과 함께 1990년대 말에 발표된 형태소 분석에 대한 국내 논문중 괜찮은 논문의 전문을 구해서 읽어보시면 크게 도움이 되실것 같습니다. 저랑 동명이인이신 것 같아서 주저리 주저리 몇 자 적어보고 갑니다. 즐거운 하루 되셔요.

blueskya의 이미지

N-gram 매칭을 이용한 검색이라고 한다면 색인을 따로 만드는 쪽이 빠르다고 할 수 있습니다.

하지만 n-gram 매칭 이상의 내용을 요구하게 되면서 확장해 나가게 되면 결국 비슷해진다는 ㅡㅡ;;

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

----------------------------------------------------------------------
인생 뭐있어? 백수로 사는거야~ 가는거야~

댓글 달기

Filtered HTML

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

BBCode

  • 텍스트에 BBCode 태그를 사용할 수 있습니다. URL은 자동으로 링크 됩니다.
  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param>
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.

Textile

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • You can use Textile markup to format text.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Markdown

  • 다음 태그를 이용하여 소스 코드 구문 강조를 할 수 있습니다: <code>, <blockcode>, <apache>, <applescript>, <autoconf>, <awk>, <bash>, <c>, <cpp>, <css>, <diff>, <drupal5>, <drupal6>, <gdb>, <html>, <html5>, <java>, <javascript>, <ldif>, <lua>, <make>, <mysql>, <perl>, <perl6>, <php>, <pgsql>, <proftpd>, <python>, <reg>, <spec>, <ruby>. 지원하는 태그 형식: <foo>, [foo].
  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 사용할 수 있는 HTML 태그: <p><div><span><br><a><em><strong><del><ins><b><i><u><s><pre><code><cite><blockquote><ul><ol><li><dl><dt><dd><table><tr><td><th><thead><tbody><h1><h2><h3><h4><h5><h6><img><embed><object><param><hr>

Plain text

  • HTML 태그를 사용할 수 없습니다.
  • web 주소와/이메일 주소를 클릭할 수 있는 링크로 자동으로 바꿉니다.
  • 줄과 단락은 자동으로 분리됩니다.
댓글 첨부 파일
이 댓글에 이미지나 파일을 업로드 합니다.
파일 크기는 8 MB보다 작아야 합니다.
허용할 파일 형식: txt pdf doc xls gif jpg jpeg mp3 png rar zip.
CAPTCHA
이것은 자동으로 스팸을 올리는 것을 막기 위해서 제공됩니다.