문서 기반 데이터베이스를 기반으로 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는 두 가지에 대한 경험을 통해 간단하고 간단한 사용법에 적합합니다. 우리가 겪은 주요 몽고 단점은 예상치 못한 쿼리의 성능이 좋지 않다는 것입니다 (가능한 모든 필터 / 정렬 조합에 대해 몽고 인덱스를 만들 수는 없으며 간단하게 할 수는 없습니다).
Lucene / Solr이 특히 FilterQuery 캐싱을 통해 많은 시간을 차지하는 곳에서는 성능이 뛰어납니다.
답변
아무도 언급하지 않았으므로 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는 스키마없는 버전이 실제로 동적 스키마임을 나타냅니다.)
