데이터베이스로 NoSQL (MongoDB) vs Lucene (또는 Solr)


280

문서 기반 데이터베이스를 기반으로 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를 작성하여 저장하십시오. 끝난. 좋고 쉬운.



4
고맙지 만 내 질문에 대답하지 않습니다. 즉, 왜 데이터베이스에 Lucene 대신 MongoDB를 사용합니까? 둘 다 문서를 처리하지만 Lucene에는 매우 강력한 검색 옵션이 있습니다. 실제로 관련 질문을 찾은 경우 +1입니다. Stackoverflow에서 여러 번 검색했지만 거의 비교하지 못했습니다.
eduncan911

Lucene은 MongoDB와 비슷한 기능을 제공한다는 점에서 어떻게 사용하고 있습니까? 저장을 위해 관계형 DB에 연결하고 있습니까?
Philip Tinney

1
@Philip : 가상의 질문입니다. Lucene을 문서 저장소로 사용하지 않겠습니까? 훨씬 더 강력한 검색 성능과 확장 성을 얻을 수 있습니다 (Solr와 혼합하여 Lucene을 훨씬 더 쉽게 사용할 수 있음).
eduncan911

답변:


250

이것은 아주 좋은 질문입니다. 배운 교훈을 요약하겠습니다.

  1. 거의 모든 상황에서 MongoDB 대신 Lucene / Solr을 쉽게 사용할 수 있지만 그 반대도 마찬가지입니다. 그랜트 잉거 솔의 게시물이 여기에 요약되어 있습니다.

  2. MongoDB 등은 검색 및 / 또는 패싯이 필요하지 않은 목적으로 사용됩니다. RDBMS 세계에서 해독하는 프로그래머에게는 더 간단하고 논쟁의 여지가없는 전환으로 보입니다. 사용하지 않는 한 Lucene & Solr은 학습 곡선이 더 가파 릅니다.

  3. Lucene / Solr을 데이터 저장소로 사용하는 사례는 많지 않지만 Guardian은 훌륭한 슬라이드 데크 에서 일부 진전을 보였으며 요약 했지만 Solr 밴드 왜건을 완전히 뛰어 넘고 Solr을 결합하여 조사하는 것에 대해서는위원회가 아닙니다. CouchDB와 함께.

  4. 마지막으로, 나는 불행히도 비즈니스 사례에 대해 많은 것을 밝힐 수없는 경험을 제공 할 것입니다. 거의 실시간에 가까운 애플리케이션 인 몇 TB의 데이터를 처리합니다. 다양한 조합을 조사한 후 Solr을 고수하기로 결정했습니다. 지금까지 후회하지 않고 (6 개월 및 계산) 다른 것으로 바꿀 이유가 없습니다.

요약 : 검색 요구 사항이없는 경우 Mongo는 간단하고 강력한 접근 방식을 제공합니다. 그러나 검색이 오퍼링의 핵심 요소 인 경우 하나의 기술 (Solr / Lucene)을 고수하고 이동 부품 수를 줄이는 것이 좋습니다.

내 2 센트, 그것이 도움이되기를 바랍니다.


10
Solr에는 맵 축소 기능이 없습니다. 따라서보고, 통계, 점수 계산 등은 불가능합니다! 텍스트 데이터로 데이터를 가지고 있거나 위협 할 수있는 경우에만 Solr을 사용하십시오
Roland Kofler

8
Solr에는 map-reduce가 내장되어 있지 않지만 Hadoop과 결합 할 수 있습니다. architects.dzone.com/articles/solr-hadoop-big-data-love
Mikos

6
Map-reduce no, 그러나 여러 solr 서버에서 병렬로 쿼리를 실행하고 해당 결과를 집계하는 기능이 있습니다. 따라서 일반적인 목적의 map-reduce는 없지만 병렬 검색 쿼리 인 map-reduce로 작성하는 것을 이미 작성했습니다.
chubbsondubs

@Roo : Lucene을 기본 DB로 사용하고 MongoDB를 사용하여 집계 인덱스를 만드는 옵션이 될까요? 아니면 말이되지 않습니까? 그리고 Mikos : 실제 경험에 대한 훌륭한 답변과 +1.
절망의 그리움

2
solr6부터 병렬 표현식으로 맵 축소 기능을 지원합니다
Divyang Shah

36

solr에서 문서를 부분적으로 업데이트 할 수 없습니다. 문서를 업데이트하려면 모든 필드를 다시 게시해야합니다.

그리고 성능이 중요합니다. 커밋하지 않으면 solr에 대한 변경 사항이 적용되지 않고 매번 커밋하면 성능이 저하됩니다.

solr에는 트랜잭션이 없습니다.

solr에는 이러한 단점이 있으므로 때로는 nosql이 더 나은 선택입니다.


