MongoDB + Elastic search 아니면 Elastic search만?

MongoDB + Elastic search 아니면 Elastic search만?

우리는 그곳에서 대량의 데이터를 색인화하고 실시간으로 제공하는 새로운 프로젝트를 진행하고 있습니다.면, 전체 텍스트, 지리적 공간으로 복잡한 검색도 가능합니다.

첫 번째 프로토타입은 MongoDB에서 인덱스를 만들고 다음으로 Elasticsearch로 인덱스를 만드는 것입니다. Elasticsearch는 저장된 파일에 체크섬을 적용하지 않으며 인덱스를 완전히 신뢰할 수 없습니다.그러나 1.5 버전의 마지막 버전 이후로 체크섬이 있으며 Elastic search를 기본 데이터 저장소로 사용할 수 있는지 여부를 추측합니다.그리고 Elastic search 외에 MongoDB를 사용하면 어떤 이점이 있습니까?

Elastic search에서 해당 기능에 대한 최신 답변을 찾을 수 없습니다.

정말 감사해요.

ES 대신 Mongo를 사용하거나 ES와 함께 사용해야 하는 주장에 대해 이야기합니다.

1. 사용자/역할 관리.

   • MongoDB에 내장되어 있습니다.여러분의 모든 요구에 맞지 않을 수도 있고 어딘가에서 서툴 수도 있지만, 그것은 존재하고 꽤 오래 전에 구현되었습니다.
   • ES의 보안을 위한 유일한 것은 입니다. 그러나 골드/플래티넘 제품은 생산용으로만 배송됩니다.

2. 스키마

   • ES는 스키마가 없지만 이를 기반으로 구축됩니다.Lucene라고 쓰여져 있습니다.Java이 도구의 핵심 아이디어인 색인 및 검색 문서와 이 방법으로 작업하려면 색인 일관성이 필요합니다.백엔드에서는 모든 문서가 평평하게 장착되어야 합니다.lucene색인 - ES가 중첩된 문서와 값을 처리하는 방법과 속도와 데이터 완전성/일관성 간의 균형을 유지하기 위해 색인을 구성하는 방법을 어느 정도 이해해야 합니다.ES로 작업하려면 스키마에 대한 몇 가지 사항을 항상 염두에 두어야 합니다.즉, 사전에 해당 매핑을 추가하지 않고도 ES에 거의 모든 것을 인덱싱할 수 있기 때문에 ES는 매핑을 즉시 "추측"할 수 있지만 때로는 잘못 수행할 수도 있고 때로는 암시적 매핑이 사악합니다. 왜냐하면 한 번 설정하면 전체 인덱스를 다시 인덱싱하지 않고 변경할 수 없기 때문입니다.따라서 ES를 스키마가 없는 저장소로 취급하지 않는 것이 좋습니다. 왜냐하면 시간이 지나면 갈퀴를 밟을 수 있기 때문입니다(그리고 이것은 고통이 될 것입니다:). 오히려 문서 작업을 할 때는 스키마 집약적인 것으로 취급합니다. 적어도 구체적인 필드로 잘라낼 수 있습니다.
   • 반면에 몽고는 여러분이 넣은 거의 모든 것에서 "부스러기를 씹고 남기지 않습니다".그리고 Mongo가 자바스크립트 관점에서 당신의 데이터를 어떻게 다룰지 기억할 때까지 당신의 쿼리는 대부분 잘 작동할 것입니다.그리고 JS가 약하게 입력되기 때문에 스키마가 없는 워크플로우로 작업할 수 있습니다(물론 필요하다면).

3. 테이블과 유사하지 않은 데이터를 처리합니다.

   • ES는 데이터를 검색 인덱스에 넣지 않고 처리하도록 제한됩니다.추가 데이터를 저장하고 검색해야 할 경우 이 솔루션으로 충분합니다(검색하려는 데이터와 비교).
   • MongoDB는 을 지원합니다.이를 통해 동일한 인터페이스 뒤에서 대량의 데이터를 처리할 수 있습니다.즉, 코드 관점에서 이진 데이터를 Mongo에 저장하고 동일한 인터페이스 내에서 검색할 수 있습니다.

자, 적절한 작업에 적합한 도구를 선택하십시오.전체 텍스트 검색, 페이싱 등과 같은 검색 기능이 필요한 경우에는 완전한 검색 엔진을 능가하는 것은 없습니다.ElasticSearch(ES) 또는 Solr는 선택의 문제일 뿐입니다.

