リアルタイム データ プラットフォーム: SingleStore vs. Databricks

2025年6月更新：こんにちは。2023年11月にDatabricksのリアルタイム機能とSingleStoreを比較したこのブログ記事を執筆しましたが、先日のLakebaseの発表を受けて更新しました。このブログ記事で「Cassandra」という単語が出てきたら「Neon」に置き換えてください。これでブログは最新版になりました🙂

SingleStore と Databricks はどちらも、顧客の重要な課題に対処する優れたデータ プラットフォームです。

しかし、パフォーマンスとコストに関しては、SingleStore にはいくつかの大きな利点があります。これは、SingleStore がパフォーマンスを徹底的に追求して構築されているため、コスト削減につながるからです。このブログは、これらの違いを検証する複数回シリーズの第1回です。まずは、SingleStore が特に優れているリアルタイム分析と運用について取り上げます。 

さらに、SingleStore は、非リアルタイムのバッチ ETL ジョブでもコストとパフォーマンスの面で優れていることがわかりました。これについては、後続のブログで取り上げる予定です。

リアルタイムデータの価値を理解する

まず、リアルタイムデータの重要性を明確にしましょう。なぜ顧客はそれを重視するのでしょうか？答えは単純です。多くのユースケースにおいて、データの価値は古くなるにつれて低下していくからです。マーケティングキャンペーンの最適化、取引スピードの監視、在庫のリアルタイム更新のプッシュ、ネットワーク障害の監視、セキュリティイベントの監視など、どのような場合でも、顧客からの反応の遅れは金銭的な損失につながります。これらのソースから生成されるイベントは、ストリームとして継続的に到着するため、ストリーミング技術の台頭につながっています。Databricksの最近のブログ「Apache Spark Structured Streamingでレイテンシが1秒未満に」は、この点を的確に表現しています。

多くのお客様との会話の中で、一貫して1秒未満のレイテンシが求められるユースケースに遭遇しました。このような低レイテンシのユースケースは、運用アラートやリアルタイム監視、いわゆる「運用ワークロード」といったアプリケーションから生まれます。

SingleStoreでは、お客様にとって最も重要なのはミリ秒単位であるため、これを品質レイテンシと呼び、1つのイベントがプラットフォームに入り、宛先に到達して価値を生み出すまでの時間と定義します。考慮すべき重要な要素は他にもあり、Databricksはブログ記事で「スループット、コスト、レイテンシのトレードオフをバランスさせる柔軟性をユーザーに提供する」ことを正しく指摘しています。私たちはさらに、シンプルさと可用性という2つの要素を追加することで、理想的なリアルタイムデータプラットフォームの目標を実現します。

1. 遅延を最小限に抑える
2. スループットを最大化する
3. コストを最小限に抑える
4. 可用性を最大化する
5. シンプルさを最大限に

SingleStoreがリアルタイムのユースケースを処理する方法

まず、次の図に示すように、ストリーミング データを SingleStore に取り込んでクエリを実行するという、リアルタイム データの使用例に対する SingleStore の推奨アプローチについて説明します。

ここまで読んで、きっと「えっ？それだけ？もっとあるはずなのに！」と思っているでしょう。どうすれば、1つのデータプラットフォームでリアルタイムSLAを犠牲にすることなく、リアルタイムでデータ取り込みと分析クエリの提供ができるのでしょうか？企業が新しい、特化したストリーミング製品の追加について頻繁に話しているのを耳にしますが、一体何をしているのでしょうか？

Databricksがリアルタイムユースケースを処理する方法

実は、Databricksもそのような企業の一つです。最近のブログ「Apache Spark Structured Streamingでレイテンシが1秒未満に」での、2つの図解を含む同社のアプローチを検証してみましょう。最初の図解は、

「分析ワークロードは通常、データをリアルタイムで取り込み、変換、処理、分析し、その結果をオブジェクトストレージを基盤とするDelta Lakeに書き込みます」[リアルタイムではなくなる]

話はこれで終わりではありません。ブログには、全く別の「運用ワークロード」構成も記載されています。この構成の存在自体が、分析ワークロード構成がDelta Lakeに到達するとリアルタイムではなくなることを示す説得力のある証拠ですが、Databricksもブログでこの点をほぼ認めています。

「一方、運用ワークロードは、データをリアルタイムで取り込み、処理し、ビジネスプロセスを自動的にトリガーします。」[これもリアルタイムです]

この2番目の図で興味深いのは、メッセージバスで終わっていることです。データは到着せず、結局何も使用しません。Databricksのリアルタイムソリューションは、Kafkaからデータを読み取り、変換を行い、Kafkaまたは…に書き戻すというものです。

「Apache CassandraやRedisのような高速キーバリューストアをビジネスプロセスへの下流統合に活用」

