ElasticsearchとCassandraの比較vs Cassandraを使用したElasticsearch

私はNoSQLを学び、クライアントの要件の1つに対するさまざまなオプションを検討しています。私はこの質問をする前にさまざまなリソースを調べました（NoSQLの知識がほとんどない人）

• より高速にデータを保存し、データを読み取る必要があります。
• 完全なフェイルセーフで簡単に拡張可能。
• アナリティクスのデータを検索できる。

私は最終的には短いリストになりました： Cassandra and Elasticsearch

私が理解しているのは、Cassandraが私にとって完璧なNoSQLストレージソリューションであることです。これは、インデックスを使用してデータの書き込みと読み取りができるためです。失敗するか、失敗する可能性があるのは、アナリティクスです。将来、からデータを取得したい場合from_date to to_dateや、分析用のデータを取得する方法が増えた場合、データモデルを適切に設計しなかったり、長期的な視野を維持しなかったりすると、変化する世界では非常に困難になる可能性があります。

一方Elastic Search、（Luceneに裏打ちされた）インデックス作成は最適であり、ランダムなテキストをスローすることでランダムにデータを検索できます。しかし、データを取得したい場合でも同じように機能しますか（そうなると思いfrom_date to to_dateます）。しかし、本当の問題は、それが検索エンジンなのか、それともCassandraのような完璧なNoSQLデータストレージなのか、です。はいの場合、なぜまだCassandraが必要なのですか？

これらの両方が異なる世界にある場合は、それについて説明してください！それらを組み合わせてより効果的なソリューションを得るにはどうすればよいですか？

アプリケーションの1つは、CassandraとElasticSearchの両方に保存されているデータを使用します。Cassandraを使用して、可能な場合はいつでもこれらのレコードにアクセスし、特定のアプリケーション側の要求に準拠するように設計されたクエリテーブルにデータを複製します。クエリテーブルで許可されているよりも自由な検索の場合、ElasticSearchはその機能を適切に実行します。

同じ質問を（私たち自身で）行いました...「ElastsicSearchからすべてを取得してみませんか？」

その答えは、ElasticSearchは永続的なデータストアではなく、検索エンジンとして設計されたことです。ElasticSearchが書き込みを失うことがあります。ElasticSearchでスキーマを変更することは、すべてを吹き飛ばしてリロードしないと困難です。そのために、ElasticSearchをCassandraクラスターと同期させるように設計されたジョブを作成しました。また、このトピックに関するQuoraに関するかなり最近の議論もあり、同様のポイントが得られました。

そうは言っても、ElasticSearch は検索エンジンとして最適です。また、Cassandra はスケーラブルで高性能なデータストアとして最適です。ただし、データのクエリは、データの検索とは異なります。どちらか一方が必要になる場合があり、2つのアプリケーションの組み合わせがうまく機能します。それはあなたのためにうまくいくかもしれません（またはそうでないかもしれません）。

分析に関しては、Cassandra Sparkコネクタを使用して、より複雑なOLAPクエリを処理することにある程度成功しました。お役に立てば幸いです。

20200421を編集

私は同様の質問に対する新しい回答を書きました：

ElasticSearchとElasticSearch + Cassandra

Cassandra + Luceneは素晴らしいオプションです。たとえば、この問題にはさまざまな取り組みがあります。

• StratioのCassandra Luceneインデックス-Stratio Cassandraから派生した、Apache Cassandraのプラグインで、そのインデックス機能を拡張します。（https://github.com/Stratio/cassandra-lucene-index）
• Stratio Cassandraは、Apache Luceneとのネイティブ統合であり、非常に興味深いものです。（https://github.com/Stratio/stratio-cassandra）-このプロジェクトはStratioのCassandra Luceneインデックスの好意で中止されました
• 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が適しています。

私のケースはデータ分析でした。したがって、後でデータを大量に走査して次のステップを確認する必要があったため、エラスティック検索で多くのラテックスを保存しました。分析パイルラインのデータのスキーマに多くの変更を加えたい場合は、casandraを使用しました。

また、いくつかの優れたグラフィックを使用してデータを表示するために使用できる、kibanaなどの多くの優れた表現ツールがあります。たぶん私は怠惰ですが、彼らはとても見栄えがよく、私を助けてくれました。

CassandraとElasticSearchを組み合わせてデータを保存すると、ほとんどの機能が得られます。キーと値のテーブルを検索したり、インデックス内のデータを検索したりできます。

組み合わせにより、アプリケーションに理想的な柔軟性が得られます。

ElassandraはCassandra + Elastic searchを組み合わせたソリューションです。Elasticsearchを使用してデータにインデックスを付け、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またはSOlrのサポーターであること。私は両方の検索エンジンに取り組んできましたが、正しく構成すれば両方の検索エンジンを流暢に使用できることを経験しました。
• リアルタイムの結果をターゲットとしていて、応答のミリ秒の遅延を損なうことができない場合、私がそれを思いつくことができる唯一の短所。次に、cassandraやcouchbaseなどの他のNoSQLデータベースを利用することをお勧めします。
• solrを使用したCassandraは、elasticSearchを使用したCassandraよりもうまく機能します。

Cassandraは、IDによるデータの取得に優れています。セカンダリインデックスのパフォーマンスについてはあまり知りませんが、Elasticsearchほど高速ではないかと思います。確かにそれは、フルテキスト検索機能に来るときElasticsearch勝（テキスト分析、関連性スコアリング、など）。

Cassandraも更新パフォーマンスで勝っています。Elasticsearchは更新をサポートしていますが、更新は実際にはアトミック操作での再インデックス+ソフト削除です。

Cassandraには、非常に優れたレプリケーションモデルがあります（フェールセーフを強化する必要がある場合）。Elasticsearchも大丈夫です。私は、ESが特に信頼性が低い（すべてのソフトウェアのように問題が発生する場合がある）と言っている陣営にはいません。

Elasticsearchには、リアルタイム分析用の集計もあります。また、検索が非常に高速であるため、データのサブセットの分析も高速になります。

あなたの要件がそれらの1つで十分に満足されている場合（ここではESがうまく機能しているようです）、私はそれを使用します。両方の世界からの要件がある場合は、次のいずれかを行うことができます。

• それらの1つを使用して、欠点を回避します。たとえば、Elasticsearchを使用すると多くの更新を処理できる可能性がありますが、シャードとハードウェアが多くなります
• 両方を使用して、それらが同期していることを確認してください