Jupyter+Pandasを使ったPostgreSQLパフォーマンス分析

本記事は PostgreSQL Advent Calendar 2019 の1日目の記事です。初日から遅れ気味ですすみません。。

久しぶりの記事ですが、最近はPostgreSQLをゴリゴリと触る感じでもなくなってきているため、本記事もゆるめの感じでお送りしたいと思います。

■PostgreSQLの「パフォーマンス分析」とは

PostgreSQLのパフォーマンス分析は、ざっくり言って、以下のようなステップで進められます。（PostgreSQLには限らないと思いますが）

• パフォーマンスの状況から、課題について仮説を設定する。
• パフォーマンスに関連する何の情報を収集するかを決める。
• 情報を収集する。
• 収集した情報を加工し、分析しやすい形式に整える。
• 分析し、仮説を検証、ないしは何かを発見する。
• より深堀り、確証を高めるために、再度情報集をしたり、データを加工、分析したりする。
• 何か対策を打って、その結果を再度分析して、従前と比較する。

ある程度PostgreSQLに詳しい人は、「仮説の設定」や「どこから情報を取得するか」はさくっと決められると思いますが、情報を収集したり分析に適した形に加工したりするのはそれなりの手間と時間がかかるものです。

しかも、ある程度探索的な分析を行わざるを得ないため、データやグラフの形式を最初から決めておいたとしても、パフォーマンス分析がディープになればなるほど、それが現実的に役に立つかどうかは微妙になっていきます。（なので、最終的には、あらゆるグラフを網羅的に出力するレポートを作成する羽目になります）

そのため「Excel最強説」が流れるわけですが、再現可能性や繰り返しの作業についてはやはりいろいろと難がありますので、スクリプトで処理したくなってきます。

■「Jupyter + Pandas」を使ってパフォーマンス分析

tablelog extension を使ってDB移行に必要なテーブルの更新差分のログを取得する

先日開催されたPostgreSQLアンカンファレンスで tablelog という extension の話をしたのですが、本エントリでは改めてその紹介をさせていただこうと思います。

• 第10回PostgreSQLアンカンファレンス - Togetter
  https://togetter.com/li/1315752

■DB移行やメジャーバージョンアップの時、、、

皆さんは、

• システム更改によるDB移行
• PostgreSQLのバージョンアップ
• 特定のテーブルだけ別インスタンスにコピーしたい

といったことをしたい場合に、どのように対処しているでしょうか？

• その方式は？
• ツールは何を使う？
• ダウンタイムは？
• DBaaSの場合はどうする？

場合によって変わってくるかと思いますが、皆さんはどのように対処しているでしょうか？

もっともシンプルな方法は Dump & Restore だと思いますが、データベースの規模が大きくなってきた状態だと非常に時間がかかる場合があり、単純な Dump & Restore だと数日間データベースを停止しなければならない、といった見積もりになることもあります。

■更新差分だけを取得・適用して追い付きたい

そういう状況で次に考えるのは、「データベースを一旦コピーしておいて、後から更新差分だけ適用して追い付きたい」という方式です。

カラムナー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の強みのひとつは「拡張性の高さ」です。そのため、その「拡張性の高さ」を最大限に活かす実装を目指します。