13
MongoDB에는 트랜잭션이 없습니다.
user183037

1
Solr 또는 Lucene은 실시간으로 검색하므로 커밋은 문제가되지 않습니다.
mihaicc

1
문서 내의 모든 업데이트는 MongoDB의 @ user183037입니다. 그리고 참고로, 루씬 중 하나 (감각)에 거래를하지 않습니다
라빈 Yarram

48
이 답변이 잘못되었습니다. Solr 4+는 부분 업데이트를 지원하며 거의 실시간에 가까운 소프트 커밋은 "old-style"Solr 커밋 문제를 해결합니다.
Mauricio Scheffer

1
그들은 MongoDB 4에서 트랜잭션에 대한 지원을 추가했습니다.
Jonas

26

우리는 MongoDB와 Solr을 함께 사용하며 성능이 우수합니다. 이 기술을 함께 사용하는 방법을 설명한 블로그 게시물을 여기 에서 찾을 수 있습니다 . 발췌문은 다음과 같습니다.

[...] 그러나 인덱스 크기가 커지면 Solr의 쿼리 성능이 저하되는 것을 알 수 있습니다. 우리는 최상의 솔루션이 Solr과 Mongo DB를 함께 사용하는 것임을 깨달았습니다. 그런 다음 MongoDB에 컨텐츠를 저장하고 전체 텍스트 검색을 위해 Solr을 사용하여 색인을 작성하여 Solr을 MongoDB와 통합합니다. Solr 인덱스에는 각 문서의 고유 ID 만 저장하고 Solr을 검색 한 후 MongoDB에서 실제 컨텐츠를 검색합니다. 분석기, 스코어링 등이 없기 때문에 MongoDB에서 문서를 얻는 것이 Solr보다 빠릅니다. [...]


3
좋은 블로그 게시물. 예, 이전의 이전 SQL 및 MySql 데이터 저장소 (Lucene에 ID 저장 및 데이터 저장소에서 복잡한 유형 검색)에서 Lucene을 사용한 방식과 정확히 같습니다. 기술적으로,이 질문은 "두 세계의 최고"를 정확히 사용하는 방법이 아니라이 둘의 차이점을 탐구하는 것이 었습니다. 방대한 양의 데이터를 사용하는 유일한 방법이므로 실제로는 +1입니다.
eduncan911

답변 주셔서 감사합니다. 질문은 Lucene보다 Nosql을 선택하는 것에 관한 것이지만 여기서는 하이브리드 방식으로 다른 것을 선택하는 대신 더 나은 결과를 얻을 수 있음을 보여주고 싶습니다.
Parvin Gasimzade

2
쿼리 성능이 너무 저하되어 MongoDB 추가에 대해 생각하기 시작했을 때 Solr 데이터베이스의 크기를 대략 1.5 년 후에 기억하십니까? (1 만 문서 또는 10,000,000 문서입니까?)
KajMagnus

매우 도움이됩니다. 나는 GIS에서 일하기 때문에 이런 방식으로 전체 텍스트와 공간 검색을 결합 할 수 있다는 것은 매우 흥미 롭습니다. 우리는 이미 MongoDB와 Postgres를 사용하고 있으며 한동안 Solr에 대해 생각하고 있습니다.
John Powell

2
@ParvinGasimzade 블로그 게시물 링크가 작동하지 않습니다. 다른 링크 나 소스를 제공해 주시겠습니까?
망각

24

또한 일부 사람들은 Solr에 모든 인덱스를 저장하고 oplog 작업을 모니터링하고 관련 업데이트를 Solr에 연계하여 Solr / Lucene을 Mongo에 통합했습니다.

이 하이브리드 방식을 사용하면 쓰기 속도가 빠른 신뢰할 수있는 데이터 저장소를 통한 전체 텍스트 검색 및 빠른 읽기와 같은 기능을 통해 두 가지 이점을 모두 누릴 수 있습니다.

약간 기술적 인 설정이지만 솔러에 통합 할 수있는 많은 oplog 테일러가 있습니다. 이 기사에서 어떤 범위 범위를 수행했는지 확인하십시오.

http://denormalised.com/home/mongodb-pub-sub-using-the-replication-oplog.html


내가 당신을 올바르게 이해했다면, MongoDB를 사용하는 이유는 (Solr과 함께) MongoDB가 더 빠른 삽입 + 읽기 속도를 가지고 있기 때문입니까? MongoDB에보다 안정적인 데이터 저장소가 있음을 나타 냈습니까? (또는 Solr을 언급 했습니까?) — 처음에 무엇을 시작 했습니까? MongoDB 만, Solr 만 또는 Mongo + Solr?
KajMagnus

12

