SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】

GPUとSSDがPostgreSQLを加速する
～クエリ処理スループット10GB/sへの挑戦～
HeteroDB,Inc
チーフアーキテクト兼代表取締役社長
海外浩平 <kaigai@heterodb.com>

自己紹介
OSC.Enterprise 2017 - GPUとSSDがPostgreSQLを加速する2
▌会社概要
 商号ヘテロDB株式会社
 創業 2017年7月4日
 社員数 2名（海外浩平、柏木岳彦）
 事業内容データ解析アプライアンス製品販売
データベース技術コンサルティングサービス
 拠点品川区西大井1-1-2-206 (西大井創業支援センター内)
▌代表者プロフィール
 海外浩平 (KaiGai Kohei)
 OSS開発者コミュニティにおいて、PostgreSQLやLinux kernelの開
発に10年以上従事。セキュリティ強化や外部データ連携等の貢
献があり、PostgreSQLのMajor Contributor として知られている。
 2007年 IPA未踏ソフト事業において “天才プログラマー” 認定
 2012年～ GPUによるPostgreSQL高速化モジュールの開発を開始
 2017年 NECを退職し、柏木と共に HeteroDB 社を創業

我々のミッション
+
GPUを用いたSQL処理の高速化製品の提供
GPU
PG-Strom

データ解析基盤としての用途
 バッチ／レポーティング
 ビジネスインテリジェンス
 異常検知／ログ解析
 統計解析／機械学習
etc...
RDBMSとしての本質的な機能
 SQLパース／クエリ最適化
 トランザクション
 バックアップ／可用性
 レプリケーション
 スケールアウト
 周辺ツールとの接続
etc...
PG-Stromとは？ (1/2)
一部処理のオフロード
PG-Strom: GPUの持つ数千並列コアと広帯域メモリを活用して
SQLワークロードを高速化するPostgreSQL向け拡張モジュール
自前で何もかも揃えるのではなく、
PostgreSQL本体機能・周辺機能を
必要に応じてチョイスする。

GPUの特徴
GPU CPU
モデル
NVIDIA
Tesla P40
Intel Xeon
E5-2699v4
世代 Pascal Broadwell
発表 Q3-2016 Q1-2016
トランジスタ数 12billion 7.2billion
コア数
3840
(simple)
22
(functional)
動作クロック
1.306GHz
~1.53GHz
2.20GHz
~3.60GHz
理論性能値
(FP32)
12 TFLOPS
1.2 TFLOPS
(with AVX2)
RAMサイズ 24GB (GDDR5) max1.5TB (DDR4)
メモリ帯域 347GB/s 76.8GB/s
消費電力 250W 145W
製造プロセス 16nm 14nm
CPU: 小回りが利くが、輸送力は小さな
乗用車のようなプロセッサ
GPU: 駅でしか乗り降りできないが、
大量輸送が可能な高速鉄道のような
プロセッサ

GPU活用による計算 – 縮約アルゴリズムの例
●item[0]
step.1 step.2 step.4step.3
GPUを用いた
Σi=0...N-1item[i]
配列総和の計算
◆
●
▲ ■ ★
● ◆
●
● ◆ ▲
●
● ◆
●
● ◆ ▲ ■
●
● ◆
●
● ◆ ▲
●
● ◆
●
item[1]
item[2]
item[3]
item[4]
item[5]
item[6]
item[7]
item[8]
item[9]
item[10]
item[11]
item[12]
item[13]
item[14]
item[15]
log2N ステップで
items[]の総和を計算
HW支援によるコア間の同期機構
SELECT count(X),
sum(Y),
avg(Z)
FROM my_table;
集約関数の計算で用いる仕組み

PostgreSQLの共通インフラ
PG-Stromとは？ (2/2)
SQL Parser
Query
Optimizer
Query
Executor
Storage
PG-Strom
CustomScan
Interface
Database Applications
Storage
Manager
Transaction
Manager
Parallel
Workers
【I/O中心ワークロードの高速化】
 SSD-to-GPUダイレクトSQL実行
 インメモリ列指向キャッシュ
 時系列データへの対応
【基本機能】
• SQL to GPUプログラムジェネレータ
• GPUコード実行時コンパイラ
• GPUカーネルの非同期並列実行
【計算中心ワークロードの高速化】
 PL/CUDA ユーザ定義関数
 gstore_fdw – onGPUデータストア
 SCAN+JOIN+GROUP BY