실제로 문서를 ES에 입력(인덱스)하여 검색한 다음 MongoDB 또는 다른 데이터베이스에서 특정 항목에 대한 전체 세부 정보를 가져올 수 있습니다.

MongoDB, ES, Redis 및 RabbitMQ를 사용하는 오픈 소스 작업을 여기 github에서 한 곳에 통합할 수 있습니다.

응용프로그램은 기본 제공됩니다.넷 C#.

프로덕션에서 Elastic 검색을 사용한 후 다음 스레드에 몇 가지 참고 사항을 추가할 수 있습니다.

• 쿼리를 허용하기 전에 요청 시 클라이언트 인증서 인증을 확인하는 역방향 프록시를 통해 Elastic 검색 클러스터링을 보호했습니다. 이는 인증을 추가하는 데 여러 가지 방법이 있음을 증명합니다. (역할을 사용하는 것과 같이 보안에 더 정확성이 필요한 경우 권한을 관리하기 위해 추가할 수 있는 플러그인이 거의 없습니다.)
• 탄력적인 검색 매핑 및 설정(조정)은 운영을 시작하기 전에 완전히 이해해야 하는 정말 중요한 개념이며, 모든 것이 어떻게 신속하게 작동하는지 파악하는 것은 그리 쉬운 일이 아닙니다.
• 클러스터링 및 수평 확장이 매우 유연하고 쉽게 설정 가능
• 제품군 툴(키바나, 비트 등)은 로그를 수집하고 주요 데이터를 노출하는 매우 편리한 방법입니다.
• 검색 기능은 매우 고급이므로 전체 텍스트 검색(퍼지함, 부스팅, 스코어링, 스템핑, 토큰화, 분석기 등)의 작동 방식을 조금 익히면 놀라운 작업을 수행할 수 있습니다.
• API는 다소 분산되어 있으며 무언가를 달성하기 위한 고유한 방법은 없습니다.그리고 일부 API는 대량 삽입 API와 같이 실제로 사용하기에 WTF입니다. JSON 형식(Ofc는 줄 끝 문자를 잊지 마십시오)으로 이진 데이터를 전달하고 일부 필드를 여러 번 반복해야 합니다.이것은 매우 장황하고 우리 모두가 프로젝트에서 가지고 있는 것과 같은 레거시 코드인 것 같습니다 ;).
• 마지막으로, Java 프로젝트를 개발할 때 데이터 소스에서 ES 클러스터로 데이터를 복제하는 데 최대 절전 모드 검색을 사용하지 않는 경우, 최대 절전 모드 검색과 관련하여 많은 문제가 발생했습니다. 이 문제를 다시 수행해야 한다면 수동으로 수행해야 합니다.

이제 진짜 질문에 대해 말씀드리겠습니다.

Elastic search만 사용하면 충분하며 여러 NoSQL 스토리지 시스템을 사용하는 복잡성을 줄일 수 있습니다.

나는 당신이 duo Relational and Transactional 데이터베이스 + NoSQL 검색 엔진을 할 때 가치가 있다고 생각하지만, 대략 같은 목적을 위해 서비스하는 두 개의 시스템을 갖는 것은 약간 과해요.

저는 최근에 회사에서 기능을 개발했습니다.

우리는 몇 가지 검색을 수행하고 여러 요인과 조건에 대한 관련성에 따라 결과의 순위를 매기고 싶었습니다.

그래서 제 애플리케이션에서는 이미 MongoDB를 DB로 사용하고 있었습니다.

그래서 ElasticSearch 인덱스에서 검색 및 필터를 수행할 일부 필드를 MongoDB에서 내보냈습니다.그래서 필요한 조건에 따라 mongo 쿼리와 탄력적인 검색 쿼리를 준비하여 검색을 수행했습니다.그런 다음 필요에 따라 결과를 필터링하고 분류했습니다.전체 흐름 의지는 ES에서 오류가 발생하더라도 mongo가 레코드를 가져오도록 설계되었습니다.그때 ES에서 결과를 얻으면 mongo 결과는 ES 결과에 따라 달라질 것입니다.이것이 제가 몽고와 ES를 조합해서 사용한 방법입니다.

또한 모든 업데이트, 삭제 및 새 레코드 삽입을 적절하게 처리하는 것을 잊지 마십시오.

그리고 저는 'Just to Know, I'm really good.

언급URL : https://stackoverflow.com/questions/29538527/mongodb-elasticsearch-or-only-elasticsearch