狠狠撸

狠狠撸Share a Scribd company logo

爆速！DBチューニング超入門 ?DB性能の基礎とPG-Stromによる高速化? OSC2024 Online/Fall版

?Download as PPTX, PDF?
?
Toru Miyahara
Toru Miyahara

爆速！DBチューニング超入門 ?DB性能の基礎とPG-Stromによる高速化?

1 of 35
Download to read offline
爆速！ DB チューニング超入門 ? DB 性能の基礎と PG-Strom による高速化? 日本仮想化技術株式会社 宮原 徹
自己紹介 ? 本名：宮原 徹 ? 1972 年 1 月 神奈川県生まれ ? 1994 年 3 月 中央大学法学部法律学科卒業 ? 1994 年 4 月 日本オラクル株式会社入社 – PC サーバ向け RDBMS 製品マーケティングに従事 – Linux 版 Oracle8 の日本市場向け出荷に貢献 ? 2000 年 3 月 株式会社デジタルデザイン 東京支社長および 株式会社アクアリウムコンピューター 代表取締役社長に 就任 – 2000 年 6 月 （株）デジタルデザイン、ナスダック?ジャパン 上場（ 4764 ） ? 2001 年 1 月 株式会社びぎねっと 設立 ? 2006 年 12 月 日本仮想化技術株式会社 設立 ? 2008 年 10 月 IPA 「日本 OSS 貢献者賞」受賞 ? 2009 年 10 月 日中韓 OSS アワード 「特別貢献賞」受賞 2
日本仮想化技術株式会社 概要 ? 社名：日本仮想化技術株式会社 – 英語名： VirtualTech Japan Inc. – 略称：日本仮想化技術／ VTJ ? 設立： 2006 年 12 月 ? 資本金： 3,000 万円 ? 売上高： 1 億 8100 万円（ 2022 年 7 月期） ? 本社：東京都渋谷区渋谷 1-8-1 ? 取締役：宮原 徹（代表取締役社長兼 CEO ） ? 伊藤 宏通（取締役 CTO ） ? スタッフ： 11 名（うち 8 名が仮想化技術専門エンジニアです） ? URL ： http://VirtualTech.jp/ ? 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築?運用サポート – 5G 活用のためのインフラ?サービス研究開発 – DevOps 支援サービスの提供 – GPU を活用した超高速データ分析基盤「爆速 DB 」の提供 ベンダーニュートラル な独立系仮想化技術の エキスパート集団 3
Think IT で本内容を連載開始 4 https://thinkit.co.jp/series/11210
5 DB の性能の基本
DB の検索性能を決定する要 素 ? データの読み込み ? 検索処理 ? 集計その他の演算処理 ? 本資料はビッグデータ処理などを想定した検索 処理のみを取り上げています ? DBMS （ DataBase Management System ）という ブラックボックスを SQL などで操作する観点で 解説しており、 DBMS の実装によって詳細が異 なる場合があります
データの読み込み ? データはストレージからメモリに読み込んで処理 ? ストレージの読み込み速度とは – ストレージ自体の速度 – 接続経路の速度 ? ストレージ自体の速度 – IOPS や読み書き速度（○ MB/ 秒）などで表される – HDD ならプラッターサイズや回転速度が影響 – SSD ならシリコンやコントローラー速度が影響 ? 接続経路の速度 – SATA や SAS 、 NVMe （ PCI Express バス直結） – SATA(6Gbps) ＜ SAS(12Gbps) ＜ NVMe(64Gbps) ※ ? NVMe は PCIe 4.0 の x4 レーンを想定 ※ 理論値であり、プロトコルオーバーヘッドなどで実速度は低下します データ メインメ モリ CPU
接続種類 帯域 主な用途 SATA 6Gbps 一般的な PC SAS 12Gbps サーバー 専用ストレージ NVMe 64Gbps （ PCI-Express 4.0 ） 最近の PC ストレージの接続経路と速度
検索処理 ? メモリに読み込んだデータを CPU で処 理 ? WHERE 句による条件一致処理 – IN 演算子や LIKE 演算子などの処理を含む – インデックスが使われない場合には全件検 索 – 副問い合わせによる条件値の抽出 ? JOIN 句による表結合処理 ? SELECT 選択リストによるデータの抽 出 データ メインメ モリ CPU
集計その他の演算処理 ? 検索処理されたデータに対する追加処 理 – CPU とメモリを使って処理 ? ソート処理 ? GROUP BY 句による集約 ? 集約関数による各種集計処理 – COUNT 関数など 演算処理を行った結果をアプリに返す
11 DB の性能を向上させるには
データベース性能向上の方法 ? ストレージの読み込みを速くする ? ハードウェアの改善など ? データの所在を明らかにする ? インデックスの利用 ? パーティショニング ? 検索処理や演算処理を速くする ? CPU やメモリ、ストレージを増やす ? 単体性能を向上させるスケールアップ ? 処理を分散させるスケールアウト
データの読み込みを速くする ? より高速なストレージデバイスを使用する – HDD より SSD – SATA ＜ SAS ＜ NVMe – FibreChannel や iSCSI で接続経路を広帯域化 ? デバイスを複数用意する – RAID 0 （ストライピング）化 ? 必要なデータだけ読み込むことで読み込み量を減らす – インデックスの活用 – カラム（列）指向データベース ? 最初からメモリ（バッファ）に読み込んでおく – インメモリデータベース
データの所在を明らかにする ? データの在処が分からなければ全件検索するしかない – 読み込みに時間がかかる – メモリが大量に必要となる ? インデックスを利用してデータの所在を明らかにする ? インデックスも万能ではない – データ件数が少ない – カーディナリティが低い（「 0 か 1 か」など取る値の種類 が少ない） ? パーティショニングでデータを分割する ? カラム（列）志向データベースの利用 – 抽出したい列が決まっている場合
ID NAME DEPT 1 山田一郎 営業部 2 岡本太郎 開発部 3 宮原徹 サポート 部 4 小川夕子 企画部 SELECT NAME FROM EMP WHERE ID=3 ID 列に対する インデックス 検索 インデックスにより 行を特定 インデックスを使った高速化
DATE QTY 2024-01-01 10 2024-01-02 20 …… …… DATE QTY 2024-02-01 15 2024-02-02 8 …… …… DATE QTY 2024-03-01 12 2024-03-02 9 …… …… SELECT QTY FROM STOCK WHERE DATE BETWEEN ‘2024-02-01’AND ‘2024-02-29’ 日付範囲の条件に含まれるパーティション表だけを検索 ※ 日付型のデータ指定方法は環境によって異なります パーティショニング
検索処理や演算処理を速くす る 1 台を高速化するスケールアップ ? CPU コアのクロック数を高速化する – プロセスルールの微細化の限界と発熱の制限 ? CPU コア数を増やす – ダイサイズによる実装可能コア数の制限 – マルチプロセスやマルチスレッドで活用 複数台で高速化するスケールアウト ? 台数を増やしてクラスター化する – 複数台利用によるコストの増加 – 管理やトラブル解決の煩雑さ
データ ストレー ジ メモリ CPU 1 台のマシンのハードウェアを強化するスケールアップ型 データ ストレー ジ データ ストレー ジ メモリ メモリ CPU CPU スケールアップ型
データ ストレー ジ メモリ CPU サーバーの台数を増やして並列動作させるスケールアウト型 データ ストレー ジ メモリ CPU データ ストレー ジ メモリ CPU スケールアウト型
中間まとめ： DB 検索が遅くなる要因 ? ストレージの速度が遅い ? データの量が多い ? CPU が遅い（クロック数?コア数） ? メモリが少ない ? インデックスが適切に使われていない ? 処理が複雑（副問い合わせや集計処 理）
GPU 活用による高速化 ? PG-STROM の仕組み? 21
PG-Strom の高速化手法 ? PG-Strom は PostgreSQL を拡張?高速化 – GPU による超並列処理 – GPUDirect Storage によるデータ高速読込 – Apache Arrow によるデータ読込の最適化 ? 通常は遅くなる処理を高速化 – インデックスが効かないフルスキャン検索 – ビッグデータの集計処理 – 位置情報データの検索処理
GPU による超並列処理 ? CPU と GPU のコア数に大きな違い – 現在のサーバー用 CPU がプロセッサあた り最大 48 コアから 96 コア – 現在のエンタープライズ用 GPU が約 5000 コア ? データの検索処理や集計処理を並列化 – より多くのコアで超並列処理 – 単純な処理ほど並列化に向いている ? 計算機は条件分岐などの複雑な処理が苦手
GPUDirect Storage による高速読込 ? NVMe 接続されたストレージから GPU のメモリ に対して直接データを読み込む技術 – メインメモリ経由で GPU メモリに読み込むより高速 ? PCIe 4.0 x4 接続の SSD を 4 台接続して 256Gbps の帯域幅を確保 – バイト換算で 32GB/ 秒 ※理論値 ? NVMe-oF （ NVMe over Fabrics ）により、外部ス トレージから高速な Ethernet 経由で直接読み込み も可能 – 100GbE でバイト換算で約 12GB/ 秒 ※理論値 ※ 理論値は概算値であり、プロトコルオーバーヘッドなどで実速度は低下します
GPUDirect Storage ? データをメインメモリ経由ではなく直 接 GPU メモリに読み込み 25 デー タ GPU メモ リ GPU コア メインメモ リ CPU
Apache Arrow による読込の最適化 ? Apache Arrow 形式はカラム（列）指向のデー タフォーマット – インメモリデータベースに向いている ? あらかじめ集計などを行う列を抽出してデータ ファイル化 – 読込量を減らして高速処理 ? 更新はできないので検索処理のみに使用 – OLTP 系 DB ならテーブルから Arrow 形式に変換 ? Fluentd の出力を Arrow 形式で保存 – IoT などのシステム
GPU キャッシュ ? GPU メモリ上にデータをキャッシュ – ストレージからの読込不要に – GPU メモリに乗りきるデータサイズに有効 ? Tesla A100 で 80GB の GPU メモリ ? メインメモリで OLTP 処理されている テーブルデータを差分同期可能
PostGIS 関数の GPU 対応 ? 地理空間情報を扱う PostGIS 関数を GPU 対応 – 対応している関数は一部の関数のみ ? PostGIS では点や線分、区画（ポリゴン）など をジオメトリ型として扱う – 例：緯度経度からジオメトリ型（点）に変換できる ? 関数の例 – st_contains() ：ジオメトリ a （ポリゴン等）にジオ メトリ b （点など）が包含されるかを判定 – st_distance() ：ジオメトリ間の距離を返す ? GiST インデックス利用で更に高速化可能
現在の開発状況 ? 新版バージョン Ver5 系が正式リリース – 内部アーキテクチャの改善 – DPU （ NIC などのプロセッサ）対応 29 https://github.com/heterodb/pg-strom
OSS 版とサブスクリプションの違い ? OSS 版とサブスクリプション購入には 以下の違いがあります 機能 OSS 版 サブスクリプション GPU 数 1 基のみ 複数可能 GPUDirect Storage 1 台のみ※ 複数台 GiST インデックス結合 × ○ HyperLogLog × ○ 技術サポート × メール アップデートのサポート × ○ ※GPU は Tesla が必要です。 GeForce では動きません
OSS 版 PG-Strom 導入 ? OSS 版 PG-Strom は CUDA 対応 GPU があれば 動作可能 – GPUDirect Storage は Tesla が必要 ? 対応 Linux ディストリビューションは CUDA がサポートされているもの – インストールのしやすさから RHEL 系推奨 ? インストールガイドを提供 ? Think IT の記事もあります https://thinkit.co.jp/article/23090
爆速 DB ? 「爆速 DB 」は PG-Strom をベースに導入から運 用までをワンストップでサポートするデータ分析 基盤ソリューションです ? 推奨ハードウェア構成をベースにしたハードウェ アアプライアンスを提供しています – サブスクリプションのみ購入も可能 ? 仮想マシンやコンテナでの動作もサポートします ? GPU が扱える各種クラウドサービスにも対応し ます – mdx 、さくらの高火力サーバーなど
活用ユースケース ? 大容量ログの解析に – Web サービス等のアクセスログ – 通信ログ – IoT のセンサー等のログ ? 位置情報分析 – 移動体通信デバイスの位置情報分析
34 お問い合わせ先 メールにて sales@VirtualTech.jp 評価したい等々、 お気軽にお問い合わせください
35 ありがとうございました

