mysql2arrowでMySQLからデータを抜く

以前からPG-Stromのパッケージにpg2arrowというユーティリティを同梱しており、これを使うと、PostgreSQLに投げたクエリからApache Arrow形式のファイルを作成する事ができる。kaigai.hatenablog.com qiita.com昨年、当初のバージョンを作った時から、内部的…

Writable Arrow_Fdwと、PL/CUDAがお払い箱になる話

昨年ラストのブログ記事は、pg2arrowに--appendモードを付けてApache Arrowファイルへの追記を行うというトピックだった。kaigai.hatenablog.com実は内部的には、PG-StromのArrow_Fdwとpg2arrowのコードは大半を共有していて*1、入り口がスタンドアロンのlib…

Dive into Apache Arrow(その4)- pg2arrow で追記モード

先日、Apache Arrow 東京ミートアップ 2019というイベントに参加させていただいた。発表時の様子(photo by 畔勝さん)発表自体は、SSD-to-GPU Direct SQLからArrow_Fdw、4GPU+16SSDによる最近のベンチマークの紹介などで、目新しいものというよりは総集編で…

CitusDB + PG-StromでScale-up+outする。

PostgreSQL Advent Calendar 2019の14日目です。PG-Stromの開発をやってると、しばしば聞かれるのが『マルチノードの並列処理って対応してるんですか?』という質問。まぁ、『対応しておりませんし、対応する予定もございません』という回答になるんですが、…

CUDA10.2 の Virtual Memory Management 機能を試してみる

11月21日にリリースされた CUDA 10.2 の Release Note を読んでみると、さらっと『Added support for CUDA Virtual Memory Management APIs.』という一文が。以前から、ManagedなGPUデバイスメモリをマルチプロセスで共有できるようにしてほしいと、機能リク…

Billion rows processed per second at a single-node PostgreSQL

I have worked on benchmarking of PG-Strom at a large hardware configuration for a couple of months. Due to the server models we had, our benchmark results had been usually measured at a small 1U rack server with 1CPU, 1GPU and 3-4 NVME-SSD…

秒速で10億レコードを処理する話

これまでのPG-Stromの性能測定といえば、自社保有機材の関係もあり、基本的には1Uラックサーバに1CPU、1GPU、3~4台のNVME-SSDを載せた構成のハードウェアが中心だった。*1 ただソフトウェア的にはマルチGPUやNVME-SSDのストライピングに対応しており、能力…

Asymmetric Partition-wise JOIN

久々に PostgreSQL 本体機能へのパッチを投げたので、それの解説をしてみる。PostgreSQL: Re: Asymmetric partition-wise JOIN 背景:Partition-wise JOIN PostgreSQLのパーティションを使ったときに、全く同一のパーティションの切り方をして、かつパーティ…

技術負債を返した話(Pre-built GPU Binary対応)

最もプリミティブなPG-Stromの処理は、ユーザが入力したSQLを元にCUDA CのGPUプログラムを自動生成し、これを実行時コンパイル。ここで生成されたGPUバイナリを用いて、ストレージから読み出したデータをGPUで並列処理するという一連の流れである。 後にJOIN…

SSDtoGPU Direct SQL on Columnar-store (Apache Arrow)

I have recently worked on development of FDW for Apache Arrow files; including SSDtoGPU Direct SQL support of PG-Strom. Apache Arrow is a column-oriented data format designed for application independent data exchange, supported by not a sm…

Dive into Apache Arrow(その3)- SSD-to-GPU Direct SQL対応

ここ最近取り組んでいた Arrow_Fdw 機能がようやく動くようになったので、性能ベンチマークを行ってみた。 今回のエントリでは順を追って説明する事にしてみたい。 Arrow_Fdwとは PostgreSQLにはFDW (Foreign Data Wrapper) という機能があり、PostgreSQL管…

Dive into Apache Arrow(その2)- pg2arrow

前回のエントリで Apache Arrow のフォーマットについて調べていたが、これのゴールは、外部テーブル(Foreign Table)を介してApache Arrowファイルを読み出し、高速に集計・解析処理を実行する事にある。 特にPG-Stromの場合はSSD-to-GPU Direct SQLという…

Dive into Apache Arrow(その1)

Arrow_Fdwを作るモチベーション 昨年、かなり頑張ってマルチGPUや拡張I/Oボックスを使用してシングルノードのクエリ処理性能10GB/sを達成できた。ただ一方で、PG-StromがPostgreSQLのデータ構造をそのまま使えるという事は、トランザクショナルに蓄積された…

PL/CUDAを使ってロジスティック回帰分析を実装してみた

PostgreSQL Advent Calendar 2018の6日目です。PG-Stromはアナリティクス向けにPL/CUDAというユーザ定義SQL関数を実装する機能を持っており、SQL処理の中で計算ヘビーな部分をCUDA Cで記述したGPUプログラムで実行させるという事ができる。 SQL関数としてPL/…

PGconf.EU 2018参加レポート

10/23~26にかけて、ポルトガル・リスボンで開催されたPGconf.EU2018へ参加してきました。 リスボンへはドイツ駐在中の2013年に一度旅行で訪れた事があり、個人的にも懐かしい、5年ぶりの訪問となります。PGconf.EUとは、PostgreSQLの欧州ユーザコミュニティ…

スキャン速度10GB/sへの挑戦~その④ 完結編~

