SingleStoreとは？HTAPの仕組み・Universal Storageと採用判断を実装者目線で解説

SingleStoreは、MySQLのワイヤプロトコルに互換性を持つ分散SQLデータベースです。旧称をMemSQLといい、トランザクション処理と分析処理を1つのクラスタで受けるHTAP型に分類されます。この記事では、アグリゲータとリーフに分かれる分散構成、行と列を1つの表型へ束ねるUniversal Storage、8.5から入ったベクトル索引、2026年8月時点の版と費用を整理し、採用条件と見送る場面を示します。

まとめ：SingleStoreの採用条件と専用DBへ分ける判断

結論から書きます。SingleStoreを選んでよいのは、取り込んだ直後のデータへ低遅延の分析クエリを当てる要件がある、書き込み系と分析系を分けたときの同期の手間を消したい、MySQL方言の既存クエリとBIツールを繋ぎたい、この3つが同時に成立する案件です。1つでも外れるなら、RDBと列指向DBの2本立てにしたほうが総額でも運用でも収まります。

見送る場面も明確です。日次バッチの集計だけを回す用途、分析が夜間バッチで足りる用途、外部キー制約やトリガに依存した既存スキーマの移行案件。この3つでは1エンジンに束ねる利得より、専用DBとの単価差や非対応機能の回避コストが上回ります。

版の選び方も先に置きます。2026年8月時点で新規に本番採用するなら9.0系が基準線です。9.1は候補版として公開されている段階で、公式ドキュメント自身が本番ワークロードには9.0系を推しています。

アグリゲータとリーフノードに分かれる分散構成と処理経路の役割分担

ノードの種類は2つです。クエリを受けて配るアグリゲータと、データを持って処理するリーフノード。この2層構造が表型や取り込みの設計の前提になります。

マスターアグリゲータと子アグリゲータが担うクエリ受付と集約の経路

アグリゲータはデータを持ちません。役割はSQLを受け取り、分散実行計画へ変換し、各リーフへ配り、部分結果を集約することです。1台だけ置かれるマスターアグリゲータがメタデータ管理とDDLを引き受け、子アグリゲータは読み取りの受け口を横へ増やすために追加します。

設計上の勘所は接続先の振り分けです。全接続をマスターへ向けると集約段のCPUが先に飽和し、リーフに余力が残ったままスループットが頭打ちになる。同時実行数の多い読み取りは子アグリゲータへ分散させ、マスターはDDLと管理系に空けておくのが基本形です。

リーフノードへのパーティション分割とシャードキーを決める順序

リーフノードはパーティションという単位でデータを持ちます。パーティション数はデータベースを作る時点で決まり、後から変えるには作り直しが要る。ここが最初の後戻りしにくい決定です。

表はシャードキーのハッシュ値でパーティションへ割り当てられます。指定しなければ主キーが使われ、主キーもなければランダム配置になる。枠組みは一般的な水平分割と同じなので、シャードキー設計と水平分割の勘所を先に押さえると当たりがつきます。自動化されるのは分割の実行と再配置までで、どの列で分けるかは利用者側に残ります。

リファレンス表とシャード表の使い分けが結合の性能を決める理由

表には2種類あります。シャードキーで分割されるシャード表と、全リーフへ同じ内容を複製するリファレンス表です。マスタ系の小さい表をリファレンス表にすると、どのリーフでもローカルに引けるため結合がネットワークをまたぎません。

結合コストの分かれ目はここです。シャードキーが揃った表同士の結合はリーフ内で閉じますが、揃わないとリパーティション、つまりネットワーク越しの再配布が挟まります。

頻繁に結合する表同士は同じ列をシャードキーに揃える。これが設計初日に効く一手です。高可用の構成ではリーフをペアで持つため、計算資源は実質2倍で数えます。

Universal Storageが行ストアと列ストアを1つに束ねる仕組み

行と列を別エンジンで持って同期するのではなく、列ストア側に手を入れて両方の処理を通す。ここがSingleStoreを他の分散SQLと分ける核心です。

