PostgreSQL Conf JP 2023
まじまっちょJSConf JPより遥かにスーツの人が多い
まじまっちょThe Future PostgreSQL
Fostering｜Adoption Through Extensibility
PostgreSQLの初期のコンセプトから拡張性というは含まれていた。
Data型やフック共有メモリ、ワーカーなどが拡張できる
1000以上のポスグレのエクステンションがある
全てが本番利用可能ではない。
Super Extentions
PostGIS
Citus ダッシュボード向け分散DB
TimescaleDB 時系列データむけ分散DB
PostgreSQL Core Principles
IndexとHeapと相互作用というものはエクステンションでも変わらず使われるAPIとしてある
InsertとDeleteのTupleの扱いはも共通
INSERTもUPDATEもaminsertで行われる。
インデックスはすぐに削除されずバッチ処理でbulk deleteされる
Buffer Manager？
Block Level WAL？
Oriole DBは上記のCoreを置き換えるプロジェクト
Oriole DBはエクステンションとして提供されるが、PostgreSQLのCoreにも小規模（3k行）のパッチを当てている
Table Access Methodの改善
パッチの詳細
まじまっちょAlloy DB for PostgreSQL
GCPのDBはPostgreSQL互換のDBが基本となっている（Alloy DB, Spanner）
Cloud SQL
オープンソースポスグレがそのまま載っている
Spanner
世界中にスケール可能
Full SQL
99.999％の可用性をダウンタウンゼロで提供
Alloy DB
完全にポスグレ互換性があるスケール可能なDB
ストレージと演算の分離、機械学習に基づく管理
書き込みはログの追記のみで一つのストレージに対して全てのノードから行われる
読み取りプールが最大20ノードになり2000vcpに相当する
リーダーはレプリカではない、データのコピーを持っていないから
リードノードのPrimaryからの遅延は10ms未満
Automatic Tiered Caching
クエリのキャッシュは行レベルのキャッシュがデフォルトだが、列のキャッシュもオプショナルで存在する。分析クエリには有用
どの列をキャッシュするかはMLのアルゴリズムで決定されている
Columnar Engine
列指向はスキャンと集計が早い
（new）Vecorized Joins＆Ultla fast Cache
Automatic vacuum management
サポートケースの中で最もVacuumの問題が大きい
CPUとIOのStatsを使ってVacuumを適応的にリソース配分を行う
Index Avisor
負荷に応じてインデックスの提案を行う
Adaptive Memory Managment
メモリキャッシュとBuffer Cacheを負荷に応じて調整してくれる
クラウド以外のデプロイも可能
オンプレ
マルチクラウド
開発にのローカル環境でAlloy DBを利用可能
生成AI AlloyDB AI（Post Training era）
PG Vectorのパフォーマンス向上、四倍大きなベクトルデータを保管可能
まじまっちょ今、改めて考えるPostgreSQLプラットフォーム -コンテナからマルチクラウドまで-
(チュートリアルセッション )
冒頭のサマリー
- 最優先はDBaas
- 中にはKubernetes Insideのものも
- マルチクラウド時代にはDBaasにもDevOps画面のポータビリティが求められる
Postgresのバージョンの追従は
AzureのCosmos→ AWS RDS Aurora -> Google Cloud SQL
のような感じ
クラウドベンダーごとのPostgreSQLの比較
AWS
クラウド上のPostgreSQLは
Compute／Storage一体型（RDS型）と
Compute／Storage分離型（Aurora型）がある
AuroraはCompute／Storage分離の先駆け
一体型の中身は純粋なPostgreSQL
分離型はPostgreSQL部分に大きく手が入っているため、リリースが遅い傾向
EC2上にPostgreSQLを立てるのと比べて、RDSの細かい最適化が行われている（IO部分の最適化）
- OptimizedRead（ソートなどのCache）
- Dedicated Log Volumes（WALを通常のEBSから分離）
Google Cloud
Cloud SQL：RDSタイプDBaas（RDS型）
Alloy DB：クラウドネイティブな構成でPostgreSQLを再実装（Aurora型）
DBサイズは最大で32TB（Auroraは128TB）
Cloud SQLはEnterprise Plusの方がSLAがだいぶ高い
AlloyDB（独自機能をたくさん盛り込んだAuroraタイプのDBaaS）
列指向エンジンや高速キャッシュを搭載
Azure
Azure Database for PostgreSQL
Aurora型ではない
シャーディング型の分散DB（Citus）
Workerでスケール＋列指向で分析系に強み
この形式はAzureのみ
CitusチームはPostgreSQLへのコントリビュートが多い
OCI（オラクル）
OCI Database with PostgreSQL（Aurora型）
オラクルもAurora型のPostgreSQL互換のサービスを出しているらしい
マルチクラウド対応
可用性の観点で言われることが多かったが、（ビジネスによっては）収益で関わる大きな選択になる
マルチクラウドの種類
-
狭義のマルチクラウド
データ連携はしないが同じサービスを複数クラウドサービスプラットっフォームで使える -
クロスクラウド
可用性の観点のマルチクラウド（データ連携をクラウド間で行う）
K8sを利用することでクラウドベンダー間でのDBの差分を無視することができる
北國銀行がGCPとAzure間でSQL Serverの同期更新を行うことに挑戦することを発表
Google CloudでもAlloy DB Omniがk8s上で動くようになれば、他クラウドベンダーとのクロスクラウドができるようになる可能性もある
まじまっちょVACUUM Simulatorを使ってVACUUMをもっと理解しよう
MVCCは内部で論理削除、論理更新をしていてVACUUMする際に削除される
xmin = transaction id
ヒープとは
テーブルこと、Indexなどではなく実際のデータ
ヒープページをたくさんまとめたのがテーブルヒープ、行はタプル
Autovacuumが頻繁に起こることの弊害は何か？
vacuum fullは広い範囲のロックがかかるとあったがAutovacuumではどういうふうにロックがかかるのか？
まじまっちょDBの状態を知って安定運用を実現しよう！～pg_statsinfoのご紹介～
pg_statsinfo概要
スナップショット用のDBにデータを保管してCLIやHTML経由で統計情報が見れる
期間を指定してパフォーマンスのレポートが見れる。
サードパーティのOSSで日本のコミュニティが手動で開発を行っている。
13以前と14以前でインストール方法やドキュメントの参照先が違う
14以降は↓
サーバーログの分配、蓄積、アラート機能がある
pg_stats_infoインストール方法
推奨設定
pg_stats_infoのインストール先はポスグレと同じサーバー？RDSなど使ってる場合は別のインスタンスが必要？
pg_stats_reporterインストール方法
レポートの作成方法（HTML）
スナップショットにコメントをつけて作成できる（パフォーマンスチューニング前、後など）
レポートの内容
- DBサーバーの統計情報
- 障害、性能劣化の情報
- その他の補助情報
CPU Usage
- 100％に張り付いた状態になる傾向があるかをチェックする。将来的にCPU不足が発生しないかの観点で確認
Load AVERAGE - 遅延が発生するとされている「コア数x2」以上とならないかチェックする
Memory Usage
「memfree + cached」が枯渇しないかチェックする（Linuxではメモリは各プログラムが利用終了直後にすぐ解放せず、次のプログラムがメモリを利用する際に獲得される動作である点に留意する）
Statements - SQLの実行回数と実行時間が確認でき、負荷の高いSQLを特定できる
- pg_stat_statementsのextentionを入れていないと後から確認できない
まじまっちょpgvectorを使ってChatGPTとPostgreSQLを連携してみよう！
ChatGPTのデータソースとしてPostgreSQLを使うことができる
RAG：LLMに対して学習済みでない外部データを与えて生成する回答の質を上げる方法
chatgpt-retrieval-plugin
- OpenAIが公開しているプラグイン
LangChainを使う
デモ
家族の好きな食べ物を答えるアプリ
使用したツール
- Python
- PostgreSQL + pgvector
- OpenAI API
- LangChain
データの挿入
- 自然言語で子どもたちの好きな食べ物をテキストで用意
- Vector化したデータをオリジナルテキストと一緒にINSERT
OpenAIのEmbeddingモデルを使っている
テキストEmbeddingモデルは第一世代と第二世代があって、第二世代の方が安くて精度が高いらしい
テキスト生成はtext-davinchi-003(プロンプト生成)
答えが出ることのデモ
もとのテキストにあった内容が回答として出てくる
システムの流れ、実装の解説
- テキストの分割
- ベクトル化
- ポスグレに保存
プロンプトはLangChainが生成する
pgvectorについて
ポスグレでVector型が使えるようになった
CREATE EXTENTIONでインストール可能
0.5.0で大きなリリースがあった
使える演算子としてコサイン距離、ユークリッド距離、内積がある、L1距離、次元数等もある
ベクトルの平均、合計もとれる
OpenAI Embeddingの場合ベクトルの長さは1に正規化されているのでCos類似度 = 内積になるので仕事量の少なさから内積を使った方が良い
インデックス（ivfflatとHNSW）
最も近いベクトルはどれかを探すためのアルゴリズム
ivfflat
最初からあったやつ
インデックス作成時にクラスタリング（K-meansっぽい）
クラスター数の目安
- 100万レコード以下 ：records/1000
- 100万以上：sqrt(records)
最大2000次元までの列に付与可能
データが挿入された後でインデックスの追加
インデックス作成後にはクラスターの重心は更新されない
データの更新がある場合定期的なREINDEXがおすすめ
Concurrencyオプションを設定すればロックは発生しない
HNSW
高速化されたやつ
早くて正確だが、メモリ使用量が大きく、インデックス構築速度が遅い
インデックスのパラメターチューニングはやはりしんどそう