Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

⾃⼰紹介 KOITABASHI Yoshitaka PingCAP株式会社 シニアソリューションアーキテクト 💙 Database / Serverless / Container

Slide 4

Slide 4 text

Our Mission エンジニアと企業がスピード、敏捷性、スケールをもって イノベーションを起こせるようにすること MySQLと互換性のある OSSの分散型SQLデータベース グローバル 以上で採⽤ 3,000社 ピンキャップ タイデービー 3,7000+ ★Stars

Slide 5

Slide 5 text

アジェンダ ● NewSQL ● TiDB / TiDB Serverless ● Vector Search ● TiDB × Vector Search ● RAG Chatbot ● Conclusion

Slide 6

Slide 6 text

NewSQL

Slide 7

Slide 7 text

RDBMS / NewSQL ※すべての製品が以下の通りではないですが、大別したイメージとして 
 RDBMS NewSQL ‧マスターとレプリカの明確な区別 ※エンドポイント管理 ‧マスターの性能に律速される ※特にWriteはボトルネック ‧機動的な性能の増減が困難 ‧アプリ側視点での構成がシンプル ※マルチマスター ‧ノード追加による性能向上 ※Read/Write共にスケール ‧リーダースイッチで障害時も⾃動フェイルオーバー  ※バージョンアップ時もダウンタイムなし App Computing Nodes App Read / Write ‧‧‧ Read Only Master Read replica リーダー:読み書き担当 フォロワー:バックアップ担当 (リーダーに) Read / Write チャンクの役割分担 Read / Write

Slide 8

Slide 8 text

TiDB Architecture

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

TiKV TiKVのアーキテクチャー Key-Value 型データベース ● CNCF Graduated Project ● 書き込み性能の⾼いLSMツリー(追記型) ● データ永続化:SSTファイルを圧縮して管理 (1,Tom) 
 (2,Jack) 
 (2,Jack) 
 ①
 ②
 Sorted String Table
 (1,Tom) 
 (2,Jack) 
 (1,Tom) 
 ③
 (1,Tom) 
 (2,Jack) 
 (1,Tom) 
 (2,Jack) 
 ④
 Background処理 Raft Engine Raft Engine Raft Engine

Slide 11

Slide 11 text

⾃動シャーディング‧負荷分散 Region毎の冗⻑化により耐障害性、負荷分散を実現 Region 3* Follower
 バックアップ 
 Region 1* Leader 
 読み書き可能 
 Region 2* Follower
 バックアップ 
 Region 3* Follower
 バックアップ 
 Region 1* Follower
 バックアップ 
 Region 2* Leader 
 読み書き可能 
 Region 3* Leader 
 読み書き可能 
 Region 1* Follower
 バックアップ 
 Region 2* Follower
 バックアップ 
 例:ユーザーテーブル データサイズは、デフォルト96MB ※⼩さいサイズにする事で柔軟性を確保 96MB 96MB 96MB TiKV TiKV TiKV TiDB TiDB 分散配置されたLeaderが、読み書きを処理

Slide 12

Slide 12 text

障害リカバリ‧無停⽌アップデート 冗⻑構成(障害時挙動) Leaderを再配置する(他ノードのTiKVに移動)ことで、   サービスは継続 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 ⾼速なスケールアウト 96MBという⼩さいサイズで管理している為、 ノード追加した瞬間からデータ移⾏が開始 昇格(リーダ) 
 無停⽌メンテナンスを実現 ファームウェアアップデート時にリーダーを 別ノードへ移動しローリングアップグレードが可能 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 TiKV バックアップデータを移動し
 リーダーに昇格
 TiKV Region 3 
 バックアップ 
 Region 1* 
 読み書き可能 
 Region 2 
 バックアップ 
 TiKV Region 3 
 バックアップ 
 Region 1 
 バックアップ 
 Region 2* 
 読み書き可能 
 TiKV Region 3* 
 読み書き可能 
 Region 1 
 バックアップ 
 Region 2 
 バックアップ 
 昇格(リーダ) 
 リーダを移動しながら 順にアップグレード対応 Region 1 
 バックアップ 
 12

Slide 13

Slide 13 text

TiDB Cloud

Slide 14

Slide 14 text

