ほほすべてがストリームだとしたら、データベースなしで生きていけるのか?
昨今ストリーミングエコシステムは、多くの注目を集める一方で、しばしば混乱を招く分野の 1 つです。
この記事では、リアルタイムデータベースがストリーミングテクノロジーと並行してどのように繁栄するか、より詳しく検証します。
つまり、これらは連携して最も効果的に機能する必須のテクノロジーであり、相互に代替することはほとんどありません。
ストリーミングにより、よりリアルタイムなユースケースが可能に
JMS や ActiveMQ のメッセージングとキューイングの世界が、Kafka や Pulsar といった分散型イベントストリーミングツールによって推進されるにつれて、移動中のデータの規模とスループットは爆発的に増加しました。
この移動データの増加により、Aerospike のようなリアルタイム データベースの市場が拡大し、銀行や アドテック企業だけでなく、小売業者、通信プロバイダー、IoT データを扱うメーカーなどにとっても差別化要因となっています。
ストリーミング技術と機能の普及により、質素なデータベースが不要になるのではないかと疑問に思う人もいます。
すべてがストリームである場合、データベースなしで生き残ることはできるのでしょうか。
実のところ、Kafka のような分散ストリーミング プラットフォームが広く採用される前から、高性能の分散データベースは企業のデータ環境のリアルタイムコンポーネントでした。
ストリーミング アーキテクチャの成長は、より多くの組織が広範に「リアルタイム化」できるようになるため、リアルタイム データベースにとって大きな進歩です。
リアルタイム データベースは通常、99 パーセンタイルで 100、10、さらには 1 ミリ秒未満のスループットで 1 秒あたり 100 万件を超えるトランザクションのワークロードを配信します。
しかし、正直なところこのパフォーマンスが魅力的なのは、アプリケーションパイプラインの他の部分のレイテンシーが、最小限である環境でのみです。
例えば、アプリケーションとメッセージングキューの処理に 2 秒かかるとしましょう。
その場合、ミリ秒未満のトランザクションを行うデータベースは、たとえば 500 ミリ秒のトランザクションを行うより平凡なデータベースと比べて、状況を大きく変えるものではありません。
金融サービス企業とAdTech企業は分散型 NoSQL データベースを早期に採用しており、通常はデータベースをデータ ソースと宛先に直接または密接に接続していました。
現在でも、最も要求の厳しいアプリケーションを使用する顧客は通常、リアルタイム入札 API に直接接続しており、TransUnionのような組織は、データベースを金融機関のデータセンターに拡張して、不正検出の導入における遅延を短縮しています。
データストリーミングプラットフォームには、データベースが必要
ストリーミングは非常に人気が高まっているため、ストリーミングを特効薬として考え、すべてのデータ アーキテクチャをストリーミング専用に構築する必要があると考える人もいます。
繰り返しになりますが、すべてがイベントであれば、データベースやテーブルではなく、ストリーミング トピックだけが必要であると主張する人もいるかもしれません。
技術的には、ksqlDB をデータベースにすることはできますが、どのような規模であっても堅牢なデータベースではありません。
多様な履歴データを組み込んだリアルタイムのユースケースでは、これは当てはまりません。
Kafka や Pulsar のような最新の分散ストリーミング サービスの強みは、膨大な数のストリーム パブリッシャーとサブスクライバーを処理できることです。
新しいストリーミングプラットフォームは、最新のハードウェアを最大限に活用し、速度とパフォーマンスが向上しています。マイクロサービス アプリケーション環境は、移動中のデータの流動性に依存しており、多くのサービスがデータのさまざまなサブセットを消費および提供しています。
基本的なオンライン ゲームを考えてみましょう。
プレーヤーのクリックがストリーム トピックに追加され、トピックにサブスクライブしているサーバーがアクションを適用し、サーバーは結果をゲーム環境にパブリッシュします。
このリアルタイム システムにはデータベースも必要ありません。
そうは言っても、この動作中のデータの多くは、基本的なゲーム内の仕組みを超えた歴史的価値があるため、永続化する必要があります。
過去のデータはプレイヤーの行動を理解し、ゲームプレイの異常を検出し、ゲーム開発に情報を提供するのに役立つため、多くのプロセスや意思決定には、最後の数回のリアルタイム クリック以上のものを組み込む必要があります。
これには、過去のストリーミング データと他の非ストリーミング データ ソースの両方が含まれます。
かなり基本的なストリーミング アーキテクチャであっても、通常は過去のデータを使用してリアルタイム データ ストリームを強化します。
ストリーミング システムは、ほとんどのデータベースとは異なり、ランダム データ アクセス パターンに対して最適化されていません。
在庫管理、顧客サポート、予防保守などのユースケースには、多くの場合、特定のデータ ポイントへの低遅延アクセスが必要となります。
すべてがレイテンシーを追加する〜ストリーミングも含めて
ストリーミング テクノロジーは、リアルタイムのユースケースと正しく関連付けられています。
ただし、データ フローの追加ステップと同様に、遅延が発生します。多くのユースケースでは、アプリケーションを高性能データベースに直接接続し、ストリーミング手順を省略することでメリットが得られます。
分散ストリーミングは高速になっていますが、エンドツーエンドのデータ プロセスでは依然として停止が追加されています。
Kafka ベースの代替品であるRedpandaは、Kafka のレイテンシーを削減し、効率を高めることを目的としています。
このKafka と Redpanda の比較では、最高のレイテンシでも 4 ミリ秒ですが、多くのテール レイテンシは 100 ミリ秒を超え、ワークロードが大きくなるとさらに高くなります。
多くの要求の厳しいアプリケーションでは、データベースをソース API や宛先 API に直接接続する方が合理的であることがよくあります。
前述したように、金融サービスやアドテックなど、ミリ秒単位で勝利を収めている企業は、ストリーミング テクノロジーを完全にバイパスするなど、ホップを最小限に抑えるように優先アプリケーションを設計しています。
分散システムのデータの一貫性
分散展開全体で一貫性を保証する必要がある組織は、ストリーミングのみに依存することはできません。
ストリーミング システムは、強力な一貫性ではなく高可用性に重点を置いています。
つまり、分散展開の一貫性とパーティション耐性の両方のバランスをとるモードを提供できません。
CAP定理は、分散システムのトレードオフを要約しています。
システムは複数のパーティションに分散されます。
したがって、パーティションが互いに壊れたり、ノードに障害が発生した場合、パーティションは応答 (可用性) を提供するか、すべてのリクエストに対して最新の書き込み更新 (一貫性) を維持して提供する必要があります (またはエラーを生成します)。
LinkedIn の Kafka の作成者は、これを CA システムとして指定しました。これは、Kafka がパーティション許容度をまったく処理しないことを意味します。
ネットワークに障害が発生すると、一貫した信頼できる情報源としてストリームに依存できなくなります。
アプリケーションがレコードの現在の値を知るためにデータベースにアクセスする方法を考えてみましょう。
個人のストリーミング トピックに 20 件のクレジット カード トランザクションがあると想像してください。
それぞれが与信限度額を超えているかどうかに影響します。次回の購入を許可するかどうかは、トピックのどの位置にいるかによって決まります。
結果整合性モデルとして、クレジット制限を計算する前に以前のすべての購入が評価されることが保証されていないため、このユースケースではストリーミング トピックをデータベースとして使用することは失敗します。
同様に、1 秒あたり 10 件以上の更新など、頻繁に更新される多くのレコードを迅速にロードして処理する必要があります。Kafka のようなストリーミング専用のアーキテクチャでは、レコードの最新バージョンを特定するには、Kafka トピック全体の時間のかかるスキャンが必要です。
Kafka は高速ランダム読み取りではなく、順次ログベースの読み取りに最適化されているため、特定のタイムスタンプの値を取得するか、トピックの先頭にある現在の値を取得するかを決定することは、さらなる課題となる可能性があります。
最新データへのリアルタイム アクセスが重要である株式取引プラットフォームのようなリアルタイム アプリケーションでこの課題を検討してください。
Kafka は大規模なデータ ストリームの管理には優れていますが、その設計は即時のランダムなデータ アクセスを必要とするシナリオにはあまり適していません。
ストリーミングがすべてのデータベースが増加させる〜一部のデータベースは他のデータベースよりも多く
ストリーミングは、多くの組織の環境におけるリアルタイム機能の基準を引き上げます。
潜在的な新規顧客と話をするとき、彼らが Kafka、Pulsar、または Redpanda を採用しているかどうかは、低レイテンシーと大規模なパフォーマンスの利点を高く評価していることを示すため、素晴らしい兆候です。
前述したように、リアルタイム データベースは、待ち時間が長くパフォーマンスが低い、より広範なアーキテクチャに囲まれている場合には役に立ちません。
一方、パフォーマンスの低いデータベースの中には、データベースの欠点を補う手段として Kafka やその他のストリーミング ツールを採用しているものもあります。
大容量環境では、データベースの取り込み速度が追いつかないため、組織はデータベースの前にキューを配置する必要がある場合があります。
ストリーミング エンジンまたはキューはすべてのストリーミング イベントを処理し、データベースへの書き込みをバッファリングします。
ただし、高スループットで低レイテンシーを実現するデータベースには、このような要点は必要ありません。
リアルタイム データベースは、大規模なストリーミングよりも高速にデータを取り込みます。
運用と分析のギャップを縮小する
ストリーミングの主な使用例の 1 つは、運用データ システムと分析データシステム間でデータを移動することです。
以前は、これは、運用データベースからデータ ウェアハウスに 1 日に 1 ～ 2 回データを移動するバッチ ETL ジョブによって実現されていました。
現在、最新のデータベース、無数のデータ ソース、ストリーミング エンジン、クラウド ウェアハウスがあり、その頻度は時間、分、秒単位です。
データは分析ユースケースに流れるだけでなく、分析およびモデル化されたデータが運用システムに戻ることも増えています。
Snowflake のような最新のデータ ウェアハウスのビジネス インテリジェンス ツールやダッシュボードは大幅に改善されており、ユーザーはレポートが最新で「ほぼリアルタイム」であることを期待しています。
これにより、組織は分析データをリアルタイムの運用ワークロードにフィードバックするようになりました。
ネイティブ Snowflake コネクタ、Kafka、およびその他のストリーミング ツールを使用して、データを運用システムに戻すことができます。
リアルタイム データに対するこのニーズにより、リアルタイム運用データベースの機会が拡大しました。
顧客が履歴分析だけでなく運用能力においても Snowflake に依存し始めると、Snowflake が大量のボリュームを提供および取り込む速度に制限が生じます。
一部の顧客は、Aerospike のようなリアルタイム データベースを、リアルタイムの要求に対応するキャッシュとしてSnowflake ウェアハウスに直接接続しています。
運用と分析のギャップを縮小するための別のアプローチは、ETL パイプラインを排除し、単一のデータベースから運用および分析のワークロードを管理することです。
ハイブリッド トランザクション/分析処理 (HTAP) データベース (トランザリティ データベースとも呼ばれる) を使用すると、データ転送の遅延と複雑さを解消できます。
同様に、Trino (旧名 PrestoSQL) のようなツールは、ETL や別のウェアハウスへのストリーミングを必要とせずに、運用データベースに残っているデータに対して直接詳細な分析を提供し、このデータのクエリと分析を行うことができます。
Aerospike – ストリーミングの世界を強化する
上記の領域では、データ ストリーミングの動的な世界における無数の課題と機会を浮き彫りにしています。
ストリーミング テクノロジーは、データ移動の処理方法に革命をもたらしましたが、これらの進歩を補完できる堅牢で効率的なデータベースの必要性も明らかにしています。
ここで Aerospike のようなソリューションが活躍し、ストリーミングによる潜在的なデータ アーキテクチャを高める独自の機能と統合を提供します。
Aerospike がこの進化する状況にどのように適合し、その革新的な機能と統合によってそれを強化するかをさらに深く掘り下げてみましょう。
Aerospike Connect – パフォーマンスを重視した設計
Aerospike は、最初からシェアードナッシングの分散データベースとして設計されました。
最新のコンピューティング機能と経済性を活用して、インターネット スケーリングのニーズに対応します。ストリーミング プラットフォームの広範な普及にも同様のルーツがあります。
特に、Kafka と Pulsar は、独立したノード間でほぼ無制限に水平方向にスケーリングできます。Aerospike にストリームを取り込むときや、Aerospike からストリーム トピックに公開するときにボトルネックはありません。
Aerospike コネクタは、独自のアーキテクチャを使用してストリーミング ツールと連携して、遅延を追加することなくスループットを一致させます。
これらのコネクタの背後には、地理的ゾーン全体でアクティブ/アクティブ構成を提供するために使用されているのと同じテクノロジーが使用されています。
具体的には、Aerospike Cross-Data Center Replication (XDR) は、変更データ キャプチャ (CDC) メカニズム (変更通知) を使用して、Kafka、Pulsar、JMS、およびその他のストリーミング テクノロジからの取り込みとプッシュを行います。
Aerospike Connect – 緊密な統合
単一のデータベースフレームワークで運用と分析のギャップを埋めるために、Aerospikeは以下のようなネイティブな機能を提供します。
セカンダリインデックス機能を備えており、Trino および Presto と緊密に統合されています。
Aerospike Connect for Presto-Trino および Aerospike SQL により、Aerospike データベース上で直接堅牢な分析が可能になります。
この統合アプローチは、混合ワークロードとマルチテナンシーの管理に熟達し、リアルタイムの運用ワークロードとともに読み取り負荷の高い分析を効率的に処理する Aerospike の堅牢なアーキテクチャを示しています。
ユーザーの導入に関する好みの範囲は多岐にわたり、多くのユーザーは専用の分析システムにデータを転送することを選択しています。
これを容易にするために、Aerospike Connecterにはアウトバウンド機能が装備されており、さまざまなアーキテクチャ設定へのシームレスな統合が可能です。
これらのコネクタは、効率と時間の節約の点で、カスタム コーディングやサードパーティの統合プラットフォームに比べて大きな利点をもたらします。
ストリーミング プラットフォームの台頭により、リアルタイム分析の機能が著しく強化されました。
Kafka、Pulsar、およびJMS用のコネクタを含む Aerospike のコネクタは、 Aerospike データをより広範な分析パイプラインにシームレスに組み込みます。
Aerospike Spark コネクタとElasticsearchコネクタは、検索と高度な分析のさらなる統合を提供します。
より良い未来を一緒に
急速に進化するデータ環境では、リアルタイム機能を実現することが重要であり、ストリーミング テクノロジーはこの需要を満たす上で極めて重要な役割を果たします。
Aerospike は、ストリーミング プラットフォームとその堅牢なリアルタイム データベース アーキテクチャとのシームレスな統合を提供します。
このブログは、2023年12月21日Why your data streaming environment needs a real-time databaseの翻訳です。
