데이터베이스로 NoSQL (MongoDB) vs Lucene (또는 Solr)
문서 기반 데이터베이스를 기반으로하는 NoSQL의 움직임에 따라 최근 MongoDB를 살펴 보았습니다. Lucene (및 Solr 사용자)과 마찬가지로 항목을 "문서"로 취급하는 방법과 눈에 띄는 유사성을 발견했습니다.
그렇다면 질문 : 왜 "데이터베이스"로 Lucene (또는 Solr)을 통해 NoSQL (MongoDB, Cassandra, CouchDB 등)을 사용하고 싶습니까?
대답에서 찾고있는 (그리고 다른 사람들이 확신하는) 것은 그것들에 대한 심도있는 비교입니다. 관계형 데이터베이스 토론은 다른 목적으로 사용되므로 모두 함께 건너 뛰겠습니다.
Lucene은 강력한 검색 및 무게 시스템과 같은 몇 가지 심각한 이점을 제공합니다. Solr의 패싯은 말할 것도 없습니다 (Sorr은 곧 Lucene에 통합되고 있습니다!). Lucene 문서를 사용하여 ID를 저장하고 MongoDB와 같은 문서에 액세스 할 수 있습니다. Solr과 함께 사용하면 WebService 기반의로드 밸런싱 솔루션을 얻을 수 있습니다.
MongoDB의 유사한 데이터 저장 및 확장성에 대해 이야기 할 때 Velocity 또는 MemCached와 같은 out-of-proc 캐시 공급자를 비교할 수도 있습니다.
MongoDB에 대한 제한 사항은 MemCached 사용을 상기시켜 주지만 Microsoft의 Velocity를 사용할 수 있으며 MongoDB보다 더 많은 그룹화 및 목록 수집 기능을 가지고 있습니다 (제 생각에). 메모리에 데이터를 캐싱하는 것보다 더 빠르거나 확장 할 수 없습니다. Lucene조차도 메모리 공급자가 있습니다.
MongoDB (및 기타)는 API 사용 편의성과 같은 몇 가지 장점이 있습니다. 문서를 새로 작성하고 ID를 작성하여 저장하십시오. 끝난. 좋고 쉬운.
이것은 아주 좋은 질문입니다. 배운 교훈을 요약하겠습니다.
거의 모든 상황에서 MongoDB 대신 Lucene / Solr을 쉽게 사용할 수 있지만 그 반대도 마찬가지입니다. 그랜트 잉거 솔의 게시물이 여기에 요약되어 있습니다.
MongoDB 등은 검색 및 / 또는 패싯이 필요하지 않은 목적으로 사용됩니다. RDBMS 세계에서 해독하는 프로그래머에게는 간단하고 논란의 여지가없는 전환으로 보입니다. 사용하지 않는 한 Lucene & Solr은 학습 곡선이 더 가파 릅니다.
Lucene / Solr을 데이터 저장소로 사용하는 사례는 많지 않지만 Guardian은 훌륭한 슬라이드 데크 에서 일부 진전을 보였으며 요약 했지만 Solr 밴드 왜건을 완전히 뛰어 넘고 Solr을 결합하여 조사하는 것에 대해서는위원회가 아닙니다. CouchDB와 함께.
마지막으로, 나는 불행히도 비즈니스 사례에 대해 많은 것을 밝힐 수없는 경험을 제공 할 것입니다. 거의 실시간에 가까운 애플리케이션 인 몇 TB의 데이터를 처리합니다. 다양한 조합을 조사한 후 Solr을 고수하기로 결정했습니다. 지금까지 후회하지 않고 (6 개월 및 계산) 다른 것으로 바꿀 이유가 없습니다.
요약 : 검색 요구 사항이없는 경우 Mongo는 간단하고 강력한 접근 방식을 제공합니다. 그러나 검색이 오퍼링의 핵심 요소 인 경우 하나의 기술 (Solr / Lucene)을 고수하고 이동 부품 수를 줄이는 것이 좋습니다.
내 2 센트, 그것이 도움이되기를 바랍니다.
solr에서 문서를 부분적으로 업데이트 할 수 없습니다. 문서를 업데이트하려면 모든 필드를 다시 게시해야합니다.
그리고 성능이 중요합니다. 커밋하지 않으면 solr에 대한 변경 사항이 적용되지 않고 매번 커밋하면 성능이 저하됩니다.
solr에는 트랜잭션이 없습니다.
solr에는 이러한 단점이 있으므로 때로는 nosql이 더 나은 선택입니다.
우리는 MongoDB와 Solr을 함께 사용하며 성능이 우수합니다. 이 기술을 함께 사용하는 방법을 설명한 블로그 게시물을 여기 에서 찾을 수 있습니다 . 발췌문은 다음과 같습니다.
[...] 그러나 인덱스 크기가 커지면 Solr의 쿼리 성능이 저하되는 것을 알 수 있습니다. 우리는 최고의 솔루션이 Solr과 Mongo DB를 함께 사용하는 것임을 깨달았습니다. 그런 다음 MongoDB에 컨텐츠를 저장하고 전체 텍스트 검색을 위해 Solr을 사용하여 색인을 작성하여 Solr을 MongoDB와 통합합니다. Solr 인덱스에는 각 문서의 고유 ID 만 저장하고 Solr을 검색 한 후 MongoDB에서 실제 컨텐츠를 검색합니다. 분석기, 스코어링 등이 없기 때문에 MongoDB에서 문서를 얻는 것이 Solr보다 빠릅니다. [...]
또한 일부 사람들은 Solr에 모든 인덱스를 저장하고 oplog 작업을 모니터링하고 관련 업데이트를 Solr에 연계하여 Solr / Lucene을 Mongo에 통합했습니다.
이 하이브리드 방식을 사용하면 전체 텍스트 검색 및 쓰기 속도가 빠른 안정적인 데이터 저장소를 통한 빠른 읽기와 같은 기능을 통해 두 가지 이점을 모두 누릴 수 있습니다.
약간 기술적 인 설정이지만 솔러에 통합 할 수있는 많은 oplog 테일러가 있습니다. 이 기사에서 어떤 범위 범위를 수행했는지 확인하십시오.
http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html
Mongo는 두 가지에 대한 경험을 통해 간단하고 간단한 사용법에 적합합니다. 우리가 겪은 주요 몽고 단점은 예상치 못한 쿼리의 성능이 좋지 않다는 것입니다 (가능한 모든 필터 / 정렬 조합에 대해 몽고 인덱스를 만들 수는 없으며 간단하게 할 수는 없습니다).
여기에서 특히 FilterQuery 캐싱으로 Lucene / Solr이 큰 시간을 차지하는 곳에서는 성능이 뛰어납니다.
아무도 언급하지 않았으므로 MongoDB는 스키마가 없으며 Solr은 스키마를 적용한다고 덧붙입니다. 따라서 문서의 필드가 변경 될 가능성이있는 경우, Solr 대신 MongoDB를 선택해야합니다.
@ mauricio-scheffer는 Solr 4를 언급했습니다. 그에 관심이있는 사람들을 위해 LucidWorks는 Solr 4를 "NoSQL 검색 서버"로 설명하고 있으며 http://www.lucidworks.com/webinar-solr-4-the-nosql에 비디오가 있습니다 . -search-server / 여기서 NoSQL (ish) 기능에 대해 자세히 설명합니다. (-ish는 스키마없는 버전이 실제로 동적 스키마임을 나타냅니다.)
키-값 형식을 사용하여 데이터를 저장하려는 경우 반전 인덱스가 디스크 공간을 너무 많이 낭비하므로 Lucene을 사용하지 않는 것이 좋습니다. 디스크에 데이터를 저장하면 redis가 RAM에 데이터를 저장하기 때문에 redis와 같은 NoSQL 데이터베이스보다 성능이 훨씬 느립니다. Lucene의 가장 큰 장점은 많은 쿼리를 지원하므로 퍼지 쿼리를 지원할 수 있다는 것입니다.
몽고 op-log 꼬리와 같은 타사 솔루션이 매력적입니다. 개발 / 아키텍처 관점을 가정 할 때 솔루션을 긴밀하게 통합 할 수 있는지에 대한 일부 생각이나 질문이 남아 있습니다. 몇 가지 이유로 이러한 기능에 대해 긴밀하게 통합 된 솔루션을 기대하지는 않습니다 (어떤 투기적이고 설명이 필요하며 개발 노력이 최신 상태가 아님).
- 몽고는 C ++이고, lucene / solr은 java입니다.
- lucene은 몽고 라이브러리를 사용할 수 있습니다.
- 아마도 mongo는 lucene 알고리즘을 다시 작성할 수 있습니다.
- lucene은 다양한 문서 형식을 지원합니다
- mongo는 JSON (BSON)에 중점을 둡니다.
- lucene은 불변 문서를 사용합니다
- 사용 가능한 경우 단일 필드 업데이트가 문제입니다.
- 복잡한 병합 작업으로 루체 색인을 변경할 수 없음
- 몽고 쿼리는 자바 스크립트입니다
- mongo에는 AFAIK (텍스트 분석기 / 토큰 라이저)가 없습니다
- 몽고 문서 크기는 제한되어 있으며, 이는 루센의 곡물에 반할 수 있습니다
- lucene에 몽고 어 그리 게이션 ops
- lucene에는 여러 문서에 필드를 저장하는 옵션이 있지만 동일하지 않습니다.
- solr은 어떻게 든 집계 / 통계 및 SQL / 그래프 쿼리를 제공합니다.
MongoDB Atlas는 곧 lucene 기반 검색 엔진을 갖게 될 것입니다. 이번 주 MongoDB World 2019 컨퍼런스에서 큰 발표가있었습니다. 이것은 수익이 높은 MongoDB Atlas 제품의 더 많은 사용을 장려하는 좋은 방법입니다.
MongoDB Enterprise 버전 4.2에 적용되기를 바랐지만 온 프레미스 제품 라인으로 가져 오는 소식은 없습니다.
자세한 내용은 여기 : https://www.mongodb.com/atlas/full-text-search
참고 : https://stackoverflow.com/questions/3215029/nosql-mongodb-vs-lucene-or-solr-as-your-database
'IT' 카테고리의 다른 글
| Node.js를위한 템플릿 엔진이 있습니까? (0) | 2020.03.26 |
|---|---|
| 방금 모든 ASP.Net 웹 사이트가 느린 이유를 발견했으며 그에 대한 조치를 취하려고합니다. (0) | 2020.03.26 |
| 최신 커밋에 대해서만 GitHub에 풀 요청을 보냅니다. (0) | 2020.03.26 |
| UTF-8 : 일반? (0) | 2020.03.26 |
| ActiveRecord의 부동 대 소수 (0) | 2020.03.26 |