Mongo는 두 가지에 대한 경험을 통해 간단하고 간단한 사용법에 적합합니다. 우리가 겪은 주요 몽고 단점은 예상치 못한 쿼리의 성능이 좋지 않다는 것입니다 (가능한 모든 필터 / 정렬 조합에 대해 몽고 인덱스를 만들 수는 없으며 간단하게 할 수는 없습니다).

Lucene / Solr이 특히 FilterQuery 캐싱을 통해 많은 시간을 차지하는 곳에서는 성능이 뛰어납니다.


10

아무도 언급하지 않았으므로 MongoDB는 스키마가 없으며 Solr은 스키마를 적용한다고 덧붙입니다. 따라서 문서의 필드가 변경 될 가능성이있는 경우, Solr 대신 MongoDB를 선택해야합니다.


6
IMHO는 사실이 아닙니다. Solr에는에 정의 된 스키마 schema.xml가 있지만 '동적 필드', 즉 와일드 카드를 통해 유형이 결정되는 필드도 *_i있으므로 정수 필드로 색인되는 모든 필드를 가질 수 있습니다 . 문서를 추가 할 때, 당신은 다음과 같은 필드 conaining 문서 수 count_i, foo_i, bar_i에 표시하지 않고 모든 정수 필드로 이해되는 것을 schema.xml그대로를. 꽤 스키마가 적습니다. 자세한 내용은 youtube.com/watch?v=WYVM6Wz-XTw 를 참조하십시오 .
흐름

Solr의 스키마 변경은 항상 다른 데이터 저장소와 동기화하기 위해 PITA에 있었기 때문에 다시 돌아와서 +1로 충돌해야합니다.
eduncan911

4
Solr에는 스키마 또는 스키마를 지원하지 않는 기능이 있습니다!
Krunal

5

@ mauricio-scheffer는 Solr 4를 언급했습니다. 그에 관심이있는 사람들을 위해 LucidWorks는 Solr 4를 "NoSQL 검색 서버"로 설명하고 있으며 http://www.lucidworks.com/webinar-solr-4-the-nosql에 비디오가 있습니다 . -search-server / 여기서 NoSQL (ish) 기능에 대해 자세히 설명합니다. (-ish는 스키마없는 버전이 실제로 동적 스키마임을 나타냅니다.)


1

키-값 형식을 사용하여 데이터를 저장하려는 경우 반전 인덱스가 디스크 공간을 너무 많이 낭비하므로 Lucene을 사용하지 않는 것이 좋습니다. 디스크에 데이터를 저장하면 redis가 RAM에 데이터를 저장하기 때문에 redis와 같은 NoSQL 데이터베이스보다 성능이 훨씬 느립니다. Lucene의 가장 큰 장점은 많은 쿼리를 지원하므로 퍼지 쿼리를 지원할 수 있다는 것입니다.


1

몽고 op-log 꼬리와 같은 타사 솔루션이 매력적입니다. 개발 / 아키텍처 관점을 가정 할 때 솔루션을 긴밀하게 통합 할 수 있는지에 대한 일부 생각이나 질문이 남아 있습니다. 몇 가지 이유로 이러한 기능에 대해 긴밀하게 통합 된 솔루션을 기대하지는 않습니다 (어떤 투기적이고 설명이 필요하며 개발 노력이 최신 상태가 아님).

  • 몽고는 C ++이고, lucene / solr은 java입니다.
  • lucene은 다양한 문서 형식을 지원합니다
    • mongo는 JSON (BSON)에 중점을 둡니다.
  • lucene은 불변 문서를 사용합니다
    • 사용 가능한 경우 단일 필드 업데이트가 문제입니다.
  • 복잡한 병합 작업으로 루체 색인을 변경할 수 없음
  • 몽고 쿼리는 자바 스크립트입니다
  • mongo에는 AFAIK (텍스트 분석기 / 토큰 라이저)가 없습니다
  • 몽고 문서 크기는 제한되어 있으며, 이는 루센의 곡물에 반할 수 있습니다
  • lucene에 몽고 어 그리 게이션 ops
    • lucene에는 여러 문서에 필드를 저장하는 옵션이 있지만 동일하지 않습니다.
    • solr은 어떻게 든 집계 / 통계 및 SQL / 그래프 쿼리를 제공합니다.

0

MongoDB Atlas는 곧 lucene 기반 검색 엔진을 갖게 될 것입니다. 이번 주 MongoDB World 2019 컨퍼런스에서 큰 발표가있었습니다. 이것은 수익이 높은 MongoDB Atlas 제품의 더 많은 사용을 장려하는 좋은 방법입니다.

MongoDB Enterprise 버전 4.2에 도입되기를 바랐지만 온 프레미스 제품 라인으로 가져 오는 소식은 없었습니다.

자세한 정보는 여기 : https://www.mongodb.com/atlas/full-text-search

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.