編集者注：PingCAPでは分散型システム (TiDB) を開発していますが、私たちは規模を問わず、エレガントなエンジニアリングを高く評価しています。OpenClawは、「ローカルファーストなRAGデータベース」の完璧なユースケースを示しています。運用コストをゼロにし、完全なデータプライバシーを確保し、個人ユーザーのために瞬時に起動させたい場合、SQLiteは極めて現実的な選択肢です。

私たちは適材適所のツール選びが重要だと考えています。デスクトップではSQLiteが威力を発揮し、クラウドや大規模環境ではTiDBがその本領を発揮するように設計されています。ローカルアーキテクチャの境界線を正しく理解することは、なぜ、そしていつ分散型システムへとステップアップすべきかを知る手がかりになります。

それでは、OpenClawがいかにしてローカルファイルを活用し、個人向けのRAGシステムを構築しているのか、その詳細を見ていきましょう。

分析の前提

• 対象プロジェクト：OpenClaw (およびその派生版Moltbot / ClawdBot)
• 分析バージョン：mainブランチのコミット9025da2 (2026年1月30日時点)
• 対象範囲：src/memory/*の実装

OpenClawは「永続的なメモリー」をコア機能として掲げています。ユーザーのコンテキストを記憶し、使うほどに自分専用のツールへと進化していくという約束です。エンジニアの視点でこれを読むと、データはどこに保存されるのか？Dockerコンテナを動かす必要があるのか？データが外部のベクトル検索クラウドに送信されるのではないか？といった疑問が自然と湧いてくるでしょう。

その答えはsrc/memoryの中にあります。OpenClawの永続メモリーは、SQLiteのみで動作する軽量なRAGローカル検索システムです。

このシステムは、ローカルにあるMarkdown形式のナレッジを分割し、エンベディングを生成して、そのインデックスをローカルの.sqliteファイルに保存します。情報の取り出しは、ベクトル検索、キーワード検索、またはその両方を組み合わせたハイブリッド検索によって行われます。

AIエージェントにおけるデスクトップ向けRAGの課題

個人用AIエージェントのメモリーシステムを構築する際には、サーバーサイドのRAGとは大きく異なる、特有の制約がいくつも存在します。

1. 運用ゼロ：エージェントを利用するためだけに、ユーザーがPostgreSQLをインストールしたり、Dockerを起動したり、複雑な認証情報を管理したりする手間を強いてはなりません。
2. ローカルファースト：「ナレッジベース」の実体は、通常、ユーザーのディスク上にあるMarkdownファイル (MEMORY.mdなど) のフォルダに過ぎません。インデックスは、このローカル性を尊重する必要があります。
3. 回復性：たとえ高度な機能 (ローカル用のベクトル検索拡張機能など) の読み込みに失敗したとしても、システムとして動作し続けなければなりません。

ローカルファーストAIにSQLiteが最適な理由

これらの制約を踏まえ、コードベースからは明確な意思決定のプロセスが見て取れます。

なぜベクトル専用データベースではないのか？専用のベクトルデータベースは強力なインデックス機能を提供しますが、通常はサービス指向アーキテクチャ (データの投入、独立したプロセス) を前提としています。ローカルツールにおいて、ユーザーに別途ベクトルデータベースを起動させることは、導入の大きな障壁となります。

なぜMySQLやPostgreSQLではないのか？本番環境ではフル機能のリレーショナルデータベース管理システムを推奨しますが、個人のマシンで動かすとなると運用上のオーバーヘッドが生じます。OpenClawに求められるのは「ダウンロードして即実行」できることです。ローカルでmysqldプロセスを要求したり、接続文字列の設定を強いたりすることは、ゼロ設定という目標に反します。

決断は？SQLiteはこの特定の需要に完璧に合致しています。

• サーバーへの依存なし：ポートもバックグラウンドプロセスも必要ありません。
• 単一ファイルによるポータビリティ：インデックス全体がたった一つの.sqliteファイルに収まるため、バックアップも極めて容易です。
• エコシステム：FTS5  (全文検索) やsqlite-vec (ベクトル検索) といった拡張機能を利用することで、単一のバイナリ内で実用的なRAGスタックを構築できます。

SQLiteによるベクトル検索とハイブリッド検索の実装

OpenClawにおいて、SQLiteは単なるストレージではありません。インデックス作成プロセス全体を管理するステートマシンとして機能しています。

データフロー

• 入力：Markdownファイル (memory/**/*.md) およびセッションの書き起こし
• 処理：テキストを行単位でチャンクに分割し、エンベディングを生成
• 出力：検索された上位K個のチャンクをプロンプトビルダーに送出

ストレージのレイアウト

インデックスは~/.openclaw/memory/{agentId}.sqliteに保存されます (フォークしたバージョンによっては~/.clawdbotや~/.moltbotになります)。

~/.openclaw/
└── memory/
    ├── my-agent.sqlite       # The active index
    ├── my-agent.sqlite-wal   # Write-Ahead Log
    └── my-agent.sqlite-shm   # Shared Memory

データベースは、4つの主要なテーブルと、2つのオプションの仮想テーブルで構成されています。

1. files：ファイルの最終更新時刻、サイズ、およびコンテンツのハッシュ値を追跡し、変更のないファイルの再インデックス作成をスキップします。
2. chunks：データの信頼できる情報源です。テキスト本体、行の範囲、およびJSON形式でシリアライズされたエンベディングを格納します。
3. chunks_vec (仮想テーブル)：sqlite-vecがロードされている場合、このテーブルにバイナリ形式の浮動小数点ベクトルを格納し、高速な類似性検索を可能にします。
4. chunks_fts (仮想テーブル)：FTS5が利用可能な場合、このテーブルでテキストのインデックスを作成し、キーワード検索を可能にします。

コード解説：インデックス作成と情報取得

OpenClawがこの構造に対してどのようにクエリを実行しているかを見ていきましょう。ここでは段階的な機能縮小を重視しています。これは、もしベクトル拡張機能が利用できない場合でも、システムがより低速ながらも動作可能な代替パスへと自動的に切り替わることを意味します。

1. ベクトル検索 (高速なパス)

sqlite-vecが利用可能な場合、SQLで直接ベクトルの類似性検索を実行できます。

クエリの仕組み：メタデータテーブル (chunks) と専用のベクトルテーブル (chunks_vec) を結合し、テキストコンテキストを取得します。スコアリングにはvec_distance_cosineが使用されている点に注目してください。

SELECT c.id, c.path, c.start_line, c.end_line, c.text,
       vec_distance_cosine(v.embedding, ?) AS dist
FROM chunks_vec v
JOIN chunks c ON c.id = v.id
WHERE c.model = ? 
ORDER BY dist ASC
LIMIT ?

仕組み：返されるdistはコサイン距離を表します。この値が小さいほど、類似度が高いことを意味します。この手法の利点は、計算処理をデータベースエンジン側で行わせることで、Node.jsプロセスの負荷を低く抑えられる点にあります。

2. フォールバック (安全なパス)

ユーザーの環境がネイティブのベクトル検索拡張機能をサポートしていない場合 (クロスプラットフォームのNode.jsモジュールでよく発生する問題です) でも、OpenClawはクラッシュしません。その代わりに、JavaScriptによる「総当たり」方式へと切り替わります。

1. SQLiteから候補となるチャンクを読み込みます。
2. JavaScriptのみ使用して、メモリ上でコサイン類似度を計算します。
3. 類似度の高い順にソートし、上位K個を返します。

これにより、大規模なデータセットではパフォーマンスが低下するものの、メモリー機能そのものは動作し続けることが保証されます。

レジリエンス（回復性）のロジック

OpenClawはtry-catchパターンを使用して、sqlite-vec拡張機能が利用可能かどうかを検知します。拡張機能のロードに失敗したり、クエリがエラーを返したりした場合は、即座にメモリ上での「総当たり」計算へと移行します。

async function searchMemory(queryVector, limit = 5) {
  try {
    // 1. THE FAST PATH: Native Vector Search [cite: 58]
    // Utilizes the 'sqlite-vec' extension for database-level cosine distance[cite: 59, 61].
    return await db.all(`
      SELECT c.text, vec_distance_cosine(v.embedding, ?) AS dist
      FROM chunks_vec v
      JOIN chunks c ON c.id = v.id
      ORDER BY dist ASC LIMIT ?`, [queryVector, limit]); [cite: 63, 68, 69]

  } catch (err) {
    console.warn("sqlite-vec not found. Falling back to JS-based search."); [cite: 73]

    // 2. THE SAFE PATH: Brute-Force JavaScript [cite: 72, 74]
    // Load all candidates and compute similarity in the Node.js process[cite: 75, 76].
    const allChunks = await db.all("SELECT id, text, embedding FROM chunks"); [cite: 75]
    
    return allChunks
      .map(chunk => ({
        ...chunk,
        dist: cosineSimilarity(queryVector, JSON.parse(chunk.embedding)) // Pure JS calculation [cite: 53, 76]
      }))
      .sort((a, b) => a.dist - b.dist) // Sorting manually in memory [cite: 76]
      .slice(0, limit); [cite: 76]
  }
}

3. ハイブリッド検索 (両方の長所を活用)

より精度の高い情報取得を実現するために、意味を理解するベクトル検索と、特定の語句を正確に一致させるキーワード検索を組み合わせています。
キーワード検索のクエリ：SQLite標準のFTS5モジュールと、ランキング関数であるBM25を使用しています。

-- Conceptual FTS Query
SELECT *, bm25(chunks_fts) as rank 
FROM chunks_fts 
WHERE chunks_fts MATCH 'OpenClaw AND Memory'
ORDER BY rank

次に、これらの結果をベクトル結果と重み付けスコアリング式を用いて統合します。

ユーザーの知識を偏りなく、バランスの取れた視点でエージェントに提供します。

まとめ

OpenClawのメモリーシステムは、アーキテクチャを適切なサイズに保つことの重要性を教えてくれます。

SQLiteを選択することで、開発チームは個人用ツールに不必要な分散システムの複雑さを持ち込むことを回避しました。その結果、運用の負担を負うことなく、ACID準拠、ポータビリティ、そして強力なクエリ言語を手に入れることができたのです。

データプライバシーを完全に確保し、個人ユーザー向けに瞬時の起動を実現するという点において、現在のこのタスクにはSQLiteこそが最適なツールです。しかし、「技術的な誠実さ」とは、いつ次のステップへ進むべきかを見極めることでもあります。マルチテナンシーや水平スケーリングが必要になり、拡張性の壁に突き当たったとき―そのとき、これまでのSQLの考え方を変える必要はありません。ただ、データベースを切り替えればよいのです。

とはいえ、アーキテクチャは進化するものです。この「メモリ」の概念を、数千のエージェントにサービスを提供するマルチテナントSaaSプラットフォームへとスケールさせる場合、「ローカルファイル」という制約がボトルネックとなります。その時点こそが、SQLiteからTiDBのような分散型SQLデータベースへと移行すべきタイミングです。それまで利用してきたSQLの作法は維持しつつ、必要とされるスケール性能を追加できるからです。

一方、ローカルで動作するエージェントにとっては、一つの.sqliteファイルがシンプルさと機能性の最も優れたバランスを提供してくれるのです。

The post OpenClawメモリアーキテクチャ：SQLiteを用いたローカルファーストRAGの構築 appeared first on TiDB.

AIコーディングエージェントは「自分のローカル環境では動作する」コードを生成するのが得意です。しかしデータベースエンジニアなら誰もが知っているように、ローカルのDockerコンテナで動作するクエリと、高い同時実行性が求められる本番環境で耐えうるクエリとの間には、大きな隔たりがあります。

私たちは、エージェントが一般的なチュートリアルをもとにSQLを生成した際に、同じ問題が繰り返し発生するのを目にしてきました：

• 一見「問題なさそう」に見えるクエリが、実際には実行計画が不適切で、スケール時に破綻するケース (しかも誰もEXPLAINを確認していない)。
• ITLS検証設定が不完全なことによる、安全でない接続。
• アプリケーション側がInnoDBと同様の動作を前提としている一方で、分散データベースエンジンが異なる動作をしていることによるトランザクションの不具合。
• MySQLには存在する機能でも分散システムでは動作が異なる互換性の落とし穴。

データベース障害の大半は構文ミスではなく「コンテキスト」の欠如が原因です。

そこで私たちは、TiDB Skillsをリリースしました。これは、Claude Code、Cursor、CodexといったAIエージェントがコード生成時に参照できるコンテキストを集めたGitHubリポジトリです。これにより、TiDB Cloudにおいて、より安全で本番運用に耐えうるSQLを生成できるようになります。

TiDB Skillsの仕組み

私たちは、こうした運用上の「落とし穴」を、AIが参照できる小さなスキルフォルダとしてまとめました。これにより、エージェントはSQLを書いているとき、移行作業をレビューしているとき、あるいは本番環境の問題をトラブルシューティングしているときに、適切なルールを確実に参照できるようになります。

リポジトリは、エージェントが必要なコンテキストだけを取得できる構造になっており、プロンプトウィンドウを効率的に保てるように設計されています：

ワークフローは、シンプルでユーザーからは見えない形になるよう設計されています：

1. 選択：エージェントは関連するスキルフォルダを選択します (例：SQLを生成する際はskills/tidb-sql)。
2. 取得：特定のタスクに必要なリファレンスだけを取り込みます (例：複数ステップの書き込み処理を扱う場合はtransactions.md)。
3. 適用：「ベストエフォート」の推測に頼るのではなく、コード生成時にそのガイダンスを制約条件として適用します。

Deep Dive：「汎用」と「本番環境」の間にあるギャップ

この仕組みが生み出す違いを見るために、汎用的なSQL生成が本番環境で失敗する2つの具体例を見てみましょう。

1. トランザクションの落とし穴

tidb-sqlスキルがない場合は、エージェントは単にBEGINと記述するだけで、特に意識することなく「悲観的ロックが使われる前提」で進めてしまいます。スキルがある場合は、どのモード (悲観的 / 楽観的) を使うのかを明示的に選ぶ必要があり、エージェントはその選択を意識的に行わなければなりません。

ルール (transactions.mdより)：「競合が頻繁に発生する場合は悲観的 (pessimistic) トランザクションを優先すること。書き込み同士の競合が少なく、かつアプリケーション側でコミット失敗を適切に処理できる場合は楽観的 (optimistic) トランザクションを検討すること。」

エージェントの出力：このルールを取り込むことで、エージェントは楽観的 (Optimistic) モードを選択した場合、アプリケーションレベルでのリトライループも併せて生成する必要があることを理解します。そして、COMMITを必ず成功する処理として扱わなくなります。

-- The agent now explicitly declares the mode [cite: 64]
BEGIN PESSIMISTIC;
-- ... DML ...
COMMIT;

2. プライマリキーのホットスポット

MySQLのチュートリアルで学習したエージェントは、AUTO_INCREMENTを好んで使います。単一ノードのデータベースであれば、これは問題ありません。しかし分散システムでは、連番で増加するIDによってすべての書き込みが単一のリージョン (いわゆる「ホットスポット」) に集中し、書き込み性能が大きく低下してしまいます。

ルール (hotspots.mdより)：「ホットスポット回避／ID戦略 (中〜高)：AUTO_RANDOMをいつ、どのように使用するか。」

エージェントの出力：汎用的なデフォルトに従うのではなく、エージェントは大規模環境での正しさを考慮して最適化されたスキーマを生成します:

CREATE TABLE users (
  -- Agent switches to AUTO_RANDOM for distribution 
  id BIGINT PRIMARY KEY AUTO_RANDOM, 
  email VARCHAR(255) NOT NULL,
  ...
);

ツールキット：含まれる内容

このガイダンスは、中核となるSQLスキルと、それを補完する接続およびORMスキルを中心に構成されています。以下は、私たちがエージェントに注入しているコンテキストの内訳です。

1. 安全性と正確性 (最重要)

これらのスキルは、データ損失や接続障害を防ぐことに重点を置いています：