More Related Content

爆速！DBチューニング超入門 ?DB性能の基礎とPG-Stromによる高速化? OSC2024 Online/Fall版

  • 1. 爆速！ DB チューニング超入門 ? DB 性能の基礎と PG-Strom による高速化? 日本仮想化技術株式会社 宮原 徹
  • 2. 自己紹介 ? 本名：宮原 徹 ? 1972 年 1 月 神奈川県生まれ ? 1994 年 3 月 中央大学法学部法律学科卒業 ? 1994 年 4 月 日本オラクル株式会社入社 – PC サーバ向け RDBMS 製品マーケティングに従事 – Linux 版 Oracle8 の日本市場向け出荷に貢献 ? 2000 年 3 月 株式会社デジタルデザイン 東京支社長および 株式会社アクアリウムコンピューター 代表取締役社長に 就任 – 2000 年 6 月 （株）デジタルデザイン、ナスダック?ジャパン 上場（ 4764 ） ? 2001 年 1 月 株式会社びぎねっと 設立 ? 2006 年 12 月 日本仮想化技術株式会社 設立 ? 2008 年 10 月 IPA 「日本 OSS 貢献者賞」受賞 ? 2009 年 10 月 日中韓 OSS アワード 「特別貢献賞」受賞 2
  • 3. 日本仮想化技術株式会社 概要 ? 社名：日本仮想化技術株式会社 – 英語名： VirtualTech Japan Inc. – 略称：日本仮想化技術／ VTJ ? 設立： 2006 年 12 月 ? 資本金： 3,000 万円 ? 売上高： 1 億 8100 万円（ 2022 年 7 月期） ? 本社：東京都渋谷区渋谷 1-8-1 ? 取締役：宮原 徹（代表取締役社長兼 CEO ） ? 伊藤 宏通（取締役 CTO ） ? スタッフ： 11 名（うち 8 名が仮想化技術専門エンジニアです） ? URL ： http://VirtualTech.jp/ ? 仮想化技術に関する研究および開発 – 仮想化技術に関する各種調査 – 仮想化技術を導入したシステムの構築?運用サポート – 5G 活用のためのインフラ?サービス研究開発 – DevOps 支援サービスの提供 – GPU を活用した超高速データ分析基盤「爆速 DB 」の提供 ベンダーニュートラル な独立系仮想化技術の エキスパート集団 3
  • 6. DB の検索性能を決定する要 素 ? データの読み込み ? 検索処理 ? 集計その他の演算処理 ? 本資料はビッグデータ処理などを想定した検索 処理のみを取り上げています ? DBMS （ DataBase Management System ）という ブラックボックスを SQL などで操作する観点で 解説しており、 DBMS の実装によって詳細が異 なる場合があります
  • 7. データの読み込み ? データはストレージからメモリに読み込んで処理 ? ストレージの読み込み速度とは – ストレージ自体の速度 – 接続経路の速度 ? ストレージ自体の速度 – IOPS や読み書き速度（○ MB/ 秒）などで表される – HDD ならプラッターサイズや回転速度が影響 – SSD ならシリコンやコントローラー速度が影響 ? 接続経路の速度 – SATA や SAS 、 NVMe （ PCI Express バス直結） – SATA(6Gbps) ＜ SAS(12Gbps) ＜ NVMe(64Gbps) ※ ? NVMe は PCIe 4.0 の x4 レーンを想定 ※ 理論値であり、プロトコルオーバーヘッドなどで実速度は低下します データ メインメ モリ CPU
  • 8. 接続種類 帯域 主な用途 SATA 6Gbps 一般的な PC SAS 12Gbps サーバー 専用ストレージ NVMe 64Gbps （ PCI-Express 4.0 ） 最近の PC ストレージの接続経路と速度
  • 9. 検索処理 ? メモリに読み込んだデータを CPU で処 理 ? WHERE 句による条件一致処理 – IN 演算子や LIKE 演算子などの処理を含む – インデックスが使われない場合には全件検 索 – 副問い合わせによる条件値の抽出 ? JOIN 句による表結合処理 ? SELECT 選択リストによるデータの抽 出 データ メインメ モリ CPU
  • 10. 集計その他の演算処理 ? 検索処理されたデータに対する追加処 理 – CPU とメモリを使って処理 ? ソート処理 ? GROUP BY 句による集約 ? 集約関数による各種集計処理 – COUNT 関数など 演算処理を行った結果をアプリに返す
  • 12. データベース性能向上の方法 ? ストレージの読み込みを速くする ? ハードウェアの改善など ? データの所在を明らかにする ? インデックスの利用 ? パーティショニング ? 検索処理や演算処理を速くする ? CPU やメモリ、ストレージを増やす ? 単体性能を向上させるスケールアップ ? 処理を分散させるスケールアウト
  • 13. データの読み込みを速くする ? より高速なストレージデバイスを使用する – HDD より SSD – SATA ＜ SAS ＜ NVMe – FibreChannel や iSCSI で接続経路を広帯域化 ? デバイスを複数用意する – RAID 0 （ストライピング）化 ? 必要なデータだけ読み込むことで読み込み量を減らす – インデックスの活用 – カラム（列）指向データベース ? 最初からメモリ（バッファ）に読み込んでおく – インメモリデータベース
  • 14. データの所在を明らかにする ? データの在処が分からなければ全件検索するしかない – 読み込みに時間がかかる – メモリが大量に必要となる ? インデックスを利用してデータの所在を明らかにする ? インデックスも万能ではない – データ件数が少ない – カーディナリティが低い（「 0 か 1 か」など取る値の種類 が少ない） ? パーティショニングでデータを分割する ? カラム（列）志向データベースの利用 – 抽出したい列が決まっている場合
  • 15. ID NAME DEPT 1 山田一郎 営業部 2 岡本太郎 開発部 3 宮原徹 サポート 部 4 小川夕子 企画部 SELECT NAME FROM EMP WHERE ID=3 ID 列に対する インデックス 検索 インデックスにより 行を特定 インデックスを使った高速化
  • 16. DATE QTY 2024-01-01 10 2024-01-02 20 …… …… DATE QTY 2024-02-01 15 2024-02-02 8 …… …… DATE QTY 2024-03-01 12 2024-03-02 9 …… …… SELECT QTY FROM STOCK WHERE DATE BETWEEN ‘2024-02-01’AND ‘2024-02-29’ 日付範囲の条件に含まれるパーティション表だけを検索 ※ 日付型のデータ指定方法は環境によって異なります パーティショニング
  • 17. 検索処理や演算処理を速くす る 1 台を高速化するスケールアップ ? CPU コアのクロック数を高速化する – プロセスルールの微細化の限界と発熱の制限 ? CPU コア数を増やす – ダイサイズによる実装可能コア数の制限 – マルチプロセスやマルチスレッドで活用 複数台で高速化するスケールアウト ? 台数を増やしてクラスター化する – 複数台利用によるコストの増加 – 管理やトラブル解決の煩雑さ
  • 20. 中間まとめ： DB 検索が遅くなる要因 ? ストレージの速度が遅い ? データの量が多い ? CPU が遅い（クロック数?コア数） ? メモリが少ない ? インデックスが適切に使われていない ? 処理が複雑（副問い合わせや集計処 理）
  • 22. PG-Strom の高速化手法 ? PG-Strom は PostgreSQL を拡張?高速化 – GPU による超並列処理 – GPUDirect Storage によるデータ高速読込 – Apache Arrow によるデータ読込の最適化 ? 通常は遅くなる処理を高速化 – インデックスが効かないフルスキャン検索 – ビッグデータの集計処理 – 位置情報データの検索処理
  • 23. GPU による超並列処理 ? CPU と GPU のコア数に大きな違い – 現在のサーバー用 CPU がプロセッサあた り最大 48 コアから 96 コア – 現在のエンタープライズ用 GPU が約 5000 コア ? データの検索処理や集計処理を並列化 – より多くのコアで超並列処理 – 単純な処理ほど並列化に向いている ? 計算機は条件分岐などの複雑な処理が苦手
  • 24. GPUDirect Storage による高速読込 ? NVMe 接続されたストレージから GPU のメモリ に対して直接データを読み込む技術 – メインメモリ経由で GPU メモリに読み込むより高速 ? PCIe 4.0 x4 接続の SSD を 4 台接続して 256Gbps の帯域幅を確保 – バイト換算で 32GB/ 秒 ※理論値 ? NVMe-oF （ NVMe over Fabrics ）により、外部ス トレージから高速な Ethernet 経由で直接読み込み も可能 – 100GbE でバイト換算で約 12GB/ 秒 ※理論値 ※ 理論値は概算値であり、プロトコルオーバーヘッドなどで実速度は低下します
  • 25. GPUDirect Storage ? データをメインメモリ経由ではなく直 接 GPU メモリに読み込み 25 デー タ GPU メモ リ GPU コア メインメモ リ CPU
  • 26. Apache Arrow による読込の最適化 ? Apache Arrow 形式はカラム（列）指向のデー タフォーマット – インメモリデータベースに向いている ? あらかじめ集計などを行う列を抽出してデータ ファイル化 – 読込量を減らして高速処理 ? 更新はできないので検索処理のみに使用 – OLTP 系 DB ならテーブルから Arrow 形式に変換 ? Fluentd の出力を Arrow 形式で保存 – IoT などのシステム
  • 27. GPU キャッシュ ? GPU メモリ上にデータをキャッシュ – ストレージからの読込不要に – GPU メモリに乗りきるデータサイズに有効 ? Tesla A100 で 80GB の GPU メモリ ? メインメモリで OLTP 処理されている テーブルデータを差分同期可能
  • 28. PostGIS 関数の GPU 対応 ? 地理空間情報を扱う PostGIS 関数を GPU 対応 – 対応している関数は一部の関数のみ ? PostGIS では点や線分、区画（ポリゴン）など をジオメトリ型として扱う – 例：緯度経度からジオメトリ型（点）に変換できる ? 関数の例 – st_contains() ：ジオメトリ a （ポリゴン等）にジオ メトリ b （点など）が包含されるかを判定 – st_distance() ：ジオメトリ間の距離を返す ? GiST インデックス利用で更に高速化可能
  • 29. 現在の開発状況 ? 新版バージョン Ver5 系が正式リリース – 内部アーキテクチャの改善 – DPU （ NIC などのプロセッサ）対応 29 https://github.com/heterodb/pg-strom
  • 30. OSS 版とサブスクリプションの違い ? OSS 版とサブスクリプション購入には 以下の違いがあります 機能 OSS 版 サブスクリプション GPU 数 1 基のみ 複数可能 GPUDirect Storage 1 台のみ※ 複数台 GiST インデックス結合 × ○ HyperLogLog × ○ 技術サポート × メール アップデートのサポート × ○ ※GPU は Tesla が必要です。 GeForce では動きません
  • 31. OSS 版 PG-Strom 導入 ? OSS 版 PG-Strom は CUDA 対応 GPU があれば 動作可能 – GPUDirect Storage は Tesla が必要 ? 対応 Linux ディストリビューションは CUDA がサポートされているもの – インストールのしやすさから RHEL 系推奨 ? インストールガイドを提供 ? Think IT の記事もあります https://thinkit.co.jp/article/23090
  • 32. 爆速 DB ? 「爆速 DB 」は PG-Strom をベースに導入から運 用までをワンストップでサポートするデータ分析 基盤ソリューションです ? 推奨ハードウェア構成をベースにしたハードウェ アアプライアンスを提供しています – サブスクリプションのみ購入も可能 ? 仮想マシンやコンテナでの動作もサポートします ? GPU が扱える各種クラウドサービスにも対応し ます – mdx 、さくらの高火力サーバーなど
  • 33. 活用ユースケース ? 大容量ログの解析に – Web サービス等のアクセスログ – 通信ログ – IoT のセンサー等のログ ? 位置情報分析 – 移動体通信デバイスの位置情報分析

Editor's Notes

  1. ストレージの接続経路一覧表
  2. コンピューターの基本构成と処理の性能に影响を与える部分
  3. コンピューターの基本构成と処理の性能に影响を与える部分