TiDB / Amazon Bedrockで作るRAGアプリケーション

Transcript

3. ⾃⼰紹介 KOITABASHI Yoshitaka PingCAP株式会社 シニアソリューションアーキテクト 💙 Database / Serverless / Container
4. Our Mission エンジニアと企業がスピード、敏捷性、スケールをもって イノベーションを起こせるようにすること MySQLと互換性のある OSSの分散型SQLデータベース グローバル 以上で採⽤ 3,000社 ピンキャップ タイデービー 3,7000+ ★Stars
5. アジェンダ • NewSQL • TiDB / TiDB Serverless • Vector Search • TiDB × Vector Search • RAG Chatbot • Conclusion
6. NewSQL
7. RDBMS / NewSQL ※すべての製品が以下の通りではないですが、大別したイメージとして 
 RDBMS NewSQL ‧マスターとレプリカの明確な区別 ※エンドポイント管理 ‧マスターの性能に律速される ※特にWriteはボトルネック ‧機動的な性能の増減が困難 ‧アプリ側視点での構成がシンプル ※マルチマスター ‧ノード追加による性能向上 ※Read/Write共にスケール ‧リーダースイッチで障害時も⾃動フェイルオーバー  ※バージョンアップ時もダウンタイムなし App Computing Nodes App Read / Write ‧‧‧ Read Only Master Read replica リーダー：読み書き担当 フォロワー：バックアップ担当 （リーダーに） Read / Write チャンクの役割分担 Read / Write
8. TiDB Architecture
10. 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
11. ⾃動シャーディング‧負荷分散 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が、読み書きを処理
12. 障害リカバリ‧無停⽌アップデート 冗⻑構成(障害時挙動) 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
13. TiDB Cloud
14. TiDBの利⽤パターン パターン
 1 Instance TiUP TiDBのセットアップから運⽤まで ※ローカルでも使える パターン
 2 Kubernetes パターン
 3 Cloud TiDB Operator K8sでのセットアップ‧運⽤ TiDB Cloud フルマネージドDBaaS ServerlessとDedicatedがある
15. Serverless マルチテナント型 Dedicated 専有型 • マルチAZ / 各コンポーネントスケール(APIあり) • MySQLからの移⾏ツールもフルで使える ※DataMigration / ChangeFeed • OSSライクに柔軟なチューニング可能 • シングルAZ / Autoスケール ※マルチAZ版も予定 • BranchingやEdge Function⽤のDriver⽤意 • Vector Search※Public Beta機能搭載       のラインナップ
16. 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/
17. 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
18. TiDB Vector Search
19. ⽣成AIに絡む包括的なエコシステムとの統合
20. Vector Search
21. Vector Search ベクトル検索 Embedding よくあるVector Searchのサービス => 入力されたテキストを受け取り、ベクトルを返す
22. テキストとベクトル化 LLMのembeddingモデル ベクトル値 テキスト
23. 最近までのテキスト検索の仕組み Christopher D. Manning, Prabhakar Raghavan and Hinrich Schütze, Introduction to Information Retrieval, Cambridge University Press. 2008. よくある検索エンジン ユーザからの質問 検索インデックスにある ドキュメントの集合 類似度を計算 単語の重複を利 用
24. 類似度の計算⽅法 ①: 検索をする前に文字列のテキストである ユーザのクエリを受け取って、単語を分解 ユーザからの質問 検索インデックスにある ドキュメントの集合 類似度を計算 私 は 人間 です ②: 単語の集合と検索インデックスに 保存された文書にある単語と比較 ③: 単語をより多く含む文章を 関連性が高いとみなし、結果リストの中でより 高いランクに設定
25. https://mathinsight.org/image/vector_2d_add ベクトル空間モデルでの表現 文章を単語の集合ではなく、 各単語が文章内にどういう頻度で 現れるかを考える方法 TiDB ドキュメントの集合 Serverless この単語に注目 各文章やドキュメントを 1つずつ見ていき、各単 語の頻度を計測 各単語を２つの数字に変換
26. ベクトル空間での類似度計算 文章を数字のリストとし、ベクトルで見れば数学的概念で、 2つの文章間の類似度を表現可能 しかし、実際にはテキストでも単語の登場回数だけでは 文章の正確な意味を十分に捉えることができない・・・ => なので、2つのものをベクトル表現にする新しい方法が必要 ベクトル表現を提供してくれるサービス Ex. ・OpenAI ・Cohere ・Amazon Bedrock
27. 実際には、変換されたベクトルに対してどう検索を行うのでしょうか？ キーワードベース検索時には、 Lucene / Solr / ElastcSearchといった 効率よく検索できるデータ構造を提供してくれるサービスは存在 ベクトル検索の為に、ベクトルに対して高速に検索するための 新しいアルゴリズムが必要 問題提起
28. TiDB Vector Search
29. インデックスとベクトル距離検索関数 [インデックス ] ・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]');
30. ベクトル検索についてのおさらい Docs Query ベクトルをインデックス化 ベクトルをクエリし、 インデックス検索に利用 インデックスを検索
31. TiDB × Vector Search
32. TiDB × Vector Searchのメリット NewSQL + HTAP機能を使い高いパフォーマンスで セマンティック検索が可能 Serverlessの為、自動でスケール データとベクトル値を一緒に保存でき、 SQLでクエリが可能
33. 試してみよう => ベクトルカラム
34. 複数カラム(ベクトル検索)を含むSELECTクエリ
35. 実⾏計画を確認
36. TiFlashの利⽤も可能
37. TiDB × Dify × Amazon Bedrock
38. RAGのAIチャットボット構築時のVector Serchに利⽤する例
39. Difyとは？ https://dify.ai/jp • OSS / SaaSで提供されている LLMアプリ開発プラットフォーム • ノーコード (ローコード )で生成AIアプリが開発可能 • RAGやAIエージェントが簡単に作成可能 Knowledge Retrievalと チャットボットアプリの例
40. TiDB × Dify × Amazon Bedrock RAGを使ったチャットボットアプリ Start Knowledge Retrieval LLM Answer Web コンテンツ ・Claude3-Sonnet ・Titan Embeddings G1 Vector Search Amazon Bedrock コンテナ化 ローカル環境
41. Web コンテンツ Vector Search ・Claude3-Sonnet ・Titan Embeddings G1 Amazon Bedrock Dify側のコンソール画⾯上での⾒え⽅
42. TiDBをVector Storeとして扱う時の設定 ①: Docker-compose内にあるTiDBへの接続情報を入力 ②: Vector Storeの設定を”tidb_vector”に変更
43. 実際のRAGアプリケーションの動作検証 ユーザからの入力 生成された回答 事前に保存された情報
44. Conclusion
45. 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)と合わせてベクトル検索が可能