列ストアが既定になった経緯とセグメント単位で圧縮が効く仕組み

Helios ではディスク上の列ストアが既定の表型で、これがUniversal Storageと呼ばれます。列ごとにセグメント単位で連続配置するため圧縮が効き、走査時は必要な列だけを読めば済む。数百万行の走査や、表の5%を超える範囲を10列未満で集計する処理で差が出ます。

列指向そのものの利点は列指向DBのセグメント設計と圧縮の効き方と共通です。固有なのは、この列ストアへ点参照と更新を通すために足された機能群のほうにあります。

ハッシュ索引とサブセグメント参照で列ストアに点参照を通す理屈

列ストアは本来、1行だけを取り出す操作が苦手です。1行を組み立てるには全列を触る必要がある。Universal Storageはここへ5つの機能を足して穴を埋めました。

• 列ストア表へのハッシュ索引（一意制約を課すこともできる）
• サブセグメント参照。位置が分かった1行へ直接届く経路
• 行レベルロック。セグメント全体を止めない同時更新
• 選択率の高いフィルタを伴う結合の高速化
• upsert、つまり存在すれば更新し無ければ挿入する操作

複数列のハッシュ索引を複数本張れるため、業務系の検索条件をひととおり通せます。表を二重化しなくても済む。行エンジンと列エンジンを分けて同期する構成とは、同じHTAPでも出発点が逆になる点を押さえると比較が早く進みます。

行ストアを選ぶべき残りのケースとメモリ消費量を見積もる計算手順

それでも行ストアが残る理由があります。行ストアはメモリ常駐で1行を単位に全列をまとめて置くため、次の条件では今も有利です。

• 更新と削除の比率が高く、書き換えが絶えず走る表
• 特定行へのランダムな点参照が処理の大半を占める表
• 問い合わせパターンが多様で、索引を何本も張り分けたい表
• 小さな更新が高い同時実行数で飛んでくる表

制約はメモリ量そのものです。行ストア表のデータはメモリに載り切る必要があり、クラスタのRAM合計が実質的な上限になる。なお列ストアもOSのディスクバッファキャッシュ経由でセグメントを載せるため、見積もりは行ストア表の実データ量に索引分を足し、列ストア側の作業対象まで積んで組みます。

ストレージの分離とワークスペースで計算資源を切り分ける設計指針

容量と計算を切り離す構造も、単一ノードのRDBから移るときに押さえておく箇所です。

ローカルディスクとオブジェクトストレージの二層で持つ記憶階層

書き込まれたデータはまずローカルディスクへ入り、背景処理でオブジェクトストレージへ複製されます。ローカル側は永続キャッシュの位置づけで、保持量がノードのディスク容量に縛られない。Enterprise版ではS3互換ストレージによる容量無制限の構成と時点指定の復旧（PITR）が使えるため、復旧の粒度を要件に持つならここが版の分かれ目です。

ワークスペースの分離で取り込みと分析を衝突させない資源の配分

Helios はワークスペースグループという単位でデータを共有し、その中に計算資源としてのワークスペースを複数置けます。取り込み用と分析用を別に立てられるため、夜間の大量取り込みが日中のダッシュボードの応答を潰す古典的な事故を構成レベルで防げる。読み取りレプリカやデータベースブランチはStandard以上に含まれ、開発環境の切り出しもここで組み立てます。

Pipelinesによる取り込みとMySQL互換の実際の線引き

周辺の作り込みが減るかどうかは、取り込み経路と互換範囲で決まります。

Kafkaやオブジェクトストレージからの取り込みをSQLで宣言する経路

SingleStoreはPipelinesという取り込み機構を持ちます。CREATE PIPELINE でKafkaやオブジェクトストレージを取り込み元として宣言し、あとはエンジン側が継続的に引き続ける形です。

利点は並列度の出方です。取り込みはアグリゲータを経由せず各リーフが直接ソースへ取りに行くため、帯域がノード数に応じて伸びる。変換をストアドプロシージャで挟めるので、単純な整形なら外部のETLツールを1段減らせます。

