MongoDB는 관계형 db+lucene의 유효한 대안입니까?
새 프로젝트에서는 검색기 구현을 위해 루센을 열심히 사용해야 합니다.이 검색기는 프로젝트에서 매우 중요하고 중요한 부분이 될 것입니다.관계형 데이터베이스 + Lucene을 MongoDb로 대체하는 것이 유효하거나 편리합니까?
편집: 네, 다음 사항을 명확히 하겠습니다.위험을 묻는 게 아니라 이 프로젝트에서 그 대가를 지불할 수 있습니다.제 요점은: MongoDB가 이런 종류의 것을 지향하고 있는가 하는 것입니다.루씬과 같은 성능의 풀 검색 엔진을 만들 수 있습니까?친구가 대안으로 MongoDB를 지목했지만 Lucene 성능이 문서 대안과 함께 제공되는지(그리고 나서 MongoDB에서도 확인할 것입니다), 반대로 반전 인덱스와 최적화는 문서 방향과 완전히 독립적입니다.
기술적으로 MongoDB로 전체 텍스트 검색을 수행할 수 있지만 전체 텍스트 검색 공급자가 제공해야 하는 많은 것을 놓치고 있습니다.저는 MongoDB를 좋아하지만 구현 시간이 문제라면 전체 텍스트 검색 공급자(예: Lucene 또는 Spinx)와 연결하고 싶습니다.단어 배열을 색인화하는 MongoDB의 편리한 기능은 전체 텍스트 검색보다 태그 지정 및 태그 기반 검색에 더 적합하다고 생각합니다.
검색(정보 검색)은 단순히 일치하는 문서를 가져오는 것이 아닙니다. 검색 결과가 관련성을 가지려면 TF-IDF, 구문 일치(시퀀스 내 단어가 더 높은 점수를 받음) 또는 검색 정확도를 향상시키기 위한 다른 IR 기술이 필요합니다.MongoDB를 사용하는 경우 처음부터 모든 것을 구현해야 합니다.
이 모든 것을 처음부터 구현하고 싶지만 원시 스토리지 측면에서는 문제가 되지 않는다면 MongoDB는 구현할 수 있는 최고의 DB 저장소에 가깝습니다(다른 DB 저장소는 많이 생각할 수 없습니다). 하지만 그렇다고 해서 좋은 옵션은 아닙니다.
CouchDb는 CouchDb-lucene 프로젝트를 통해 Lucene을 사용할 수 있는 (다른) 가능한 대안인 것 같습니다.
MongoDb는 NOSQL, Lucene 및 SOLR은 검색 엔진이며, EhCache와 함께 Teracota와 같은 캐시를 비교에 추가했습니다.모두 각자의 목적이 있습니다.
전체 텍스트 검색과 함께 검색이 필요한 경우, 설명에서 텍스트 일치보다 제품 제목 순위에서 텍스트 일치와 함께 결과를 표시하는 것과 같은 관련 설정 및 이러한 텍스트 기반 기능이 많이 있습니다.또한 순위, 관련성, 유사한 소리 처리, 부분 단어 일치 등 이 모든 것은 SOLR 및 Lucene과 같은 검색 기반 스토리지 시스템에서 가장 잘 처리됩니다.
만약 당신의 기준이 더 나은 검색만을 위한 것이고 당신의 프레젠테이션 데이터 객체가 내구성을 가질 필요가 없다면, 단순히 테라코타와 같은 캐시를 사용하세요.
더 빠른 검색이 필요하고 데이터를 하나의 데이터 소스에서 공동으로 수집하고 집계해야 하며 집계된 데이터의 내구성이 필요한 경우 Mongodb와 같은 NOSQL을 사용합니다.
가능하지만 속도가 느립니다(여기 참조).
- 여러분은 단어 분열과 자신을 억제해야 할 것입니다.
- 쿼리 순위는 '사용자가 제공한 코드가 필요합니다'입니다.
저는 MongoDB에 익숙하지 않아서 직접 답변할 수는 없지만 Lucene(약 10년) 및 관계형 데이터베이스(수십 년)와 달리 MongoDB는 3년 미만이라는 점에 주목하고 싶습니다.
게임의 이 단계에서는 아직 성숙할 가능성이 높습니다.사용자의 요구에 적합할 수도 있지만(사용에 익숙한 사람이 여기서 차임벨을 울리는지 궁금합니다), 이를 방정식에 반영해야 합니다.최첨단 기술을 사용하기 위해 대가를 지불할 의향이 있습니까?
안정적이고 효율적으로 작동하더라도 사용자 기반이 작기 때문에 웹 사이트/자습서 등의 지원이 제한적일 수 있습니다.당신은 또한 그것이 중단될 수도 있다는 모험을 하고 있습니다.
이 기회를 잡는 것은 가치가 있을 수 있지만, 여러분은 "오, 빛나는 새 장난감을 보세요" 효과에 눈이 멀어지지 않고 눈을 뜨고 해야 합니다.
또 다른 옵션은 탄력적인 검색(lucene으로 백업) 너비 카우치DB를 사용하는 것입니다. http://www.elasticsearch.org/blog/2010/09/28/the_river_searchable_couchdb.html
Lucene은 안정적이고 안정적인 제품입니다.A MongoDB에 대해서는 아직 동일한 사실이 없습니다.그래서 저는 Lucene과 RDBMS가 훨씬 덜 위험한 옵션이라고 생각합니다.
물론 어느 정도까지는 프로젝트의 성격에 따라 다릅니다. "매우 중요하고 큰" 것이 얼마나 중요한가요?다른 하나는, 당신은 MongoDB의 이전 경험이 있습니까(아마 없을 것입니다)?전문 지식을 가진 사람들에게 접근할 수 있다면 위험을 줄일 수 있을 것입니다.
Devoxx 2011에 참석하고 10Gen의 프레젠테이션에 참석한 후 MongoDB와 RDBMS 데이터베이스를 비교하는 작은 블로그를 작성했습니다.MongoDB는 인기 있는 Nosql dbs 중 하나입니다.MongoDB 이전의 답변에서 언급한 바와 같이 NoSQL db는 기존의 메인스트림 rdbms 데이터베이스와는 다릅니다.
전체 텍스트 검색 솔루션의 경우 이전에 Lucene & Spinks를 사용했지만 제공된 키워드에 최상의 결과를 가져오기에는 그다지 좋지 않습니다.그래서 저는 mongodb 전문 검색 플러그인 MongoLantern을 사용했는데, 이 플러그인은 매우 능숙합니다.게다가 성능 면에서도 MongoDB를 백엔드 엔진으로 사용하고 있어 성능 문제가 전혀 없습니다. MongoLantern의 생산 사용성 측면에서 더 많은 리뷰를 기다리고 있습니다.
https://sourceforge.net/projects/mongolantern/
아니요, MongoDB는 관계형이 아니기 때문에 그렇지 않습니다.
언급URL : https://stackoverflow.com/questions/2546494/is-mongodb-a-valid-alternative-to-relational-db-lucene
'source' 카테고리의 다른 글
| '할당 지점 조건 크기가 너무 높음'의 의미는 무엇이며 이를 수정하는 방법은 무엇입니까? (0) | 2023.06.21 |
|---|---|
| 병합 중인 변경 사항 위에 현재 분기의 변경 사항을 어떻게 다시 기준으로 삼습니까? (0) | 2023.06.21 |
| R 마크다운과 R 노트북의 차이점 (0) | 2023.06.21 |
| Android - 편집 텍스트에서 "Enter" 처리 (0) | 2023.06.21 |
| 반응 후크/전체 딥을 글로벌하게 무시하도록 eslint 규칙을 구성하려면 어떻게 해야 합니까? (0) | 2023.06.21 |