…あるいは他のデータベースに！なぜDatabricksのようなデータプラットフォーム企業が、顧客にデータを別のデータベースに保存するよう勧めるのでしょうか？それは、それらのデータベースがDatabricksにはない機能、つまり高速なポイント読み取り・書き込み（CRUD）を提供しているからです。これらのデータベースはこの機能を実現するためにキーバリュー形式を採用していますが、分析クエリは必要であり、それらのデータベースもKafkaも、分析クエリを簡単かつ効率的に実行することはできません。 

SingleStoreDBは、特許取得済みのUniversal Storageを備え、トランザクションクエリと分析クエリの両方を実行できます。実際、SingleStoreはDatabricksとキーバリューストアを組み合わせた以上の機能を備えており、単一のSQLインターフェースで以下の読み取りと書き込みを実行できます。

1. 高い選択性（OLTP、CRUDを含む）
2. 中程度の選択性（リアルタイム分析） — SingleStore だけがこれを実行できます
3. 低い選択性（大規模な分析と一括挿入）

DatabricksがリアルタイムデータベースとしてCassandraまたはRedisを推奨する理由としてはこれで十分ですが、SingleStoreとこれらのデータベースはDatabricksよりも可用性が高いという、もう一つの説得力のある理由があります。SingleStoreは、クラスター内のノード内だけでなく、ボタン一つでアベイラビリティゾーン間でも自動的に冗長化されます。一方、Databricksのドキュメントには高可用性に関するページはありません。その代わりに、DatabricksはシステムのコンポーネントであるAWS S3の高可用性について説明しています（ただし、システム全体が高可用性であるという意味ではありません）。

この機能がないことが、このAWSデプロイメントガイドの存在を裏付けています。このガイドでは、かなりの労力を費やすことで2つのAZにDatabricksクラスターをデプロイする方法が説明されています。ただし、これはあくまでもクロスAZのクラスターではなく、2つのAZにクラスターが存在するというだけのことです。Databricks搭載アプリをAZ障害に真に耐えられるようにしたい場合は、上記の設定を行い、アプリが2つのクラスターと通信するように変更することで、ご自身で実現する必要があります。しかし、どちらの方法も、多大な労力、費用、そして複雑さを伴います。   

これらすべてを念頭に置くと、Databricks の提案のこの図は、彼らが提案するルーブ・ゴールドバーグ・マシン (つまり、リアルタイム データ プラットフォーム) とその欠点をより完全に表現したものになります。

SingleStoreの仕組み

どのように実現しているのか気になりますか？ ありがとうございます！ SingleStore をシンプルで高性能なリアルタイム分析プラットフォームにしているアーキテクチャを詳しく見ていきましょう。

ストリーミングデータはソースから生成され、イベントはSingleStoreのパイプラインによって取り込まれます。パイプラインは完全に並列化されており、Kafkaをはじめとする様々なソースから、多くの一般的な形式でデータを読み取ることができます。  リアルタイムデータのもう1つのソースとして、データの挿入、更新、削除、およびアップサートを実行するDMLステートメントがあります。これらのステートメントは、行レベルのロック（テーブル全体ではなく個々の行を書き込みロックできる）により、高スループットでストリーミング取り込みと並行して実行できます。これにより、エンドツーエンドシステムのスループットが大幅に向上します。

変換はストアドプロシージャを使用して適用できます。ストアドプロシージャはSingleStoreのパイプラインのエンドポイントとして呼び出すことができ、フィルタリング、結合、グループ化、集計、複数のテーブルへの書き込みなど、ストリーミングデータに複雑な変換を適用できます。ストアドプロシージャはパイプラインのエンドポイントとして機能できるため、単一のパーティション化されたライターで複数のデータバッチを処理し、並列処理を容易にします。 

以下は、CDC データ (「アクション」列にDELETEDおよびINSERTEDが含まれる場合があります) を含むパイプラインからのグループ化されたデータに対してカスタム実行SUM (またはAVG ) 集計を維持するストアド プロシージャの例です。

SingleStoreとDatabricksアーキテクチャの主な違い

なぜ Databricks は同等のリアルタイム機能を提供できないのでしょうか? 主な理由は 2 つあります。

1. 書き込みの場合、Tier 1とTier 2は存在しない
2. 読み取りの場合、Tier 1は存在せず、Tier 2はデフォルトでオフになっており、使いにくく、レイテンシが増加します。

まず書き込みパスを見てみましょう。SingleStoreでは、書き込みはTier 1に到着し、ログはTier 2に書き込まれ、データはシステム全体に複製され、即座にクエリ可能になります。一方、Databricksでは、書き込みはクラウドオブジェクトストアまで到達してからでないと認識されません。

