TiDBファミリーにDWHが新登場！！ TiDB最新情報 / TiDB update 202609

2026年9月26日(土)に開催された「第16回 関西DB勉強会」での発表資料です。
https://kansaidbstudy.connpass.com/event/398751/

TiDBの概要に加えて、TiDBファミリーに新しく追加されたDWH製品であるTiDB Cloud Lake(2026年9月26日時点でパブリックプレビュー)など、TiDBの最新情報について紹介しています。

Transcript

1. TiDBファミリーにDWHが新登場！！ TiDB最新情報 PingCAP株式会社 シニアソリューションアーキテクト ⼭﨑 由章
2. About PingCAP
3. PingCAP と TiDB について PingCAP社は「TiDB」を開発/提供しています 社名 社名の由来 PingCAP社 本社：⽶国カリフォルニア州 事業内容 ▪CAP定理 Webサービスを運⽤する上で「⼀貫性‧可⽤性‧分断耐性」の3つの性質を 同時に満たすことは不可能であるという定理 ▪PingCAP(ピンキャップ) 『CAP定理』にPingを打ち続けるという想いで命名 (挑戦し続ける) DB名の由来 New SQLデータベース を開発/提供 ▪TiDB(タイ‧デービー)の由来 「Ti」は「チタニウム（Titanium）」の元素記号「Ti」を意味し、 チタンのような堅牢なデータベースという意味で命名
4. PingCAP Our Mission is … to empower engineers and enterprises to innovate with speed, agility, and scale. グローバル About PingCAP 3,000社 以上で採⽤ / 4
5. TiDB概要
6. NewSQL + HTAPの先進性 ミッションクリティカルな ワークロードをスケーラブルに Horizontal Scalability High Availability アーキテクチャを複雑に することなくスケールア ウト ビジネス継続性を確実に する自動フェイルオー バーと回復 Strongly Consistent MySQL Compatibility 分散環境でスケールする ACIDトランザクション ほとんどのケースで MySQLコードの変更は 不要 +リアルタイム分析 リアルタイムの 洞察力を高める ビジネスの スピードを向上 シンプルな アーキテクチャ 低い維持コスト
7. 特徴とメリット NewSQL HTAP ベクトル検索 スケーラブル 無停⽌ 分析統合 AI対応 コスト パフォーマンス 向上 運⽤負荷の劇的 低減 チームの能⼒を スケール 次世代AIアプリ のデータ基盤 無停⽌運⽤により SLAの向上 分析まで可能な汎⽤ 性で基盤を統⼀ ベクトル検索、AI エージェントの記憶 領域を担う 動的スケールにより 運⽤負荷低減 / 7
8. TiDBのコンポーネント - 複数のコンポーネントでひとつのTiDBクラスターを構成 - ストレージ層とコンピュート層を分離し複数台で構成することでスケーラビリティ/可⽤性向上を実現 コンピューティング TiDB - SQL解析を⾏う *MySQLプロトコルをKVに変換 - ParseやOptimizeを担う - HTAPではTiKV(row型)かTiFlash(column型)判断 PD TiDB 司令塔 PD - データ配置場所の管理（Region管理） - 分散トランザクションで利⽤するTSOを発⾏ TiKV TiFlash row型 column型 ストレージ TiKV TiFlash TiKV - OLTP⽤途の分散Key-Value Store※RocksDB利⽤ - パーティショニングによるデータ分散管理 - Raftや2PCにより整合性担保 TiFlash *オプション - HTAP利⽤時の追加コンポーネント - OLAP⽤途のカラム型ストア
9. スケーラビリティと高可用性を実現する自動シャーディング テーブル/インデックスはシャード単位（≒Regionと呼ぶ）に分割され、それぞれ３つのレプリカを持つ（冗⻑構成） １つのLeader（RW）と２つのFollower（Backup）で役割分担 例：ユーザーテーブル 各Regionは以下によって分割/配置される ‧PK/Indexの範囲 ‧データサイズ（256MiB） ‧各TiKVノードでレプリカを均等配置 ：Region TiDB TiDB TiKV TiKV TiKV Leader 読み書き可能 Follower バックアップ Follower バックアップ Follower バックアップ Leader 読み書き可能 Follower バックアップ Follower バックアップ Follower バックアップ Leader 読み書き可能 / 9
10. TiDB Xアーキテクチャーと 新しいマネージドサービス / 10
11. TiDB X のアーキテクチャ TiDB Cloud Starter（2021）から継続して開発 • Shared Everythingアーキテクチャ ◦ S3が主要ストレージ ◦ KV層はキャッシュとして動作 • マイクロサービスとオンデマンド プロビジョニング ◦ 利⽤量（RU）による従量課⾦ ◦ 統計更新やインデックス作成など のバッチ処理の⾼速化 • 数百万スケールの論理クラスタを サポートするメタデータ管理 • データの複製不要で瞬時にコピーを作成 できるブランチ機能
12. アーキテクチャーの違い 各コンポーネントが担っていた役割を分割 ※マイクロサービス化のイメージ TiDB X TiDB Cloud Dedicated PD App App Gateway Gateway TP (TiDB) TiDB MPP (TiFlash) DDL (TiDB) Columnar Engine (TiFlash) Row-based Engine (TiKV) TiKV Analyze (TiDB) TiFlash Object Storage Compaction (TiKV) Coprocessor (TiKV) TSO (PD) Scheduler (PD) / 12
13. アーキテクチャーの違い Auto Scale：共有のリソースプールから必要な分を追加投⼊ TiDB X App On Demand Pool TP (TiDB) Gateway TP (TiDB) MPP (TiFlash) DDL (TiDB) Analyze (TiDB) Columnar Engine (TiFlash) Row-based Engine (TiKV) TP (TiDB) TP (TiDB) MPP (TiFlash) Object Storage Compaction (TiKV) Coprocessor (TiKV) TSO (PD) Scheduler (PD) / 13
14. TiDB X のアーキテクチャー上の利点 従来のアーキテクチャーでの課題 解決策 TiKVノードの追加時にリバランシングが 必要になる オブジェクトストレージ上から永続データをコピー できるためリバランシング不要 SQLの処理などのフォアグランドタスクと GCなどのバックグランドタスクでリソースを共有し ている それぞれの処理に専用のノードを用意することで リソース競合を排除 バックアップ取得時にもコンピューティングリソー スを必要とする オブジェクトストレージのスナップショットベースのバック アップを使用可能 プロビジョニングされたコンピューティングリソー スはオフピーク帯に無駄が生じる オートスケールによってリソースを自動的に最適化 / 14
15. TiDB Cloud(マネージドサービス)のラインナップ TiDB Cloud Dedicated TiDB Cloud Starter TiDB Cloud Essential TiDB Cloud Premium 専有型 共有型 共有型 専有型 性能とコンプラ イアンスの完全な コントロールが可能 エンタープライズ向け 完全従量課⾦ サーバレスDB ベースラインを 確保した サーバレスDB TiDB Xアーキテク チャーを採⽤した 専有型TiDB Cloud Public Preview Public Preview TiDB Xアーキテクチャ / 15
16. AI時代のデータベース TiDB Cloud Starter/Zero
17. TiDB Cloud Starter/Zero: AI時代のデータベース AIワークロードのためのクラウドネイティブTiDBアーキテクチャ オートスケール マルチモデル AIワークロードに 応じて⾃動的に拡張 リレーショナル + ベクトル検索 + 全⽂検索 従量課⾦ Zero Friction すぐ⽴ち上がり 利⽤した分だけの課⾦ API/Skillを活⽤し、利⽤ 開始から開発までAIで
18. マルチモデルサポート：AI実装の複雑さを解消 RDB‧ベクトル検索‧全⽂検索を単⼀のDBで提供 エージェントのデータの記録‧検索をワンストップで RDB 統⼀されたアクセス LLM 1111 応答速度の低下 ベクトルDB データの不整合 分散した権限管理 全⽂検索DB 素早い回答 TiDB ⼀貫性のあるデータ Auto Embeddingも提供 LLM
19. AI駆動開発に有効なSkills / MCP コーディングエージェントを⽤いて開発からテストまで実⾏可能 https://github.com/pingcap/pytidb https://github.com/pingcap/agent-rules
20. ノーコードからカスタム開発まで MySQL互換、MCP対応、Pythonフレームワーク対応により サービスからも呼び出しやすく、カスタム開発の⽣産性も⾼い Agent SaaS Coding Agent Agent SDK Claude Code Microsoft Foundry OpenAI Codex Google ADK Google Antigravity AWS Strands Agents Frameworks
21. AIエージェントのデータ基盤：Agent = One TiDB エージェントごとに独⽴したDBを瞬時に展開し、待機コストも極⼩化 完璧な隔離  Agent = One TiDB 1エージェント = 1DB / ブランチ 驚異的なコスト効率  待機時 $0（コンピュート） 不要なコストを徹底削減 • ミリ秒単位の⾼速プロビジョニング • 他社DB：インスタンス維持による定常的 なコストが発⽣ • 他エージェントの⼲渉を排除する完全な データ分離 • TiDB Starter：待機時はストレージ課⾦ のみ • セマンティック検索（Vector）と構造化 データを1つに統合 • プロビジョニング：APIで数秒。オンデマ ンドの作成も容易
22. エージェントデータの分離: manusの事例 AIエージェントプラットフォーム「manus」は、爆発的な ユーザー増加（10万⼈のアクティブユーザー、200万⼈の Waitlist）により、単ーインスタンスデータべースの限界 に直⾯しました。エージェントのメモリとして利⽤した MySQLデータベースは、指数関数的に増える利⽤に耐えき れなかったのです。 2週間でTiDBに移⾏し、manus 1.5をリリース。全ての ユーザーにその機能を解放。年末には $1M のARRを達成し ました。 100,000 10 10 ユーザー数 200万の参加待ち エージェントあ たりのタスク数 タスクあたりの 試⾏錯誤数 TiDB Cloud Starterにより、manusはデータベースを「ボトルネック」からエージェントの「無限の記憶基盤」ヘと 変⾰しました。TiDB Cloud Starterは、エージェント毎に固有のデータベースを持つことを可能にします。
23. エージェントによるサイト⽣成: Kimiの事例 先進モデルによるWebサイト⽣成 ⾃律的なWebサイト構築‧公開を実現するKimi K2.6は、数百万のテ ナントを低コストで管理する課題に直⾯しました。 直⾯したデータベース課題: • • Serverless Postgresの利⽤: アイドル時のコスト⾼ テナント毎のスキーマ: 性能劣化と接続過負荷 TiDB Cloud Starterにより、数秒でのインスタンス提供と、コストの 劇的な削減を達成しました 数秒 < 1$ スケール データベース 作成時間 データベース毎の 費⽤ 柔軟な性能 数百万のDB Kimiは、TiDB Cloud Starterを利⽤することで、コストを低く抑えつつ俊敏性を⼿に⼊れました。 TiDB Cloud Starterは、AIによる多数の成果物の基盤となるデータベースです。
24. TiDB Cloud Lake (パブリックプレビュー) / 24
25. TiDB Cloud Lake TiDB Cloud上で利⽤可能な、クラウドネイティブなデータウェアハウス 使っていない時は⾃動で停⽌して無駄なコストを削る、運⽤不要 / 25
26. TiDB Cloud Lakeの特徴 No setup or ops Pay as you go 運用工数ゼロで即座に利用可能 完全従量課金型でコスト最適化 Multi-cloud ready マルチクラウド対応 （現時点では AWSのみ提供中） BI-ready console 24/7 support コンソールから即座に可視化し BIツールをつなぐ手間も省く PingCAPサポート 26
27. TiDB Cloud Lakeのアーキテクチャー Meta-Service Layer システム全体の情報を一元管理するコントロールセンターの 役割 高可用性を持つクラスタとして機能し、スキーマ情報などを管 理 Compute Layer (Warehouses) 実際のデータ処理（ SELECTクエリの実行、データの更新・ ロードなど）を行う計算リソース 自動スケール (Multi-Cluster Warehouse)により、運用コス トなし 無稼働時はコストをゼロ に Storage Layer (Object Storage) S3等のオブジェクトストレージ活用 カラムナー形式で強力に圧縮し、保存コストを削減 データ保存時に、 MinMaxやBloomfilterインデックスを 自動生 成。 • I/O操作や CPUの消費量削減 • チューニング不要 / 27
28. データ取り込み COPY INTO文でオブジェクトストレージ上のデータを取り込み可能 (オブジェクトストレージ上のファイルに対して直接クエリーも実行可能 ) Near-real-time loading pattern ▪ ▪ オブジェクトストレージへの PUT eventsを秒単位で検知し自動取り込み Kafka連携でストリーム（ `tidbcloudlake-ingest-kafka` ） 28
29. TiDB Cloud Lake 主な機能 Feature Description Learn more 統合エンジン 分析、ベクトル、検索、および地理空間が、単一のオプティマイザとランタイムを共有 TiDB Cloud Lake Architecture 統合データ 構造化、半構造化、非構造化、およびベクトルデータがオブジェクトストレージを共有 TiDB Cloud Lake Architecture 分析ネイティブ ANSI SQL、ウィンドウ処理、増分集計、およびストリーミングがBIを強化し、同じプラット フォーム上で実行されます。 Worksheets ベクトルネイティ ブ エンベディング（埋め込み）、ベクトルインデックス、およびセマンティック検索がすべて SQL内で実行 Vector Search 検索ネイティブ 全文検索と転置インデックスがハイブリッド検索 Full-Text Index Geoネイティブ 地理空間インデックスと関数が、マップおよび位置情報サービスをサポート Geo Analytics 29
30. 事例紹介 海外ゲーム会社 Snowflake → Cloud Lake 移行 コスト削減 Immersive Translate AI 翻訳サービス 移行容易性 運用工数削減 AI 活用基盤 課 題 課 題 Snowflake の Stream / Task を活用した変換パイプラインを運用していたが、データ量 増加とともにコストが膨らみ、請求額の予測が困難になっていた。月間 1,000 億行規 模のデータ処理に対して、 Snowpipe やストレージのコスト構造が合わなくなってきた。 月間数千万ユーザーのログ収集・行動分析を自社ホスト型 HTAP データベースで運 用 していたが、データ量増加に伴い運用負荷が増大。手動レポート作業が多く、データ チームが本来の分析業務に集中できない状況だった。 AI サービスのデータ基盤も別 途整備が必要だった。 解決策 解決策 Aurora → JSON → S3 → Cloud Lake の構成に移行。 Snowflake に近い SQL 構文のため 移行の摩擦を最小化。 Stream / Task も同等機能が Cloud Lake に存在するため、既存 パイプラインをほぼそのまま移植できた。 自社ホスト型 HTAP から TiDB Cloud Lake に移行。 Tasks によるレポート自動化、ログ分 析、ビジネスデータの外部直接提供を一基盤に統合。同一プラットフォーム上にエンド ユーザー向け AI Agent サービスも構築した。 成 果 成 果 約3週間 1,000億行 10,000行/秒 50%コスト削減 自動化 直接提供 AI 構築 ゼロ運用 数千本の SQL 移行完了 月間処理 データ量 安定した 取り込み速度 Snowflake年間コス ト比 Tasks でレポート 生成を完全自動化 （手動処理を排除） DWH から外部へ ビジネスデータを ダイレクト配信 2C 向け AI Agent サービスを Lake 上に構築 専任 Big Data チーム不要の インフラを実現 PingCAP
31. TiFlash vs TiDB Cloud Lake TiFlash Lake リアルタイム業務分析エンジン 統合データウェアハウス (DWH) 業務データの ”今”をデータ移動なしで可視化する リアルタイム分析 全社データを統合し、過去から現在までを低コスト で深掘りする大規模分析・ AI連携 アーキテクチャー TiDBの一部として 独立したクラウドネイティブなシステム データ規模 GB 〜 TB クラス TB 〜 PB クラス データ構造 TiKVからレプリケートされたカラムナーストア オブジェクトストレージ (S3) リアルタイムなダッシュボードとモニタリング 不正検知やリアルタイム・レコメンデーション ログデータの大規模・継続的な分析 AI・機械学習基盤（データサイエンス連携） DIMENSION ポジション 役割 最適なユースケース / 31
32. 参考情報：クラスメソッド様によるブログ記事 • public previewのTiDB Cloud Lakeを触ってみた https://dev.classmethod.jp/articles/tidb-cloud-lake-trial/ • TiDB CloudのデータをTiDB Cloud Lakeへ移してみた https://dev.classmethod.jp/articles/tidb-cloud-lake-migrate-from-tidb/ • TiDB Cloud LakeのMySQL Endpointを有効にして、Grafanaからログを可視化してみた https://dev.classmethod.jp/articles/tidb-cloud-lake-grafana-mysql-endpoint/ • TiDB Cloud LakeのMySQLデータソースにTiDB Cloudを直接指定して同期してみた https://dev.classmethod.jp/articles/tidb-cloud-lake-mysql-datasource-snapshot/ / 32
33. まとめ / 33
34. OLTPもOLAPもAIも全てTiDB(One TiDB)で実現！ ①アプリケーション：業務アプリを含めたOne TiDBによるサイロの排除 ②リアルタイム分析：リアルタイム分析層による意思決定の迅速化 ③ペタバイトスケール分析：低コスト・高機能のDWH基盤 ④AI活用：One TiDBがあらゆるAIユースケースをカバー 業務アプリケーション リアルタイム分析 / データハブ層 分析基盤 データ連携機能(開発中) w/TiFlash TiCDC Lake
35. イベント案内：TiDB User Day / 35
36. TiDB User Day 2026 国内最大のNewSQL イベント 登録用 Webページ： https://pingcap.co.jp/tidb-user-day/ ※昨年は1,000名を超える登録 ◆ 登壇予定企業（一部） Day1 10/29 (木) AI Day ・ クラスメソッド株式会社 ・ 株式会社サイバーエージェント ・ FlashLabs株式会社 | OrcaRouter ・ KDDIアイレット株式会社 ・ 株式会社 LangGenius | Dify ・ Notta株式会社 Day2 10/30 (金) TiDB Day ・ 株式会社コラボスタイル ・ 株式会社 Cygames ・ 株式会社 GAGA ・ 株式会社ひとまいる (カクヤス ) ・ 株式会社メルカリ ・ 株式会社 SODA | SNKRDUNK ・ サミット株式会社 ・ Vポイントマーケティング株式会社 And more・・・
37. 2026年イベントテーマ AI + NewSQLの波に乗ろう 「波に乗る」という言葉には、勢いやタイミングを捉え、チャンスを掴むという前向きな 意味が込められています。AI時代において、データ基盤の進化はますます重要に なっています。AIという大きな波に乗り、データの可能性を 最大限に引き出すために、TiDB User Dayで最新情報に触れ、ユーザー同士のリア ルな声から新たなアイデアやヒント、実践知を得る機会を提供します。ここで得られ るアイデアや実践知が、次の挑戦へ踏み出すきっかけとなる――そんな想いを込め ています。
38. Thank You! / 38