• TLSおよび接続の安全性：不安定または安全でない接続を防ぐため、厳格なSSL検証要件やクライアント設定パターンを強制します。
• トランザクションと並行処理：これは最もよくある落とし穴のひとつです。このスキルは、楽観的トランザクションと悲観的トランザクションの違い、コミット失敗の処理方法、そしてセッションレベルとグローバルレベルの設定をいつ使い分けるべきかを明確にします。

2. Pパフォーマンスとスケール (重要)

エージェントはしばしば、分散環境でのパフォーマンスを考慮せずにスキーマを書いてしまいます。これらのスキルは、スケーラブルなパターンへと導きます：

• ホットスポット回避 / ID戦略：Tプライマリキーの書き込みホットスポットを避けるために、AUTO_INCREMENTの代わりにAUTO_RANDOMをいつ、どのように使うべきかをエージェントに教えます。
• クエリプランと診断：パフォーマンスを検証するためにEXPLAINやEXPLAIN ANALYZEをどのように使用するか、また統計情報をいつ更新すべきかをエージェントに指示します。
• 互換性の落とし穴：「MySQLでは動作するが、TiDBでは問題を引き起こす」一般的な構文や書き方にフラグを立てて注意を促します。

3. 高度な機能

特定のDDLや可用性チェックを必要とする高度な機能についてもカバーしています：

• ベクトル検索：VECTOR型、ベクトル関数、ベクトルインデックスのDDLに関する正しいパターンを提供します。
• リカバリ手順：FLASHBACK TABLEやFLASHBACK DATABASEを含む、フラッシュバックベースのリカバリワークフローの構文を示します。
• 全文検索：TiDBにおける全文検索の実装に特有のSQLパターンや、可用性に関する注意点 (落とし穴) を示します。

4. アプリケーション統合 (ドライバ & ORM)

アプリケーションとの統合に向けては、コネクションプーリング、安全なパラメータ化、TLS設定をカバーする専用のドライバスキルを提供しています。これにより「デフォルトのNode.jsドライバ」を使用する場合でも、本番環境で安全に利用できることを保証します。

• Node.js：標準的なプーリングおよびTLS対応には
  tidbx-javascript-mysql2、レガシーコードベース向けにはtidbx-javascript-mysqljsを使用します。
• TypeScript / ORM：型付きSQL、スキーマ管理、そして正しいDATABASE_URLのTLSパラメータ設定のためにtidbx-kyselyおよびtidbx-prismaを使用します。
• Serverless / Edge：TCP接続が利用できないエッジランタイム環境向けに、HTTPベースの接続方法を示すtidbx-serverless-driverのガイダンスを提供します。
• Python：CRUD、ベクトル検索、ハイブリッド検索統合のためのpytidbのガイダンスを提供します。

エージェントのインストール

リポジトリはpingcap/agent-rulesで利用可能です。これらのスキルは、Vercelのスキルパッケージを使って、直接エージェントの設定にインストールできます。

ターミナルで以下のコマンドを実行してください。実行すると、使用したいスキルや利用中のエージェント (Claude Code、Codex、Cursorなど) を選択する必要があります：

npx skills add pingcap/agent-rules

インストールが完了すると、エージェントは適切なタイミングで自動的に正しいスキルを選択します。通常、「どのスキルを使うか」を意識する必要はありません。

よくある質問

Q：これは標準的なMySQLでも使えますか？A：TLSの安全性、EXPLAINチェック、安全なパラメータ化など、多くのスキルはどのMySQL環境でも共通のベストプラクティスです。しかし、AUTO_RANDOMや特定のトランザクションモードのような分散向け機能はTiDB向けに最適化されており、単一ノードのMySQLでは調整が必要な場合があります。

Q：これらのスキルを手動で起動する必要はありますか？A：いいえ。skillsCLIをインストールすれば、Claude CodeやCursorのようなエージェントは、例えば「TiDB用のスキーマを書いてほしい」と要求したときに自動でコンテキストを検出し、コード生成前に関連するルールを取得します。

Q：これはコードレビューの代わりになりますか？A：いいえ。TiDBスキルは、コード生成中に動作する「ガードレール」やリンターのようなものと考えてください。TLSの漏れやホットスポットのような典型的な「新人エンジニアのミス」を早期に検出しますが、本番環境への変更は常に人間によるレビューを経るべきです。

まとめ

これらのスキルは、コードレビューやセキュリティポリシーの代わりになるものではありません。しかし、典型的なミスを防ぐ「ガードレール」として機能します。AIエージェントに不足していたコンテキストを提供することで、早期に警告を出し、より安全なデフォルト設定を生成し、本番環境でも問題なく動作するSQLを作成できるようになります。

もしMySQL／TiDBの未対応の注意点やハマりどころを見つけた場合は、IssueやPRを作成してください。そうすることで、将来のエージェント実行時にデフォルトで正しく処理されるようになります。

The post AIエージェントに「本番品質」のSQLを実装させる：TiDB Skillsのご紹介 appeared first on TiDB.

3名の開発者、1つのハッカソン、そしてバイラルしたミームから始まったミッション。これは、マレーシアの若者が直面する経済的困難と現実のB40 (所得の下位40%層) の経験に着想を得た金融教育ゲーム「B40 Life Simulator」の物語です。このプロジェクトは、社会的インパクトと巧妙な技術戦略を両立させています。チームは、リアルタイムのゲームプレイにConvexを、行動分析にTiDB Cloudを組み合わせることで、「高速なユーザーインタラクション」と「複雑なデータ集計」を分離するという重要な課題を解決しました。

彼らのアーキテクチャは、分散SQLがいかに身近なものになったかを証明しています。「Fire-and-forget (投げっぱなし)」の同期パターンを採用することで、ゲームの速度を落とすことなく、プレイヤー行動の生データをTiDB Cloudで深いインサイト (特定の経済的破綻ポイントの特定など) へと変換することに成功しました。これは、あらゆるアプリケーションに強力でスケーラブルな分析機能を短期間で追加したい開発者にとって、完璧な指針と言えます。

彼らのストーリーをチェックして、Cursor x Anthropic ハッカソン・マレーシアでいかにして「Best Use of TiDB」賞を勝ち取ったのか、その舞台裏をご覧ください。

金融リテラシーのゲーム化：B40問題への挑戦

私たちはMelon (Adam)、Rimba (Redzwan)、そしてPekNga (Shafeeq) です。私たちはマレーシア人の開発者3名で構成されており、少しエッジの効いた「DGD (Dark Game Dev)」というチーム名でCursorハッカソンに登録しました。実態は「Wayang Studio」という小さなクリエイティブ・スタジオで、いつか自分たちのゲームを作るという夢について、これまで数え切れないほどの時間を費やして議論してきました。

ハッカソンの説明会のためにモナッシュ大学に足を踏み入れたとき、強烈な緊張感に襲われました。AdamとShafeeqにとって、これが人生で初めてのハッカソンだったからです。

「おい、参加チームがめちゃくちゃ多いぞ。しかも時間は1日しかない。何か形にすることなんてできるのか？」

しかし、私たちには秘密兵器がありました。それはプロンプトエンジニアリングです。私たちはChatGPTに、過去5年間のハッカソン優勝チームを分析させました。AIが導き出したパターンは、「社会的インパクト」「テクノロジーの独創的な活用」「人々が関心を寄せる現実的な問題の解決」でした。そしてAIが提案してくれたアイデアが、私たちの心に深く刺さりました。それが「金融リテラシーに焦点を当てた人生シミュレーター」です。

皆が目にしていた、バイラル化したB40ミームと組み合わさったことで、コンセプトは一気に具体化しました。

「もし…これをゲームにしたらどうだろう？ 実際にB40の生活をシミュレートするようなゲームだ」

単にミームを面白がるだけでなく、私たちはそのメッセージを心から重要だと感じていました。マレーシアの若者の60%は、1,000リンギット (約4万円) の急な出費に対処できません。退屈なパンフレットで教えられる金融リテラシーは役に立ちません。統計やインフォグラフィック、ありがちなキャンペーンはいくらでも見てきましたが、数字だけでは理解は深まりませんし、共感も生まれません。

マレーシアで育つ中で、私たちはB40の人々の苦労を目の当たりにしてきました。30,000リンギット (約120万円) ものPTPTN (マレーシアの高等教育基金局) 学生ローンに押しつぶされる新卒者。月給1,800 (約7万円) リンギットで仕事と育児を両立させるひとり親。生活費の支払いを済ませるか、食料を買うか、それとも正気を保つか――そんな不可能な選択を迫られる現実です。

もし、ゲームの中でその経済的な苦境を体験できるとしたら？ 現実の世界で手痛い教訓を学ぶ前に、疑似体験を通じて学ぶことができたらどうでしょう。

こうして、AIによるリサーチと1つのミームから「B40 Life Simulator」が誕生しました。(最高のアイデアとは、往々にしてそういうものです。)

技術スタック：パフォーマンスを支えるTiDB CloudとConvexの選択

私たちはある戦略を立てました。このハッカソンには19もの異なるトラックが用意されていたのです。「自分たちのゲームを、できるだけ多くの賞の対象になるように設計したらどうだろう？」と考えた私たちは、オープンエリアから2階のワークショップルームへ移動しました。新しいツールのセッションに参加して学びながら、同時にそれらを自分たちのアイデアに実装していったのです。マルチタスクのレベルは、まさにカオスそのものでした。

中でもTiDBのワークショップは非常に有意義でした。実はTiDBに直接触れるのは今回が初めてだったのですが、学習曲線は予想以上にスムーズなものでした。分散SQLの基礎から、TiDB Cloudのセットアップ方法、そして分析クエリの構築方法までを学ぶことができました。おまけに、TiDBのTシャツまでもらえました。コーディング中に身なりもキマっているのは、モチベーションに繋がりますからね。

最終的に、私たちは19あるトラックのうち10個を自分たちのゲームに統合しました。私たちが何を選び、なぜそれを選んだのかを以下に紹介します。

技術スタックが決まったところで、次にアーキテクチャを検討する必要がありました。ストレスフリーなゲームプレイと深い分析の両方を最適化するにはどうすればよいのでしょうか。

アーキテクチャ：関心の分離

私たちは、B40 Life Simulatorを明確な関心の分離に基づいて設計しました。リアルタイムのゲームプレイにはConvexを、分析および調査データにはTiDBを使用しています。このアーキテクチャを採用することで、プレイヤー体験とデータインサイトの両方を最適化することが可能になりました。

核となる知見は、ゲームプレイと分析では求められるパフォーマンス要件が異なるという点にあります。ゲームプレイには低レイテンシ (レスポンス時間100ms未満) が必要ですが、分析には数千ものセッションをまたいだ集計処理が必要です。これら両方を一つのデータベースで実行しようとすると、競合が発生してしまいます。

データの流れは以下の通りです：プレイヤー → Next.js → Convex (ストレスフリーなのゲームプレイ)  → TiDB (Fire-and-forget 同期による分析)

実装：Cursor AIと「Fire-and-Forget」同期による本番仕様のTiDB接続レイヤーの構築

Cursorのおかげで、SSLを利用したTiDB接続のセットアップ、パラメータ化されたクエリの記述、そしてトランザクションの適切な処理をスムーズに行うことができました。AIはTiDBのMySQL互換性を理解しており、最適な設定を提案してくれました。

私たちは次のようにプロンプトを入力しました：「分析用にSSLを使用したTiDB接続プールを設定し、クエリ実行、結果の取得、およびトランザクション用のヘルパー関数を作成してください。mysql2/promiseを使用してください。」

わずか数分で、本番環境でもそのまま使えるコネクションプーリングのコードが完成しました。

import mysql from "mysql2/promise";

const tidbConfig = {
  host: process.env.TIDB_HOST,
  port: parseInt(process.env.TIDB_PORT || "4000"),
  user: process.env.TIDB_USER,
  password: process.env.TIDB_PASSWORD,
  database: process.env.TIDB_DATABASE,
  ssl: {
    minVersion: "TLSv1.2" as const,
    rejectUnauthorized: true,
  },
  waitForConnections: true,
  connectionLimit: 10,
  queueLimit: 0,
};

let pool: mysql.Pool | null = null;

export function getPool(): mysql.Pool {
  if (!pool) {
    pool = mysql.createPool(tidbConfig);
  }
  return pool;
}

export async function query<T>(sql: string, params?: unknown[]): Promise<T[]> {
  const connection = await getPool().getConnection();
  try {
    const [rows] = await connection.execute(sql, params);
    return rows as T[];
  } finally {
    connection.release();
  }
}

シングルトンパターン (コネクションプールが存在しないときのみ生成する) を採用することで、APIリクエストをまたいでコネクションを確実に再利用できるようにし、try/finallyブロックによってコネクションが必ずプールに返却されることを保証しました。これは、ハッカソンの混乱の中でコネクションリークを防ぐために極めて重要でした。

「Fire-and-Forget」同期パターンを採用した理由

私たちはFire-and-Forget同期パターンを実装しました。ゲームの状態は、リアルタイムな反応性を確保するためにConvexで管理し、特定の重要なタイミング (週の完了時やゲームオーバー時など) に、分析用データとしてTiDBへ同期させています。

プレイヤーが1週間を完了すると、Convexのアクションが実行されます。このアクションが現在のゲーム状態を取得しまとめて、TiDBへの書き込みを担当するNext.jsのAPIルートへと送信します。

export const syncWeeklyProgress = action({
  args: {
    gameId: v.id("games"),
    weekCompleted: v.number(),
    weekendActivity: v.optional(v.string()),
  },
  handler: async (ctx, args): Promise<SyncResult> => {
    // Get game state from Convex
    const game = await ctx.runQuery(api.games.getGame, { gameId: args.gameId });

    // Get decisions for this specific week
    const allDecisions = await ctx.runQuery(api.games.getAllDecisions, {
      gameId: args.gameId,
    });
    const weekDecisions = allDecisions.filter(d => d.week === args.weekCompleted);

    // Prepare snapshot data for TiDB
    const snapshotData: WeeklySnapshotData = {
      convex_game_id: args.gameId,
      player_name: game.playerName || "Anonymous",
      persona_id: game.personaId,
      week: args.weekCompleted,
      money: game.money,
      credit_score: game.creditScore,
      health: game.health,
      stress: game.stress,
      objectives_completed: checkObjectives(game.weeklyObjectives),
      is_game_over: game.isGameOver,
      // ... more fields
    };

    // Fire-and-forget sync to TiDB via API route
    await fetch(`${baseUrl}/api/analytics/sync`, {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
        "X-Internal-Key": process.env.INTERNAL_API_KEY,
      },
      body: JSON.stringify({
        syncType: "weekly",
        weeklySnapshot: snapshotData,
        decisions: decisionsData,
      }),
    });

    return { success: true };
  },
});

ここで重要なのは、fetchの呼び出しがTiDBへの書き込み完了を待機しない点です。リクエストを送信したらすぐにプレイヤーへ成功レスポンスを返すことで、UIのレスポンス性能を維持しつつ、分析データが最終的にTiDBへと届くようにしています。

分析クエリ：現実の問いに答える

私たちは、重要な調査課題に対する答えを導き出すための包括的な分析レイヤーを構築しました。例えば、「プレイヤーが失敗する原因は何なのか、そしてそれはいつ起こるのか？」といった問いを明らかにしたいと考えたのです。

export async function getFailurePatterns(): Promise<FailurePattern[]> {
  return query(
    `SELECT
       failure_reason,
       COUNT(*) as count,
       persona_id,
       AVG(weeks_completed) as avg_week_failed
     FROM completed_games
     WHERE failure_reason IS NOT NULL
     GROUP BY failure_reason, persona_id
     ORDER BY count DESC`
  );
}

// Example insight: "Fresh graduates fail most often in week 2
// due to 'health_crisis' - choosing instant noodles over vegetables"

