selastic search v.s.응용 프로그램 필터링용 MongoDB
이 질문은 실험과 구현의 세부사항을 조사하기 전에 아키텍처 선택을 하는 것에 관한 것입니다.확장성 및 성능 측면에서 탄력 검색 v.s.의 적합성에 대한 것입니다.MongoDB, 좀 더 구체적인 목적을 위해.
둘 다 필드와 값이 있는 데이터 개체를 저장하고 해당 개체의 본문을 조회할 수 있습니다.따라서 애드혹을 선택한 필드에 따라 오브젝트의 서브셋을 필터링하는 것은 양쪽 모두에 적합합니다.
나의 어플리케이션은 기준에 따라 오브젝트를 선택하는 것을 중심으로 합니다.여러 필드를 동시에 필터링하여 개체를 선택합니다. 달리 말하면 쿼리 필터링 기준은 일반적으로 1~5개의 필드로 구성됩니다.경우에 따라서는 더 많을 수도 있습니다.반면 필터로 선택된 필드는 훨씬 더 많은 양의 필드의 하위 집합이 됩니다.존재하는 약 20개의 필드 이름을 상상합니다.각 쿼리는 전체 20개 필드 중 몇 개의 필드를 기준으로 개체를 필터링합니다(기존 전체 필드 이름보다 작거나 20개가 넘을 수 있습니다.이 숫자는 모든 이산 쿼리에서 필터로 사용되는 필드 대 필드 비율을 나타내기 위해 사용한 것입니다).필터링은 필드 값뿐만 아니라 선택한 필드의 존재에 의해서도 가능합니다.예를 들어 필드 A가 있고 필드 B가 x와 y 사이이고 필드 C가 w와 같습니다.
응용 프로그램은 이러한 필터링을 지속적으로 수행하지만 필터링에 사용되는 필드는 항상 없거나 거의 일정하지 않습니다.탄력적 검색에서는 인덱스를 정의해야 하지만 인덱스가 없어도 MongoDB와 같은 속도가 될 수 있습니다.
매장에 들어온 데이터에 대해서는 특별히 자세한 내용은 없습니다.삽입 후 오브젝트는 거의 변경되지 않습니다.오래된 오브젝트를 삭제해야 할 수도 있습니다.두 데이터스토어 모두 내부 또는 어플리케이션에서 작성한 쿼리에 의해 지원이 만료된다고 가정합니다.(특정 쿼리에 맞는 오브젝트도 삭제해야 합니다.)
당신은 어떻게 생각하나요?그리고 이 측면을 실험해 본 적이 있습니까?
이러한 작업을 위해 두 데이터 저장소 각각에 대한 성능과 확장성에 관심이 있습니다.이것은 아키텍처 설계 질문의 일종이며, 충분히 숙고한 제안의 실증으로서 스토어 고유의 옵션이나 쿼리 주춧돌의 상세 내용을 환영한다.
감사합니다!
우선, 여기서 중요한 구별이 있습니다.MongoDB는 범용 데이터베이스이고 Elastic Search는 Lucene이 지원하는 분산 텍스트 검색 엔진입니다.사람들은 Elastic Search를 범용 데이터베이스로 사용하는 것에 대해 이야기 해 왔지만, 이것이 원래 디자인이 아니라는 것을 알고 있다.범용 NoSQL 데이터베이스와 검색 엔진은 통합을 목표로 하고 있다고 생각합니다만, 현 상태에서는, 이 둘은 매우 다른 2개의 진영에서 온 것입니다.
저희 회사에서는 MongoDB와 Elastic Search를 모두 사용하고 있습니다.당사는 데이터를 MongoDB에 저장하여 Elastic Search의 전체 텍스트 검색 기능만을 사용합니다.우리는 탄력적으로 조회해야 하는 mongo 데이터 필드의 서브셋만 보냅니다.당사의 사용 사례는 Mongo 데이터가 항상 변경된다는 점에서 다릅니다. 레코드 또는 레코드 필드의 서브셋은 하루에 여러 번 갱신할 수 있으며, 이로 인해 해당 레코드의 인덱스를 탄력적으로 재색인해야 할 수 있습니다.이러한 이유만으로 Elastic을 유일한 데이터스토어로 사용하는 것은 좋은 옵션이 아닙니다.일부 필드를 갱신할 수 없기 때문에 문서 전체를 재인덱스화할 필요가 있습니다.이것은 탄력적인 제한이 아니라 Lucene이 작동하는 방식이며, 탄력적인 검색 엔진의 기반이 됩니다.이 경우, 일단 저장된 레코드는 변경되지 않으므로 이러한 선택을 할 필요가 없습니다.단, 데이터의 안전성이 걱정된다면 데이터를 저장하기 위한 유일한 메커니즘으로 Elastic Search를 사용하는 것을 다시 한 번 생각해 보겠습니다.어느 시점에 도착할지 모르지만 아직 도착했는지 잘 모르겠어요.
속도 면에서는 Elastic/Lucene이 Mongo의 쿼리 속도와 동등할 뿐만 아니라 "어떤 필드가 필터링에 사용되는지 어느 시점에서도 거의 일정하지 않은 경우" 데이터 세트가 커질수록 속도가 훨씬 빨라질 수 있습니다.차이점은 기본 쿼리 구현에 있습니다.
- Elastic/Lucene은 정보 검색에 벡터 공간 모델 및 반전 인덱스를 사용합니다.이것은 조회와 레코드 유사성을 비교하는 매우 효율적인 방법입니다.Elastic/Lucene을 쿼리할 때는 이미 답을 알고 있습니다.대부분의 작업은 쿼리 용어와 일치하는 결과를 순서대로 나열하는 것입니다.이것은 중요한 포인트입니다.데이터베이스와 달리 검색 엔진은 정확한 결과를 보장할 수 없습니다.검색 결과는 쿼리에 얼마나 근접했는지에 따라 순위가 매겨집니다.대부분의 경우 결과는 정확에 가깝습니다.
- Mongo의 접근방식은 보다 범용적인 데이터 스토어입니다.JSON 문서를 서로 비교합니다.어떤 방법으로든 뛰어난 성능을 얻을 수 있지만 실행할 쿼리와 일치하도록 인덱스를 신중하게 작성해야 합니다.특히 쿼리할 필드가 여러 개 있는 경우 쿼리되는 데이터 집합을 최대한 빨리 줄일 수 있도록 복합 키를 신중하게 만들어야 합니다.예를 들어 첫 번째 키는 데이터 세트의 대부분을 필터링하고 두 번째 키는 남은 데이터를 필터링하는 등의 작업을 수행합니다.쿼리가 정의된 인덱스에서 키와 키의 순서와 일치하지 않으면 성능이 상당히 저하됩니다.한편, Mongo는 진정한 데이터베이스이기 때문에, 정확성이 필요한 것이라면, 그 해답은 딱 들어맞을 것입니다.
오래된 레코드의 기한이 만료되는 경우 Elastic에는 TTL 기능이 내장되어 있습니다.Mongo가 방금 버전 2.2부터 소개한 것 같아요.
예상되는 데이터 크기, 트랜잭션, 정확도, 필터의 모양 등 기타 요구 사항을 알 수 없기 때문에 구체적인 권장 사항을 제시하기는 어렵습니다.시작하기에 충분한 양이 있길 바랍니다.
언급URL : https://stackoverflow.com/questions/12723239/elasticsearch-v-s-mongodb-for-filtering-application
'programing' 카테고리의 다른 글
| spring에서 bean xml 구성 파일이 존재해도 찾을 수 없습니다. (0) | 2023.03.11 |
|---|---|
| Oracle Data Source와Oracle UCP Pool Data Source (0) | 2023.03.11 |
| Angular js와 Express js의 기본적인 차이와 유사점은 무엇입니까? (0) | 2023.03.11 |
| jQuery에서 .fail로 전송되는 파라미터는 무엇입니까? (0) | 2023.03.11 |
| JSON에서는 여러 줄의 스트링을 사용할 수 있습니까? (0) | 2023.03.11 |