オープンソースの Apache Cassandra、Kafka、Spark、ES はいつ使用すべきで、いつ使用すべきではないのでしょうか?

[51CTO.com クイック翻訳] ほぼすべてのテクノロジーに関する決定は、企業がビジネス目標を達成できるようにし、テクノロジー アーキテクチャの残りの部分と連携して動作できるようにするという 2 つの基本基準を満たす必要があります。アプリケーション アーキテクチャを構築するためのデータ層テクノロジの選択に関しては、オープン ソースの Apache Cassandra、Apache Kafka、Apache Spark、Elasticsearch が引き続き人気があります。

ただし、すべてのユースケースに適した選択肢というわけではありません。

[[284852]]

これらのテクノロジーのそれぞれと、これらのオープンソース ソリューションが適しているユースケースと適していないユースケースのいくつかを詳しく見てみましょう。

1. アパッチカサンドラ

Cassandra はもともと、Dynamo アーキテクチャと Bigtable スタイルのデータ モデルを使用して高可用性と高スケーラビリティを実現する NoSQL データ ストアを提供するために、2007 年に Facebook によって作成されました。

•Apache Cassandra はいつ使用すればよいですか?

Cassandra は、最高レベルの常時可用性を必要とするユースケースに最適です。このデータベースは、大規模なワークロードが予想される企業や、ワークロードの増加に合わせてサービスを柔軟に拡張できるようにしたい企業にサービスを提供するのにも特に適しており、Cassandra は簡単にスケーラブルであるという利点があります。 Cassandra は、複数のデータセンターにわたって信頼性の高いデータ冗長性とアクティブ/アクティブ操作を提供します。

•いつ使用してはいけないのですか?

データ ウェアハウスや純粋な分析ストレージに関しては (利用可能な Spark コネクタや Tableau および Hadoop プラグインを考慮しても)、Cassandra は他のテクノロジーよりも多くのリソースを消費します。 Cassandra は、アプリケーション側でコードを実装する必要性が複雑になる可能性があるため、特にエンド ユーザーによるアドホック クエリやカスタム クエリの形式でのリアルタイム分析にはまだ適していません。さらに、Cassandra はほとんどの ACID 要件を満たすことができません。

2. アパッチカフカ

Apache Kafka はもともとLinkedIn の技術チームによって作成されました。非常にスケーラブルで可用性の高いストリーミング プラットフォームとメッセージ バスを提供します。 Kafka は分散ログとして機能し、新しく到着したメッセージはキューの先頭に追加され、リーダー (コンシューマー) はオフセットに基づいてそれらを消費します。

•Apache Kafka はいつ使用すればよいですか?

Apache Kafka は、マイクロサービスやサービス指向アーキテクチャを含むユースケースにとって、多くの場合、賢明な選択となります。 Kafka は効率的な作業キューとしても機能し、さまざまな作業パスを調整し、作業が到着するまで待機することで計算能力を節約できます。プラットフォームのストリーム処理機能は、異常検出、ドリルアップ、集約、およびメトリックの配信に役立ちます。 Kafka は、イベント ソーシング、さまざまなマイクロサービス間でのデータ調整、分散システムへの外部コミット ログの提供に使用できる強力なテクノロジーでもあります。その他の適切なユースケースとしては、ログの集約、データのマスキングとフィルタリング、データの拡充、不正行為の検出などがあります。

•いつ使用してはいけないのですか?

状況によっては魅力的かもしれませんが、少なくともそのような使用ケースでの Kafka の制限と特性を十分に理解していない限り、Kafka をデータベースまたはレコード ソースとして使用しないでください。実際のデータベースは、ほとんどの場合、操作が簡単で柔軟性も高くなります。 Kafka は、トピック全体を含む順次処理にも適していません。リアルタイムのオーディオやビデオ、その他の損失のあるデータ ストリームなど、パケットをエンド ソースにすばやくプッシュすることが目的のユース ケースでは、企業は Kafka ではなくカスタム ソリューションを使用する必要があります。

3. Apache Spark

Apache Spark は、大量のデータを扱うユースケースに適した汎用クラスター コンピューティング フレームワークです。データを分割し、分割されたデータに対して計算を実行することで、ワーカーは他のワーカーのデータが必要になるまで、可能なすべての作業を実行できます。この設計により、Spark はデータ損失に対して非常に耐性を持つと同時に、大規模なスケーラビリティと可用性を実現します。

•Apache Spark はいつ使用すればよいですか?

Spark は、特に複数のソースからデータが到着する場合など、大規模な分析を伴うユースケースに適しています。 Spark は、トランザクション データ ストアからデータ ウェアハウスやデータ レイクに継続的にデータを入力する場合でも、データベースやシステムの移行などの 1 回限りのシナリオの場合でも、ETL やシステム間でデータを移動する必要があるあらゆるユース ケースに最適な強力なソリューションです。既存のデータに基づいて機械学習パイプラインを構築したり、高レイテンシのデータ ストリームを処理したり、インタラクティブ、アドホック、探索的な分析を実行したりする企業にとって、Spark は最適です。 Spark は、コンプライアンスの観点からデータ マスキング、データ フィルタリング、大規模データ セット監査機能も提供しており、企業がコンプライアンス要件を満たすのに適しています。

•いつ使用してはいけないのですか?

Spark は一般に、リアルタイムまたは低レイテンシの処理を伴うユースケースには最適な選択肢ではありません。 (Apache Kafka やその他のテクノロジーは、リアルタイム ストリーム処理を含むこれらの要件を満たす優れたエンドツーエンドのレイテンシを提供します)。小規模なデータセットや単一のデータセットを扱う場合、Spark は過剰になることがよくあります。また、データ ウェアハウスやデータ レイクに関しては、Apache Spark ではなく高度なテクノロジを使用する方が適切ですが、Spark 用のそのような製品も存在します。

4. エラスティックサーチ

Elasticsearch は、非構造化データの検索と分析のための広範な機能を備えた全文検索エンジンを提供します。このテクノロジーは、ほぼリアルタイムのスケーラブルな線形検索、強力な検索ドロップイン置換、および強力な分析機能を提供します。

•Elasticsearch はいつ使用すればよいですか?

Elasticsearch は、全文検索、地理検索、公開データのクロールと集約、ログ記録とログ分析、視覚化、少量のイベント データとメトリックを必要とするユース ケースに最適です。

•いつ使用してはいけないのですか?

Elasticsearch は、リレーショナル データのデータベースやレコード ソースとして使用したり、ACID 要件を満たすために使用したりしないでください。

補完的な技術の選択

ビジネスに最適なテクノロジーの組み合わせを選択するには (オープンソースかどうかに関係なく)、ソリューション自体を評価するだけでは不十分であることは明らかです。意思決定者は、企業がテクノロジー アーキテクチャの一部として各ソリューションをどのように採用し、使用するかについても想定する必要があります。 Apache Cassandra、Apache Kafka、Apache Spark、Elasticsearch は、企業が一緒に使用するのに特に適しており、特に補完的なテクノロジ セットを提供します。また、オープンソースであるため、ライセンス料は不要で、ベンダーロックインもありません。これらのテクノロジーを組み合わせて、それらがもたらす利点を活用することで、企業は目標を達成し、拡張性、可用性、移植性、耐障害性に非常に優れたアプリケーションを開発できます。

原題: オープンソースの Apache Cassandra、Kafka、Spark、Elasticsearch を使用するタイミングと使用しないタイミング、著者: Ben Slater

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。