このクエリは、興味深い事実を明らかにしました。新卒者 (persona_id “graduate”) は、決まって2週目に健康の問題によって失敗しているのです。彼らは栄養よりも貯金を優先してしまい、その結果、医療費の請求が発生して蓄えをすべて失ってしまいます。このインサイトは、ゲームの難易度バランスを調整する上で非常に役立ちました。

もう一つの重要な指標は、生存ファネルです。各週を乗り越えられたプレイヤーは、一体どれくらいいるのでしょうか？

export async function getSurvivalFunnel(): Promise<Array<{
  week: number;
  started: number;
  survived: number;
  survival_rate: number;
}>> {
  const weekCounts = await query<{ week: number; count: number }>(
    `SELECT week, COUNT(DISTINCT convex_game_id) as count
     FROM weekly_snapshots
     GROUP BY week
     ORDER BY week`
  );

  // Calculate week-over-week retention
  return weekCounts.map((wc, index) => ({
    week: wc.week,
    started: wc.count,
    survived: wc.count - (endMap.get(wc.week) || 0),
    survival_rate: Math.round(survivalRate),
  }));
}

私たちは、第2週目の離脱率が35%に達していることを発見しました。これはゲーム内で最も急激な下落です。このデータは、難易度の上昇曲線が過酷すぎる可能性を示唆していましたが、同時に現実世界の経済的苦境も反映しています。新しい仕事を始めてから (最初の給与が支払われる前の) 2ヶ月目は、しばしば最も困難な時期になるからです。

課題：挫折しかけた瞬間 (そして乗り越えた日々)

ここからが正念場でした。バグが発生し、機能が壊れ、プレッシャーが重くのしかかります。

複数セッションのバグ：最大の悪夢は、ゲームが個別のセッションではなく、1つのグローバルな状態を同期してしまったことでした。一人のプレイヤーが選択を行うと、全員の画面にそれが反映されてしまうのです。最終的にConvexのサブスクリプション処理に原因があることを突き止めました。午前3時に修正できた時の安堵感は、言葉では言い表せません。

「おい、なんで俺のキャラがいきなり破産してるんだ？ 何もしてないぞ！」

「…すまん、それ俺だ。タブを間違えた。」

TiDBのSSL接続：TiDB Cloudへの安全なSSL接続の確立には、細心の注意が必要でした。コネクションプーリングの効率を維持しながら、最小バージョンTLS 1.2の使用と適切な証明書の検証を確実に行う必要がありました。

べき等な同期：Fire-and-forgetパターンの同期では、重複して送信されるデータに適切に対処する必要があります。ON DUPLICATE KEY UPDATEと複合ユニークキー (game_id + week) を使用することで、データの整合性を確保しました。

文化的な真正性：Manglish (マレーシアの英語) を、無理やりではなく自然に使うことにもこだわりました。Pak Aliの「常連さんだから、ちょっとだけ負けとくよ、ラー (lah)」といった台詞が、形だけではなく本物らしく感じられるようにしました。

私たちはクアラルンプールのAirbnbで作業を続けました。目の前にはKLタワーがくっきりとそびえ立ち、遠くにはペトロナスツインタワーが輝いていました。徹夜作業をするには、これ以上ないモチベーションでした。

結果：バイラルミームからハッカソン優勝へ

最後の致命的なバグを修正し (そして「味」としていくつかの軽微なバグは残したまま)、午前5時、ついに公開と提出ボタンを押しました。

目は燃えるように熱く、脳は疲れ果てていましたが、どういうわけか満足感に包まれていました。私たちは形にしたのです。本物のゲームを。わずか1日で。たった一つのミームから。

「よし、これで終わりだ。勝てれば最高だけど、そうでなくても、少なくとも俺たちには完成したゲームがある」

2時間だけ泥のように眠り、フラフラになりながら、かすかな希望を胸に結果発表が行われるモナッシュ大学へと向かいました。

数字で見る私たちのゲーム：

会場に戻ると、強烈な疲労が襲ってきました。Rimbaにいたっては、あまりの疲れに、あろうことか皆の目の前で口を大きく開けたまま自分の席で爆睡していました。彼らしいです。

Cursorトラックの結果が発表されました。私たちは勝てませんでした。まあ、仕方がありません。その日はトロフィーを手にすることなく帰路につきましたが、それよりも素晴らしいものを手に入れていました。自分たちが誇りに思えるゲーム、そして、それをさらに拡張していくための計画です。

え、本当に受賞したの？

ハッカソンから1週間後、ついに最終結果が発表されました。その時の私たちは、正直もう何も期待していませんでした。

しかし、自分たちの名前を見つけたのです。それも、2つも

優勝：BEST USE OF TIDB

準優勝：BYTE IN TRACK

ただゲームを作りたかっただけの、3人のゲーム好き。一つのミームから始まったミッション。そして、あらゆる予想に反して、私たちは2つの賞を勝ち取ることができたのです。

ゲームをプレイする： B40 Life Simulator

データベースをそれぞれのワークロードに適合させたことで、このデュアルデータベース・アーキテクチャは真価を発揮しました。Convexが低レイテンシで高頻度の書き込みを処理し、TiDBが全セッションにわたる分析クエリを担います。そしてFire-and-forget同期が、両者を密結合させることなくデータの整合性を保っています。

単なるトロフィー以上に、私たちはB40 Life Simulatorが社会に変化をもたらすと心から信じています。TiDBを通じて収集される分析データは、単なる数字ではありません。それは、人々が極限のプレッシャーの中でどのような経済的決断を下すのかを解き明かすための、貴重なインサイトなのです。

ぜひご自身で体験してください

ハッカソンで制作したプロトタイプは、現在公開中で実際にプレイ可能です。B40の苦境を自ら体験し、不可能な選択を迫られる中で、あなたがどれだけ長く生き残れるか挑戦してみてください。次のステップとして、モバイル向けにUnityでの再構築を計画しています。どなたでも大歓迎ですので、ぜひお試しください！

技術スタック：Next.js 15, React 19, TypeScript, Convex, TiDB Cloud Starter, Claude AI, PixiJS, Tailwind CSS 4, Framer Motion, shadcn/ui, Cursor, Vercel

The post Fire-and-Forgetパターン：TiDB CloudとConvexによるゲーム分析のスケーリング appeared first on TiDB.

私は早口なのですが、既存のツールはどれも画一的で、まるで味気ないJIRAチケットのように事務的に扱ってきます。そこでこの問題を解決するため、Chrome拡張の開発に取り組み、Speak Itを作りました。Speak Itは、ユーザーの声そのものを記録することなく、ユーザーの文体や話し方のスタイルを学習する音声認識アプリです。

プライバシーを最優先するAIを活用し、本システムは音声の「フィンガープリント」をマッピングします。具体的には、文の丁寧さや長さといった要素に着目し、話した内容そのものを保存することはありません。TiDBベクトル検索技術により、データが一切収集されないことを保証することで、最も厳格な企業の法務チームでさえも満足させる、パーソナライズされたフォーマットを提供します。

このブログでは、SlackからGmailまであらゆるプラットフォームに合わせてあなたの声を変換する書き起こしツールの構築方法を詳しく解説します。また技術スタック全体に加え、実際のメッセージを一切保存せずに個人の文章スタイルを学習する「統計的フィンガープリント」のロジックについてもご紹介します。

技術スタック：TiDB、Claude、Deepgram

使用している技術とその理由：

• Chrome拡張機能：このアプリは特定のプラットフォーム専用ではなく、あらゆるウェブサイトで動作する必要がありました。Gmail、Slack、Notion、Twitterなどあらゆる場所にマイクボタンを挿入する唯一の手段がブラウザ拡張機能でした。
• Web Speech API + Deepgram：ChromeとEdgeは無料でWeb Speech APIをサポートしています。非対応ブラウザ (Arc、Safari、Firefox) についてはDeepgramのストリーミングAPIにフォールバックします。これにより、幅広い互換性を維持しつつ、大多数のユーザーに対してコストを抑えることができます。
• TiDB Cloud Starter：通常の業務データ用とベクトルデータ用に、2つのデータベースを別々に運用したくありませんでした。幸いTiDBはベクトルデータと業務データを1つのデータベースで扱うことが可能です。さらにMySQL互換のため、既存の知識をそのまま使えるうえ、アイドル時はゼロまでスケールするため、未使用のリソースにコストをかけずにすみます。
• Claude Sonnet 4：フォーマットエンジンとしてClaude Sonnet 4を採用しました。生の文字起こしデータを文脈やスタイル指示に基づき再構成します。Sonnetは制約事項を非常によく守りつつ、過剰な書き換えを行わない点が優れており、この文脈では極めて重要な特性です。
• OpenAI Embeddings：埋め込みにはOpenAIのtext-embedding-3-smallを使用します。文章スタイルのサンプルをベクトル表現に変換し、スタイルの分類に必要な類似性マッチングを支えています。

アーキテクチャ：コンテンツを保存しないパーソナライズ

以下は、本システムにおけるデータの流れです。

[ユーザーの発声] 
      ↓
[Deepgram / Web Speech API]
      ↓
[文字起こしテキスト]
      ↓
[コンテキスト検出：Gmail? Slack? Twitter?]
      ↓
[TiDBからスタイルプロファイルの取得]
      ↓
[Claude がスタイルとコンテキストを利用して内容を変換]
      ↓
[ユーザーが提案を受け入れ、または拒否]
      ↓
[受け入れられたテキストから統計情報を抽出]
      ↓
[TiDBにあるスタイルプロファイルを更新]
      ↓
[類似性マッチングのために埋め込みを生成]

重要なアーキテクチャ上の決定は、内容ではなく統計情報を保存することでした。ここでは、スタイルプロファイルに含まれる項目を示します：

ここにある内容はどれも、メッセージの本質ではありません。これはあなたが何を書き記すかではなく、あなたのメッセージのフィンガープリントを捉えたものです。

企業の顧客は、内部通信を保存するようなツールには一切手を出しません。この制約が、あらゆる設計判断の指針となりました。

Gmail、Slack、Xにおけるリアルタイムな文脈検知の実装

プラットフォームによって作法は異なります。例えばLinkedInはXに比べてずっとフォーマルな傾向にあります。またSlackのメッセージはメールのような堅い文章であっては違和感が生じます。そこで私が最初に行ったのは、ユーザーがどこで入力するかを把握することでした。

コンテキスト検出

この拡張機能は、現在のURLを既知のパターンと照合し、さらにプラットフォーム固有のDOMセレクタを検索することで、アクティブなテキストフィールドを特定します：

const CONTEXT_PATTERNS = {
  email: {
    urls: [/mail\.google\.com/, /outlook\.live\.com/, /outlook\.office\.com/],
    selectors: [
      '[aria-label="Message Body"]',
      '[role="textbox"][aria-multiline="true"]',
      'div[contenteditable="true"][g_editable="true"]',
    ],
  },
  slack: {
    urls: [/\.slack\.com/],
    selectors: [
      '[data-qa="message_input"]',
      '.ql-editor',
      '[contenteditable="true"][data-message-input]',
    ],
  },
  twitter: {
    urls: [/twitter\.com/, /x\.com/],
    selectors: [
      '[data-testid="tweetTextarea_0"]',
      '[role="textbox"][data-testid]',
    ],
  },
  // ... 20+ contexts total
};

この検出処理は、あらゆるフォーマット処理が行われる前に実行されます。検出された文脈によって、Claudeがどのようにテキストを書式設定するか、およびプラットフォームごとに最適化されたどのような指示をClaudeに与えるかが決定されます。

例えば、X (旧Twitter) のフォーマットでは、簡潔さを保ち、フォーマルな挨拶は削除されます。一方、メール向けのフォーマットでは、署名部分を保持し、段落分けを追加します。Slackはこれらの中間的な位置付けとなります。

TiDBにおけるプライバシー重視のスタイルプロファイル用のスキーマの設計

スタイルプロファイルはTiDBに存在します。テーブル構造は以下の通りです：