TiDBの利⽤パターン パターン
 1 Instance TiUP TiDBのセットアップから運⽤まで ※ローカルでも使える パターン
 2 Kubernetes パターン
 3 Cloud TiDB Operator K8sでのセットアップ‧運⽤ TiDB Cloud フルマネージドDBaaS ServerlessとDedicatedがある

Slide 15

Slide 15 text

Serverless マルチテナント型 Dedicated 専有型 ● マルチAZ / 各コンポーネントスケール(APIあり) ● MySQLからの移⾏ツールもフルで使える ※DataMigration / ChangeFeed ● OSSライクに柔軟なチューニング可能 ● シングルAZ / Autoスケール ※マルチAZ版も予定 ● BranchingやEdge Function⽤のDriver⽤意 ● Vector Search※Public Beta機能搭載       のラインナップ

Slide 16

Slide 16 text

TiDB Serverless 数十秒で起動し、自動でスケールする 従量課金のサーバレスデータベース サーバの管理不要 拡張が自動 ⾃動拡張 Pay as you go 従量課⾦ 自動フェイルオー バーと自己回復 ゼロ ダウンタイム + HTAP機能も使用 可能 リアルタイム分析 パフォーマンス改善 日本語による SQL生成支援 AI アシスタント MySQL driverや ORMツールからも 利⽤可能 MySQL互換 https://aws.amazon.com/jp/blogs/storage/how-pingcap-transformed-ti db-into-a-serverless-dbaas-using-amazon-s3-and-amazon-ebs/

Slide 17

Slide 17 text

Shared Gateway Isolated SQL Layer Shared Storage Layer Gateway Gateway Gateway Virtual Cluster - Tenant 1 TiDB MPP Row Engine Row Engine Row Engine Virtual Cluster - Tenant 2 Resource Pool TiDB TiDB MPP Worker Columnar Engine Columnar Engine Columnar Engine TiDB MPP Virtual Cluster - Tenant n TiDB MPP MPP MPP TiDB ・・・ EBS EBS EBS EBS EBS EBS Shared Storage Pool Amazon S3 Shared Service Compacti on Checksu m Analyze Coproces sor Import Export DDL PD TSO Scheduling API Server Architecture

Slide 18

Slide 18 text

TiDB Vector Search

Slide 19

Slide 19 text

⽣成AIに絡む包括的なエコシステムとの統合

Slide 20

Slide 20 text

Vector Search

Slide 21

Slide 21 text

Vector Search ベクトル検索 Embedding よくあるVector Searchのサービス => 入力されたテキストを受け取り、ベクトルを返す

Slide 22

Slide 22 text

テキストとベクトル化 LLMのembeddingモデル ベクトル値 テキスト

Slide 23

Slide 23 text

最近までのテキスト検索の仕組み Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, Introduction to Information Retrieval, Cambridge University Press. 2008. よくある検索エンジン ユーザからの質問 検索インデックスにある ドキュメントの集合 類似度を計算 単語の重複を利 用

Slide 24

Slide 24 text

類似度の計算⽅法 ①: 検索をする前に文字列のテキストである ユーザのクエリを受け取って、単語を分解 ユーザからの質問 検索インデックスにある ドキュメントの集合 類似度を計算 私 は 人間 です ②: 単語の集合と検索インデックスに 保存された文書にある単語と比較 ③: 単語をより多く含む文章を 関連性が高いとみなし、結果リストの中でより 高いランクに設定

Slide 25

Slide 25 text

https://mathinsight.org/image/vector_2d_add ベクトル空間モデルでの表現 文章を単語の集合ではなく、 各単語が文章内にどういう頻度で 現れるかを考える方法 TiDB ドキュメントの集合 Serverless この単語に注目 各文章やドキュメントを 1つずつ見ていき、各単 語の頻度を計測 各単語を2つの数字に変換

Slide 26

Slide 26 text

ベクトル空間での類似度計算 文章を数字のリストとし、ベクトルで見れば数学的概念で、 2つの文章間の類似度を表現可能 しかし、実際にはテキストでも単語の登場回数だけでは 文章の正確な意味を十分に捉えることができない・・・ => なので、2つのものをベクトル表現にする新しい方法が必要 ベクトル表現を提供してくれるサービス Ex. ・OpenAI ・Cohere ・Amazon Bedrock