外部キーとトリガが非対応であることが移行前の設計に及ぼす制約

MySQLのワイヤプロトコルに互換性があるため、既存のドライバやBIツールは接続文字列を変えるだけで繋がります。ただし互換は全機能ではありません。外部キー制約とトリガは非対応で、参照整合性の担保はアプリ側の責任になります。

移行前の検査で確認すべきは、外部キーを実際の整合性維持に使っているか、設計書上の記述に留まっているかの区別です。カスケード削除に業務が依存するならアプリ側の削除処理が要り、トリガで監査ログを取っているなら取得箇所をアプリかPipelines側へ移します。

もう1つ、9.0で既定の照合順序が utf8mb4_general_ci から utf8mb4_bin へ変わりました。大文字と小文字を区別する挙動になるため、旧版から持ってきた等値比較の一致件数が静かに変わる。移行時は照合順序を列かテーブルで明示しておくほうが安全です。

SingleStore KaiでMongoDBのワイヤプロトコルを受ける条件

SingleStore Kaiは、MongoDBのワイヤプロトコルを受けるAPIです。プロキシがCRUDコマンドと集約パイプラインを等価なSQLへ変換し、結果をBSONで返します。一意索引を強制しない形でも受けられるため、コード無改修で載る範囲が広い。

とはいえ未対応のコマンドは残ります。判断の基準は、JSON中心のアプリを分析基盤ごと1つに寄せたいかどうか。文書DBが欲しいだけなら選ぶ理由にはなりません。

ベクトル索引の性格とAI用途でSingleStoreへ寄せる判断

生成AIの周辺でSingleStoreが候補に挙がる理由がこの節です。ベクトルを別のデータストアへ出さず、業務データと同じSQLで扱えます。

8.5から入った索引付き近傍探索と7種類ある索引型の使い分け

データ型としてVECTORが用意され、要素の型はI8、I16、I32、I64、F32（既定）、F64から選べます。8.5以降は索引を張った近似最近傍探索（ANN）に対応し、索引型はFLAT、IVF_FLAT、IVF_PQ、IVF_PQFS、HNSW_FLAT、HNSW_PQ、自動選択のAUTOの7種類です。

距離関数は DOT_PRODUCT と EUCLIDEAN_DISTANCE の2つで、ベクトルを長さ1に正規化してあれば内積がコサイン類似度と一致します。埋め込みモデルの出力が正規化済みかどうかで選ぶ関数が決まるため、モデル側の仕様を先に確認してください。

HNSW_FLATとIVF_PQFSのメモリ消費と再現率のトレードオフ

索引はメモリに常駐します。ここが選び分けの起点です。

HNSW_FLATは検索時間も再現率も高い水準にまとまりますが、索引の大きさがベクトルの総量とほぼ等しくなるため、その分のメモリを積む前提です。対してIVF_PQFSは量子化でメモリをおよそ10分の1以下へ落とし、構築も速い。再現率と検索時間は劣るものの、構築時と検索時のパラメータ調整で実用域まで詰められます。件数が数百万を超える領域では、IVF_PQFSから当たるほうが現実的でしょう。

専用ベクトルDBを別に立てるかSingleStoreへ寄せるかの分岐

判断の軸は1つで足ります。同じクエリの中で、ベクトルの近傍探索と業務条件の絞り込みを混ぜるかどうかです。「この顧客セグメントかつ在庫のある商品から近いものを返す」型の問い合わせが主なら、SingleStoreへ寄せると2つのデータストア間の整合を取る処理が丸ごと消えます。

逆に、埋め込みの近傍探索だけを高スループットで回すのが目的なら、索引構造から見たベクトルデータベースの仕組みで扱っている専用製品のほうが構成は単純に収まります。

9.0系と9.1候補版の版差とHeliosの費用を積み上げる数え方

版の選定と費用の構造は、稟議の段階で必ず問われる項目です。

本番の据え置き先を9.0系に置く根拠と9.1候補版の位置づけ

