カラムナーDB拡張 cstore_fdw とその性能評価

本エントリは PostgreSQL Advent Calendar 2018 の Day24 の記事です。

昨日の記事は @kabaome さんによる 拡張統計情報とテーブル結合 でした。

本エントリでは、PostgreSQLのカラムナーDB拡張である cstore_fdw について、その基本的な使い方から、 DBT-3 のスキーマとクエリを使ってベンチマークをしてみた結果を解説してみます。

とは言え、私自身、cstore_fdw をそれなりに使ったのはこれが初めてですので、あまり深く踏み込めていないところもあるかと思いますが、そういったところがありましたら、コメント欄や Twitter などで補足いただけると助かります。

■cstore_fdw とは

cstore_fdw は Citus Data によって開発されているオープンソースの PostgreSQL 拡張で、PostgreSQL 本体に手を加えなくてもカラムストア型（カラムナー型）の備えたテーブルを利用することができるようになるものです。

• https://github.com/citusdata/cstore_fdw

cstore_fdw では、テーブルを外部テーブルとして定義することによって、 PostgreSQL のオリジナルのストレージ構造をバイパスして、独自のストレージフォーマットを持つテーブルを保持することができるようになっています。

機械学習ライブラリApache MADlibで決定木を使ってKaggleのTitanicを解く

この記事は PostgreSQL Advent Calendar 2018 のDay20の記事です。昨日19日は U_ikki さんによるPostgreSQL 12の新機能の話でした。

以前から興味はあるのだけれどなかなか手を付けられなかったものの中に「Kaggleにチャレンジしてみる」というものがありました。

「趣味はKaggleを少々嗜んでおりまして」とか言ってみたい。

そんなことをずっと考えていたのですが、最近ようやくKaggleデビューしました。

本エントリではPostgreSQLで使える機械学習ライブラリであるApache MADlibを使って、Kaggleの「チュートリアル」と言われているTitanicの問題を解いてみます。

■Kaggle Titanicとは

Titanicは、Kaggle初心者のために準備されているチュートリアルの問題（Competition）のことで、以下のページから参照できます。

• Titanic: Machine Learning from Disaster | Kaggle
  https://www.kaggle.com/c/titanic

簡単に言うと、

「タイタニックで生き残った乗客と亡くなった乗客を記録した訓練用データ（トレーニングデータ）があり、その乗客の属性情報などを元に予測モデルを作成し、予測用データ（テストデータ）に掲載されている乗客が生き残るかどうかを予測し、その予測精度を競う」

というものです。

Python版dblinkでデータベース連携をもっと「自由」に

本エントリは、 PostgreSQL Advent Calendar 2018 の Day1 のエントリです。

エントリを書くのは実に半年以上ぶりなのですが、今回は以前から試してみたかったdblinkネタをお届けします。

■なぜ今さら「dblink」？

PostgreSQLには、PostgreSQL、あるいは異種DBMSのデータベース連携を実現する手段として、dblinkとForeign Data Wrapper (FDW) が提供されています。

• https://www.postgresql.jp/document/10/html/dblink.html
• https://www.postgresql.jp/document/10/html/postgres-fdw.html

最近の方向性としては、FDWを充実させていくのが一般的な認識かと思います。

しかし、実際にデータベース連携を実現していく中で、FDWでは対応が困難なシーンがあります。

• FDWを使って外部テーブルを実装する際に設定すべき項目が多い。
• FDWは、VIEWのようにクエリを定義（固定）して使うため、アドホックな（もしくは動的に変わる）クエリのリモート実行ができない。
• FDWのAPIは年々複雑化しており、もはや普通の開発者が気軽に拡張できるレベルでない。
• そもそも、Cで開発できる or したい人はもうそんなにいない。

というわけで、このエントリではdblink（のサブセット）をPL/Pythonで再実装し、それを他のDBMSに対応させるために拡張する、ということを試みます。

PostgreSQLの強みのひとつは「拡張性の高さ」です。そのため、その「拡張性の高さ」を最大限に活かす実装を目指します。

この連休の読書にオススメの一冊「SQLパフォーマンス詳解」（割引コードあり）

最近、久しぶりにPostgreSQLのクエリチューニングをしていたのですが、その過程で「この本はぜひもっと多くの人に読んでもらいたい」と改めて思い出した一冊がありました。

それは、「SQLパフォーマンス詳解（原題：SQL Performance Explained）」という本です。

• SQLパフォーマンス詳解
  http://sql-performance-explained.jp/

パフォーマンスチューニング、特にクエリチューニングについて説明する場合、その前提となる知識は広範なものになります。

そのため、自分が頑張って説明するよりも、優れたエキスパートのまとめたコンテンツを活用させてもらう方が、質・量ともに優れたインプットにしていただけるのではないか、と思うのです。

また、この「SQLパフォーマンス詳解」は非常に良い本であるにも関わらず、一般の出版社から出ているわけではないため、それほど積極的にプロモーションされているわけではなく、日本語版についても、（残念ながら）一般的な書籍ほど話題になることが無いように思います。

そういった理由により、本エントリではこの本について皆さんに知っていただくべくご紹介するとともに、著者のMarkus Winand氏から日本の読者の皆さんに「最大で半額」となる割引コードを提供いただけることになりましたので、その使い方についてご紹介したいと思います。

ゴールデンウィーク直前ですが、ぜひ連休中に読む一冊に加えていただければと思います。データベースのパフォーマンスについて、網羅的かつ本質的な理解が深まること、間違いのない一冊です。

■著者のMarkus Winand氏について

著者のMarkus Winand氏は、PostgreSQLを始めとするRDBMSのチューニングのエキスパート／コンサルタントとして有名な方で、「Use the Index, Luke!」というブログでお馴染みです。

PostgreSQLのデータをPandasのデータフレームとして読み書きする

最近、JupyterやPandasを使ってデータを処理する機会が増えてきました。

とは言え、手元のデータはPostgreSQLに溜まっていたり、あるいはSQLで処理したい、ということがよくあります。

というわけで、Jupyterを使っている時に、「PostgreSQLからデータを取り出して、Pandasやら何やらでいろいろ処理した後、結果をPostgreSQLを書き出す」というユースケースを想定して、その方法を調べてみました。

■やりたいこと

やりたいことは、PostgreSQLのデータをJupyter上でPandasのデータフレームとして読み込み、集計やデータ分析をした結果をPostgreSQLに書き戻す、ということです。

データの加工や整形など（データ前処理）はPostgreSQLの方が高速に行えるのでSQLで、複雑なアルゴリズムの適用はPythonで行いたい、そしてその結果をPostgreSQLに書き戻して利用したい、というケースを想定しています。

あるいはPostgreSQLのデータをmatplotlibを使って可視化したい、といった場合にも使えるでしょう。（この場合は書き戻しは必要ありませんが）

■必要なもの

必要なものは以下の通りです。