SingleStoreが速い理由——Universal Storageと分散処理の仕組み解説 | SingleStore解説シリーズ③

「データを入れたらすぐ分析に使いたい」「大量のデータを高速に集計したい」——この2つを同時に満たすことが、なぜ難しいのでしょうか。

第1回・第2回では「従来のDB構成にはリアルタイム性の限界がある」という課題を整理しました。今回は、その課題を技術的にどう解消するのか、リアルタイム分析DBの「なぜ速いのか」という仕組みを現場目線で紐解いていきます。

シリーズ他の記事はこちら

データベースが遅くなる根本的な理由のひとつは、「どのようにデータを保存・読み出すか」というストレージの構造にあります。

従来のデータベースは大きく2種類に分かれます。

「書き込みが多いトランザクションDBと、集計が多い分析DBを分けて使ってきた」のはこの構造上の理由があった、ということです。

SingleStoreの中核技術が Universal Storage です。

行ストアと列ストアを1つのアーキテクチャに統合し、オプティマイザが最も効率的な実行プランを選択します。分析スキャンには列形式のセグメントを、ポイント参照には行指向の構造を活用し、エンジニアが手動でクエリをルーティングする必要はありません。

アプリが書き込んだデータは、まずUniversal Storage内部の書き込み最適化された行指向のメモリ構造に入ります。これは別の「行ストアテーブル」ではなく、Universal Storage内部のバッファです。バックグラウンドでSingleStoreがデータをSSD/ディスク上の圧縮された列形式セグメントに整理・フラッシュします。これにより、書き込み直後は行指向の速度を活かし、その後すぐに分析効率の高い列形式で読み出せる状態になります（正確なタイミングはワークロードと構成に依存します）。分析クエリが発行されると、オプティマイザは必要な列データだけを読み出す実行プランを構築します。最新の書き込みに対するポイント参照では、行指向構造・インデックス・メタデータを活用して不要なスキャンを回避します。

• シンプルな理解の仕方として
  行ストアテーブルはメモリ優先で小規模なオペレーショナルアクセスに最適化。Universal Storageテーブルはディスク優先＋メモリアクセラレーションにより、1つのテーブルで書き込みと高速分析の両方をサポートします。
  　

• 行ストアテーブルについて
  SingleStoreでは、データを完全にメモリ上に保持する行ストアテーブルを明示的に作成することもできます（耐久性のためにディスクへの永続化も行われます）。これはサブミリ秒のポイント参照・書き込みが求められるワークロード——セッション管理、キャッシュ、リアルタイムルックアップなど——に最適です。デフォルトのテーブルタイプはカラムストア（Universal Storage）であり、ほとんどのHTAP（ハイブリッド・トランザクション・アナリティカル・プロセッシング）ワークロードはこちらで対応します。なお、Universal Storage内部の書き込みバッファは、ユーザーが作成する行ストアテーブルとは別物です。Universal Storageが書き込み速度を実現するための内部実装の一部です。

「書き込みを止めずに分析できる、つまりETLを介さずにリアルタイムで集計できる」設計が実現します。

SingleStoreは分散SQLデータベースです。複数のノード（サーバー）が協調して動き、データと処理を分散します。

イメージとしては、物流倉庫の仕分け作業に似ています。1人の作業員が全荷物を1つずつ確認するのではなく、複数のレーンに荷物を分けて、それぞれの担当者が同時に処理し、最後にカウントを合算する——分散クエリ処理の本質はまさにこれです。ノードを追加すれば複雑さが増えるのではなく、処理が速くなります。

分散処理イメージ

特定環境でのワークロード比較では、PostgreSQLと比べて読み込みが約19倍、データ取り込みが約300〜400倍高速というデータが示されています（※特定環境・ワークロード条件での比較値。結果は環境・構成により異なります）。

「データ量が増えてもノードを追加することで性能を維持できる」スケールアウト設計を取れます。

「データが入ってきた瞬間から分析に使える」を実現するのが、SingleStore Pipelinesという機能です。

KafkaやCDC（Change Data Capture：データベースの変更を即時検知する仕組み）から流れ込むデータを、停止なく連続的に取り込みます。

バッチETLでは「夜間の処理が終わるまで使えない」状況でしたが、Pipelinesを使うことでKafkaに到着してからほぼリアルタイムでクエリ可能な状態になります。業務上の意思決定にとっては、事実上のリアルタイムです。

「ETLの完了を待たずに、今届いたデータをそのまま分析に使える」状態が実現します。

ここまでの内容を、従来のDBカテゴリと比較して整理します。特に注目してほしい列は「データ反映」と「スケールアウト」の2つです。ここが従来アーキテクチャとSingleStoreの差が最も大きいポイントです。

「目的ごとに複数のシステムを組み合わせる構成を、1つに集約できる可能性がある」ということです。

SingleStoreはMySQLワイヤープロトコルに対応しているため、既存のMySQLドライバー、ORM、ツールの多くがそのまま接続できます。すでにMySQL系の技術スタックを使用しているチームにとって、導入のハードルは大幅に下がります。

ただし、すべての用途でSingleStoreが最適というわけではありません。数十年分の静的データを定期集計するだけなら従来DWHで十分です。リアルタイム性が不要なコールドストレージ用途や、分析要件のないシンプルなトランザクション処理だけであれば、他のアーキテクチャのほうがシンプルかつ低コストになる場合もあります。「書き込みと分析を同時にリアルタイムで行いたい」「低レイテンシの大量取り込みが必要」「複数システムの複雑さを減らしたい」という要件がある場合に、その強みが活きます。

SingleStoreの導入に、既存インフラの全面刷新は不要です。よくあるパターンは、リアルタイム性が必要な特定のワークロードだけをSingleStoreに任せ、それ以外は従来のDWHをそのまま使い続けるという構成です。まずは1つのユースケース（例：リアルタイムダッシュボード1枚、不正検知ストリーム1本）から始めて価値を実証し、段階的に拡大していくのが現実的な進め方です。

いかがでしたでしょうか。この記事では以下の点についてまとめました。

• 行ストアと列ストアは得意なことが根本的に異なり、従来はそれが「システム分離」の原因だった
  書き込みに強いトランザクションDBと、集計に強いDWHを分けてきたのはストレージ構造上の理由がある。
  　
• Universal Storageは書き込み最適化されたメモリ上の行指向構造と、ディスク上の圧縮列形式セグメントを組み合わせ、1つのテーブルで書き込みと高速分析の両方に対応する
  オプティマイザが効率的な実行プランを選択し、分析には列スキャンを、ポイント参照には行指向アクセスを活用する。
  　
• 分散SQL＋Pipelinesにより、大量データの高速処理とリアルタイム取り込みを同時に実現
  スケールアウトによる性能維持と、ETL不要なリアルタイム取り込みが技術的な差別化点。

「仕組みはわかった。では、実際の業務でどう使えばいいのか」——次回は金融・通信・製造・セキュリティ・EC小売など、業種別の具体的なユースケースを紹介します。自社の課題と照らし合わせて、どの現場に当てはまるか考えてみていただければと思います。