構想は半年ほど前？ここ一ヶ月ほど集中して開発に取り組んでいた、Fluentd向けApache Arrowプラグインがようやく動くようになったので、今回はこちらのモジュールについてご紹介します。 そもそもPG-Stromは、IoT/M2M領域で大量に発生するデータを高速に処理できますというのがセールスポイントで、GPU-Direct SQLはじめ、各種の機能によってそれを実現しているワケですが、実際に運用する際には、発生したデータを『どうやってSQLで処理できるようDBにインポートするか？』という問題があります。 例えば、PostgreSQLに一行ずつINSERTするというのも一つの解です。ただし、単純なI/Oに比べると、DBへの書き込みはどうしても処理ボトルネックになりがちです。 そこで、大量に収集するログデータを、少ない時間ロスで（つまり一時ファイルに保存したデータを再度DBにインポート

タイトルでほぼほぼ出オチですが、先日、NVIDIAからCUDA Toolkit 11.4と共にリリースされた新機能GPUDirect Storage 1.0のドキュメントを読んでいると、面白い記述を見つけた。 曰く、MOFEDドライバ5.3以降と、Mellanox Connect-X4/5の組み合わせで、NFS-over-RDMAとGPUDirect Storageを組み合わせ、リモートのNFS区画からローカルのGPUへと直接のデータ転送を行う事ができるようになる、と。 14.10. NFS Support with GPUDirect Storage This section provides information about NFS support with GDS. 14.10.2. Install GPUDirect Storage Support for the NFS Cli

これまでのPG-Stromの性能測定といえば、自社保有機材の関係もあり、基本的には1Uラックサーバに1CPU、1GPU、3～4台のNVME-SSDを載せた構成のハードウェアが中心だった。*1 ただソフトウェア的にはマルチGPUやNVME-SSDのストライピングに対応しており、能力的にどこまで伸ばせるのかというのは気になるところである。 そこで、方々に手を尽くして、次のようなベンチマーク環境を整備してみた。 （機材をお貸し頂いたパートナー様には感謝感激雨あられである） 4UサーバのSYS-4029GP-TRTというモデルは、GPUをたくさん乗っけるためにPCIeスイッチを用いてPCIeスロットを分岐している。ちょうど、PCIeスイッチ1個あたり2個のPCIe x16スロットが用意されており、同じPCIeスイッチ配下のデバイス同士であれば、完全にCPUをバイパスしてPeer-to-Peerのデ

Arrow_Fdwを作るモチベーション 昨年、かなり頑張ってマルチGPUや拡張I/Oボックスを使用してシングルノードのクエリ処理性能10GB/sを達成できた。ただ一方で、PG-StromがPostgreSQLのデータ構造をそのまま使えるという事は、トランザクショナルに蓄積されたデータをそのまま使えるという手軽さの一方で、どうしても行指向データに伴う非効率なI/Oが処理速度全体を律速してしまうという事になる。 昨年の10月頃から直接お会いした人にはお話していたが、現在、PG-StromでApache Arrow形式のファイルを扱うようにするための機能強化に取り組んでいる。目標としては、３月末には動かせる状態にしたいと思っているが。 Apache Arrow形式とは、Sparkの人がよく使っているデータ形式で、大量の構造化データを列指向で保持する事ができる。特定の行を更新したり削除したりといっ

ご報告が遅れましたが、6月30日付で新卒の2003年から14年あまり勤務したNECを退職しました。 また、本日、東京法務局品川出張所においてヘテロDB株式会社の登記申請を行い、また、併せて新会社のチーフアーキテクト兼代表取締役社長に就任しました。 今後は、前職では実現できなかった、GPUやSSDなどヘテロジニアスな計算機資源を活用する事で、高性能、低価格、使いやすさを両立するデータベース製品の事業化を目指していく事になります。 どうぞよろしくお願いいたします。 web: http://heterodb.com/ 弊社が入居する西大井創業支援センター（品川区） 10年以上も勤務した会社を辞めてスタートアップを立ち上げるというのは、おそらく人生の中でも上位に食い込むビッグイベントの一つだと思うので、今の決意や創業に至る一連の流れについて記録を残しておこうと思います。 （書き下してみたら意外と長

従前、AWSの提供するGPUインスタンス g2.* に搭載されているGPUはGRID K520というちょっと古いモデルで、PG-Stromは非対応だった。 理由は、一年ほど前にComputing Capability 3.5以降で対応のDynamic Parallelism機能を使うように全面的に作り直したからで、詳細は以下のエントリを参照。 kaigai.hatenablog.com その後、昨年の10月にAWSは新世代*1のGPUインスタンスを新たにリリースした。 japan.zdnet.com これでPG-Stromの動作要件を満たすようになった上に、特にメモリ搭載量で相応の強化が行われたため、例えばPGconf.ASIAで発表を行った創薬領域の類似度サーチのような、I/Oが支配的でないようなワークロードであれば相応の効果が見込める、ハズである。 発表から少し間が空いてしまったが、p

おっとっと、やらかしてしまった（但し、良い方に）。 PG-Strom + NVMe-Stromでのパフォーマンス計測の際に、SSDからロードしたデータ以外に、例えばテーブル定義情報や定数パラメータといったSQLの実行に必要な情報は一般的なRAM-to-GPU DMAで転送していたのだけども、ココがうっかり同期DMAになっていたために、本来の性能を発揮できないでいた。 そこで、きちんと非同期DMAを実行できるようにコードを修正し、改めてPG-Strom + NVMe-Stromの実行速度を測り直した数字が以下の通り。じゃん。 ワークロードは変わらず、以下の三種類のクエリを64GB/7億件のテーブルに対して実行した。 Q1: 比較的シンプルな検索条件を持つスキャン Q2: 比較的複雑な検索条件を持つスキャン Q3: 文字列マッチ（LIKE句）を持つスキャン 応答時間が概ね42～43secの範囲

ここしばらく、NVMe-SSDからGPUへとPeer-to-Peer DMAを行うためのLinux kernelドライバを書いている。 これは昨年末のPGconf.JPのLTでアイデアを先に発表したもので、従来は、例えばテーブルスキャンに際して90%の行がフィルタリングされる場合であっても、データをストレージからRAMにロードしていた。しかし、どうせフィルタリングするのであれば、バッファのために利用したRAMのうち90%は無駄である。 基本的なアイデアは、ストレージからのデータロードに際して、CPU側のRAMではなく、GPU側のRAMへロードし、そこで数百～数千コアの計算能力を使って行のフィルタリングや、あるいは、テーブル同士のJOINや集約演算を行ってしまう。そして、これらの前処理が終わった段階でCPU側へデータを書き戻してやれば、CPUから見ると『ストレージからデータを読出したら、既に

昨年、オタワでTim Child氏の発表を聞いて以来、実装できないものかと思って暖めていたアイデアがある。GPUの処理能力を使って、PostgreSQLの検索処理を高速化できないか？というものである。 特に複雑な計算を含むクエリの場合、Index-Scanに落ちないで、全件スキャンが走ることが往々にしてあるが、こういったケースで有効に作用するのではなかろうか？という着想である。 クリスマス休暇の間、割とまとまった開発時間を取る事ができたので、PostgreSQLのFDW(Foreign Data Wrapper)として動作するモジュールを作成してみた。 モジュールの名前は PG-Strom で、ドイツ風に『しゅとろ〜む』と発音する。 これは GPU の処理単位である Streaming Multiprocessor に由来する。 もちろん、現状のFDWのI/F前提なので、更新は不可能でソー