Combined kernel
v2.0
v2.0

PostgreSQL/PG-Stromは
どのようにクエリを実行するか

PostgreSQLの内部構造
SQL Parser
Query Optimizer
Query Executor
Storage
Manager
Transaction
Manager
IPC
(Lock, Latch,
shmem)
SQLクエリ
パース木
クエリ実行計画
クエリ
実行結果  SQL構文を分解し、取り扱いやすい
内部データ形式（パース木）に変換
 文法エラーの検出
 統計情報を元にコスト値を算出
 最も合理的と予想される実行計画を
作成する。
 クエリ実行計画に基づいて、
ScanやJoin、Sortなどを実行する。
 PostgreSQL内部のインフラを使用

PostgreSQLはどのように実行計画を作るか (1/2)
Scan
t0 Scan
t1
Scan
t2
Join
t0,t1
Join
(t0,t1),t2
GROUP
BY cat
ORDER
BY score
LIMIT
100

PostgreSQLはどのように実行計画を作るか (2/2)
Scan
t0 Scan
t1
Join
t0,t1
統計情報）
nrows: 120万行
width: 80
インデックス：なし
候補パス
HashJoin
cost=4000
候補パス
MergeJoin
cost=12000
候補パス
NestLoop
cost=99999
候補パス
Parallel
Hash Join
cost=3000
候補パス
GpuJoin
cost=2500
WINNER!
PostgreSQLビルトインの実行パス拡張モジュールによる提案
（PostgreSQL v9.5以降）
（PostgreSQL v9.6以降）
GpuJoin
t0,t1
統計情報）
nrows: 4000行
width: 120
インデックス：id列
複数の処理アルゴリズムを競わせ、“コスト値”で評価

CustomScanによる介入
同じ結果を返しさえすれば、手段は問わない。
CustomScan (GpuJoin)
(*BeginCustomScan)(...)
(*ExecCustomScan)(...)
(*EndCustomScan)(...)
:
SeqScan
on t0
SeqScan
on t1
GroupAgg
key: cat
ExecInitGpuJoin(...)
 GPUコンテキストの初期化
 自動生成したGPUプログラムの
実行時コンパイル開始
ExecGpuJoin(...)
 配下のt0,t1からデータを読み出し、
DMAバッファにセット
 GPUへ非同期タスクをキック
 実行が完了した非同期タスクを
取り出し、結果をGroupAggへ渡す。
ExecEndGpuJoin(...)
 非同期タスクの終了待ち（あれば）
 GPUリソースの解放

PG-Strom基本機能(1/2) – SQLからGPUコードを自動生成
QUERY: SELECT cat, count(*), avg(x) FROM t0
WHERE x between y and y + 20.0 GROUP BY cat;
:
STATIC_FUNCTION(bool)
gpupreagg_qual_eval(kern_context *kcxt,
kern_data_store *kds,
size_t kds_index)
{
pg_float8_t KPARAM_1 = pg_float8_param(kcxt,1);
pg_float8_t KVAR_3 = pg_float8_vref(kds,kcxt,2,kds_index);
pg_float8_t KVAR_4 = pg_float8_vref(kds,kcxt,3,kds_index);
return EVAL((pgfn_float8ge(kcxt, KVAR_3, KVAR_4) &&
pgfn_float8le(kcxt, KVAR_3,
pgfn_float8pl(kcxt, KVAR_4, KPARAM_1))));
} :
例) 条件句中の数値演算式を
CUDA命令列にオンデマンドで変換
Reference to input data
SQL expression in CUDA source code
Run-time
Compiler
(nvrtc)
Just-in-time
Compile
Parallel
Execution
v1.0

PG-Strom基本機能(2/2) – 非同期・並列実行
非同期DMA転送
GPUメモリ
GPU搭載の数千コアによる
並列実行
処理済みのブロックは開放
GPUへのデータ転送と、GPUでのSQL処理をパイプライン化する事で
PCIeバスのデータ転送速度の “遅さ” を隠ぺい。
 同時に、GPU RAMサイズ以上のデータを効率的に処理する事が可能に。