CREATE TABLE user_style_profiles (
user_id VARCHAR(255) PRIMARY KEY,
avg_sentence_length FLOAT DEFAULT 12,
formality_score FLOAT DEFAULT 0.5,
uses_contractions BOOLEAN DEFAULT TRUE,
top_phrases JSON,
greetings JSON,
signoffs JSON,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

見ての通り、message_content (メッセージ本文) のカラムは存在しません。何を書いたかではなく、どのように書くかを保存しているのです。

Formality_score (フォーマルさ) は0 (非常にカジュアル) から1 (非常にフォーマル) までの範囲で設定されています。文の長さ、句読点のパターン、語彙選択といった指標から算出されます。例えば、「やあ！ちょっと質問なんだけど、それ送れる？」と書く人は、「いつもお世話になっております。資料の件で追ってご連絡いたしました。」と書く人よりもスコアが低くなります。

プロファイルの取得は、次のようなシンプルなクエリで行われます：

async function getUserStyleProfile(userId: string): Promise<StyleProfile | null> {
  const [rows] = await connection.execute<RowDataPacket[]>(
    `SELECT avg_sentence_length, formality_score, uses_contractions,
            top_phrases, greetings, signoffs
     FROM user_style_profiles WHERE user_id = ?`,
    [userId]
  );
  
  if (rows.length === 0) return null;
  
  const row = rows[0];
  return {
    avg_sentence_length: row.avg_sentence_length || 12,
    formality_score: row.formality_score || 0.5,
    uses_contractions: row.uses_contractions !== false,
    top_phrases: row.top_phrases ? JSON.parse(row.top_phrases) : [],
    greetings: row.greetings ? JSON.parse(row.greetings) : ["Hey"],
    signoffs: row.signoffs ? JSON.parse(row.signoffs) : ["Thanks"],
  };
}

新規ユーザーには適切なデフォルト設定が適用されます。フォーマット提案を承認するか却下するかによって、プロファイルは更新されていきます。

プロンプトエンジニアリング：スタイル統計データをClaudeへの指示に変換する

スタイルプロファイルはプロンプト指示文へと変換されます。Claudeは過去の履歴を参照しているわけではなく、与えられた制約事項として解釈しています。

function buildStylePrompt(profile: StyleProfile | null, context: string): string {
  if (!profile) {
    return `Format this transcript for ${context}. Keep it natural and conversational.`;
  }

  const formality = profile.formality_score > 0.7 ? "formal" :
                    profile.formality_score < 0.3 ? "casual" : "balanced";

  const contractionNote = profile.uses_contractions
    ? "Use contractions naturally (don't, won't, can't)."
    : "Minimize contractions for a more formal tone.";

  const greetingNote = profile.greetings.length > 0
    ? `Preferred greetings: ${profile.greetings.slice(0, 3).join(", ")}`
    : "";

  const signoffNote = profile.signoffs.length > 0
    ? `Preferred sign-offs: ${profile.signoffs.slice(0, 3).join(", ")}`
    : "";

  return `Format this transcript for ${context}.

User's writing style:
- Tone: ${formality}
- Average sentence length: ~${Math.round(profile.avg_sentence_length)} words
- ${contractionNote}
${greetingNote ? `- ${greetingNote}` : ""}
${signoffNote ? `- ${signoffNote}` : ""}

Rules:
1. ONLY add punctuation and paragraph breaks
2. Remove filler words: um, uh, like, basically, you know
3. Keep EVERY other word exactly as they said it
4. Do NOT rewrite, rephrase, or "clean up" their language`;
}

文末にあるルールは極めて重要です。これらがなければ、Claudeはユーザーの言葉を「改善」してしまいます。しかし人々は自分の声を別ものに置き換えられたいのではなく、ただ「整えて」ほしいだけなのです。この両者には、明確な違いがあります。

各コンテキストには、それぞれのプラットフォーム固有の指示も追加されます：

function getContextInstructions(context: string): string {
  switch (context) {
    case "email":
      return `Email format:
- Add punctuation and paragraph breaks
- Keep their exact words
- Add sign-off if missing`;

    case "slack":
      return `Slack format:
- Keep it brief and casual
- No formal greetings needed
- Okay to use shorter sentences`;

    case "twitter":
      return `Twitter/X format:
- Add punctuation only
- Keep their exact words
- If over 280 characters, don't trim`;
    
    // ... more contexts
  }
}

スタイルプロファイルとコンテキストに応じた指示の組み合わせにより、Claudeは余計な改変をすることなく、適切に文章を整形するために必要なガイダンスを得ることができるのです。

学習ループ：加重平均を用いたスタイルの適応

ここがまだ試行錯誤を重ねている部分です。

ユーザーがフォーマットの提案を承認または拒否した際、プロファイルを更新したいと考えています。最初に考えた単純なアプローチは、新しいサンプルデータで統計値をそのまま上書きしてしまうことでした。

しかし、それは誤りでした。

数ヶ月間アプリを使用し、数百件の承認済みフォーマットがプロファイルに反映されているユーザーの場合、たった一つの新しいサンプルによって統計が劇的に変動すべきではありません。プロファイルが成熟するにつれ、新しいサンプルの影響力は小さくしていく必要があります。

その解決策が加重平均です。新しいサンプルを移動平均に対して一定の割合だけ反映するが、その割合は段階的に減少していく手法をとっています。

function updateStyleProfile(
  existingProfile: StyleProfile,
  newStats: TextStats,
  sampleCount: number
): StyleProfile {
  // Weight decreases as sample count increases
  // First sample: 100% weight. 100th sample: ~1% weight.
  const weight = 1 / (sampleCount + 1);
  
  return {
    avg_sentence_length: 
      existingProfile.avg_sentence_length * (1 - weight) + 
      newStats.avg_sentence_length * weight,
    formality_score:
      existingProfile.formality_score * (1 - weight) +
      calculateFormality(newStats) * weight,
    // ... other fields
  };
}

フレーズ、挨拶、そして結びの言葉については、単に使われたかだけではなく、出現頻度をトラッキングしています。一度しか使わない挨拶と頻繁に使う挨拶を同等に扱うべきではないからです。

また、承認されたフォーマットに対して埋め込みベクトルも生成しています：

const embeddingResponse = await openai.embeddings.create({
  model: "text-embedding-3-small",
  input: `Sentence length: ${stats.avg_sentence_length}. ` +
         `Formality: ${stats.formality_score}. ` +
         `Context: ${context}. ` +
         `Contractions: ${stats.uses_contractions}`,
});
const styleEmbedding = embeddingResponse.data[0].embedding;

ここでの考え方は、似たような文章スタイルをまとめることにあります。自分と似た書き方をするユーザーがいれば、その人のフォーマット設定は自分にとっても好ましいものである可能性が高いからです。しかし正直に言うと、この機能はまだ完全には実装されていません。埋め込みの生成までは行っていますが、これを使ってレコメンデーションのためのクエリを発行するまでには至っていないのが現状です。

これが次のイテレーションの課題です。

結論：クロスプラットフォーム対応・プライバシー第一の音声認識アプリ

現在の機能：

• 20以上のプラットフォームで音声認識を実現 (Gmail、Slack、Notion、Twitter、LinkedIn、GitHubなど)
• 自動文脈検出：手動切り替え不要
• 出力フォーマットに影響するスタイルプロファイル
• 統計情報のみ保存、内容を保存しないプライバシー最優先設計

今後の予定：

• スタイル分類のためのベクトル類似性 (「あなたと似た書き方のユーザーは…を好みます」)
• プロファイル更新のための洗練されたフィードバックループ
• 英語以外の多言語サポート
• 対応ブラウザの拡大 (Firefoxアドオン)

無料版のコードはこちらから入手可能です。

公開されたソースと導入方法：独自の文字起こしツールを構築する

このアプリ開発から得た主な知見：パーソナライズに監視は不要です。コンテンツの内容を学習することなく、パターンは学習できます。統計的フィンガープリントは、実際のコンテンツをデータベースに一切保存せずに、動作をカスタマイズするのに十分なシグナルを得られます。

プライバシーが絶対条件となる企業向けユースケースでも、このアプローチならコンテンツベース学習では閉ざされた扉を開くことができます。

類似のものを構築したい場合、TiDB Cloudを使えば十分に試すことができます。リレーショナルテーブル (ユーザープロフィール用) とベクトル検索 (スタイル類似性用) を単一データベースの組み合わせは、アーキテクチャを劇的にシンプルにしてくれました。

The post 音声データを保存せずに、話し方を学習する音声認識アプリの開発方法 appeared first on TiDB.

データベースのアップグレードは、往々にして「パフォーマンスへの不安」の種となります。入念なテストを重ねても、クリーンなステージング環境と、SQLパラメータの変動、突発的な同時実行、複雑な実行コンテキストが絡み合う本番環境の混沌とした現実との間にはギャップがあります。このギャップが、アップグレード後に予期せぬリグレッションを招く原因となるのです。

TiDB Cloudのトラフィック・リプレイは、現在一般公開に向けて開発中の社内ツールで、このギャップを埋めるものです。実行計画のリグレッションやパフォーマンスの「急落」をユーザーに影響が出る前に捉えることで、確固たる自信を持ってアップグレードを実行できるようになります。

主要用語

• CPS (Commands Per Second)：1秒間に実行されるSQLコマンドの数。リプレイの再現性は、テスト環境のCPSが本番環境の推移にどれだけ密接に一致するかで測定されます。
• プリペアドステートメントとプランキャッシュ：ステートメントIDを維持し、プリペアドステートメントを1対1でシミュレートすることで、プランキャッシュの効率が正確に再現されることを保証します。
• 99%の精度：CPSの推移とクエリ構成において、本番トラフィックとリプレイ・トラフィックが統計的に相関しています。

従来のデータベーステストにおける課題

一般的な「合成ベンチマーク (クライアント側でのシミュレーション)」は、実際の本番環境の負荷を反映できないことが多々あります。トラフィック・リプレイは、以下のような具体的な「再現性のギャップ」を解消します。

TiDB Cloudトラフィック・リプレイをいつ使用すべきか？

アプリケーションが以下のいずれかの基準に該当する場合、メンテナンス・サイクルにおいてトラフィック・リプレイの実施を必須ステップとすべきです。

• メジャーバージョンのアップグレード：アーキテクチャが大きく変更される移行 (例：TiDB 6.x から 8.x への移行)。
• オプティマイザの変更：オプティマイザの強化など、新しい機能を有効にする場合。
• P99/P999レイテンシへの高い敏感度：わずか5msのリグレッションも許容されない、低レイテンシが極めて重要なアプリケーション。
• ワークロードの激しい変動：トラフィックの突発的な急増が頻繁に発生するシステムや、複雑なクエリパターンを持つシステム。

TiDB Cloudトラフィック・リプレイの仕組み

TiDB Cloudトラフィック・リプレイは単なるツールではなく、統合された運用ワークフローです。

1. ストレージとセキュリティ

まず、ウェブコンソールから監査ログを有効にする必要があります。これにより、リクエストがオブジェクトストレージ (S3など) に直接記録されます。

• 暗号化：監査ログは暗号化されたS3バケットに保存されます。また、データ転送時はTLSによって暗号化されます。
• 機密データの除外：監査ログには元のSQLステートメントが含まれます。高い再現性を確保するため、リプレイ中にデータはマスクされません。ただし、ユーザーはソース側でデータプライバシーを管理できます。記録フェーズにおいて、特定のデータベース、テーブル、または機密性の高いSQLタイプを選択的に除外することが可能です。
• 保持期間：リプレイしたい「ピークトラフィック」期間がログの保持期間に含まれていることを確認してください。

2. 運用の流れ

• 環境のセットアップ：リプレイを開始する前にテストクラスタを作成し、TiDB CloudのBRツールを使用して本番データをこのテストクラスタに復元します (通常、数時間で完了します)。テストクラスタのサイズ選択はトレードオフとなります。
  • 1:1クラスタ：最高の再現性を得るため (P99レイテンシやリソース競合の検証に適しています)。
  • スケールダウンしたクラスタ：コスト効率の良い傾向テストのため。※絶対的なレイテンシやホットスポットの挙動は異なる可能性があることに注意してください。
• 入力：バックアップスナップショットのタイムスタンプをリプレイの開始点として選択します。十分なデータが集まった段階で、いつでも手動でセッションを終了できます。
• 実行：リプレイツールはそのタイムスタンプから監査ログの読み取りを開始し、それらをSQLステートメントにパースしてテストクラスタ上で実行します。エンジンは本番環境のコネクションIDをテスト環境に1対1でマッピングし、トランザクションの状態を維持します。

3. 出力

リプレイ完了後、TiDB Cloudは以下の項目に基づき、クラスタの健全性を効率的に比較するためのレポートを生成します。

• 主要メトリクスの差分：CPS、レイテンシ、およびCPU使用率の変化を表示します。
• スロークエリの差分：本番環境では高速だったにもかかわらず、新バージョンで低速化したクエリを特定します。
• トップSQLの差分：新バージョンにおいて、より多くのCPUリソースを消費しているクエリを表示します。

以下のチャートは、あるお客様がアップグレード前に実施したトラフィック・リプレイにおける、CPS、各コンポーネントのCPU使用率、およびレイテンシの結果を比較したものです。

チャートには以下の内容が示されています。

• CPSの重なり：CPSの誤差は1%以内であり、比較曲線はほぼ完全に重なっています。これはワークロードの再現性がほぼ完璧であることを示しており、実際のビジネス負荷に基づいたテストが行われていることを意味します。
• P999レイテンシ：最大P999レイテンシが20%以上減少しています。アップグレードは複雑なエッジケースのクエリに影響を与えることが多いため、このテールレイテンシの改善は非常に重要です。
• CPU使用率：TiDB、TiKV、およびTiFlashのCPU使用率が10%以上減少しています。これにより、明確なパフォーマンスの向上、あるいはコスト削減の機会を確認できたことになります。

次に、スロークエリおよびリソース消費の激しいSQLステートメントの比較を見てみましょう。

スロークエリの総数が大幅に減少しており、実行計画が最適化されたSQLステートメントの数が、リグレッションを示したものを大きく上回っていることは明らかです。特定されたリグレッションについては、詳細をダウンロードして実行計画を固定することで、アップグレード後のビジネスへの影響を未然に防ぐことができます。

リグレッションへの対応策：問題が発生した場合は？

リグレッションが見つかることは、むしろ「勝利」を意味します。それは、問題が表面化する前に事前に察知できたということだからです。以下の手順に従って対応してください。

1. 特定：「スロークエリ」セクションから、特定のSQL Digestを特定します。
2. 確認：実行計画を比較します。統計情報の乖離か、あるいはオプティマイザの変更によるものかを確認してください。
3. 修正：SQLプランバインディングを使用して、既知の「良好な」実行計画を固定するか、統計情報を更新します。
4. 検証：リプレイセッションを再実行し、本番環境の負荷条件下で修正が有効であることを確認します。

留意すべき制限事項

ユーザーは、リプレイプロセスに内在する以下の技術的な制約を認識しておく必要があります。

• コネクション間の時間的乖離：独立したセッション間における絶対的な時間的整合性は変動する場合があり、本番環境での全体的な実行順序とは異なる順序になる可能性があります。
• DML実行結果の相違：DMLステートメントの結果が本番環境とは異なる場合があります。例えば、テーブルでオートインクリメント列を使用している場合、同時実行のタイミングや環境変数の違いにより、リプレイ環境で生成されるIDが本番環境と一致しない可能性があります。

まとめ

ワークロード再現において99%の精度を達成することで、TiDB Cloudのトラフィック・リプレイは、アップグレードを「リスクを伴うイベント」から「検証済みのルーチン」へと変貌させます。

次回のアップグレードを安全に行う準備はできていますか？直近のピーク期間から30分間のトラフィックセッションを実行し、P999レイテンシとTop SQLのCPU時間を比較してみましょう。

The post シームレスなTiDB Cloudアップグレード：トラフィック・リプレイによる本番ワークロードの複製 appeared first on TiDB.

高性能なデータベース環境におけるメモリ管理は、単に十分なサイズのRAMを確保するだけでなく、そのRAMがどのように構成されているかが重要です。SREやDBAにとって、Linuxカーネルのメモリ管理の微妙な違いを理解することは、システムの安定稼働と予測不能なテールレイテンシが発生するかの分かれ目となります。

このブログでは、Linuxにおけるメモリフラグメンテーションの核となるメカニズムを紐解きます。バディアロケータの内部構造や、その主要な防御策であるページマイグレーションタイプについて深く掘り下げるとともに、Transparent Huge Pages (THP) とhugetlbの間にある、パフォーマンス上の重要なトレードオフを明確にします。最後に、/proc/buddyinfoやftraceを活用した具体的な診断ワークフローを紹介します。これにより、TiDBのような本番環境において、メモリコンパクション がテールレイテンシにどのような影響を与えているかを定量化する手法を解説します。

60秒でわかるメモリフラグメンテーション

Linuxカーネルの文脈において、メモリフラグメンテーションとは物理RAMがどのように割り当てられ、使用されているかを指す概念です。これはディスクのデフラグメンテーションとは異なり、特にRAMとカーネルメモリに特有の問題です。中核となる制約は連続メモリ割り当てにあります。カーネルを効率的に動作させるには、メモリブロックが物理的に隣接している必要があることが多いためです。

これらの連続したブロックが分断されると、たとえ数ギガバイトの「空き」メモリがあったとしても、カーネルは必要とするサイズの単一の連続ブロックを見つけられず、その結果として性能低下を引き起こす可能性があります。

内部フラグメンテーションと外部フラグメンテーション (Linuxにおける現状)

パフォーマンスの問題を診断するためには、まずフラグメンテーションの2つの種類を区別する必要があります：

• 内部フラグメンテーション：これは、カーネルが実際に要求された量よりも多くのメモリを割り当てた場合に発生します。割り当てられたブロックの内部に「無駄な」領域が存在しますが、その領域は他の用途に使用することができません。
• 外部メモリフラグメンテーション：これはシステム性能にとって最も重要な問題です。システム内に空きメモリが存在しているにもかかわらず、それらが小さく非連続な「穴」として分散している状態を指します。その結果、トータルの空きメモリ量は十分であっても、大きな連続ブロックの要求は失敗することになります。

なぜ仮想メモリだけでは不十分なのか (カーネルとDMAの制約)

物理的に連続していないページを連続した仮想アドレス空間にマッピングできる仮想メモリの時代において、なぜフラグメンテーションが問題になるのか疑問に思うかもしれません。仮想的な連続性はアプリケーションにとっては有用ですが、カーネルやハードウェアにはより厳しい要件が存在します：

• カーネルのリニアマッピング：特定のカーネルサブシステムは、性能の観点からリニアマッピングに依存しており、物理的に連続したメモリを必要とします。
• デバイスI / OとDMA：Direct Memory Access (DMA) により、ハードウェアデバイスはCPUを介さずにデータを転送できます。現代のデバイスの中には「スキャッタ・ギャザーDMA」をサポートするものもありますが、多くの旧式デバイスや特殊なデバイスは、依然として物理的に連続した大きなバッファを必要とします。

バディアロケータ：Linuxのページオーダーがどのようにフラグメンテーションを生むのか

Linuxは、物理メモリをバディアロケータを用いて管理しています。これはメモリを「オーダー (Order)」単位で階層化する仕組みで、オーダー0は単一ページ (通常4KB)、オーダー1は2ページ (8KB) というように、オーダーが1上がるごとにサイズが倍増していきます。

図1. Linuxのバディアロケータにおけるブロックの分割と結合

高いオーダーの割り当て、つまり大きな連続メモリブロックが要求されると、アロケータはより大きなブロックを分割して「バディ(相棒)」を生成します。逆に、メモリが解放されると、それらは再び結合して元の大きなブロックに戻ります。このとき、小さく移動不可能な割り当てがメモリマップ全体に散在していると、高いオーダーのブロックが不足するようになり、バディ同士が結合できなくなります。その結果としてフラグメンテーションが発生します。

スラブアロケータ (SLUB / SLAB) の役割と位置付け

バディアロケータが巨大なページ単位のメモリブロックを管理する一方で、スラブアロケータ (現代のカーネルでは主にSLUBが採用されています) は、タスク記述子やiノードといった小規模なオブジェクトを管理します。スラブアロケータは最終的にバディアロケータからページを消費します。スラブの増加が大きい場合、連続したページブロックへの圧力が高まり、外部フラグメンテーションの原因となることがあります。

ページマイグレーションとマイグレーションタイプ：Linuxにおけるフラグメンテーション対策の第一歩

フラグメンテーションに対抗するため、Linuxカーネルはメモリページをマイグレーションタイプごとに分類してします。「移動不可能なページ」が本来コンパクト化可能なブロックを汚染するのを防いでいます：

• MIGRATE_UNMOVABLE：カーネルによって割り当てられたページなど、移動が不可能なページ。
• MIGRATE_MOVABLE：ユーザ空間のアプリケーションで使用される、移動可能なページ。
• MIGRATE_RECLAIMABLE：ファイルキャッシュのように、破棄して解放することが可能なページ。

カーネルが優先されるマイグレーションタイプから要求を満たせない場合、「フォールバック」割り当てを実行します。このフォールバック動作が頻発している状態は、外部メモリフラグメンテーションが深刻化している明確なシグナルとなります。

Huge Pages, hugetlb, および Transparent Huge Pages (THP)：断片化が「コスト」に変わる瞬間

TiDBのような分散SQLデータベースは、ページテーブルの参照オーバーヘッドを削減できるHuge Pagesの恩恵を大きく受けます。しかし、Huge Pagesは広大な連続領域 (2MBや1GBなど) を必要とするため、メモリの断片化 (フラグメンテーション) による影響をより顕著に受けることになります。

データベースでTHPを無効化すべきタイミング (およびその代替案)

Transparent Huge Pages (THP) はメモリ管理の簡素化を目的としていますが、データベースにおいては深刻なレイテンシのスパイクを引き起こす原因となります。カーネルのバックグラウンドスレッドである「khugepaged」が連続したメモリ領域を見つけられずにいるすると、強引なコンパクションが実行され、結果として処理の停止が発生します。

本番環境のデータベースにおいては、THPを無効化し、代わりに明示的な巨大ページ (hugetlb) を使用するのが標準的な運用のデフォルトです。これにより、起動時にメモリ領域が確実に確保され、予測可能なパフォーマンスが担保されます。詳細については、データベースにおけるTransparent Huge Pages (THP) ガイドを参照してください。

メモリコンパクション：Linuxが連続した空き領域を再構築する仕組み

メモリコンパクションとは、カーネルが移動可能なページを移動させて、より大きな連続した空き領域を作るプロセスのことです。

必須の処理ではありますが、コンパクションは両刃の剣にもなり得ます。
「直接コンパクション」は、プロセスが割り当て要求の際にカーネルによるメモリのデフラグが終わるまで待たされる場合に発生し、大きなレイテンシスパイクやパフォーマンスの急降下を引き起こすことがあります。

メモリフラグメンテーションの検出方法 (重要なコマンド)

フラグメンテーションを診断するには、freeやtopのような基本的なツールだけでは不十分です。

• /proc/buddyinfo：各メモリゾーンでのオーダーごとの利用可能ブロック数を表示。オーダー0は多いのにオーダー10が少ない場合、システムは深刻なフラグメント化が発生しいます。
• /proc/pagetypeinfo：マイグレーションタイプの分布や、フォールバックがどれくらい発生しているかを確認できます。
• Fragmentation Index：一部のカーネルでは、/sysを通じてフラグメンテーションの深刻度を定量化できます。

外部フラグメンテーションイベントをftraceで測定 (ステップバイステップ)

リアルタイムでフラグメンテーションイベントを取得するには、ftraceを利用します：

1. イベントを有効化： echo 1 > /sys/kernel/debug/tracing/events/kmem/mm_page_alloc_extfrag/enable
2. データを収集：cat /sys/kernel/debug/tracing/trace_pipe > frag_log.txt
3. 結果の解釈：Look for “fallback” events. An example event line might look like this:
   
   mm_page_alloc_extfrag: page=0x12345 pfn=74565 alloc_order=9 fallback_order=0
   
4. awkで解析：awk '/fallback_order/ {print $NF}' frag_log.txt | sort | uniq -c
5. トレースを無効化： echo 0 > /sys/kernel/debug/tracing/events/kmem/mm_page_alloc_extfrag/enable

本番データベースサーバー向け性能低下の緩和チェックリスト

データベース向けに健全なLinux環境を維持するため、以下を確認しましょう：

• [ ] 高いオーダー依存の抑制：実行時に巨大な連続ブロックを必要とするようなカーネルレベルの設定を避ける。
• [ ] Huge Page戦略の策定：THPとhugetlbのどちらを使用するか意図的に選択する。データベースでは通常、明示的なHuge Pages (hugetlb) が好まれます。
• [ ] パフォーマンス・ベースラインの確立：コンパクションやフォールバックイベントのベースラインを策定し、急激なスパイクを検知・アラートできるようにする。
• [ ] システム挙動のトレース：ftrace などのツールを使用して、本番環境への影響を最小限に抑えつつLinuxシステムの挙動を追跡する。

TiDBのワークロードにおける重要性 (予測可能なテールレイテンシ)

TiDBのような分散データベースでは、一貫したパフォーマンスがサービスレベル目標 (SLO) の達成に不可欠です。
メモリフラグメンテーションがバックグラウンドのコンパクションやダイレクトリクレームを引き起こすと、それはそのままデータベースのテールレイテンシに直結します。
カーネルレベルのボトルネックを理解し対策することで、負荷が高い状況でも予測可能なパフォーマンスを提供できるデプロイ環境を安定して維持できます。

TiDBが高性能ワークロードをどのように処理するか、ご覧になりませんか？ 手動でのシャーディングなしでMySQLワークロードをモダナイズしたり、Linuxカーネルのメモリフラグメンテーションについてさらに深く学べる「続き (パートII)」で、より高度な技術的インサイトを得ることができます。

FAQ：Linuxにおけるメモリフラグメンテーション (一問一答)

RAMは断片化されることがありますか？

はい。RAMにはハードディスクのような物理的な駆動部はありませんが、ここでの「フラグメンテーション」とは、Linuxカーネルが特定の操作で必要とする連続した物理メモリ領域が不足している状態を指します。

現代のカーネルでもフラグメンテーションは問題ですか？

はい。現代のカーネルではコンパクションアルゴリズムやマイグレーションタイプが改善が進んでいますが。しかしHuge Pageの利用増加や大容量RAMの普及により、フラグメンテーションの影響はさらに大きくなっています。

コンパクションは常に効果的ですか？

必ずしもそうとは限りません。連続した領域を解放する一方で、ページ移動に伴うCPUオーバーヘッドがパフォーマンス低下を引き起こす可能性があり、特に「ダイレクトコンパクション」時にはその悪影響が利点を上回る場合があります。

The post Linuxにおけるメモリフラグメンテーションとは何か、なぜ性能に影響するのか、そしてその対処法 appeared first on TiDB.

MySQLは、地球上で最も人気のあるオープンソース・リレーショナルデータベース管理システム (RDBMS) の一つであり続けています。多くの企業、コントリビューター、およびユーザーがそれをサポートするための製品やサービスを構築してきたため、強力なコミュニティとエコシステムを有しています。加えて、多くのツールやMySQLの互換データベースは、同データベースのコードベースを使用しているか、あるいは完全なワイヤプロトコル互換性を維持しています。このブログでは、2つの人気のあるMySQL互換データベースであるMariaDBとTiDBについて深く掘り下げます。これら両方のデータベースの利点と制限事項について議論します。また、TiDBがいかにして、極限の水平スケーラビリティと高性能な分析のための、より強力で実用的な代替案となり得るかを明らかにします。

MySQLの代替案とは何か、そしていつ必要になるのか？

チームがMySQLの代替案を検討し始めるのは、通常、MySQLの強みが大規模環境においてボトルネックに変わり始めた時です。代表的な問題点には以下のようなものがあります。

• キャパシティの限界 (単一のプライマリ・サーバーで快適に処理できる範囲を超えた、テーブルの肥大化、書き込みレートの上昇、同時実行ユーザー数の増加)
• 複雑化する高可用性構成 (レプリケーション構成の無秩序な拡大、フェイルオーバーの自動化、レプリケーションの遅延、およびテストの困難な災害復旧シナリオ)
• 常に「遅れ」を感じる分析処理 (別途パイプラインを構築しない限り、OLTPトラフィックと競合してしまう重いレポートクエリ)

このような状況に直面したとき、エンジニアは「MySQLに代わるもの」を探し始めます。多くの場合、使い慣れたSQLやドライバー、運用上のノウハウをそのまま活かせる、MariaDBのようなMySQL互換のオープンソースの代替や、ドロップインで置き換え可能なデータベースから検討を開始します。その過程で、「データベースエンジン」という言葉を2つの意味で再考することになります。一つはデータベースサーバーそのもの (MySQLやMariaDBなど) であり、もう一つはデータアクセスとストレージを制御するMySQLストレージエンジン (InnoDBなど) です。ストレージエンジンのチューニングや変更は特定のボトルネック解消には役立ちますが、水平スケーリング、ノード間の一貫性、マルチテナントの分離、突発的なワークロード下での予測可能なパフォーマンスといった、現代の大規模環境における本質的な課題を解決できることは稀です。

MariaDBとMySQL：フォークによって生じた差異の実態

MariaDBは、サン・マイクロシステムズによる買収後に作成されたMySQLのフォークです。MariaDBの主な目標の一つは、オープンソースでコミュニティ主導のMySQL互換データベースを継続的に提供することにあります。既存のMySQLアプリケーションやツールとの互換性維持に注力しており、MySQLからMariaDBへのシームレスな移行が可能です。この互換性により、開発者や組織はMySQLへの既存投資を活かしつつ、MariaDBが提供する機能強化や改善の恩恵を受けることができます。

MariaDBはイノベーションと新機能の継続的な開発を重視しています。コミュニティは、機能強化、バグ修正、およびパフォーマンスの最適化を通じてプロジェクトに積極的に貢献しています。この協力的なアプローチにより、MariaDBは急速に進化し、この分野における最新の進歩に対応し続けることができています。

コミュニティ主導のMySQL代替案としてのMariaDB

イノベーションの源泉は、MariaDBの強力なコミュニティ主導の開発モデルにあります。これは、開発がコミュニティの貢献やフィードバックに対して開かれていることを意味します。その結果、開発サイクルが短縮され、ユーザーのニーズに応える機動力の高い製品が実現しました。対照的に、オラクル社が開発、管理するMySQLは、より中央集権的な開発プロセスを採っています。MariaDB対MySQLという文脈において、この違いはしばしばイノベーションの速度やリリース頻度の認識に現れます。MariaDBはコミュニティの意見を取り入れた迅速な反復と結び付けられることが多い一方、MySQLのロードマップやリリースサイクルは、オラクルのガバナンスモデルにより、よりトップダウンで中央制御されているように感じられる場合があります。

MariaDBのエンタープライズ機能とMySQLストレージエンジン

エンタープライズ向けに、MariaDBはMaxScaleとColumnStoreを提供しています。これらはそれぞれ、水平スケーラビリティと分析用の列指向ストレージを実現するものです。MySQLにも同様のソリューションは存在しますが、MariaDBほど包括的ではありません。対照的に、標準のMySQLストレージエンジン (InnoDBなど) は、主に単一のMySQLインスタンス内でのデータアクセスとストレージの最適化を目的としています。そのため、エンジンを変更するだけでは、大規模環境で必要となるシャーディング、レプリケーション構成、あるいは独自のフェイルオーバーなどの設計負荷を解消することはできません。その結果、ストレージエンジンをチューニングした後でも、依然としてスケーラビリティや高可用性の限界に直面することあります。これは、ボトルネックがエンジン単体ではなく、アーキテクチャ全体にあるためです。

SkySQLはMariaDBのマネージドサービスであり、データベース保守の負担を取り除き、開発者がビジネスの革新に集中できる環境を提供します。

総合的に見て、これらの独自製品を備えたMariaDBは、高度な機能と信頼性を求める開発者にとって強力な選択肢となります。これは、MySQLのワイヤプロトコル互換性を備えたデータベースを必要としている場合に特に当てはまります。

MariaDBのような従来のMySQL代替案が直面する限界

MySQLの代替案として有力なMariaDBですが、依然として欠点も存在します。アプリケーションのシナリオによっては、開発者は以下のような制限に直面する可能性があります。

単一ノードのデータベースエンジンにおけるスケーラビリティの限界

MariaDBは単一構成のデータベースです。つまり、単一マシンのリソースには限りがあり、それがパフォーマンスや信頼性に影響を及ぼす可能性があります。その結果、ビジネスが急速に拡大した際、開発者はパフォーマンスの壁に突き当たることになります。

MaxScaleを利用すれば、MariaDBは単一ノード構成よりも優れたスケールを実現できます。しかし、他のデータベースが備えているような自動シャーディングやデータパーティショニングといった高度なスケーラビリティ機能は依然として不足しています。シャーディングの導入はアプリケーション側に多大な複雑さをもたらし、新機能の開発やリリースのスピードを鈍化させます。一方で、シャーディングはデータベースの運用コスト増大も招きます。多くの場合、この段階がチームにとっての転換点となります。アプリケーション側にシャーディングやルーティングのロジックを押し付けることなくスケールアウトが可能な、水平スケーリング対応のMySQL互換データベースの選択肢や、分散SQLデータベースの検討を開始するタイミングとなるのです。

高可用性、レプリケーション、および運用オーバーヘッド

MariaDBには組み込みの高可用性機能はありませんが、レプリケーション、クラスタリング、Galera Clusterなど、いくつかのソリューションを提供しています。レプリケーションでは、データベースのコピーを複数作成して同期を維持し、あるコピーが故障した際でも別のコピーが引き継げるようにします。クラスタリングでは、複数のサーバーをグループ化し、単一の実体として動作させます。また、Galera Clusterは、すべてのノードがプライマリとして動作できるマルチマスターレプリケーションのソリューションであり、一箇所のノードがダウンしても別のノードが即座にプライマリとして機能を引き継ぐことが可能です。

しかし、これらのソリューションにも欠点はあります。レプリケーションにおける大きな問題の一つは、データ損失の可能性です。レプリケーションが他のノードに到達する前にノードが故障した場合、それらの変更内容は失われてしまいます。さらに、レプリケーションの構築や管理は複雑になりがちで、複数のデータベースコピーを維持するために追加のリソースも必要となります。

クラスタリングにも、特にスケーラビリティに関する課題があります。クラスタにノードを追加するほど、ノード間のコンセンサスを維持するためのオーバーヘッドが増大し、パフォーマンスを損なう可能性があります。加えて、すべてのノードが正しく同期して動作することを保証するために、慎重な設定と管理が求められます。総じて、これらのアプローチは有効ではありますが、個別のコンポーネントを繋ぎ合わせるのではなく、アーキテクチャそのものに高可用性やフェイルオーバーが組み込まれている分散SQLデータベースと比較すると、より多くの運用コストを必要とします。

ColumnStoreと単一ノードアーキテクチャにおける分析機能のトレードオフ

並列実行エンジンとColumnStoreを備えたMariaDBは、より複雑なクエリの処理においてMySQLよりも優れています。しかし、単一マシンのCPUとメモリが並列実行の限界を規定するため、分析のパフォーマンスと同時実行性は、分散された列指向実行レイヤーによるスケールアウトではなく、依然として単一ノードアーキテクチャに制限されます。また、ColumnStore自体にも独自の弱点があります。

一つは、スキーマ設計における柔軟性の欠如です。ColumnStoreはデータを行ではなく列単位で保存する列指向ストレージエンジンです。これは分析クエリのパフォーマンス向上に寄与する一方で、スキーマを事前に定義する必要があり、容易に変更できないことを意味します。これは、変化するデータ要件に迅速適応する必要があるビジネスにおいて問題となる可能性があります。

最後に、ColumnStoreはリアルタイム分析やトランザクション向けに設計されていません。大規模なデータセットのバッチ処理を目的としています。そのため、リアルタイム分析を実行する必要があるビジネスや、トランザクションの一貫性を必要とするビジネスにとっては、最適なソリューションではない可能性があります。

モノリシックでレガシーなアーキテクチャに基づいた設計

MySQLと比較して、MariaDBには多くのイノベーションが見られますが、依然としてMySQLのコードベースを保持しています。これは、アーキテクチャの核が依然として単一ノードであり、マイクロサービスのような現代的なアプリケーションのニーズを満たせないことを意味します。小さな機能を追加するのは容易ですが、大幅な変更を加えるのは非常に困難、あるいは不可能かもしれません。グローバルなスケールと強力な一貫性を必要とする現代のアプリケーションには、透過的なシャーディングや組み込みの高可用性といった機能が求められます。

しかし、これらの機能をMariaDBの単一ノードのアーキテクチャに組み込むのは容易ではありません。このため、多くの小規模なサービスが突発的で並行性の高いトラフィックパターンを生成するマイクロサービス環境や、別システムにすべてをオフロードすることなく最新のデータと低レイテンシなクエリを必要とするAIやリアルタイム分析のワークロードにおいて、より顕著になります。このようなケースでは、強力な一貫性と慣れ親しんだSQLセマンティクスを維持しつつ、水平方向にスケールアウトできる分散SQLデータベースが選ばれる傾向にあります。

TiDBの紹介：MySQL互換の分散SQLデータベース

TiDBは、MySQL互換性を備え、広く採用されているオープンソースの分散SQLデータベースです。標準機能として水平スケーラビリティと高性能な分析機能を備えています。そのため、よりモダンでスケーラブルなソリューションへの移行を検討している開発者にとって、MariaDBに代わる有力なMySQL代替案となります。このセクションでは、開発者にとって魅力的な選択肢となるTiDBの主な特徴と、MariaDBとの比較について詳しく見ていきます。

アプリケーションの改修が不要なMySQL互換データベース

TiDBの大きな利点の一つは、その高いMySQL互換性です。これにより、開発者はすでに使い慣れているツールやアプリケーションの多くをそのままTiDBで利用でき、既存システムへの統合が容易になります。オープンソースのMySQL互換データベースであるTiDBは、MySQLとワイヤプロトコルレベルで互換性があるため、既存のMySQLドライバーやコネクターは通常、大きな変更を加えることなく動作します。さらに、TiDBはJava、Python、Goを含む幅広いプログラミング言語をサポートしており、開発者にとって汎用性の高い選択肢となっています。

手動シャーディング不要なMySQLワークロードの水平スケーリング

TiDBに組み込まれた水平スケーラビリティは、最も強力な機能の一つです。TiDBを使用すれば、データベースを手動でシャーディングすることなく、アプリケーションの成長に合わせて簡単にキャパシティを追加できます。これは、分散SQLデータベースを用いてMySQLワークロードを水平スケーリングするのに理想的な形です。高いスケーラビリティと柔軟性を必要とするアプリケーションにとって、TiDBは最適な選択となります。MariaDBもMaxScaleという製品で同様のソリューションを提供していますが、TiDBは標準で分散アーキテクチャを採用しているため、よりスケーラブルで柔軟性に優れています。

分散SQLデータベース上のTiFlashによるリアルタイム分析

TiDBのもう一つの主要な機能は、高性能な分析エンジンであるTiFlashです。TiFlashは、大規模データセットに対して高速なアドホッククエリを提供する分散型列指向エンジンであり、OLTPと分析を統合するためにTiDBの分散SQLアーキテクチャと密接に結合されています。TiDBはTiFlashとシームレスに動作し、開発者はコンピューティング層とストレージ層の間でデータを容易に移動させることができます。これにより、高速な分析能力を必要とするアプリケーションにとって、TiDBは優れた選択肢となります。

TiFlashはセットアップが容易で、TiDBのOLTP機能とネイティブに統合されています。データの自動レプリケーションとリバランシングをサポートしており、障害耐性とデータの可用性を保証します。また、TiFlashはアプリケーションに対し、行ストアと列ストアの間で強力な一貫性を提供できます。さらに、分析処理に不可欠な超並列処理 (MPP) などの高度な機能もサポートしています。MariaDBのColumnStoreと比較して、TiDBはよりスケーラブルで使いやすく、かつ強力です。

TiDBを支える活発なオープンソースコミュニティ

TiDBには強力で活発なオープンソースコミュニティがあり、プラットフォームに多大なイノベーションをもたらしています。オープンソースのMySQL互換データベースとして、TiDBは活発なコミュニティ開発の恩恵を受けているだけでなく、本番環境レベルのSLAやガイダンスを必要とするチーム向けに商用サポートも提供されています。このコミュニティの存在により、データベースが常に最新の状態に保たれ、最新の技術や標準との完全な互換性が維持されています。さらに、コミュニティはTiDBをアプリケーションで利用しようとする開発者のために、豊富なリソースとサポートを提供しています。

MySQLおよびMariaDBからTiDBへの移行ツール

TiDBは、MariaDBや他のMySQL互換データベースからTiDBへの切り替えを容易にする包括的ないくつかの移行ツールを提供しており、MySQLおよびMariaDBからの移行を明示的にサポートしています。これらのツールにはTiDB Data MigrationやTiDB Lightningが含まれており、長時間のダウンタイムや不安定な切り替えのリスクを冒すことなく、従来のMySQL互換データベースから安全に移行したいチーム向けに設計されています。

これらのツールを使用することで、開発者はアプリケーションへの影響やダウンタイムを最小限に抑えながら、データとスキーマをシームレスに移行できます。TiDBの移行ツールはドキュメントが充実しており使いやすいため、TiDBへの切り替えをスムーズかつシンプルに進めることが可能です。

TiDB Cloud：MySQL代替案のためのマネージド分散SQL

マネージドなクラウドソリューションを求める開発者のために、TiDBはTiDB Cloudを提供しています。これはフルマネージドでスケーラブルなクラウドサービスであり、オンプレミスのインフラを必要とすることなく、TiDBのすべてのメリットを享受できます。TiDB Cloudは、MariaDBが提供するマネージドクラウドサービスSkySQLと同様の機能と利点を提供します。TiDB Cloudを利用することで、開発者はデータベースの管理や保守を専門家に任せ、アプリケーションの構築に専念できるようになります。なお、突発的な需要やオートスケーリングによる成長にはTiDB Cloud Starterが、一貫したパフォーマンスとキャパシティ計画が必要な予測可能なワークロードにはTiDB Cloud Dedicatedが適しています。

TiDBと他のオープンソースMySQL互換データベースの比較

前述の通り、MariaDBと比較して、TiDBは異なるアーキテクチャ上のアプローチを採用しています。MariaDBは、MaxScaleやColumnStoreといった製品によって従来なMySQLの系譜を拡張していますが、その核となるエンジンは依然として単一ノードに根ざしています。そのため、ワークロードが増大するにつれて、チームはレプリケーション構成の複雑化や手動シャーディング、運用上の回避策を強いられることになります。対照的に、TiDBは強力なACID一貫性を維持したまま水平方向にスケールアウトすることを前提に構築された分散SQLデータベースです。これにより、アプリケーションをルーティング層に変えたり、使い慣れたSQLパターンを放棄したりすることなく、成長やマルチテナントの複雑さに対応できます。また、MySQL互換性も維持されているため、移行のハードルを軽減し、既存のツール類をそのまま活用することが可能です。

Amazon Auroraをはじめとする、他のMySQL互換の「スケールアップ型」システムとの比較においては、一般的に真の水平スケールが必要になる前に、垂直スケーリングとマネージドな高可用性でどこまで対応できるかというトレードオフに集約されます。スケールアップ型プラットフォームは運用を簡素化し可用性を向上させますが、多くの場合、依然として単一のプライマリ・ライターモデルに縛られており、データ量や書き込みスループット、テナント間の並行性が増大するにつれて限界に達します。同様に、多くのオープンソースMySQL互換データベースも、依然として単一ノードのデータベースエンジンを継承しているか、スケールのために手動シャーディングや外部クラスタリングに依存しており、シャードキーやリシャーディング、クロスシャードクエリといった特有の複雑さを再導入することになります。TiDBのモデルは、SQLやMySQL互換性を損なうことなく水平スケールと強力な一貫性を提供することで、この罠を回避するように設計されています。「MySQL互換」であることに加え「設計レベルでのスケールアウト」が求められる場面において、TiDBは自然な次の一手となります。

TiDBが最適なMySQL代替案となる場合、ならない場合

MariaDBは多くの開発者に愛されている素晴らしいデータベースであり、多くのシナリオで非常にうまく機能します。しかし、MariaDBでは対応できないシナリオにおいて、TiDBは有力な選択肢となります。どちらのオプションが最も適しているかを判断するために、以下のクイック・チェックリストを活用してください。

以下のようなケースでは、MariaDBやMySQLで「十分」であることが多いでしょう。

• 予測可能な成長と、シンプルな高可用性要件を持つシングルリージョンのアプリケーション
• 単一のプライマリとレプリカの構成で十分に収まる程度の、中規模なデータセットと書き込みレート
• OLTP中心のワークロードで、レポート出力が軽微 (または分析をメインデータベースの外で処理している) な場合
• 弾力的なスケールよりも、シンプルさが重要視される小規模な運用体制

以下のようなニーズがある場合は、TiDBのような分散SQLのMySQL互換データベースが明らかに優れています。

• 複雑なレプリケーションやフェイルオーバー・ツールを繋ぎ合わせることなく実現する、マルチリージョンでの耐障害性と高可用性
• 別途パイプラインを構築したりレプリカの遅延に悩まされたりすることなく、最新データに対して実行する重い分析処理 (HTAPスタイルのパターン)
• アーキテクチャの再設計やシャーディングを行う代わりに、ノードを追加することで対応したい、予測不能または突発的なトラフィック
• 強力な分離、一貫したパフォーマンス、そしてシャードキーの制約に縛られない成長が求められるマルチテナントSaaSの要件

数あるMySQL互換データベースの中でも、SQLやMySQL互換性を維持したまま、水平スケールと強力な一貫性を求める場合にTiDBは最適です。TiDBは、MySQLプロトコル互換のデータベースカーネル、XpandやColumnStoreに匹敵するソリューション、そしてマネージドなクラウドデータベースサービスなど、MariaDBが持つ機能の大部分をカバーしています。これらすべてが、開発者の負担を大幅に軽減することに繋がります。究極のスケールと信頼性の高いインフラを必要とする現代のアプリケーションにとって、TiDBは将来にわたる拡張性も兼ね備えた、極めて実用的なMySQL互換データベースです。

MySQLやMariaDBからTiDBへ移行する方法

ほとんどのチームにとって、データベースの切り替えにおける最大の障壁はアーキテクチャではありません。移行のリスクそのものです。不安定な切り替え作業、予期せぬメンテナンスダウンタイム、あるいは数週間後に発覚するようなデータ不整合を望む人はいません。幸いなことに、TiDBは既存のMySQLシステムからの移行専用に構築されたツール群と、互換性第一のパスを提供することで、そうした不安を解消するように設計されています。

TiDBは、MariaDBや他のMySQL互換データベースからTiDBへの切り替えを容易にする包括的な移行ツールセットを提供しており、MySQLおよびMariaDBからの移行をサポートしています。これらのツールにはTiDB Data MigrationやTiDB Lightningが含まれており、長時間の停止や不安定な切り替えのリスクを冒すことなく、従来のMySQL互換データベースから安全に移行したいチーム向けに設計されています。TiDBはMySQLプロトコル互換であるため、一般的なInnoDBベースのMySQLなどやMariaDB環境からデータとスキーマを取り込むことができ、既存のSQLやアプリケーションコネクタをそのまま使い続けることが可能です。

これらのツールを活用することで、開発者はアプリケーションへの影響やダウンタイムを最小限に抑えながら、データとスキーマをシームレスに移行できます。TiDBの移行ツールはドキュメントが充実しており使いやすいため、TiDBへの切り替えをスムーズかつシンプルに進めることができます。TiDBは、MariaDBや他のMySQL互換データベースからTiDBへの切り替えを容易にする包括的な移行ツールセットを提供しており、MySQLおよびMariaDBからの移行をサポートしています。これらのツールにはTiDB Data MigrationやTiDB Lightningが含まれており、長時間の停止や不安定な切り替えのリスクを冒すことなく、従来のMySQL互換データベースから安全に移行したいチーム向けに設計されています。TiDBはMySQLプロトコル互換であるため、一般的なInnoDBベースのMySQLなどやMariaDB環境からデータとスキーマを取り込むことができ、既存のSQLやアプリケーションコネクタをそのまま使い続けることが可能です。

MySQLやMariaDBからの移行に伴うダウンタイム、データの不整合、あるいはロールバックの緊急対応にお悩みですか？お問い合わせページからご連絡ください。弊社のデータベースエキスパートが、適切なツール、検証フェーズ、そして明確な切り替えプランに基づいた、最も安全な移行パスの策定をお手伝いします。

The post TiDBとMariaDBの比較から考察する大規模環境におけるMySQLの代替案 appeared first on TiDB.

AIワークロードが最初に本番システムに投入され始めた当初、多くのチームでは、ボトルネックはコンピュートに現れると考えられていました。GPUを増やすこと、CPUを高速化すること、メモリプールを拡張すること――それが自然なスケーリングの方向性だと思われていたのです。

しかし、実際に最初に限界を迎えたのは、そこではありませんでした。

システムが問題を起こした原因は、コンピュートの不足ではありませんでした。ストレージの余力が先に尽きてしまったのです。CPUが飽和するよりもはるかに早い段階でクエリレイテンシが悪化し、レプリケーションは処理に追いつかなくなり、コンパクションジョブは想定していた実行時間を超えてしまいました。その結果、コストは性能向上のペースを上回って増加していきました。

AIは単にワークロードを増大させただけではありません。将来に対する備えが最も不十分だったデータベースアーキテクチャの領域、すなわちストレージを浮き彫りにしたのです。

このような傾向は業界全体で繰り返し見られており、そこには大きな構造的変化が示されています。データベース設計における戦略的な重心は、コンピュートからストレージレイヤーへと徐々に移りつつあるのです。

変化の焦点：ストレージアーキテクチャがシステムの優位性を決定づける時代

長年にわたり、コンピュートの進化はデータベース性能を大きく向上させてきました。しかし、その時代はすでに終わりを迎えています。

現在のワークロードは、大規模かつ急速に増大するデータセット、マルチモーダルなクエリパターン、頻繁なベクトル演算、そして巨大なコンテキストウィンドウを生成するマルチエージェントAIシステムによって形作られています。さらに、特にコンシューマ向けやAI駆動のアプリケーションでは、トラフィックの予測が以前よりもはるかに困難になっています。

FlipkartのBig Billion Daysセールは、その状況をよく示しています。クラスタは数週間前からスケールアウトする必要があり、セール後も段階的にしかスケールダウンできませんでした。それでもなお、コストの多くはコンピュートではなく、ディスクやレプリカの準備に費やされていました。

この課題は決して特定の企業に限ったものではありません。業界全体を見渡すと、もはやコンピュートが最初の制約条件になるケースは少なくなっています。代わりに、ストレージのスループット、IOPSの上限、レプリケーションによるオーバーヘッド、コンパクションの負荷といった要素が、先に顕在化するようになっています。

初期の分散データベース――初期のTiDBアーキテクチャも含めて――は、今とは異なる時代のハードウェアやワークロードを前提として設計されていました。ワークロードが進化するにつれて、それらの前提は次第に制約となっていきました。現在では、どれだけストレージを中心に深く設計されているかが、競争上の優位性を左右する要因になりつつあります。

Cursorのデータベース遍歴から得られた3つの教訓

この変化は、Cursorが最近経験したインフラの変遷によって明確に示されています。この内容は、同社のCTO兼共同創業者がスタンフォード大学のCS153の講義で共有したものです。

教訓1：分散SQLは洗練されているが、複雑さが足かせになることがあります

Cursorは当初、コアとなるインデックス処理のワークロードに対して、Spanner系の分散SQLシステムを採用しました。理論上は、強い整合性、自動シャーディング、水平スケーラビリティといった利点を備えていました。しかし実際には、プロダクトを進化させる以上にデータベースの管理に時間を費やすことになり、最終的には、よりシンプルなマネージドPostgreSQL構成へと移行しました。

ここから得られた教訓は、分散SQLが欠陥を抱えているということではありません。スケールした環境では、理論的な洗練さよりも、シンプルさが勝る場面が多いということです。

教訓2：従来型データベースが、書き込みが止まらないAIワークロードに苦戦する理由

PostgreSQLは汎用性の高い強力なデータベースですが、MVCCやバキューム処理を前提としたシングルノードのストレージエンジンである点は変わりません。Cursorのように、継続的な更新、巨大なテーブル、急速なデータ増加を伴うワークロードでは、チューニングはいずれ限界に突き当たりました。

根本的な解決策は、さらなる最適化ではありませんでした。アーキテクチャそのものを見直すことだったのです。Cursorは、最大かつ最も高負荷なテーブルを、オブジェクトストレージを基盤とするシステムへ移行しました。

この教訓は明確です。現代のAIワークロードにおいては、従来型データベースはいずれ、オブジェクトストレージを前提に設計されたシステムに及ばなくなるということです。

教訓3：将来のデータアーキテクチャはオブジェクトストレージファーストへ

Cursorは試行錯誤を重ねる中で、現代的な構成にたどり着きました。それは、大規模データの永続的な置き場所としてオブジェクトストレージを据え、その上にコンピュートやクエリエンジンを重ねるというパターンです。オブジェクトストレージは、耐久性、容量、そしてコスト効率の高いスケーリングを担い、データベースはストレージではなく、コンピュートを提供するサービスとして位置付けられるようになりました。

なぜオブジェクトストレージがデータベースの前提を変えるのか

オブジェクトストレージは、コールドデータ向けの低コストな保存先として語られがちです。しかし、これがデータベースの基盤になると、システムの振る舞いはそれ以上に大きく変わってきます。

オブジェクトストレージは、イミュータブルなデータ特性、非常に高い耐久性、そして事実上無制限の容量を提供します。耐久性はローカルのレプリカに依存するのではなく、ストレージレイヤーそのものが担うようになり、コストの予測性が高まり、ライフサイクル管理もシンプルになります。

データがオブジェクトストレージに移行すると、データベースの中核コンポーネントは再設計が必要になります。並行制御、インデックス戦略、コンパクションの流れ、キャッシュ設計、リカバリロジック、ワークロード分離、分散実行といった要素はすべて変わってきます。コンピュートとデータが密結合していることや、レプリカを多用して耐久性を確保することなど、ローカルストレージやブロックストレージを前提に成り立っていた設計上の仮定は、もはや当てはまらなくなっていくのです。

図1：コンピュートとオブジェクトストレージの分離で実現する弾力的スケーリングと統合ワークロード

このため、オブジェクトストレージは既存のアーキテクチャに単純に重ねるだけでは効果を発揮できません。その利点を最大限に引き出すには、システムをゼロから設計し直す必要があります。

TiDBにとって重要な理由

TiDBは、多くの分散SQLシステムと同様に、Google Spannerに触発され、ローカルディスクやEBSなどのクラウドボリュームを基盤として構築されています。多くの同業システムと異なり、TiDBは大規模かつミッションクリティカルな本番環境での運用に耐えるように強化されています。

しかし、Cursorの事例が示すのは、より本質的なポイントです。優れたSpannerスタイルのシステムであっても、AIワークロードが急増する状況では根本的な負荷に直面します。巨大なベクトルデータ、長期の履歴、エージェントのトレース、さらに同じ論理データ上でOLTP、分析、AIワークロードを同時に提供する必要があることが、ディスク中心のアーキテクチャに大きな負荷を与えます。

だからこそ、私たちはTiDB Xを開発したのです。

TiDB X：オブジェクトストレージ時代に向けての設計

TiDB Xは、私たちの分散SQLデータベースの最新アーキテクチャで、シンプルな考え方に基づいて設計されています。すなわち、オブジェクトストレージが真のデータソースとなり、データベースはその上でコンピュートとクエリを担うレイヤーであるということです。

すべてのコアデータはオブジェクトストレージ上に存在し、安価で耐久性が高く、独立してスケール可能な容量を提供します。コンピュートはステートレスかつ弾力的であるため、OLTP、分析、AIといったハイブリッドワークロードをその場しのぎの回避策ではなく第一級の標準機能として扱えます。TiDB Cloudの従量課金モデルにより、チームはアイドル状態のクラスタに支払う必要はなく、実際に処理した分だけ支払う仕組みとなっており、急激な負荷変動の多いAI駆動ワークロードにも自然に対応できます。

一つの大規模データベースから、数百万の小規模データベースへ

AIやエージェント型システムは、このアーキテクチャをさらに進化させます。一つのモノリシックなデータベースではなく、各エージェントが独自のコンテキストストアや一時的なステート、あるいは一時的なベクトルインデックスを生成するようになるのです。

これにより、モデルは一つの大規模データベースから、数百万もの小規模で弾力的かつ一時的なデータベースへと変わります。このモデルが成立するのは、耐久性がオブジェクトストレージ上で担保され、コンピュートがステートレスかつ使い捨て可能である場合に限られます。この変化がなければ、AI時代のアーキテクチャはすぐにコストが膨れ上がり、運用も不安定になってしまいます。

TiDB Cloudで始める、アプリ書き換えなしのスケール

AIコーディングアシスタント、エージェント型RAGシステム、マルチテナントSaaSプラットフォーム、あるいは大量かつ急速に変化するデータを扱うプロダクトを開発する場合、Cursorが直面したのと同じ構造的課題に直面します。

従来の道をたどることもできます――伝統的なデータベースで始め、スケーリングの限界にぶつかり、ワークロードを少しずつ移行し、最終的にオブジェクトストレージを中心に再構築する方法です。

あるいは、その旅の終着点からスタートすることも可能です。

TiDB Xを基盤としたTiDB Cloudは、最初からオブジェクトストレージを土台とする環境を提供します。スケール実績のある分散SQL、単一の論理システムでのハイブリッドワークロード、そしてAI時代に最適化された弾力的な従量課金を備えています。

これらのアーキテクチャ変革は、すでに本番環境のAIシステムにも影響を与えています。汎用エージェント型AIプラットフォームのManusは、巨大なコンテキスト増加、書き込み負荷の高いワークロード、再設計なしでのスケーリングという同様の課題に直面していました。TiDB Xを基盤とするTiDB Cloudを採用することで、オブジェクトストレージを爆発的な成長と大規模エージェント群の基盤として活用することができました。

TiDB Cloudを使って、数千のエージェントによる秒以下のブランチングをどのようにスケールさせたのか、その詳細を確認できます。

The post オブジェクトストレージ：データベースアーキテクチャの新たな基盤 appeared first on TiDB.

現代のソフトウェア開発において、新機能のリリースには本来あるべき以上の時間がかかり、データベースの請求額は必要以上に高くなっていると感じることはないでしょうか。それは、あなたのチームの能力が足りないからでも、あなたのプロダクトが例外的に複雑だからでもありません。いつのまにかデータレイヤーが、エンジニアリングチームのスピードとコストを阻害する最大の要因となってしまっているのです。

つまり、SaaS、AI、Web3、ゲーミング、あるいはISVなど、どのようなエンジニアリングチームであっても、以下の2つの不完全な選択肢の間で身動きが取れなくなっています。

• 従来のクラウドデータベース：事前の見積もり、プロビジョニング、チューニング、そして継続的な運用作業を要求する。
• 開発者フレンドリーな「サーバーレス」データベース：ユーザー体験は簡略化されているものの、信頼性、ワークロードの多様性、あるいはエンタープライズ級の機能が不足している。

このトレードオフが、市場にギャップを生み出しています。チームが求めているのは、シンプルさと機能性の両立、柔軟性とコスト管理の両立、そして、スピードと安心感の両立です。

そのギャップを埋めるために構築されたのが、TiDB Xを基盤とするTiDB Cloud Essentialなのです。

中堅市場の現実：スピードが重要、コストはさらに重要

チームが5人のエンジニアであろうと50人であろうと、直面する制約は似通っています。

1. 素早くリリースする必要がある。プロダクトのロードマップはぎっしり詰まっています。顧客は継続的な改善を期待しています。そして、ETLパイプラインやデータのサイロ化、あるいは複数のデータベースを組み合わせたアーキテクチャに起因するあらゆる遅延が、競争上の優位性を損なわせます。
2. 効率的であり続ける必要がある。クラウドのコストは上昇しています。プロビジョニング型のデータベースでは、アイドル状態のキャパシティに対しても支払いを余儀なくされます。スケールアップには承認が必要で、スケールダウンが行われることは滅多にありません。毎月、請求額は知らぬ間に膨らんでいきます。
3. データベースにかかりきりになるスタッフはいない。おそらく、DBAの大軍を抱えているわけではないでしょう。絶え間ないチューニングやトラブルシューティングを必要とせず、ワークロードを処理できるシステムを採用する必要があります。
4. アーキテクチャ設計のミスは許されない。データベースが新しいワークロードやトラフィックパターンをサポートできないために、システムを再構築することだけは、最も避けたい事態です。

もしこれらすべてに心当たりがあるなら、あなたこそが、私たちがTiDB Cloud Essentialを設計する際に想定したターゲットそのものです。

TiDB Cloud Essentialのご紹介：次世代のために構築された、適応型クラウドデータベース

TiDB Cloud Essentialは、単なる「もう一つのデータベース階層」でも、何かの「ライト版」でもありません。

これは、新しいカテゴリーのクラウドデータベースです。あなたのワークロードに適応し、コストを低く抑え、運用のストレスを取り除きます。そして、複数のシステムを繋ぎ合わせることなく、モダンな機能を構築するための柔軟性を提供します。

これらすべてを支えるのが、以下の3つの原則に基づいて構築された、分散型SQLアーキテクチャの最新バージョンTiDB Xです。

ワークロードを認識する適応性

ピーク時のトラフィックに合わせた事前のプロビジョニングは、もう必要ありません。キャパシティを推測したり、手動でリサイズしたりすることも不要です。

TiDB X は、実際の需要に基づいてコンピューティングとストレージを調整し、アイドルリソースを排除して総コストを削減します。

オブジェクトストレージを土台とした設計

オブジェクトストレージは、高い耐久性と回復力をもちながら、ストレージコストを劇的に削減します。その削減幅は、多くの場合50〜60%にも及びます。

統合ワークロードエンジン

OLTP、アナリティクス、ベクトル検索。これらすべてを、単一のMySQL互換エンジンで実現します。

ETLも、同期も、連携のためのコードも、3つの異なるデータベースを維持管理する必要もありません。

アプリケーションのトランザクション、運用チーム向けのダッシュボード、そしてAI機能のためのベクトル検索を、データを他の場所へコピーすることなく、同じデータに対して実行できるようになります。

オープンソースの主要な大規模言語モデル (LLM) アプリ開発プラットフォームであるDifyは、TiDB Cloud Essentialを使用してデータアーキテクチャを変革し、重大な課題を解決しました。膨大な数のデータベースコンテナを単一の統合システムに集約することで、AIアプリケーションを構築する数千人の開発者を支える、スケーラブルな基盤を構築したのです。また、インフラコストの80%削減と運用オーバーヘッドの90%削減という、驚異的な効率化も達成しました。

TiDB Cloud Essential：中堅市場のチームが最も重視する3つの柱

SaaS、AI、ゲーミング、そしてISV市場の数十ものエンジニアリングリーダーにインタビューを行った結果、明確なパターンが見えてきました。エンジニアリングチームがTiDB Cloud Essentialを選ぶ理由は3つあります。

1. コスト効率：使った分だけ支払う

従来のクラウドデータベースでは、以下のような対応を余儀なくされます。

• 過剰なプロビジョニング
• アイドル状態のコンピューティングに対する支払い
• IOPS料金、ストレージの上乗せ料金、および運用オーバーヘッドの負担

TiDB Cloud Essentialはこのモデルを変えます。

ワークロードを認識する消費モデルと、オブジェクトストレージベースのエンジンにより、実際に使用した分だけを支払うことになります。その結果、多くのお客様は従来のクラウドデータベースと比較して、総所有コストを70〜80%削減しています。

急成長中のあるスマートIoT企業は、AIアシスタントのリリースを控えており、よりシンプルな運用で高い並行性を実現する必要がありました。彼らはStarRocksとリージョンごとのMySQLから TiDB Cloud Essentialへと集約を行いました。その結果、書き込み負荷の高い環境下でP99レイテンシを安定させつつ、月額コストを約50%削減し、リクエストユニットのピークも約50%低下させました。

これはディスカウントやロックインによって実現されたものではありません。アーキテクチャによって実現されたものです。

2. 新機能をより速くリリースする：OLTP、アナリティクス、AIを支える単一のデータ基盤

プロダクト開発において最も時間がかかるプロセスは、多くの場合…データベースです。

それはクエリのせいではなく、以下のような要因によるものです。

• ETLのサイクル
• 分析データの同期
• 複数のシステムの維持管理
• パイプラインのデバッグ
• 新しいワークロードの統合

TiDB Cloud Essentialがあれば、OLTP、アナリティクス、AIという3つのワークロードすべてが1か所に集約されます。チームはデータの移動に費やす時間を減らし、構築により多くの時間を割けるようになります。

3. 将来への備え：再設計なしで成長する

プロダクトが成功したからといって、データレイヤーのシャーディングや移行、再設計を迫られるべきではありません。

TiDB Cloud Essentialは、あなたの成長に合わせて拡張します。

• テナントが増えた？容易に対応可能です。
• データが増えた？問題ありません。
• 新しいAI機能が必要？ベクトル検索とエージェントのサポートが組み込まれています。
• 分析クエリが増えた？同じエンジンで対応できます。

小さく始めて、自然に成長させる。アーキテクチャの壁に突き当たることは、もうありません。

TiDB Cloud Essentialはどのような人のためのものか？

もしあなたが以下のようなものを構築しているなら：

• マルチテナント要件を伴うSaaSプラットフォーム
• ベクトル検索とトランザクションワークロードを組み合わせたAI活用アプリ
• 予測不能なトラフィックが発生するゲームのバックエンド
• 大量の読み取り/書き込み需要があるWeb3やフィンテック製品
• レガシーなMySQL / Postgresアーキテクチャを近代化しようとしているISV

その場合、TiDB Cloud Essentialは即座にあなたの環境を簡素化し、コストを即座に削減します。

TiDB Cloud Essential：中堅市場のチームが「実際にどう動くか」を考えて設計されたデータベース

もしあなたが以下を求めているなら：

• サーバーレスデータベースのシンプルさ
• 分散型SQLのパワー
• 真の従量課金によるコストモデル
• そして、AI駆動型アプリに不可欠な統合エンジン…

これら4つすべてを提供できるプラットフォームは、TiDB Cloud Essentialだけです。チューニングは不要。キャパシティプランニングもゼロ。つきっきりで管理する必要もありません。ただ構築し、リリースし、改善を繰り返すだけです。

コスト削減をご希望ですか？ TiDB Cloud Essentialによるコスト優位性をご確認ください

中堅市場のチームが、コストのためにスピードを犠牲にしたり、機能のためにシンプルさを諦めたりする必要はありません。TiDB Cloud Essentialによるコスト削減は、ディスカウントによるものではなく、以下のアーキテクチャによって実現されます。

• 実際の需要に合わせてコンピューティングを適応させることで、アイドル状態のキャパシティへの支払いを排除する
• オブジェクトストレージ基盤を採用することで、耐久性を維持しながらストレージコストを削減する
• OLTP、アナリティクス、AIを単一のMySQL互換エンジンに集約することで、余分なシステム、ETL、および運用オーバーヘッドを回避する

TiDB Cloud Essentialに切り替えることで、具体的にどれほどのコストが削減できるかお知りになりたいですか？パーソナライズされたデモをリクエストしてください。私たちが実際にデプロイする詳細なアーキテクチャについて、丁寧にご案内いたします。

The post 迅速に構築。効率的に運用。中堅企業がTiDB Cloud Essentialを選ぶ理由 appeared first on TiDB.

先日開催された年次イベントTiDB SCaiLEにおいて、TiDB Cloudの新しいコアエンジンであるTiDB Xを発表したところ、反響は即座に、そして非常に大きなものとなりました。発表後、多くの方々から、TiDB Xはどのようにして生まれたのか、なぜ開発することにしたのか、そしてそれがTiDB Cloudの将来とどのようにつながっているのかについて、技術的な質問から技術以外の質問まで、さまざまな問い合わせが寄せられました。すべての方に個別に返信する代わりに、私たちはこのストーリーを書き残すことにしました。新しいエンジンのアーキテクチャだけでなく、その背景にある考え方、途中での試行錯誤、そしてこのエンジンに至るまでの長年にわたる進化の過程についても含めてお伝えします。

TiDB Xは突然生まれたわけではありません。
それは、TiDB Cloudの構築を何年も重ね、限界に直面し、長年の常識に挑戦し、最終的に、これまでの延長線上にあるアプローチでは、進むべき未来には到達できないと判断した結果として生まれたものです。多くの点で、TiDB Xは原点に立ち返る試みと言えます。すなわち、なぜ私たちはTiDBを作ったのか、顧客が本当に価値を置いているものは何か、そしてAIやクラウドネイティブ開発によって変化した世界において、スケーラビリティとは本当は何を意味するのか、という問いに立ち返ることです。

最も重要な問いに立ち返る：なぜ人々はTiDBを選ぶのか？

長年にわたり、私たちが社内で直面してきた大きな課題の一つは、TiDB Cloud Starter とTiDB Cloud Dedicatedの間に存在するアーキテクチャの分断でした。両者はTiDBという名前を共有していましたが、技術、チーム、進化の方向性において大きく異なっていました。私たちは統合を何度も試みましたが、いずれも成功しませんでした。

最終的に私たちの方向性を再び揃えるきっかけとなったのは、非常にシンプルな問いでした。「なぜユーザーはTiDBを選ぶのか？」数えきれないほどの会話を通じて、その答えは常にたった一つの言葉に集約されました — スケーラビリティです。

それは単にデータ量やスループットの話ではなく、実運用においてデータベースが限界に達するあらゆる次元におけるスケーラビリティを意味しています。インデックス、テナント、テーブル、コネクション、メタデータ、運用の複雑性などです。システムは最も強い部分で失敗するのではなく、最も弱い部分で限界に達します。TiDBはこれらすべての要素において、他に類を見ないバランスの良さを示してきました。

一例としてAtlassianの事例があります。Atlassianでは、単一のデータベース内で数百万のテーブルをサポートする必要がありました。データサイズ自体はそれほど大きくありませんでしたが、メタデータに対する要求は非常に高いものでした。競合するシステムは数千テーブル規模で限界を迎えましたが、TiDBはほぼ1,000万テーブルまでスケールし、この導入を勝ち取りました。この事例は、私たちが繰り返し目にしてきた核心的な事実を改めて裏付けています。スケーラビリティこそがTiDBの得意分野であり、しかもそれは決して固定的なものではないということです。

10倍または100倍のスケールでは何が起きるのか？

私たちは従来のTiDBアーキテクチャを、かつて考えていた以上に拡張しました。快適に運用できる100TBクラスタから、安定した1PB超クラスタまでです。しかし次に自然に浮かぶ問いはこうです。10PB以上のスケールでは何が起きるのでしょうか？

率直に言うと、従来のシェアード・ナッシングアーキテクチャ (ローカルストレージ上に構築されたもの) では、そのスケールに必要な柔軟性、コスト構造、運用上の動的な対応を提供することはできません。

今後10年間のワークロード、特にAIエージェントによって生成される個別SQL、爆発的に増えるロングテールのユースケース、大量の動的アプリケーションに対応するためには、データベースは次の2つのクラウド原則を完全に受け入れる必要があります。

1. 弾力的なリソース：真の従量制コンピュート
2. オブジェクトストレージ：安価で耐久性があり、大規模並列処理が可能なストレージ

もし今日のワークロードが手に負える範囲に思えても、歴史は私たちが未来を過小評価しがちであることを教えてくれます。ムーアの法則はそれを痛感させてくれます。私たちの想像力はめったに技術的現実に追いつきません。そして過去6か月のAIの進展だけでも、それは一層明らかになっています。

アプリケーションを数分で作成でき、データ収集が容易で、各ユーザーにAIエージェントが生成する個別ワークロードがある場合、SQLパターン、テーブル構造、クエリ経路の組み合わせはデータベースシステムのあらゆる部分に負荷をかけます。

そこで問いはこうなります。高速なイノベーションを維持しつつ、長期的な安定性と安全性を保証するデータベースをどう設計するか？

この問いこそが、TiDB Xの真の始まりを示しています。

TiDB Xの起源：初期の技術的構想

TiDB Xの方向性の最初の兆しは、私が2021年4月にCCFのカンファレンスで行った講演にまでさかのぼりますが、このアイデア自体ははるか以前から形成されていました。2017年ごろ、PingCAPの共同創業者兼CEOのMax Liuは、トランザクションの最適化を探求し、SQLレイヤーのテストを加速するための小規模な社内プロジェクトを立ち上げました。同時に、私たちはWiscKey論文 (FAST ’16) やDgraphのGo実装であるBadgerDBから影響を受けました。これらはLSMツリーにおいてキーと値を分離することで書き込み増幅を削減することを追求していました。

図1：TiDB Xがオブジェクトストレージ、ワークロードに応じたスケーリング、タスク分離をどのように組み合わせているか

Go愛好者として、私たちはBadgerDB上に構築したTiKV互換の分散キーバリューストアを試作しました。軽量で柔軟性があると感じましたが、その楽観的な考えが誤りであることは後に痛い目で学びました — TiDB Xは最終的にRustで書き直されました。それでも、このプロトタイプは重要なアイデアを生み出しました：ストレージに関する懸念をより積極的に分離できるということです。

同時に、Snowflakeのコンピュートとストレージの分離は、クラウドネイティブデータシステムに対する期待を再形成していました。SnowflakeはOLAPを対象としていましたが、私たちにOLTP向けの挑発的な問いを投げかけました：SSTファイルをS3上に置き、キャッシュとRaftログだけをローカルに保持することは可能か？RockSetやRocksDBチームのような他のプロジェクトも同様の方向性を探っていましたが、既存の制約の中での試みでした。私たちはさらに一歩進み、完全にサーバーレスでクラウドネイティブなOLTPデータベースを構築したいと考えました。

転換点：2022年と段階的な手法を捨てた決断

2022年までに、私たちはクラウドネイティブエンジンプロジェクトを再開し、具体的かつ挑戦的な目標を掲げました。それらは大胆すぎて、段階的な手法では実現できるものではありませんでした：

• 世界中の開発者向けに無料のTiDB Cloudサービスを提供。
• 新しいクラスタを数秒で作成し、完全セルフサービスに。
• 0から1億QPS/TPSまで自動でスケールし、同じ速度で0まで縮小することを可能に。
• データセットのサイズをキロバイトからペタバイトまでサポート。
• 標準的なクラウドAPIのみを使用し、特殊なハードウェアや特殊な構成に依存しないこと。

当時、最小規模のTiDBクラスタでさえ月に数百ドルかかりました。クラスタの立ち上げには数分かかり、大規模クラスタのスケーリングは、ワークロードをノード間でゆっくり再バランスする必要があったため数日かかることもありました。これらの制約は、私たちが描いていた未来には適合しませんでした。

1,000倍の改善を達成するには、段階的な手法を完全に捨てる必要がありました。

わかりやすい例えとしてニューラルネットワークの歴史があります。バックプロパゲーションは何十年も存在していましたが、十分な計算資源がなければその潜在能力を発揮できませんでした。2012年にAlexNetがGPUを利用して初めてAIブームが起こったのです — GPU自体は何年も前から存在していたにもかかわらずです。2022年、私たちはTiDBにも独自の「GPUの転換点」が必要だと気付きました。シェアード・ナッシングアーキテクチャはここまで私たちを支えてきましたが、それ以上の進化は難しくなっていました。

そこで私たちは、すべてを根本から作り直すことを選んだのです。

TiDB Xを支える5つのアーキテクチャ原則

何度も試行を重ねた結果、TiDB Xを形作った主要な原則は以下の通りまとめられます。

1. データベースではなくサービスを構築する

これは最も重要な転換です。TiDB Xはユーザーが導入するパッケージ型のデータベースではありません。オンラインのクラウドネイティブサービスであり、その製品としてSQLデータベース (この場合はTiDB Cloud) が提供されるという形です。この違いはすべてに影響します：チーム構成、デプロイ、監視、マルチテナンシー、スケーリング、アップグレード、そしてコンピュートとストレージの役割まで。

このマインドセットが、次の原則へと直接つながっています。

2. 真のSOA (サービス指向アーキテクチャ) を採用する

サービス指向アーキテクチャ (SOA) により、私たちは以下を実現できました：

• きめ細やかななスケーラビリティ
• 高密度なマルチテナンシー
• コスト管理
• 障害ドメインの分離
• コンポーネントの独立した進化

実際のところ、私たちの最大のアーキテクチャ的飛躍の多くは、分散システムのアルゴリズムによるものではなく、システム全体にこのSOAを徹底的に適用したことから生まれました。

3. 物理インスタンスではなく仮想クラスタを採用する

無料で世界中からアクセス可能なデータベースを提供したい場合、ユーザーごとに物理インスタンスを割り当てることはできません。最小構成でさえ同様です。ほとんどのユーザーは「コールド」であり、1時間に数回のリクエストしか送信しません。彼らは重要ですが、専用ハードウェアを割り当てることは不可能です。

TiDB Xでは仮想クラスタを導入しています。仮想クラスタはコンピュートとストレージを共有しながら、メタデータとルーティングによって分離を維持する論理的なクラスタです。仮想クラスタにより、数百万のテナントに効率的にサービスを提供することが可能になります。これは、サーバーレスデータベースの一部ベンダーが行っているように、Postgresのストレージ層をS3に置き換えるだけでは不十分である理由でもあります。完全な垂直分解とサービス指向設計がなければ、「サーバーレス」は表面的なものにとどまります。

4. 「ログがデータベースである」という原則を受け入れる

Auroraがこの考え方を広め、私たちはこれを現代データベース設計における最も根本的なな貢献の一つと考えています。ログが真実の情報源である場合、その他のすべては再構築可能になります：

• NVMeやメモリは高速な読み取りキャッシュを提供します。
• SSDは追記専用の書き込みに優れています。
• レプリケーションにより可用性と耐久性が確保されます。
• ローカルで状態を失っても問題にはなりません、再構築が可能なためです。

これにより、データ構造や正確性保証が簡素化され、カーネル開発者の負荷も軽減されます。

5. TiDBの強みを最大限に活かす：シャーディング戦略

TiDBの既存アーキテクチャは、私たちにいくつかの利点をもたらしました：

• SQLレイヤー (tidb-server) はステートレスで動作していました。
• 当初シームレスなオンラインアップグレードをサポートしていたtidb-proxyは、自然なゲートウェイサービスとなりました。
• TiKVの動的レンジベースシャーディングはすでに存在していました；以前の制約は、シャード移動に物理データの移動が必要でした。

TiDB Xでは、TiKVはステートレスになりますが、シャードの抽象は維持されます。シャードは論理化され、スナップショットストレージはS3に移行します。これにより、非常に大きな利点が生まれます：

• 数百〜数千のTiKVノードを瞬時に起動し、それぞれがシャードを並行してロードが可能。
• ルーティングを更新し、ノードを即座にシャットダウンすることで縮小が可能。
• 数時間に及ぶデータ移行作業を回避。
• シャードごとにRaftログを分割し、シングルライタのボトルネックを排除。
• マルチテナンシーの場合は、単にキーの先頭にtenantID_を追加するだけで、各テナントのフットプリント小さくかつ独立して動作します。

この組み合わせ — 論理シャード + S3スナップショット + ステートレスコンピュート — により、私たちが目指していた突破的な弾力性が実現されます。

TiDB Xで可能になること

TiDB Xは、AIエージェント、動的なワークロード、爆発的に増えるロングテールアプリケーションによって形作られる次世代ソフトウェア時代のために設計されています。SQLがユーザーごと、リクエストごと、コンテキストごとに生成される場合、データベースは数％単位でスケールするのではなく、桁違いに上下にスケールする必要があります。

TiDB Xはまさにそれを可能にします：

• クラスタを数秒で起動
• 数百万の軽量テナントにサービスを提供
• オブジェクトストレージを用いてペタバイト規模までスケール
• 巨大なトラフィックの急増に対応
• 「コールド」ワークロードのコストを最小化
• ユーザーに支持されるSQLという抽象化を維持
• 長期的な正確性と耐久性を確保
• クラウドの動態に応じた弾力性を提供

TiDBは常にアプリケーションの柔軟性を尊重するデータベースとして設計されてきました。TiDB Xは、シェアード・ナッシングアーキテクチャの限界を超えてさらにスケールする道を与えることで、その使命を強化します。

図2：TiDB Xがコンピュートとストレージを分離し、独立してスケールできる仕組み

今後の展望

今後のブログ投稿では、TiDB Xのクラウド管理レイヤーについてさらに深く掘り下げます。このレイヤーは、仮想クラスタのオーケストレーション、ワークロード対応オートスケーリング、マルチテナンシー、共有リソースプールを担当するシステムです。このレイヤーがあることで、TiDB Xは従来のようにユーザーがプロビジョニングして運用するデータベースではなく、現実の需要に応じて常に適応するクラウドサービスのように振る舞います。

また、チームが今日TiDB Xをどのように体験できるかを明確にすることも重要です。TiDB XはTiDB Cloudのコアエンジンであり、オブジェクトストレージベースのアーキテクチャとワークロード対応スケーリングにより、最初から真のサーバーレス弾力性を提供します。ほとんどのユーザーにとって、TiDB Cloud EssentialはTiDB Xを始めるための基本かつ推奨される方法であり、MySQL互換性、エンタープライズ級の信頼性、利用量ベースの課金を提供しつつ、インフラ管理、容量計画、スケーリングの判断を行う必要がありません。

TiDB X自体は独立した製品でもデプロイの選択肢でもありません。TiDB Xは、運用の簡素化、総所有コストの低減、モダンなワークロードにおける長期的スケーラビリティのサポートを可能にする基盤アーキテクチャを提供します。TiDB Cloudが進化するにつれ、TiDB Xはこれらの能力を提供する共通のアーキテクチャ的基盤としてますます重要になります。一方で、TiDB Cloudはチームが迅速に構築し、効率的に運用し、自信を持ってスケールできる最もアクセスしやすい方法であり続けます。

このブログ投稿は、TiDB Xに関するより広範なシリーズの始まりと考えてください — その起源、仕組み、チームが今日どのように活用できるか、そしてTiDB Cloudの未来にどのように影響するかについてです。

このアーキテクチャが実際にどのように機能するか気になりますか？

Manus 1.5がTiDB Xを活用し、AIエージェントが大規模にフルスタックアプリケーションを生成、分岐、進化させる仕組みをご覧ください — 本番環境での事例です。

参照：How Manus 1.5 Uses TiDB X to Let Agents Ship Full-Stack Apps at Scale

The post TiDB Xの誕生：起源、アーキテクチャ、そして今後の展望 appeared first on TiDB.