今回のエントリは、ここ1年ほど取り組んでいた PG-Strom による大量データのスキャン・集計処理性能改善の取り組みが、当面の目標であったシングルノード10GB/sを達成したという完結編です。(長かった) 要素技術:SSD-to-GPUダイレクトSQL 先ず、PG-Strom…

PostgreSQLとcupyを繋ぐ~機械学習基盤としてのPG-Stromその①~

世間の機械学習屋さんは、機械学習・統計解析のライブラリにデータを食わせる時に、どうやってデータを入力しているのだろうか? 話を聞くに、データを一度CSV形式に落とし込んで、それをPythonスクリプトで読み込むというパターンが多いようではある。ただ…

時系列データ/BRINインデックス対応

PG-StromにBRINインデックス対応機能を実装してみた。まずは、以下のEXPLAIN ANALYZEの実行結果をご覧いただきたい。 条件句で参照しているymd列は日付型(date)で、テーブルにデータを挿入する際には意図的に日付順にINSERTを行っている。 postgres=# EXPL…

Partition-wise GpuJoin/GpuPreAgg

PostgreSQL v10以降ではテーブルパーティショニングの機能が入っており、値の範囲、または値のリストによってテーブルをいくつかのパーティションに分割する事が可能となっている。遅まきながら、PG-Stromにパーティションを意識した実行計画を作成するよう…

スキャン速度10GB/sへの挑戦~その③~

ちょっと前(2017年10月)に以下のような記事を書いた。 kaigai.hatenablog.comこの時点では、SeqRead 2.2GB/s の Intel SSD 750(400GB) を3枚束ねて、理論帯域6.6GB/sに対してクエリ処理のスループット6.2GB/s程度までは能力を引き出す事ができていた。 デ…

gstore_fdwの圧縮オプション

昨年11月に、GPUメモリをSQLで読み書きするための新機能『gstore_fdw』というものを実装した。*1これは、PostgreSQLのFDW(Foreign Data Wrapper)の機能を利用して、SELECTが実行された時にはGPUメモリから読み出した内容をPostgreSQLの内部データ表現に…

PostgreSQL v11新機能先取り:Hash-PartitioningとParallel-Append

今回のエントリーは PostgreSQL Advent Calendar 2017 - Qiita に参加しています。PG-Stromの視点からも、PostgreSQL v11には首を長くして待っていた機能が2つ入っている。その1:Hash-Partitioning github.comその2:Parallel-Append github.comHash-Part…

GTCJapan雑感と、ちょっとした思い付き。

12月12日(火)~13日(水)にかけて、お台場のヒルトンホテルでGPU Technology Conference Japanが開催された。(関係者の皆様、お疲れさまでした!) www.gputechconf.jp当方の出番は、初日夕方の INCEPTION AI Startup Summit というスタートアップ19社のプレ…

gstore_fdw: GPUメモリをSQLで読み書き、そして…。

昨年、PGconf.ASIAで発表したPL/CUDAによる創薬ワークロードの高速化実験のテーマであるが、 kaigai.hatenablog.com 実測したベンチマークを見ると、奇妙な傾向が見てとれる。 このワークロードにおける計算量は「Qの行数×Dの行数」であるので、Dの行数が同…

カスタムロジックをWHERE句で使う

しばらくSSD-to-GPUダイレクトSQL実行の開発にどっぷり時間を突っ込んでいたので、久々にPL/CUDAネタ。この辺のネタや、 kaigai.hatenablog.comこの辺のネタで kaigai.hatenablog.com紹介したように、PG-Stromはユーザ定義関数をCUDA Cで記述するための機能…

スキャン速度10GB/sへの挑戦~その②~

一年半ほど前、次のようなエントリーを書いた。kaigai.hatenablog.comかいつまんで言うと、多段JOINのように、実際に実行してみないと結果行数が明らかではなく、かつ、ステップ(k+1)の最適な問題サイズがステップkの結果に依存する場合、Kepler以降のGPUで…

GpuJoinの結果バッファ問題を考える。

GPUでSQLのJOIN処理を実装する場合、一つ悩ましい問題は、JOINの結果生成されるレコード数は実際に実行してみなければ正確には分からないという点である。 JOINを処理した結果、行数が減る事もあれば増える事もある。減るパターンはまだ良いとして、時として…

GpuJoin + GpuPreAgg combined kernel

以下のクエリは、t0とt1の2つのテーブルをJOINし、その結果をGROUP BYして出力するものである。 しかし、EXPLAIN ANALYZEの出力には奇妙な点がある。 postgres=# explain analyze select cat,count(*),avg(ax) from t0 natural join t1 group by cat; QUERY …

Pascal以降のUnified Memoryを使いたおす。

今でこそTESLA P40に24GBのRAMが載り、コンシューマ向けでもGTX1080Tiに11GBのRAMが搭載されてたりと、GPU側でも10GBを越えるメモリを積むことは珍しくなくなってきた*1。 長らく自分の開発環境で頑張ってくれたGTX980は(当時のハイエンド製品だったにも関…

NECを退職し、新会社を立ち上げました。

ご報告が遅れましたが、6月30日付で新卒の2003年から14年あまり勤務したNECを退職しました。 また、本日、東京法務局品川出張所においてヘテロDB株式会社の登記申請を行い、また、併せて新会社のチーフアーキテクト兼代表取締役社長に就任しました。今後は、…