約64MBのブロック毎に転送
平均10万～30万行を含む
GPU上のバッファに余裕がある限り、
先行ブロックの処理完了を待たず、
次々にデータを送り込む。
v1.0

実際にユーザ様の課題をヒアリングしてみると・・・。
I/O
(ストレージ)
計算
(CPU)
『大量データの処理で困ってるんです・・・』
 実際にはCPU以上にI/O問題である事もしばしば

果たして I/O のボトルネックを PG-Strom で解消できるのか？

SSD-to-GPUダイレクトSQL実行
～GPUの役割を再定義する～

SSD-to-GPUダイレクトSQL実行とは
PCIe Bus
NVMe SSD GPU
SSD-to-GPU P2P DMA
(NVMe-Stromドライバ)
WHERE句
JOIN
GROUP BY
Large PostgreSQL
Tables
PostgreSQL
データブロック
SSD-to-GPUダイレクトSQL
SSDから転送したレコードを、
GPUの数千コアを用いて
SQLワークロードを実行。
CPUがロード/処理すべきデータ
量を削減し、I/Oを高速化。
従来のデータフロー
本来は不要なレコードであっても、
一度CPU/RAMへロードしなければ
要・不要を判断できないため、
データサイズは大きくなりがち。
SELECT cat, count(*), avg(X)
FROM t0 JOIN t1 ON t0.id = t1.id
WHERE YMD >= 20120701
GROUP BY cat;
SQL最適化ステージ
SQL実行ステージ
SQL-to-GPU
プログラム
ジェネレータ
GPUコード
実行時
コンパイル
SQLからGPUプログラムを
自動的に生成し、実行時
コンパイルを行う
ストレージからデータをロードする“前に” GPUでデータ量を減らす。
GPUコード生成
SQLから自動的にGPU
コードを生成するため、
利用者からは透過的に
GPUを使用するように
見える。
GPUでのSQL実行
PostgreSQLのデータ
ブロックを、直接
SSDからGPUへ転送。
SQLワークロードを
GPU上で並列実行する
事で、不要なデータを
ふるい落とす。
CPUでのSQL実行
GPUで前処理済みの
データを処理するため、
本来のデータ量よりも
遥かに小さな負荷を
処理するだけで済む。
v2.0

要素技術① GPUDirect RDMA (1/2)
▌CPUを介さず、GPU他のPCIeデバイス間のP2Pデータ転送を行う機能
 元々は、マルチノード環境でInfinibandを介したGPU間のデータ転送効率化技術
 Linux kernelドライバを作成する事で、他の PCIe デバイスにも対応可能
Copyright (c) NVIDIA corporation, 2015

要素技術① GPUDirect RDMA (2/2)
物理アドレス空間
PCIe BAR1領域
GPU
デバイス
メモリ
RAM
NVMe-SSD Infiniband
HBA
PCIe デバイス
GPUDirect RDMA
GPUデバイスメモリを
物理アドレス空間に
マップする機能
『GPUデバイスメモリの物理アドレス』が
存在すれば、PCIeデバイスとのDMAで、
Source/Destinationアドレスとして指定できる。
0xf0000000
0xe0000000
DMA要求
SRC: 1200th sector
LEN: 40 sectors
DST: 0xe0200000

要素技術② NVMe-SSD
Intel SSD
750 Series
Intel SSD
DC P4600
Samsung
PM1725
HGST
Ultrastar SN260
Seagate
Nytro 5910
Interface PCIe 3.0 x4 PCIe 3.0 x4 PCIe 3.0 x8 PCIe 3.0 x8 PCIe 3.0 x16
Capacity 400GB, 800GB,
1.2TB
2.0TB, 4.0TB 3.2TB, 6.4TB 1.6TB, 3.2TB,
6.4TB
7.7TB
Form Factor HHHL HHHL HHHL HHHL FHHL
Max SeqRead 2.5GB/s 3.2GB/s 6.0GB/s 6.1GB/s 8.0GB/s
Max SeqWrite 1.2GB/s 1.9GB/s 2.0GB/s 2.2GB/s 4.7GB/s
Rand Read 460K IOPS 617K IOPS 1000K IOPS 1200K IOPS 975K IOPS
Rand Write 290K IOPS 225K IOPS 120K IOPS 200K IOPS 130K IOPS
Warranty 5years 5years 5years 5years 5 years
MTBF 1.2M hours 1.0M hours 2.0M hours 2.0M hours 2.0M hours
Target consumer enterprise / data-center
高速SSDの本命として、NVMe規格に対応した製品が各社からリリース

