Elasticsearch 대 Cassandra 대 Cassandra를 사용한 Elasticsearch

저는 NoSQL을 배우고 있으며 고객의 요구 사항 중 하나에 대해 다른 옵션을 찾고 있습니다. 이 질문을 올리기 전에 다양한 리소스를 살펴 보았습니다 (NoSQL에 대한 지식이 거의없는 사람).

• 더 빠른 속도로 데이터를 저장하고 데이터를 읽어야합니다.
• 완전히 안전하고 쉽게 확장 할 수 있습니다.
• Analytics 용 데이터를 검색 할 수 있습니다.

나는 짧은 목록으로 끝났다 : Cassandra and Elasticsearch

내가 이해하는 것은 Cassandra가 인덱스를 사용하여 데이터를 쓰고 읽을 수 있기 때문에 나에게 완벽한 NoSQL 스토리지 솔루션이라는 것입니다. 실패하거나 실패 할 수있는 곳은 Analytics에 있습니다. 미래에에서 데이터를 가져 from_date to to_date오거나 분석을위한 데이터를 가져 오는 더 많은 방법을 원하거나 데이터 모델을 제대로 설계하지 않거나 장기적인 시각을 유지하지 않으면 세상이 계속 변하는 상황에서 상당히 어려울 수 있습니다.

동안 Elastic Search(Lucene을 바탕으로) 색인에서 최고입니다, 어떤 임의의 텍스트를 던져 무작위 데이터를 검색 할 수 있습니다. 그러나 데이터를 검색하려는 경우에도 동일하게 작동합니까 from_date to to_date(그럴 수도 있습니다). 하지만 진짜 질문은 이것이 검색 엔진입니까, 아니면 Cassandra와 같은 완벽한 NoSQL 데이터 저장소입니까? 그렇다면 왜 우리는 여전히 카산드라가 필요합니까?

둘 다 다른 세계에 있다면 설명해주세요! 더 효과적인 솔루션을 얻기 위해 어떻게 결합합니까?

우리의 애플리케이션 중 하나는 Cassandra와 ElasticSearch 모두에 저장된 데이터를 사용합니다. 우리는 Cassandra를 사용하여 가능할 때마다 이러한 레코드에 액세스하고 특정 애플리케이션 측 요청을 준수하도록 설계된 쿼리 테이블에 데이터를 복제합니다. 쿼리 테이블이 허용하는 것보다 더 자유로운 검색을 위해 ElasticSearch는 해당 기능을 훌륭하게 수행합니다.

우리는 같은 질문을했습니다. "ElastsicSearch에서 모든 것을 얻지 않는 이유는 무엇입니까?"

대답은 ElasticSearch가 영구 데이터 저장소가 아닌 검색 엔진으로 설계되었다는 것입니다. 때때로 ElasticSearch가 쓰기를 잃습니다. ElasticSearch에서는 모든 것을 날려 버리고 다시로드하지 않고 스키마 변경을 수행하기가 어렵습니다. 이를 위해 ElasticSearch를 Cassandra 클러스터와 동기화 상태로 유지하도록 설계된 작업을 작성했습니다. 또한 이 주제에 대해 Quora에 대한 최근 논의 가 있었는데 , 비슷한 점이 나타났습니다.

그 존재는 ElasticSearch 작동 말했다 큰 검색 엔진으로. 그리고 Cassandra 는 확장 가능한 고성능 데이터 저장소로 훌륭하게 작동합니다 . 그러나 데이터 쿼리는 데이터 검색 과 다릅니다 . 둘 중 하나가 필요할 때가 있으며 두 가지 조합이 우리의 응용 프로그램에 적합합니다. 그것은 당신에게 잘 작동 할 수도 있고 그렇지 않을 수도 있습니다.

분석에 관해서는 Cassandra Spark 커넥터를 사용하여 더 복잡한 OLAP 쿼리를 처리하는 데 성공했습니다. 도움이 되었기를 바랍니다.

20200421 편집

비슷한 질문에 대한 새로운 답변을 작성했습니다.

ElasticSearch 대 ElasticSearch + Cassandra

Cassandra + Lucene은 훌륭한 옵션입니다. 이 문제에 대한 다양한 이니셔티브가 있습니다. 예를 들면 다음과 같습니다.

