Databricksの皆さん、パーティーへようこそ！

DatabricksのLTAPとLakehouse//RTの発表は、真剣に受け止める価値があります。それは、彼らが新しいカテゴリを発明したからではなく、世界最大級のレイクハウスベンダーの1社が、私たちのアーキテクチャを支持する基調講演を行ったからです。ゴドシ氏が、顧客は単一のデータコピー、パイプラインの削減、低レイテンシ、そして最新の運用データに対する分析を求めていると述べたとき、彼はまさにSingleStoreが存在する理由を説明しているのです。

これは意義のある価値の証明です。ただし、同じアーキテクチャではありません。

LTAPは2つのエンジンで構成されています。SingleStoreは1つのエンジンです

Databricks自身の説明からもそれが明らかです。LTAPは「LakebaseとLakehouseを組み合わせたもの」です。同じ記事の中でゴドシ氏は、「1つのコピーにアクセスするOLAPエンジンと、レコードを更新するOLTPエンジン」と述べています。

それは、他に選択肢がないよりはましです。他に選択肢があるとすれば、CDCジョブと下流のレプリカがTerraform、Slackアラート、そして疲弊しきったデータエンジニア一人の組織的な記憶だけでかろうじて繋ぎ合わされている、もろい混乱状態です。私たちはそのデータエンジニアに何の恨みもありません。彼らは休暇を取るに値する人物でしたが、結局休暇は取れませんでした。

しかし、ストレージ層を共有することと、統一されたクエリエンジンを持つことは同じではありません。

2つのシステムを運用している顧客は、最終的に「クエリルーティングガイドラインv4」のようなタイトルの文書を作成します。しかし、その文書は常に古く、何らかの理由で誤ったエンジンが選択されてしまうため、常に誰かが対応に追われています。

SingleStoreは、トランザクション、分析、データ取り込み、検索、およびアプリケーションサービスワークロードを単一の分散SQLエンジンで実行します。別のLakehouseランタイムにデータを供給するPostgres互換レイヤーは存在しません。ルーティングロジックもありません。システム間のフォーマット変換もありません。ガイドライン文書のバージョン4もありません。

本番環境では、その違いはレイテンシ、運用上の複雑さ、そしてオンコール体制に現れます。

Postgresとの互換性があるからといって、Postgresが水平方向に拡張可能になるわけではありません

Lakebaseは、DatabricksのサーバーレスPostgres製品です。Postgresは非常に優れています。開発者が好むのには十分な理由があり、その理由は数多くあります。

10,000件の同時エージェントセッションを処理しながら、同時に稼働中の運用データに対して分析結合を実行することは、当初の設計要件には含まれていませんでした。

エージェントはダッシュボードでは成し得なかった方法でデータベース需要の形態を変えるため、これは今や重要な意味を持ちます。エージェントは分散し、フォローアップの質問を行い、運用コンテキストを取得し、現在の状態と履歴データを組み合わせ、バースト的な同時負荷を生成します。その間も、ビジネスはエージェントの下で新しいレコードを書き込んでいます。Databricks自身のデータもこの変化を反映しており、同社のプラットフォーム上のデータベースの約80%が人間ではなくエージェントによって作成されていると報告しています。

データコピーを減らすことは有効ですが、エージェントに必要なのは、より新鮮なデータレイクだけではありません。低遅延かつ高並行処理で、負荷が急増した際に水平方向に拡張できるシステムから、広範な運用コンテキストを取得する必要があります。トランザクション層がPostgres互換インスタンス上に構築され、分析層が別の場所に存在する場合、ルーティングの問題は解消されません。単に、他の誰かが午前2時に抱える問題になるだけです。

SingleStoreは、まさにそのような負荷に対応するために構築されました。分散型アーキテクチャを最優先に設計されており、水平スケーラビリティを備えています。

ベンチマークは有用ですが、LTAPの証明にはなりません

Lakehouse//RTの主要レイテンシ測定結果（公開されているミリ秒単位のグラフ）は、TPC-H Q6（フィルタと単純な集計を含む単一テーブルスキャン）で測定されています。Q6は正当なクエリであり、スキャン速度、述語プッシュダウン、ベクトル化実行、およびカラム効率をテストします。結合はテスト対象外です。

Databricksは、競合他社（具体的な名称は明かされていない）と比較して16倍および5倍のパフォーマンス向上を個別に挙げており、それらの記述にはマルチジョインクエリパターンに関する言及が含まれています。これは関連性の高い情報です。しかし、具体的な規模が不明で、絶対的なレイテンシ値も構成情報も公開されていません。具体的な名称が明かされていない競合他社とのベンチマークは、顧客が再現したり検証したりできるものではありません。16倍という主張が、顧客のワークロードに当てはまるのか、限定的なテストケースに当てはまるのか、あるいは低スペックのシステムで動作する競合他社に当てはまるのかを判断することはできません。

ミリ秒単位のアピールはQ6です。結合パフォーマンスに関する主張は相対的なものであり、検証不可能です。どちらも、Lakehouse//RTが本番環境の分散データベースのように、同時書き込み、運用読み取り、分析結合、およびエージェント/アプリケーションの負荷を単一のエンジンで処理できることを証明していません。

ベンチマーク自体は間違っていません。それぞれが異なる役割を果たしているのです。組み合わせを証明とみなす前に、それぞれがどのような役割を果たしているのかを問うのは当然のことです。

パーティーへようこそ

Databricksの指摘は的を射ています。企業は、運用システムに古くなった分析機能を無理やり追加することを望んでいません。完全なデータパイプラインも求めていません。すでに1時間も遅れているビジネスデータのコピーに基づいてAIエージェントが推論することも望んでいません。

彼らは、アプリケーションの取り込み、トランザクション処理、分析、検索、およびリアルタイムでの提供が可能な単一のプラットフォームを求めています。

それこそが、SingleStoreが築き上げてきたカテゴリーなのです。

ようこそ。私たちはここにしばらくいます。飲み物はぬるいですよ。

しかし、レイクハウスとの緊密な連携という話と、リアルタイムAIアプリケーション向けの本格的な分散データベースを混同してはいけません。共有ストレージは便利です。オープンテーブル形式は便利です。PostgreSQLとの互換性は便利です。

それらのどれも、単独ではOLTPとOLAPの実行を水平方向に拡張可能な単一のエンジンに統合することはできません。

Databricksが問題の存在を証明しました。SingleStoreは、その問題を解決するデータベースを構築しました。