ベンチマーク (1/2) – SSBMによるスループット計測
▌典型的なバッチ・レポーティング処理を模した Star Schema Benchmark にて計測
 PostgreSQLの処理速度は 2.1GB/s 程度で頭打ち（SSDを3枚束ねた場合）
 SSD-to-GPUダイレクトSQL実行を用いるPG-Stromの場合、ハードウェア限界に近い
6.2GB/s 近くまで処理性能を引き出せている。
 従来はDWH専用機や小規模クラスタを用いていた水準の能力を１台のマシンで。
SSD x2枚構成の
理論限界値 [4.4GB/s]
SSD x3枚構成の
理論限界値 [6.6GB/s]
v2.0

ベンチマーク (2/2)– SSBMベンチマーク環境
■ クエリ例
SELECT sum(lo_revenue), d_year, p_brand1
FROM lineorder, date1, part, supplier
WHERE lo_orderdate = d_datekey
AND lo_partkey = p_partkey
AND lo_suppkey = s_suppkey
AND p_category = 'MFGR#12‘
AND s_region = 'AMERICA‘
GROUP BY d_year, p_brand1
ORDER BY d_year, p_brand1;
customer
1200万件
(1.6GB)
date1
2500件
(400KB)
part
180万件
(206MB)
supplier
400万件
(528MB)
lineorder
24億件
(351GB)
典型的な Star Schema に JOIN, GROUP BY を含む集計クエリを実行
v2.0
読出し: 2.2GB/s
Intel SSD 750
3840コア搭載
NVIDIA Tesla P40
測定環境
Chassis Supermicro 5018GR-T
CPU Xeon E5-2650v4 (2.2GHz, 12C) x1
RAM 128GB (16GB DDR4-2133 x 8)
GPU NVIDIA Tesla P40 (3840C, 24GB) x1
SSD Intel SSD 750 (HHHL; 400GB) x3
OS
Red Hat Enterprise Linux 7.4
CUDA 9.0 + Latest driver
DB PostgreSQL v9.6 + PG-Strom 2.0devel

〈余談〉GTC2017でSSD-to-GPU機能の発表がTop-5に選出
世界中から集まったGPU関連R&Dの
ポスター発表全138件のうち、
最も評価の高い5件の一つとして選出。
（来場者投票では惜しくも次点…）
GPU Technology Conference 2017
8th~ 11th May, San Jose

〈補足〉PostgreSQLのI/O性能に関する考察
① 小さなブロックサイズによる大量のシステムコール呼び出し
② ブロックレイヤ／ファイルシステムでの複数回のバッファコピー
PostgreSQL
(Shared Buffer)
ファイルシステム
(Page Cache)
ブロックデバイス
(DMA Buffer)
NVMe-SSD
read(2)
DMA要求 DMA完了
memcpy to
Page Cache
memcpy to
Shared Buffer
集計処理集計処理
request to
block read
NVMe-SSDにより
デバイスの遅延は
劇的に改善
バッファ間コピー
システムコール
呼び出し

〈補足〉ハードウェア構成に関する考慮事項
▌マルチGPU環境への対応
 SQLの実行開始時に、スキャンすべきテーブルを保持するSSDに至近のGPUを使う。
 PostgreSQL v10は複数の異なるテーブルを並列スキャンできないため、
マルチGPU環境下でのSSD-to-GPUダイレクトSQL実行は必ずしも効率的ではない。
 PostgreSQL v11の “Parallel Append” 機能を待って対応予定。
① PCIeスイッチを介して
SSDとGPUが接続の場合
OK
② CPUがPCIeバスを管理し、
SSDにGPU直接接続の場合
Workable
③ SSDとGPUが互いに異なる
CPUに接続の場合
Not Supported
CPU CPU
PLX
SSD GPU
PCIeスイッチ
CPU CPU
SSD GPU
CPU CPU
SSD GPU
QPI
SSDとGPUのペアは、同一CPUまたはPLXの配下に接続されている必要がある