2026年8月時点で公開されている最新の系列は9.1ですが、これは候補版という位置づけです。公式ドキュメントも、新機能を事前に評価するための版であり本番ワークロードには9.0系を使うよう案内しています。9.0系は9.0.10が2025年10月15日に出て以降もパッチが継続し、2026年7月21日時点の更新まで確認できる。検証環境に9.1を当てつつ本番は9.0系で揃える二本立てが扱いやすい形です。

9.0で入った変更のうち既存システムの移行時に効いてくる4項目

9.0の変更点のうち、移行の設計に影響が出るものを挙げます。

1. AUTO_INCREMENTへのSEQUENCE修飾子。分散環境で飛びがちな採番の間隔が縮む
2. 過去の実行統計からクエリ計画を組み直す機能（Feedback Reoptimization）
3. JSON配列への多値ハッシュ索引。配列要素を条件にした集計が速くなる
4. 既定照合順序の変更。大文字小文字の区別が入り、等値比較の結果が変わる

クレジット課金とセルフホストのDev Image制限から総額を数える手順

費用はマネージドとセルフホストで構造が違います。2026年8月時点の公開情報です。

計算資源はクレジット単位で課金され、1クレジットあたり3.96ドルです。ストレージは月あたり1GBで0.023〜0.025ドル程度。取り込みにSingleStore側の課金はありませんが、クラウド事業者の転送料は別途かかります。

見積もりで抜けやすいのは高可用の複製ぶんです。リーフをペアで持つ構成では計算資源が実質2倍になるため、単価に台数を掛けた額へもう1系統を積んで数えます。セルフホストの検証はDev Imageで足りる。8vCPU・64GB RAMの上限はあるものの期限がないため、移行検査を無償で回してから有償版へ移れます。

TiDBと分析専用DBに対するSingleStoreの棲み分けの線

候補が並んだときの分岐条件を、製品ごとに言い切ります。用語の整理から入りたい場合はトランザクション処理と分析処理の区分を先に見ておいてください。

MySQL互換で並ぶTiDBとの分岐条件を2点に絞り込む考え方

MySQL互換の分散SQLという看板で最も近いのがTiDBです。ただし内部構造は対照的で、TiDBは行指向と列指向のストレージを別コンポーネントとして持ち、その間を複製で同期します。SingleStoreは同じリーフの中に両者を同居させ、列ストア側へ点参照の機能を足す方向を採りました。

分岐は2点です。複数リージョンにまたがる強い整合性が主目的なら、PostgreSQL互換の分散SQLと地理分散の配置で扱う製品群のほうが設計思想に合う。単一リージョンで取り込み直後の分析遅延を詰めるのが主目的ならSingleStoreに分があります。

更新頻度の低い集計だけなら分析専用のDBを選ぶという判断基準

分析だけなら列指向専用のほうが単純です。バッチで入れて集計するだけの用途に、トランザクション機能ぶんの単価を払う理由はない。

実装の中身はMPP列指向のテーブル設計と採用判断や時系列に強い即時集計エンジンの取り込み設計で扱っています。更新が主で分析は夜間バッチで足りるなら単一ノードのRDBの版選定に留めたほうが軽く、種類そのものから迷う段階ならRDBとNoSQLの選び分けまで戻ると早く着地します。

SingleStoreを採用してよい条件と見送るべき失敗パターン

SingleStoreを採用してよい3条件と欠けた場合に取るべき代替

採用してよいのは次の3条件がそろう場合です。第一に、取り込みから数秒から数十秒以内のデータへ分析クエリを当てる要件が業務側にある。第二に、書き込み系と分析系を分けた場合の同期の設計と運用を持ちたくない。第三に、MySQL方言の既存クエリ資産やBIツールの接続を引き継ぎたい。

1つでも欠けたときの代替は明快です。鮮度が日次で足りるなら列指向の分析DBとRDBの2本立てで十分。同期の運用を許容できるなら専用DBを選んだほうが単価は下がり、MySQL資産がないならPostgreSQL系の分散SQLも同列に並びます。

非対応機能への依存と鮮度要件の不在で見送りに倒す失敗3パターン