読み取りパスにも同様の制限があります。SingleStoreでは、Universal StorageはTier 1とTier 2の両方を活用し、純粋なインメモリ行ストアテーブルを使用することでパフォーマンスを最大限に最適化できます。Databricksと比較してみましょう。DatabricksはSparkメモリ層に何も保存しないことで有名ですが、これは非常に高速な読み取りが必要な場合を除き、非常に優れています。 

さらに、Databricksのディスクレイヤーはデフォルトでオフになっており、有効になっている場合でも、新しいデータはまずオブジェクトストアに取り込まれ、その後キャッシュに取り込まれるため、レイテンシが大幅に増加します。SingleStoreでは、新しいデータは入力時にディスクに書き込まれるため、必要なときにすぐに読み取ることができます。

最も重要なことは、クラウド オブジェクト ストアへの書き込みと読み取りを低遅延で実行できないことを Databricks が認識しており、この機能の欠如を補う方法としてストリーミング アーキテクチャ全体を設計したことです。  

Databricks は、ユーザーにアプリケーションを 2 つの部分に分割し、完全に異なるシステムで実行することを推奨しています。

1. Spark Structured Streaming パイプラインによるデータの前処理
2. 前処理されたデータに対する軽量クエリ

ただし、最初のシステムでは遅延が発生し、処理がリアルタイムではなくなります。また、2 番目のシステムでは、多くのシナリオで依然としてレイテンシが十分に低くなりません。

SingleStore は、生の取り込みデータ、または取り込みパイプラインのエンドポイントであるストアドプロシージャで前処理されたデータに対して、高速かつ低レイテンシのクエリを実行できます。後者の場合、前処理はSQLを使用して同じ環境で実行されます。これにより、真のリアルタイム処理が実現します。

Databricksの強み

上記すべてにもかかわらず、データベースに一切アクセスしないストリーミングアーキテクチャにも確かに用途はあります。例えば、ストレージに収まりきらないほどの膨大なデータ量があり、あるKafkaストリーム内のイベントにいくつかの変換処理を施し、アラートをトリガーする別のKafkaストリームを再送信したい場合などです。 

Databricksはデータ探索においても大きな進歩を遂げており、開発者はノートブックインターフェースの柔軟性を高く評価しています。さらに、同社の製品には高度な機械学習機能が数多く搭載されています。 

DatabricksはETLジョブの実行にも広く利用されていますが、SingleStoreはこの分野でパフォーマンスとコスト面で優位性があるため、一部のジョブではSingleStoreの方が適している場合があります。このトピックと、この2つの製品を併用する最適な方法については、このシリーズの今後のブログで取り上げます。

概要: リアルタイム データ プラットフォーム: SingleStore と Databricks

リアルタイムのユースケースでは、SingleStoreではストリーミング データを SingleStore に取り込んでクエリするだけで済むため、Apache Spark Structured Streaming と別のデータベースの組み合わせは過度に複雑で非実用的なソリューションになります。

低レイテンシー

• SingleStoreには、新たに取り込まれたINSERTとUPDATE、そしてメタデータへの高速アクセスのためのインメモリデータ層があります。この層はDatabricksには存在しません。 
• SingleStoreは、オペレーションシステムやデータフォーマットで見られるような行レベルのインデックスを備えており、低コストのシークをサポートします。一方、Databricksは、行レベルではなく、ファイルレベル（SingleStoreも同様にサポートしています）の読み取りセットのプルーニングに使用される冗長データ構造のみをサポートします。これにより、SingleStoreは、特に高選択性および中選択性のクエリにおいて、DatabricksよりもCPUとディスクI/Oの使用量を大幅に削減できます。
• SingleStoreのデータは、行中心と列中心のハイブリッド表現で保存できます。これは、当社が数年前にUniversal Storageで開始し、最近Column Group Indexesで拡張した重要なイノベーション領域です。これにより、SingleStoreはDatabricksと比較してディスクI/OとCPUを節約できます。特に、テーブル内のすべてまたはほとんどの列を選択するクエリでは顕著です。
• SingleStoreへの書き込みは、インメモリ層と先行書き込みログ（WAL）のおかげで、1桁ミリ秒で一貫してクエリ可能になります。これを、オブジェクトストアを基盤とするDeltaテーブルで終了するパイプラインと比較してみてください。S3への各BLOB書き込みには最大100ミリ秒かかる可能性があり、各更新に対して複数のBLOB書き込みが発生する可能性があります。これは、データがParquetに変換された後の処理です。これは、レイテンシが重要なコードパス上のSingleStoreでは不要なステップです。つまり、エンドツーエンドで見ると、Databricksへの書き込みはSingleStoreよりも1～2桁遅くなるということです。
• 前述のすべての利点を合計すると、SingleStoreクエリがDatabricksと比較して非常に高速であることは驚くべきことではありません。これは、このTPC-Hベンチマークで確認できます。

スループットの向上