〈補足〉ディスクキャッシュと一貫性を保つための工夫
 課題 ①対象ブロックがOSキャッシュに保持されている場合、ストレージブロックの内容は
最新でない可能性がある。
②8KB単位のコマ切れDMA（RAMGPU）は非常に性能が悪い
 対策キャッシュされているブロック(=8KB単位)を一度ユーザ空間のバッファに書き戻し、
その後 CUDA API を用いて、一度に RAMGPU 転送を行う。
 処理ペナルティ的には read(2) + cuMemcpyHtoDAsync() と同等
 GPUメモリ上でのブロック並び順が変わるが、処理の妥当性に影響はない。
BLK-100: uncached
BLK-101: cached
BLK-102: uncached
BLK-103: uncached
BLK-104: cached
BLK-105: cached
BLK-106: uncached
BLK-107: uncached
BLK-108: cached
BLK-109: uncached
BLCKSZ
(=8KB)
Transfer Size
Per Request
BLCKSZ *
NChunks
BLK-108: cached
BLK-105: cached
BLK-104: cached
BLK-101: cached
BLK-100: uncached
BLK-102: uncached
BLK-103: uncached
BLK-106: uncached
BLK-107: uncached
BLK-109: uncached
BLK-108: cached
BLK-105: cached
BLK-104: cached
BLK-101: cached
unused SSD-to-GPU
P2P DMA
File Userspace DMA
Buffer (RAM)
Device Memory
(GPU)
CUDA API
(userspace)
cuMemcpyHtoDAsync

想定適用領域① – ビジネス・インテリジェンス
▌Why PG-Strom?
 SSD-to-GPUダイレクトSQL実行によってハードウェア能力を全て引き出し、
DWH専用機に匹敵する処理能力を1Uスタンドアロンシステムで実現。
 PostgreSQLの豊富な周辺ツールや運用ノウハウを“そのまま”適用できる。
レプリケーション
“ニア”リアルタイム同期
BIツール
業務系システム
集計系クエリ
結果
データの発生・集積データの集計・サマライズデータの可視化
 集計系クエリ（JOIN/GROUP BYの多用）の高速な実行
 大量のデータに対する高い読み出しスループット
 異種DBを含む業務系システムとの連携
課題）商用DB製品（Oracle DB, SQL Serverなど）の価格体系
集計処理は並列処理に向いているが、CPUコア単位の課金が一般的で、
並列度を上げると同時にライセンス費／保守費が急激に上昇する。

セキュリティ
事故発生
想定適用領域② – ログ解析基盤【通信分野】
▌ログ集積・解析ＤＢに求められる要件
 普段の負荷は低くても、“いざ” という時には高速な集計・探索処理が必要。
（セキュリティ事故の場合、“翌朝まで” という事も珍しくはない）
 予め検索パターンを予期できないため、インデックスや事前集計無しでも
実用時間で探索が可能な並列処理機能・高スループット
▌Why PG-Strom?
 “プロセッサとストレージの力技” でSQLを処理するため、インデックスや事前
集計の難しい問題であっても、高速に集計・探索処理を実行可能。
 定常時の負荷は高くないため、高価なDB製品の利用は費用対効果の説明が困難。
ゲートウェイサーバログ集積・解析ＤＢ
Real Life Log
データの生成
• セキュリティ事故の状況・影響範囲の探索
• 短納期での上位責任者への報告
事故報告レポート
（納期：翌朝）

PG-Strom v2.0へ向けたスケジュールと
その先のロードマップ

PG-Strom開発ロードマップ
Development Activity Business Activity
 In-memory Columnar Cache
 時系列データ対応
 NVMe-Stromドライバ改良
 先進ユーザ開拓
 代理店／SIer開拓
 対外発表
2018年1月 PG-Strom 2.0β版リリース
 テスト＆デバッグ
 パッケージング
 ドキュメンテーション
 実ワークロードを用いた実証実験
 サポート体系の整理
2018年3月 PG-Strom 2.0GA版リリース
2018年4月 HeteroServer製品販売開始
 v3.0向け開発サイクル開始
2019年1Q（暫定）PG-Strom 3.0リリース
１月中には新機能追加を凍結。３月末のPG-Strom 2.0GAリリースを目指す。