• Stratio의 Cassandra Lucene Index-Stratio Cassandra에서 파생 된 것은 인덱스 기능을 확장하는 Apache Cassandra 용 플러그인입니다. ( https://github.com/Stratio/cassandra-lucene-index )
• Stratio Cassandra, Apache Lucene과의 기본 통합입니다. 매우 흥미 롭습니다. ( https://github.com/Stratio/stratio-cassandra)- 이 프로젝트는 Stratio의 Cassandra Lucene Index를 선호하여 중단되었습니다.
• Tuplejump Calliope는 Stratio Cassandra와 비슷하지만 덜 활동적입니다. ( https://github.com/tuplejump/stargate-core )
• Datastax로 DSE 검색. Apache Solr와 함께 Cassandra를 사용할 수 있지만 독점 옵션입니다. ( http://www.datastax.com/what-we-offer/products-services/datastax-enterprise )

이 문제를 직접 해결 한 후에는 casandra와 같은 NoSQL 데이터베이스가 안정적인 쓰기 작업으로 데이터 스키마를 보존하고 elasticsearch가 제공하는 인덱싱 작업을 활용하고 싶지 않을 때 유용하다는 것을 깨달았습니다. 일부 인덱스 데이터를 보존하려는 경우 스킴을 신뢰하고 쓰기보다 훨씬 더 많은 읽기만 수행 할 경우 elasticsearch가 좋습니다.

제 경우는 데이터 분석이었습니다. 그래서 나중에 다음 단계가 무엇인지 확인하기 위해 데이터를 많이 탐색하기를 원했기 때문에 탄력적 검색에서 많은 Latices를 보존했습니다. 분석 파일 라인에서 데이터 스키마를 많이 변경하려면 casandra를 사용했을 것입니다.

또한 좋은 그래픽으로 데이터를 표시하는 데 사용할 수있는 kibana와 같은 멋진 표현 도구가 많이 있습니다. 어쩌면 나는 게으르지 만 그들은 매우 잘 생겼고 나를 도왔습니다.

Cassandra와 ElasticSearch의 조합으로 데이터를 저장하면 대부분의 기능을 사용할 수 있습니다. 키-값 테이블을 조회 할 수 있으며 색인에서 데이터를 검색 할 수도 있습니다.

이 조합은 애플리케이션에 이상적인 많은 유연성을 제공합니다.

Elassandra 는 Cassandra + Elastic search의 결합 된 솔루션입니다. Elastic search를 사용하여 데이터를 인덱싱하고 Cassandra를 데이터 저장소로 사용합니다. 성능에 대해서는 잘 모르겠지만이 기사에 따르면 성능이 좋습니다.
애플리케이션에 검색 기능이 필요한 경우 Elassandra가 최고의 오픈 소스 옵션입니다. DSE 검색을 사용할 수 있지만 비용이 많이 듭니다.

Elasticsearch와 Cassandra를 사용하는 애플리케이션을 개발했습니다. 유사한 데이터가 Cassandra에 저장되고 Elasticsearch에 인덱싱되었습니다.

우리 애플리케이션의 UI에는 검색, 집계, 데이터 내보내기 등과 같은 기능이있었습니다. 백엔드 마이크로 서비스는 지속적으로 거대한 데이터 (Kafka 주제에 대한)를 가져와 Cassandra에 저장했습니다. 데이터가 Cassandra에 저장되면 서비스는 데이터가 Elasticsearch에 인덱싱되었는지 확인합니다.

Cassandra는 Elasticsearch의 "진실의 근원"역할을했습니다. ES 인덱스의 재 인덱싱이 필요한 경우 Cassandra를 쿼리하고 데이터를 ES로 다시 인덱싱했습니다.

이 솔루션은 확장이 매우 쉽고 검색 및 집계 속도가 훨씬 빨 랐기 때문에 도움이되었습니다.

• elasticsearch는 Lucene 인덱스를 기반으로하므로 elasticsearch에 인덱싱을 저장하려는 경우 데이터 검색을 위해 Cassandra 자체의 인덱싱과 비교하여 가장 잘 수행됩니다.
• 요구 사항이 실시간 검색과 관련이없는 경우 Elasticsearch를 NoSQL 데이터베이스로 사용할 수도 있습니다. ElasticSearch가 쓰기를 잃고 스키마 변경이 어렵다는 생각이 있지만 데이터 볼륨이 너무 크지 않은 경우. Elasticsearch를 NoSQL 데이터베이스로 사용하는 elasticsearch와 함께 최상의 인덱싱을 제공하는 검색 엔진으로 elasticsearch를 쉽게 얻을 수 있습니다. 이를 방지 할 수있는 몇 가지 방법이 있습니다. 데이터 구조가 일관되면 문제가 발생할 수 있으므로 elasticsearch에서 스키마 변경 작업을 수행했습니다.
• ElasticSearch 또는 SOlr의 후원자입니다. 나는 두 검색 엔진 모두에서 작업했으며 올바르게 구성하면 두 검색 엔진을 유창하게 사용할 수 있다는 것을 경험했습니다.
• 실시간 결과를 목표로하고 응답에서 밀리 초 지연을 방해 할 수 없다면 내가 생각할 수있는 단점 만 있습니다. 그런 다음 cassandra 또는 couchbase와 같은 다른 NoSQL 데이터베이스의 도움을받는 것이 좋습니다.
• solr를 사용하는 Cassandra는 elasticSearch를 사용하는 Cassandra보다 더 잘 작동합니다.

Cassandra는 ID로 데이터를 검색하는 데 능숙합니다 . 보조 인덱스 성능에 대해서는 잘 모르지만 Elasticsearch만큼 빠르지 않은 것 같습니다. 확실히 Elasticsearch는 전체 텍스트 검색 기능 ( 텍스트 분석 , 관련성 점수 등)에있어 승리 합니다.

Cassandra는 업데이트 성능에서도 승리합니다 . Elasticsearch는 업데이트를 지원하지만 업데이트는 실제로 원 자성 작업에서 재 인덱스 + 소프트 삭제입니다.

Cassandra는 매우 멋진 복제 모델을 가지고 있습니다 (고장 안전이 필요한 경우). Elasticsearch도 괜찮습니다. 저는 ES가 특히 불안정하다고 말하는 캠프에 있지 않습니다 (모든 소프트웨어와 마찬가지로 때때로 문제가 있음).

Elasticsearch에는 실시간 분석을위한 집계도 있습니다 . 검색 속도가 너무 빠르기 때문에 데이터 하위 집합에 대한 분석도 빠릅니다 .

귀하의 요구 사항이 그들 중 하나에 의해 충분히 만족된다면 (여기 ES가 잘 작동하는 것처럼 보입니다), 저는 하나만 사용합니다. 두 세계의 요구 사항이 있으면 다음 중 하나를 수행 할 수 있습니다.

• 그중 하나를 사용하고 단점을 해결하십시오. 예를 들어 Elasticsearch로 많은 업데이트를 처리 할 수 ​​있지만 더 많은 샤드와 더 많은 하드웨어를 사용할 수 있습니다.
• 둘 다 사용하고 동기화되어 있는지 확인하십시오.