• スループットに影響を与える重要な要素は2つあり、最も重要なのはレイテンシです。SingleStoreのクエリに10ミリ秒かかり、同様の規模のDatabricksクラスターで同じクエリに1秒かかる場合、他の条件が同じであれば、SingleStoreのスループットはDatabricksの100倍になります。レイテンシにおけるSingleStoreの優位性については、上記のセクションをご覧ください。
• もう1つの追加要因は同時実行性です。クエリが互いに干渉し合うことで中断が発生するシステムは、スループットが低下します。これも、他の条件が同じであれば同じです。この点でも、SingleStoreはDatabricksよりも優れています。例えば、SingleStoreにはデフォルトの行レベルロック機能があり、これはテーブルレベルでのみ動作するDatabricksの同等の書き込み競合機能と比較できます（プレビュー版でのみ利用可能な、いくつかの非常に厳しい制限付きのケースを除く）。この種の機能は、誰でもいつでも開いているテーブルに書き込むことができるため、Databricksにとっては実現が非常に困難です。つまり、書き込み競合を回避するために多くの手順を追加する必要があるということです。
• スループットをテストするための最も一般的なベンチマークはTPC-Cから派生したもので、結果は「1分あたりのトランザクション数」で示されます。私たちはSingleStoreのTPC-Cにおけるパフォーマンスを公開しましたが、私たちの知る限り、Databricksや他のサードパーティは同様のベンチマークを実施したことがありません。

よりコスト効率が高い

• SingleStoreDBと同じリアルタイムSLAを満たすには、Databricksで追加のデータベースと追加のメッセージングバスが必要になります。オープンソースソフトウェアを選択するかマネージドソリューションを選択するかは、どちらにしても最終的にはコストがかさみます。前者はより多くの人員を必要とし、後者はコストがかかるからです。
• SingleStoreは、多くの場合、Databricksよりも10～100倍高速に同じクエリを実行できます（レイテンシのセクションを参照）。また、SingleStoreはより優れた同時実行性を備えています（スループットのセクションを参照）。DatabricksでSingleStoreのレイテンシに匹敵するほどの資金を投入することはできません。そして、SingleStoreのスループットに匹敵するには、Databricksユーザーがスケールアップし、同じ結果を得るためにより多くの費用を費やす必要があります。実際、CSPは時間単位で課金するため、ジョブにかかる時間を大幅に短縮できれば、コストも大幅に削減できます。

より多く利用可能

• Databricks には、レプリケーション、クロスAZ 、クエリや増分バックアップ用に常に 2 つのホット コピーを用意するなどの高可用性機能がないため、RPO=0 および非常に低い RTO を必要とするアプリケーションやユースケースに対応できません。

はるかにシンプル

• SingleStoreはよりリアルタイムです。ストリーミングデータの集計に5秒または1分のウィンドウ関数が含まれている場合、SingleStoreは次のクエリで部分的な時間ウィンドウにデータを即座に表示します。これに対し、Databricksユーザーがストリーミングパイプラインで集計結果を計算する場合、ウィンドウが終了し、結果がデータベースに挿入された時点で初めて集計結果が表示されます。 
• ストリームの結合について無理やり考える必要はありません。テーブルの結合の方がずっと簡単です。
• データの到着が遅れることを心配する必要はありません。一部のイベントが遅れた場合、次のクエリではイベントタイムラインの過去の変更が反映されます。
• 当社は「正確に 1 回のみ」（Exactly Onceセマンティクス）をサポートしているため、データが失われることはありません。Databricksでは、「正確に 1 回のエンドツーエンドの処理はサポートされません」。
• ストアドプロシージャで終了するパイプラインは、変換や集計を実行できます。
• SingleStore は読み取り、変更、書き込みをサポートしているため、純粋なイベントベースのプログラミングとデータ モデリング パラダイムに固執する必要なく、最終的なユースケースをよりシンプルにすることができます。
• SingleStoreはノートブックまたはストアドプロシージャにコードを保存して実行できますが、Databricksにはノートブックしかありません。
• そして最後に、繰り返しになりますが、追加のデータベースは必要ありません。

簡単に言えば、SingleStore のクエリは非常に効率的で信頼性の高い高速性を備えているため、高い同時実行性をサポートし、高可用性と組み合わせることで、アプリケーションを強力にサポートできます。だからこそ、LiveRamp や Outreach（Databricks も使用）といった企業が、ミッションクリティカルなリアルタイム分析ワークロードの基盤として SingleStore を信頼しているのです。

これまでに議論したすべての内容を把握するのに役立つ表を以下に示します。

このシリーズのパート 2 では、SingleStore と Databricks を併用する最適な方法と、非リアルタイムのバッチ ETL 領域における SingleStore のパフォーマンスとコストの利点についてさらに詳しく説明します。