〈参考〉なぜGPUには列指向のデータが向いているか
▌行データ形式 – 不連続なデータアクセス (random memory access)
 メモリトランザクションの回数が増え、データバスの使用率が低下
▌列データ形式 – 隣接領域に対するデータアクセス (coalesced memory access)
 最小限のメモリトランザクション回数、データバスの使用率を最大化
32bit
Memory transaction width: 256bit
32bit 32bit32bit 32bit 32bit
32bit 32bit 32bit 32bit 32bit 32bit 32bit 32bit
Memory transaction width: 256bit
256bit幅のメモリトランザクション中、
32bit x 8 = 256bitが有効なデータ
（バス使用率 100.0%）
256bit幅のメモリトランザクション中、
32bit x 1 = 32bitのみ有効なデータ
（バス使用率 12.5%）
GPUコア
GPUコア
GPUの能力をフルに引き出すには、適切なデータ形式の選択が必要
v3.0

OLTPの世界 OLAPの世界
インテリジェント・ストレージ構想 (1/2)
SSD上でRow-to-Column変換を行い、Rowで書いてColumnで読む
R/C
変換
ロジック
列データ
解析系データ
読出し
（列形式）
業務データ
書込み
（行データ）
データ形式変換
FPGA等による
H/W実装
SQLクエリ処理
GPU本来の計算能力を
引き出す列データ形式
集計済み、
JOIN済み
データ
列抽出において
必要なデータだけ
取出し
v3.0

インテリジェント・ストレージ構想 (2/2)
カスタムロジックを搭載可能な NVMe-SSD 製品が
容易に入手可能になりつつある。
Nallatech社
250Sシリーズ
NGD Systems社
Catalina 2 NVMe PCIe SSD
v3.0
SSD上のロジックは単純で汎用性の高いデータ形式変換に特化
集積度の高いGPUでは、処理内容が都度変化するSQLを“超”並列実行
PostgreSQLデータブロック
カスタムロジック
PageHeader ItemPointers
Record-01Record-02
Record-03Record-04Record-05
Record-06Record-07
Record-08Record-09
列A
列D
列F

地理情報データベース（PostGIS）への対応
 ユーザ様 PoC などを踏まえ、実際に利用されている PostGIS 関数を優先して実装
 現在、PostGIS関数のカバレッジ範囲や技術課題を検討中
v3.0
地理情報マスタセンサーデータ
位置情報（座標）を
含むデータを大量に生成
PostGIS関数のGPU処理に対応し、地理情報に基づく集計処理を可能に。
都道府県・市区町村などを単位とするデータの集計や絞り込み
【PostGIS対応】

PCIeトポロジ最適化とパーティション対応 (1/2)
▌～PostgreSQL v10までの課題
 ある一時点においては、常に特定の１テーブルだけがスキャンの対象
 SSD-to-GPUダイレクトSQL実行を使うには、SSDに近傍のGPUを選択しなければならない。
 複数GPU搭載でも、スキャン中のテーブルを保存するSSDに近傍のGPUだけがアクティブ
となり、リソース有効活用の面で課題があった。
v3.0
PostgreSQL v10までは、パーティション子テーブルの並列スキャンに非対応
t1
t2
t3
t4
Append
～PostgreSQL v10
t1
t2
t3
t4
Append
PostgreSQL v11以降
※個々の子テーブルの
スキャンが並列化
される事はあるパーティション配下の子テーブル
全てを並列にスキャン

PCIeトポロジ最適化とパーティション対応 (2/2)
 ワーカーの並列化に伴い、GPU1/GPU2を同時に利用する事が可能に
 マルチGPU環境においても、計算機資源を有効に活用できることに。
v3.0
Append
ワーカーの起動時に対象SSDの近傍GPUを選択し、複数GPUを同時利用可能に
t1 t2 t4t3
GPU1 GPU2
BgWorker BgWorker BgWorker BgWorker
CPU並列処理用の
ワーカープロセス
テーブル t1 を保存する
SSDと同一のCPUに接続
されているGPU1を選択
PCIe接続トポロジーに
基づく自動チューニング

SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】

SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】

Semelhante a SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】 (20)

Mais de Kohei KaiGai

Mais de Kohei KaiGai (13)

Último

Último (11)

SSDとGPUがPostgreSQLを加速する【OSC.Enterprise】