失敗するのは次の3パターンです。

1. 鮮度要件を確認しないまま導入し、実際は日次バッチで足りて単価だけが上がった
2. 外部キーやトリガに依存した既存スキーマを、移行の途中で作り直す羽目になった
3. 行ストアで全表を作り、データ増加に対してメモリを積み増し続ける構成になった

3件とも事前調査で防げます。1つ目は業務側へ「集計結果は何分前のデータまで許容できるか」を数値で確認するだけ。2つ目は移行前のスキーマ検査だけ。3つ目は行ストアを例外として扱うだけです。時間を使うべきなのは性能検証ではなく、この3点の事前確認になります。

導入初日に決めるシャードキーと表型に関する設計5項目の決定順序

後戻りしにくい項目を、決める順に並べます。第一にパーティション数（作成時に確定する）。第二にシャードキー（頻繁に結合する表で揃える）。第三に表型の割り当て（既定は列ストア、行ストアは例外）。第四に版の系列（本番は9.0系）。第五に照合順序の明示指定です。

この5つは相互に依存します。シャードキーを決めないと結合の型が読めず、表型を決めないとメモリの見積もりが立たない。要件整理から表設計と取り込み経路の実装までを外部と組んで進めるなら、データ分析基盤構築・MLOps構築支援で分散データベースを含むデータ基盤の設計と構築を承っています。

よくある質問

実際に検索されている質問へ、判断材料の形で答えます。

SingleStoreはMySQLとどこまで互換ですか？

ワイヤプロトコルに互換性があるため、MySQLのドライバやBIツールは接続文字列を変えるだけで繋がります。SQLの方言も大部分が通る。一方で外部キー制約とトリガは非対応で、参照整合性と監査ログの取得はアプリ側かPipelines側へ移す必要があります。9.0で既定の照合順序が変わった点も確認してください。

SingleStoreは無料で使えますか？

評価と非本番の範囲であれば無償枠があります。マネージドのHelios には共有基盤の無償プランがあり、セルフホストでは8vCPU・64GB RAMを上限とするDev Imageが期限なしで使えます。本番運用は有償で、Standardが1時間あたり0.99ドルから、Enterpriseが1.49ドルから。計算資源はクレジット単位（1クレジット3.96ドル）で課金されます。

SingleStoreとTiDBはどちらを選ぶべきですか？

複数リージョンにまたがる強い整合性が主目的ならTiDBを含む分散SQLの系列、単一リージョンで取り込み直後の分析遅延を詰めるのが主目的ならSingleStoreです。内部構造も、TiDBが行と列を別コンポーネントで同期するのに対し、SingleStoreは1つの表型に束ねている。機能表で比べるより、手元の主要クエリを両方へ流して応答時間を測るほうが速く決まります。

ベクトルの近傍探索は専用DBなしで足りますか？

同じクエリの中でベクトルの近傍探索と業務条件の絞り込みを混ぜるなら足ります。8.5以降はHNSW系とIVF系の索引に対応し、業務データと同じSQLで結合できるため、データストア間の整合を取る処理が不要になる。近傍探索だけを高スループットで回すなら専用DBのほうが単純です。索引はメモリ常駐なので、件数が多い場合はIVF_PQFSから当たってください。

本番で使うSingleStoreの版はどれを選べばよいですか？

2026年8月時点では9.0系です。最新系列の9.1は候補版という位置づけで、公式ドキュメント自身が本番には9.0系を推し、あとから9.1へ上げられると案内しています。9.0系は9.0.10が2025年10月15日に出て以降もパッチが継続しており、据え置き先として扱いやすい。

関連記事

• TiDBとは？MySQL互換の分散SQLとHTAP：最も近い比較対象です
• OLTPとは？OLAP・DWHとの違いとHTAP：用語の区分を整理できます
• ClickHouseとは？列指向DBの仕組みと設計：分析専用に振る候補です
• StarRocksとは？MPP列指向のテーブル設計：結合の多い分析の代替です
• シャーディングとは？水平分割とシャードキー：分割設計の前提です