Slide 27

Slide 27 text

実際には、変換されたベクトルに対してどう検索を行うのでしょうか? キーワードベース検索時には、 Lucene / Solr / ElastcSearchといった 効率よく検索できるデータ構造を提供してくれるサービスは存在 ベクトル検索の為に、ベクトルに対して高速に検索するための 新しいアルゴリズムが必要 問題提起

Slide 28

Slide 28 text

TiDB Vector Search

Slide 29

Slide 29 text

インデックスとベクトル距離検索関数 [インデックス ] ・HNSWインデックスを利用可能 ・例えば、コサイン距離を使用して HNSW インデックスを下記のように作成 > CREATE TABLE vector_table_with_index (id int PRIMARY KEY, doc TEXT, embedding VECTOR(3) COMMENT "hnsw(distance=cosine)"); [利用可能なベクトル距離検索関数 ] ・Cosine Distance > SELECT vec_cosine_distance('[1,1,1]', '[1,2,3]'); ・Manhattan Distance > SELECT vec_l1_distance('[1,1,1]', '[1,2,3]'); ・Squared Euclidean > SELECT vec_l2_distance('[1,1,1]', '[1,2,3]'); ・Negative Inner Product > SELECT vec_negative_inner_product('[1,1,1]', '[1,2,3]');

Slide 30

Slide 30 text

ベクトル検索についてのおさらい Docs Query ベクトルをインデックス化 ベクトルをクエリし、 インデックス検索に利用 インデックスを検索

Slide 31

Slide 31 text

TiDB × Vector Search

Slide 32

Slide 32 text

TiDB × Vector Searchのメリット NewSQL + HTAP機能を使い高いパフォーマンスで セマンティック検索が可能 Serverlessの為、自動でスケール データとベクトル値を一緒に保存でき、 SQLでクエリが可能

Slide 33

Slide 33 text

試してみよう => ベクトルカラム

Slide 34

Slide 34 text

複数カラム(ベクトル検索)を含むSELECTクエリ

Slide 35

Slide 35 text

実⾏計画を確認

Slide 36

Slide 36 text

TiFlashの利⽤も可能

Slide 37

Slide 37 text

TiDB × Dify × Amazon Bedrock

Slide 38

Slide 38 text

RAGのAIチャットボット構築時のVector Serchに利⽤する例

Slide 39

Slide 39 text

Difyとは? https://dify.ai/jp ● OSS / SaaSで提供されている LLMアプリ開発プラットフォーム ● ノーコード (ローコード )で生成AIアプリが開発可能 ● RAGやAIエージェントが簡単に作成可能 Knowledge Retrievalと チャットボットアプリの例

Slide 40

Slide 40 text

TiDB × Dify × Amazon Bedrock RAGを使ったチャットボットアプリ Start Knowledge Retrieval LLM Answer Web コンテンツ ・Claude3-Sonnet ・Titan Embeddings G1 Vector Search Amazon Bedrock コンテナ化 ローカル環境

Slide 41

Slide 41 text

Web コンテンツ Vector Search ・Claude3-Sonnet ・Titan Embeddings G1 Amazon Bedrock Dify側のコンソール画⾯上での⾒え⽅

Slide 42

Slide 42 text

TiDBをVector Storeとして扱う時の設定 ①: Docker-compose内にあるTiDBへの接続情報を入力 ②: Vector Storeの設定を”tidb_vector”に変更

Slide 43

Slide 43 text

実際のRAGアプリケーションの動作検証 ユーザからの入力 生成された回答 事前に保存された情報

Slide 44

Slide 44 text

Conclusion

Slide 45

Slide 45 text

POINT 1 NewSQL POINT 2 HTAP POINT 3 MySQL互換 POINT 4 フルマネージド POINT 5 Vector Search Write含むスループットと 可⽤性の向上(耐障害性/VerUpもオンライン) ハイブリッドワークロード対応 (OLTP + OLAP) MySQL エコシステムも利⽤ 既存ナレッジを最⼤限活かす TiDB Cloudの利⽤が可能 Serverless / Dedicated 既存のデータ(NewSQL)と合わせてベクトル検索が可能

Slide 46

Slide 46 text

No content

Slide 47

Slide 47 text

No content