필터링 애플리케이션을위한 elasticsearch vs MongoDB [닫기]

이 질문은 실험과 구현의 세부 사항을 파고 들기 전에 아키텍처를 선택하는 것에 관한 것입니다. Elasticsearch와 MongoDB의 확장 성 및 성능 측면에서 다소 구체적인 목적에 대한 적합성에 관한 것입니다.

가설 적으로 필드와 값이있는 데이터 개체를 저장하고 해당 개체의 본문을 쿼리 할 수 ​​있습니다. 따라서 선택한 임시 필드에 따라 객체의 하위 집합을 필터링하는 것이 두 가지 모두에 적합한 것으로 추정됩니다.

내 응용 프로그램은 기준에 따라 객체 선택을 중심으로 진행됩니다. 하나 이상의 필드로 동시에 필터링하여 객체를 선택하고 다르게 말하면 쿼리 필터링 기준은 일반적으로 1 ~ 5 개의 필드로 구성되며 경우에 따라 더 많을 수 있습니다. 반면 필터로 선택된 필드는 훨씬 더 많은 필드의 하위 집합이됩니다. 20 개의 필드 이름이 존재하고 각 쿼리는 전체 20 개 필드 중 몇 개의 필드로 개체를 필터링하려고 시도합니다 (기존 필드 이름이 20 개보다 작거나 많을 수 있음). 모든 이산 쿼리에서 필터로 사용되는 필드). 필터링은 선택한 필드의 존재 여부뿐만 아니라 필드 값 (예 : 필드 A가있는 객체 필터링) 및 필드 B가 x와 y 사이에있을 수 있습니다.

내 응용 프로그램은 이러한 종류의 필터링을 지속적으로 수행하는 반면 어떤 필드가 필터링에 사용되는지는 거의 또는 거의 일정하지 않습니다. 탄력적 검색에서는 인덱스를 정의해야하지만 인덱스가없는 경우에도 속도는 MongoDB의 속도와 비슷합니다.

상점에 들어가는 데이터에 따라 그에 대한 특별한 세부 사항은 없습니다. 삽입 된 후에는 거의 변경되지 않습니다. 아마도 오래된 객체를 삭제해야 할 수도 있습니다. 두 데이터 저장소 지원이 내부적으로 또는 응용 프로그램에서 쿼리를 작성하여 항목 삭제를 만료한다고 가정하고 싶습니다. 덜 자주, 특정 쿼리에 맞는 객체도 삭제해야합니다.

어떻게 생각해? 그리고이 측면을 실험 했습니까?

이러한 종류의 작업을 위해 두 데이터 저장소 각각의 성능과 확장성에 관심이 있습니다. 이것은 일종의 아키텍처 설계 질문이며, 잘 설계되어야하는 매장 별 옵션 또는 쿼리 초석의 세부 사항은 완전히 고려 된 제안의 시연으로 환영받습니다.

감사!

우선 여기에서 중요한 차이점이 있습니다. MongoDB는 범용 데이터베이스이고 Elasticsearch는 Lucene이 지원하는 분산 텍스트 검색 엔진입니다. 사람들은 Elasticsearch를 범용 데이터베이스로 사용하는 것에 대해 이야기하고 있지만 이것이 원래 디자인이 아니라는 것을 알고 있습니다. 나는 범용 NoSQL 데이터베이스와 검색 엔진이 통합을 향하고 있다고 생각하지만 그 두 가지는 매우 다른 두 캠프에서 나온 것입니다.

우리 회사에서는 MongoDB와 Elasticsearch를 모두 사용하고 있습니다. 우리는 MongoDB에 데이터를 저장하고 전체 텍스트 검색 기능을 위해서만 Elasticsearch를 사용합니다. 탄력적으로 쿼리해야하는 몽고 데이터 필드의 하위 집합 만 보냅니다. 우리의 사용 사례는 Mongo 데이터가 항상 변경된다는 점에서 다릅니다. 레코드 또는 레코드 필드의 하위 집합은 하루에 여러 번 업데이트 될 수 있으며 이로 인해 해당 레코드를 탄력적으로 다시 인덱싱해야 할 수 있습니다. 이러한 이유만으로도 선택 필드를 업데이트 할 수 없으므로 Elastic을 유일한 데이터 저장소로 사용하는 것은 좋은 선택이 아닙니다. 문서 전체를 다시 색인화해야합니다. 이것은 탄력적 인 제한이 아니며, 이것이 탄성 뒤에있는 기본 검색 엔진 인 Lucene의 작동 방식입니다. 귀하의 경우, 기록이 일단 저장된 후에는 변경하지 않아도됩니다. 데이터 안전성이 중요하다면 Elasticsearch를 데이터의 유일한 스토리지 메커니즘으로 사용하는 것에 대해 두 번 생각할 것입니다. 어느 시점에 도착할 수 있지만 아직 있는지는 확실하지 않습니다.

속도 측면에서 "Mongo / Lucene"은 Mongo의 쿼리 속도와 동등 할뿐만 아니라 "언제나 필터링에 사용되는 필드가 거의 일정하지 않은 경우"의 순서 일 수 있습니다. 특히 데이터 세트가 커질수록 크기가 빨라집니다. 차이점은 기본 쿼리 구현에 있습니다.

• Elastic / Lucene 은 정보 검색을 위해 Vector Space Model 및 Inverted Index 를 사용하는데 , 이는 쿼리와 레코드 유사성을 비교하는 매우 효율적인 방법입니다. Elastic / Lucene을 쿼리하면 이미 답을 알고 있습니다. 대부분의 작업은 검색어와 일치 할 가능성이 가장 높은 결과를 사용자에게 표시하는 데 있습니다. 검색 엔진은 데이터베이스와 달리 정확한 결과를 보장 할 수 없습니다. 검색어와의 거리에 따라 결과 순위가 결정됩니다. 대부분의 경우 결과가 정확 해집니다.
• 몽고의 접근 방식은보다 일반적인 목적의 데이터 저장소입니다. JSON 문서를 서로 비교합니다. 항상 뛰어난 성능을 얻을 수 있지만 실행할 쿼리와 일치하도록 인덱스를 신중하게 작성해야합니다. 특히 쿼리 할 필드가 여러 개인 경우 복합 키 를 신중하게 작성해야 합니다.가능한 빨리 쿼리 할 데이터 세트를 줄입니다. 예를 들어 첫 번째 키는 대부분의 데이터 세트를 필터링하고 두 번째 키는 남아있는 항목 등을 추가로 필터링해야합니다. 쿼리가 정의 된 인덱스에서 키와 해당 키의 순서와 일치하지 않으면 성능이 약간 떨어집니다. 반면에 Mongo는 진정한 데이터베이스이므로 정확성이 필요한 것이라면 그에 대한 답변을 찾을 수 있습니다.

기존 레코드 만료를 위해 Elastic에는 내장 TTL 기능이 있습니다. Mongo는 방금 2.2 버전으로 소개했습니다.

예상 데이터 크기, 트랜잭션, 정확성 또는 필터 모양과 같은 다른 요구 사항을 모르기 때문에 특정 권장 사항을 만들기가 어렵습니다. 바라건대, 여기에 시작하기에 충분합니다.