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 쿼리를 처리하는 데 성공했습니다. 도움이되기를 바랍니다.
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는 Lucene 인덱스를 기반으로하므로 elasticsearch에 인덱싱을 저장하려는 경우 데이터 검색을 위해 Cassandra 자체의 인덱싱과 비교하여 가장 잘 수행됩니다.
- 요구 사항이 실시간 검색과 관련이없는 경우 Elasticsearch를 NoSQL 데이터베이스로 사용할 수도 있습니다. ElasticSearch가 쓰기를 잃고 스키마 변경이 어렵다는 생각이 있지만 데이터 볼륨이 너무 크지 않은 경우. Elasticsearch를 NoSQL 데이터베이스로 사용하는 elasticsearch와 함께 최상의 인덱싱을 제공하는 검색 엔진으로 elasticsearch를 쉽게 얻을 수 있습니다. 이를 방지 할 수있는 몇 가지 방법이 있습니다. 데이터 구조가 일관되면 문제가 발생할 수 있으므로 elasticsearch에서 스키마 변경 작업을 수행했습니다.
- ElasticSearch 또는 SOlr의 후원자입니다. 저는 두 검색 엔진 모두에서 작업했으며 올바르게 구성하면 두 검색 엔진을 유창하게 사용할 수 있다는 것을 경험했습니다.
- Only cons that i can think of it, if you are targetting real time result and can't comprosie milliseconds delay in your response. Then its better to take help of other NoSQL databases like cassandra or couchbase.
- Cassandra with solr, work better than Cassandra with elasticSearch.
We had developed an application where we used Elasticsearch and Cassandra. Similar data was stored into Cassandra and indexed into Elasticsearch.
Our application's UI was having features like searches, aggregations, data export, etc. The back-end microservices were continuously getting huge data (on Kafka topics) and storing it into Cassandra. Once the data is stored into Cassandra, the services would make sure the data is indexed into Elasticsearch.
Cassandra was acting as "Source of truth" for Elasticsearch. In the cases, where reindexing of the ES index was required, we queried Cassandra and reindexed the data into ES.
This solution helped us, as this was very easy to scale and the searches and aggregations were much faster.
'programing tip' 카테고리의 다른 글
| 언제 분기해야합니까? (0) | 2020.08.12 |
|---|---|
| Visual Studio에서 디버그와 릴리스의 차이점은 무엇입니까? (0) | 2020.08.12 |
| 중복 키로 구현 매핑 (0) | 2020.08.12 |
| 문자열의 줄을 반복합니다. (0) | 2020.08.12 |
| Rmarkdown에 \ newpage를 현명하게 추가하는 방법은 무엇입니까? (0) | 2020.08.12 |