데이터베이스로서의 NoSQL(MongoDB) vs Lucene(또는 Solr)
문서 기반 데이터베이스를 기반으로 한 NoSQL 운동이 커지면서 최근 MongoDB에 대해 알아보았습니다.Lucene(및 Solr 사용자)과 마찬가지로 아이템을 "Documents"로 취급하는 방법과 현저한 유사성을 발견했습니다.
자, 질문은 다음과 같습니다.Lucene(또는 Solr)보다 NoSQL(MongoDB, Cassandra, CouchDB 등)을 '데이터베이스'로 사용하는 이유는 무엇입니까?
내가 (그리고 다른 사람들이) 답을 찾고 있는 것은 그들을 깊이 있게 비교하는 것이다.관계형 데이터베이스 논의는 서로 다른 목적을 위해 모두 생략합니다.
Lucene은 강력한 검색 및 무게 시스템과 같은 몇 가지 심각한 이점을 제공합니다.Solr의 측면은 말할 것도 없고(Solr은 곧 Lucene에 통합됩니다, 예!).Lucene 문서를 사용하여 ID를 저장하고 MongoDB와 마찬가지로 문서에 액세스할 수 있습니다.Solr과 함께 사용하면 웹 서비스 기반의 로드 밸런싱 솔루션을 얻을 수 있습니다.
Velocity나 MemCached와 같은 프로세서 외 캐시 프로바이더의 비교도 MongoDB의 유사한 데이터 저장 및 확장성에 대해 언급할 수 있습니다.
MongoDB에 관한 제약으로 인해 MemCached를 사용하는 것이 생각나지만, Microsoft의 Velocity를 사용할 수 있어 MongoDB보다 그룹화 및 목록 수집 능력을 높일 수 있다고 생각합니다.메모리에 데이터를 캐싱하는 것보다 더 빠르고 확장성이 뛰어납니다.심지어 루신도 메모리 공급자가 있다.
MongoDB(및 기타)는 API의 사용 편의성 등 몇 가지 장점이 있습니다.문서를 새로 만들고 ID를 만든 후 저장합니다.됐어, 살살해
이것은 훌륭한 질문입니다. 제가 꽤 많이 고민해 본 질문입니다.학습한 내용을 정리합니다.
거의 모든 상황에서 MongoDB 대신 Lucene/Solr을 쉽게 사용할 수 있지만 그 반대도 아닙니다.그랜트 잉거솔의 포스트는 여기에 요약되어 있다.
MongoDB 등은 검색 및/또는 패싯이 필요 없는 목적에 도움이 되는 것 같습니다.프로그래머가 RDBMS의 세계에서 해독하는 것이 더 간단하고 쉽게 이행할 수 있는 것으로 보입니다.익숙치 않다면 루신과 솔르는 학습곡선이 더 가파르다.
데이터 저장소로 Lucene/Solr을 사용하는 예는 많지 않지만, Guardian은 일부 성과를 거두고 이를 훌륭한 슬라이드 데크로 요약하고 있지만, Solr과 CouchDB를 완전히 결합하는 것에 대해서도 명확한 입장을 밝히지 않고 있습니다.
마지막으로, 우리의 경험을 말씀드리지만, 유감스럽게도 그 비즈니스 케이스에 대해서는 많은 것을 밝힐 수 없습니다.NAT은 실시간에 가까운 애플리케이션인 몇 TB의 데이터 규모로 작업합니다.다양한 조합을 검토한 후 Solr를 고수하기로 결정했다.지금까지의 후회도 없고(6개월 및 계산) 다른 것으로 바꿀 이유도 없습니다.
개요: 검색 요건이 없는 경우 Mongo는 심플하고 강력한 접근 방식을 제공합니다.다만, 검색의 열쇠가 되는 제품이라면, 1개의 테크놀로지(Solr/Lucene)를 고집해, 최대한의 최적화(이동 부품의 수 감소)를 실시하는 것이 좋습니다.
내 2센트, 도움이 됐으면 좋겠어.
솔에서 문서를 부분적으로 업데이트할 수 없습니다.문서를 업데이트하려면 모든 필드를 다시 게시해야 합니다.
퍼포먼스도 중요합니다.커밋하지 않으면 solr로의 변경이 활성화되지 않고 매번 커밋하면 퍼포먼스가 저하됩니다.
solr에는 트랜잭션이 없습니다.
solr에는 이러한 단점이 있으므로 NoSQL이 더 좋을 수 있습니다.
MongoDB와 Solr을 함께 사용하고 있는데 성능이 좋습니다.블로그 투고는 이쪽에서 보실 수 있습니다.여기에서는 이 테크놀로지를 함께 사용하는 방법에 대해 설명하고 있습니다.발췌문은 다음과 같습니다.
[...] 그러나 인덱스 크기가 증가하면 Solr의 쿼리 성능이 저하됩니다.Solr와 Mongo DB를 함께 사용하는 것이 최선의 해결책이라는 것을 깨달았습니다.그리고 콘텐츠를 MongoDB에 저장하고 Solr을 사용하여 인덱스를 생성하여 전체 텍스트 검색을 수행함으로써 Solr을 MongoDB와 통합합니다.각 문서의 고유 ID만 Solr 인덱스에 저장하고 Solr에서 검색한 후 MongoDB에서 실제 콘텐츠를 가져옵니다.MongoDB에서 문서를 가져오는 속도가 Solr보다 빠릅니다. 분석기, 점수 매기기 등이 없기 때문입니다. [...]
또한 일부에서는 Solr/Lucene을 Mongo에 통합하여 모든 인덱스를 Solr에 저장하고 oplog 작업을 모니터링하며 관련 업데이트를 Solr에 캐스케이드하고 있습니다.
이 하이브리드 방식을 사용하면 쓰기 속도도 매우 빨라지는 안정적인 데이터 저장소를 통해 전체 텍스트 검색 및 빠른 읽기 등의 기능을 통해 두 환경의 장점을 모두 누릴 수 있습니다.
셋업은 조금 기술적이지만 솔러에 통합할 수 있는 oplog 테일러가 많이 있습니다.이 기사에서 범위 범위가 어떤 역할을 했는지 확인하십시오.
http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html
둘 다 경험해보니, Mongo는 단순하고 간단한 사용법에 매우 적합합니다.Mongo의 주된 단점은 예기치 않은 쿼리의 퍼포먼스가 저조하다는 것입니다(모든 필터/소트 조합에 대해 mongo 인덱스를 작성할 수 없습니다.단순히 할 수 없습니다).
또한 Lucene/Solr이 특히 FilterQuery 캐싱에서 크게 우세할 경우 뛰어난 성능을 발휘합니다.
아무도 언급하지 않았기 때문에 MongoDB는 스키마가 없는 반면 Solr은 스키마를 적용합니다.따라서 문서의 필드가 변경될 가능성이 있는 경우 Solr 대신 MongoDB를 선택해야 하는 이유 중 하나입니다.
@solidicio-scheffer는 Solr 4에 대해 언급했다.LucidWorks는 Solr 4를 "NoSQL Search Server"라고 표현하고 있으며, http://www.lucidworks.com/webinar-solr-4-the-nosql-search-server/에는 NoSQL(ish) 기능에 대한 자세한 비디오가 있다.(-ish는 실제로는 동적 스키마인 스키마 버전을 나타냅니다.)
키-값 형식을 사용하여 데이터를 저장하는 경우 반전 인덱스가 너무 많은 디스크 공간을 낭비하므로 Lucene을 사용하지 않는 것이 좋습니다.또한 디스크에 데이터를 저장할 경우 redis와 같은 NoSQL 데이터베이스보다 성능이 훨씬 느립니다. redis는 데이터를 RAM에 저장하기 때문입니다.Lucene의 가장 큰 장점은 대부분의 쿼리를 지원하므로 퍼지 쿼리를 지원할 수 있다는 것입니다.
몽고DB 아틀라스는 조만간 루센 기반의 검색엔진을 탑재할 예정이다.이번 주 MongoDB World 2019 컨퍼런스에서 큰 발표가 있었습니다.이는 수익성이 높은 MongoDB Atlas 제품의 사용을 촉진하는 좋은 방법입니다.
MongoDB Enterprise 버전 4.2로 출시되기를 기대했지만, 아직 프리미엄 제품 라인으로 출시될 소식은 없습니다.
자세한 내용은 이쪽:https://www.mongodb.com/atlas/full-text-search
mongo op-log tail과 같은 서드파티 솔루션은 매력적입니다.개발/아키텍처의 관점에서 솔루션을 긴밀하게 통합할 수 있는지에 대한 생각이나 의문은 남아 있습니다.몇 가지 이유로 이러한 기능에 대해 긴밀하게 통합된 솔루션은 기대하지 않습니다(일부 추측이 많고 명확해야 하며 개발 노력이 최신이 아닙니다).
- mongo c++, lucene/solr java.
- 루센은 몽고립이 필요할지도 몰라
- 몽고조조: :
- 루센
- mongo는 JSON(BSON)에 초점을 맞추고 있다.
- 신신은불불불문문문문문문
- 단일 필드 업데이트가 가능한 경우 문제가 됩니다.
- 복잡한 Marge ops에서는 lucene 인덱스는 불변합니다.
- mongo 쿼리는 javascript입니다.
- mongo에는 텍스트아나라이저/토큰라이저(AFAIK)가 없습니다.
- mongo 문서 크기가 제한되어 있어 루센에 맞지 않을 수 있습니다.
- 몽고
- Lucene은 여러 문서에 필드를 저장할 수 있는 옵션이 있지만, 이는 동일하지 않습니다.
- solr은 집약/통계 및 SQL/그래프 쿼리를 제공합니다.
언급URL : https://stackoverflow.com/questions/3215029/nosql-mongodb-vs-lucene-or-solr-as-your-database
'it-source' 카테고리의 다른 글
| WordPress 3.0 및 nginx - permalink, 404 문제 (0) | 2023.03.12 |
|---|---|
| Word press는 기본 역할 제거 및 사용자 지정 역할 추가 (0) | 2023.03.12 |
| Word press를 통해 사용자 ID 가져오기 (0) | 2023.03.12 |
| jQuery.ajax에서 성공으로 간주되는 HTTP 상태 코드는 무엇입니까? (0) | 2023.03.12 |
| WordPress에 mysql 확장자가 없는 PHP 7 컴파일 (0) | 2023.03.12 |