顧客向け分析機能は、特にユーザー数やデータ量が増加するにつれて、アプリケーションの他の部分よりもずっと早く、MySQLやPostgreSQLデータベースの容量不足を引き起こす可能性があります。どちらのデータベースも、開発者にとってプロトタイプから本番環境への移行を容易にし、トランザクション処理を長年にわたって支えることができます。
チームがリアルタイムレポート、検索、レコメンデーション、その他のデータ集約型機能を追加するにつれて、分析クエリとトランザクションの組み合わせにより、同時実行処理能力が限界に達します。データ量と同時使用の増加により、両方の応答性を維持することが難しくなります。
チームは、分散型SQLデータベースへの移行によって、アプリケーションの拡張性を高めることができます。しかし、これを一度に行うのは複雑でリスクも伴います。ほとんどのユーザーは、リスクを軽減しながら段階的に拡張できる方法を望んでいます。
アプリケーションを段階的に移行するには、アプリケーションが元のデータベースに書き込みを続ける間も常に最新の状態を保つデータのコピーを別途作成する必要があります。変更データキャプチャ（CDC）は、ソースデータベースにおける挿入、更新、削除を追跡することで、このコピーを常に最新の状態に保ちます。
SingleStore FlowはCDC（変更データキャプチャ）を使用して、MySQLまたはPostgreSQLからSingleStore Heliosへ変更を継続的にレプリケートします。開発者は、ワークロードの分析部分を段階的にHeliosに移行することで、既存のアプリケーションを稼働させながら、ソースデータベースへの負荷を軽減できます。
アプリケーションの成長問題
セキュリティプラットフォームでは、数百万件ものイベントを検索・集約する必要があり、同時に新しいイベントが継続的に取り込まれる場合があります。FinTechアプリケーションでは、トランザクションデータとリアルタイムのリスク分析やアカウント分析を組み合わせる必要があるかもしれません。オブザーバビリティアプリケーションでは、大量のテレメトリデータを取り込むと同時に、ユーザーが最近のイベントをインタラクティブにフィルタリングして集約できるようにする必要があるかもしれません。SaaSプラットフォームでは、使用状況分析、セグメンテーション、レポート機能を製品内で直接提供する必要があるかもしれません。
これらの作業負荷は、以下のような困難な要件の組み合わせを生み出します。
- 運用アプリケーションからの高い書き込みスループット
- データ量の増加
- 顧客基盤の拡大に伴い、同時接続数が増加
- 低遅延ポイントルックアップ
- 大規模データセット間の集計と結合
- 数秒または数ミリ秒前に到着した可能性のあるデータに対する最新の結果
- 使用量の増加に伴うアプリケーションの応答時間の予測可能性
開発者はしばらくの間は対応できるでしょう。インデックス、キャッシュ層、リードレプリカ、事前計算済みテーブル、バックグラウンドジョブ、あるいは独立した分析データベースなどを追加するのです。しかし、ある時点から、問題はクエリを最適化する別の方法ではなく、データベースアーキテクチャがワークロードに依然として適合しているかどうかという点に移ってきます。
CDCは移行を段階的なアプリケーション変更へと転換する
分散SQLは、ストレージとクエリ処理を複数のノードに分散させることで、負荷の高いワークロードの拡張性を高めます。導入には、書き込み処理を継続しながら大規模なデータセットを移動したり、アプリケーションの互換性を検証したり、パフォーマンスをテストしたり、本番環境への移行を調整したりといった作業が必要となる場合があります。変更データキャプチャ（CDC）を使用すると、チームは2つ目のデータベースをソースデータベースと同期させながら、個々のワークロードをテストおよび移動することで、段階的に移行を進めることができます。
SingleStore Flowを使用すると、開発者はMySQLやPostgreSQLなどのデータベースからSingleStore Heliosへの管理されたCDCパイプラインを作成できます。移行は、既存のアプリケーションが現在のデータベースに対して引き続き動作している間でも実行できます。
そのプロセスはおおよそ以下のようになります。
MySQL / PostgreSQL → CDCパイプライン → SingleStore Helios → アプリケーションワークロード
Flowは既存データの初期同期を実行した後、ソースデータベース からの変更を継続的に取り込みます。アプリケーションによって書き込まれた新しいトランザクションは、開発者が独自のレプリケーションインフラストラクチャを構築・運用する必要なく、SingleStoreに反映されます。
以下のようなアプローチの代わりに：
データベースの移行 → アプリケーションの変更 → 切り替え → 全てがうまくいくことを祈る
チームは漸進的なアプローチを採用できます。
データの複製 → ワークロードの検証 → クエリの移動 → パフォーマンスの測定 → 導入の拡大
これにより、開発者はアプリケーション全体を一度に移行する必要なく、ワークロードレベルでSingleStoreを導入できるようになります。
拡張が必要なワークロードから始めましょう
これは、特定のデータ集約型機能においてMySQLやPostgreSQLでは対応しきれなくなったものの、運用データベースを完全に置き換える準備がまだできていないアプリケーションにとって特に有用です。例えば、アプリケーションチームはトランザクション書き込みはPostgreSQLで行いつつ、顧客向けの分析クエリをまずSingleStoreに移行するといったことが可能です。
アプリケーションアーキテクチャは次のようになります。
アプリケーションが書き込む → PostgreSQL
PostgreSQL → CDC → SingleStore
分析アプリケーションクエリ → SingleStore
開発者は、分散実行が最大のメリットをもたらす箇所、例えば大規模な集計、高並行性レポート作成、運用分析、検索、あるいは大量の最新データと過去データにわたるクエリなどにクエリを移動させることができます。
移行パフォーマンス指標
最近の実際の導入事例は、SingleStore Flowが大規模データセットと多様なソースエンジンにわたって高いスループット能力を発揮することを示しています。
- 600GBのMySQLデータを3時間以内に移行しました。
- 1.5TBのPostgresデータを2時間以内に移行しました。
- 75TBのMySQLデータを4,000のテーブルにわたって1週間で移行しました。
既存のトランザクションパスは初日から変更する必要はありません。ワークロードの検証が完了したら、チームはSingleStoreを分析サービスレイヤーとして維持するか、追加のアプリケーションワークロードも移行するかを決定できます。これにより、技術的リスクと組織的リスクの両方を軽減できます。
SingleStoreはMySQLワイヤプロトコルをサポートしているため、チームは既存の多くのMySQL互換ドライバ、ORM、およびデータベースツールを利用できます。
別のレプリケーションプラットフォームを構築することは避けてください。
チームはKafkaやDebeziumなどのツールを使用してCDCパイプラインを構築できますが、レプリケーションの監視、障害からの復旧、スキーマ変更の処理、トラフィックの増加に伴うインフラストラクチャのスケーリングについても責任を負います。
SingleStore Flowは、Heliosに統合されたCDC（コンテンツデータセンター）取り込みサービスです。開発者は、別途レプリケーションインフラストラクチャをデプロイおよび運用することなく、ソースと宛先を設定し、パイプラインを作成できます。
単にダッシュボードを高速化するだけでなく、リアルタイムのデータ集約型アプリケーションを構築しましょう
最終目標は、既存のダッシュボードの読み込み速度を単に速くすることだけではありません。アプリケーションが運用データを使ってできることを拡張することこそが、最終目標なのです。
アプリケーション開発チームが大量の最新データを低遅延でクエリできるようになれば、従来のトランザクションデータベースアーキテクチャでは実現が難しい製品体験を構築できるようになります。
これには、数十億件のレコードに対するインタラクティブな顧客分析、リアルタイムの不正行為やリスク調査、セキュリティイベントの調査、可観測性およびテレメトリ分析、使用状況の計測、運用監視、パーソナライゼーション、リアルタイムのレコメンデーション、あるいは急速に変化するアプリケーションデータ全体にわたる検索などが含まれる可能性があります。
これらは、データがデータウェアハウスにコピーされて数時間後にクエリされるような、従来型の分析ワークロードとは異なります。クエリのパスはアプリケーションのユーザーエクスペリエンスの一部であり、ユーザーは結果が現在の状況を反映していることを期待します。
これにより、トランザクション、データ取り込み、検索、分析がますます融合していくワークロードが生まれる。
分散SQLを使用することで、開発者が新しいアプリケーション機能を開発するたびに専用のデータベースやパイプラインに分割する必要がなくなり、データ層をワークロードに合わせて拡張できるようになります。
