2019年12月1日

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

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

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

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


PostgreSQLのパフォーマンス分析は、ざっくり言って、以下のようなステップで進められます。(PostgreSQLには限らないと思いますが)
  • パフォーマンスの状況から、課題について仮説を設定する。
  • パフォーマンスに関連する何の情報を収集するかを決める。
  • 情報を収集する。
  • 収集した情報を加工し、分析しやすい形式に整える。
  • 分析し、仮説を検証、ないしは何かを発見する。
  • より深堀り、確証を高めるために、再度情報集をしたり、データを加工、分析したりする。
  • 何か対策を打って、その結果を再度分析して、従前と比較する。
ある程度PostgreSQLに詳しい人は、「仮説の設定」や「どこから情報を取得するか」はさくっと決められると思いますが、情報を収集したり分析に適した形に加工したりするのはそれなりの手間と時間がかかるものです。

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

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

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


2019年2月5日

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

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

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


皆さんは、
  • システム更改によるDB移行
  • PostgreSQLのバージョンアップ
  • 特定のテーブルだけ別インスタンスにコピーしたい
といったことをしたい場合に、どのように対処しているでしょうか?
  • その方式は?
  • ツールは何を使う?
  • ダウンタイムは?
  • DBaaSの場合はどうする?
場合によって変わってくるかと思いますが、皆さんはどのように対処しているでしょうか?

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

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


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

2018年12月24日

カラムナー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 本体に手を加えなくてもカラムストア型(カラムナー型)の備えたテーブルを利用することができるようになるものです。
cstore_fdw では、テーブルを外部テーブルとして定義することによって、 PostgreSQL のオリジナルのストレージ構造をバイパスして、独自のストレージフォーマットを持つテーブルを保持することができるようになっています。

2018年12月20日

機械学習ライブラリ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)のことで、以下のページから参照できます。
簡単に言うと、

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

というものです。

2018年12月1日

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

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

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

■なぜ今さら「dblink」?


PostgreSQLには、PostgreSQL、あるいは異種DBMSのデータベース連携を実現する手段として、dblinkとForeign Data Wrapper (FDW) が提供されています。
最近の方向性としては、FDWを充実させていくのが一般的な認識かと思います。

しかし、実際にデータベース連携を実現していく中で、FDWでは対応が困難なシーンがあります。
  • FDWを使って外部テーブルを実装する際に設定すべき項目が多い。
  • FDWは、VIEWのようにクエリを定義(固定)して使うため、アドホックな(もしくは動的に変わる)クエリのリモート実行ができない。
  • FDWのAPIは年々複雑化しており、もはや普通の開発者が気軽に拡張できるレベルでない。
  • そもそも、Cで開発できる or したい人はもうそんなにいない。
というわけで、このエントリではdblink(のサブセット)をPL/Pythonで再実装し、それを他のDBMSに対応させるために拡張する、ということを試みます。

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

2018年4月23日

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

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

それは、「SQLパフォーマンス詳解(原題:SQL Performance Explained)」という本です。
パフォーマンスチューニング、特にクエリチューニングについて説明する場合、その前提となる知識は広範なものになります。

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

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

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

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

■著者のMarkus Winand氏について


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

2018年3月17日

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

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

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

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

■やりたいこと


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

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

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

■必要なもの


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

2017年12月6日

Oracle対応アプリケーションのDockernize事始め

本エントリはJPOUG Advent Calendar 2017 Day6の記事です。

普段はPostgreSQLのブログなのですが、今回はスピンオフ企画(番外編)として、先日のJPOUGのイベント「JPOUG in 15 minutes #6」で発表した「Oracle対応アプリケーションのDockernize事始め」の内容をブログエントリとしてお送りします。(Oracleネタを書くブログが無いので・・・)

なお、資料は公開していますので、興味のある方はそちらも併せてどうぞ。

■なぜ今さら「Docker」か、という前口上


既にDockerに十分触れている方、慣れている方には釈迦に説法になるかと思いますが、なぜ最近になってDockerに着目して使うようになったのか、ということからお話しようと思います。

私がDockerを使い始めたのは、実は先日のJPOUGのイベントでのセッションが決まってからです。なので、片手間に触り始めてからまだ数ヶ月と言ったところです。

2017年12月3日

Dockerを使ってデータ分析用にPostgreSQLを使ってみる

これは PostgreSQL Advent Calendar 2017 の Day3 の記事です。昨日はMorihayaさんの「DB Management tool新時代の幕開けか!? OmniDBを評価させていただく!」でした。

さて、最近ようやくDockerに触り始めたのですが、使い方が少しずつ分かってきたのでいろいろと遊んでいます。

今回は、In-Database AnalyticsとDockerです。

■全部入りのDockerイメージを作ってみた


最近、In-Database Analyticsがマイブームになっていますので、ボチボチと遊んでいます。

いろいろ遊んではいるのですが、いろいろセットアップしたり変更したり、アレが足りない、コレが動かない、みたいなことをやっているのが面倒になってきていました。面倒さが原因で手が動かないことも。。

これはいかん。

というわけで、データ分析に使えそうなExtensionをいろいろと入れ込んだ(自分的な)全部入りのPostgreSQLのDockerイメージを作ってみました。
  • CentOS 7
    • Python 2.7
  • PostgreSQL 10.1
    • PL/Python
    • postgres_fdw
  • PL/R 8.3.0.17
    • R 3.4.2
  • Apache MADlib 1.13-dev
  • pg_bigm 1.2
  • mecab 0.996
    • mecab-ipadic 2.7.0
    • mecab-python 0.993
  • numpy / scipy / scikit-learn / pandas / matplotlib
おかげで1.7GBもあるイメージになってしまいましたが、まぁそこはご愛敬、ということで。

2017年11月28日

[翻訳] たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか (How a single PostgreSQL config change improved slow query performance by 50x)

先日、「How a single PostgreSQL config change improved slow query performance by 50x」というPostgreSQLのSSD環境でのチューニングの記事を見つけたのですが、これをTweetしたらRTやLikeを比較的たくさん頂きました。 日本でも興味を持つ方がいるかもと思い、オリジナルの著者の方に許可をもらったので翻訳したものを対訳形式で掲載します。

オリジナル版と併せて、よろしければご覧ください。

■How a single PostgreSQL config change improved slow query performance by 50x
■たった一つの設定変更が如何にしてクエリのパフォーマンスを50倍も改善したか


Pavan Patibandla

At Amplitude, our goal is to provide easy-to-use interactive product analytics, so everyone can find answers to their product questions. In order to provide a great user experience, Amplitude needs to provide these answers quickly. So when one of our customers complained about how long it took to load the event properties dropdown in the Amplitude UI, we started digging into it.

Amplitudeでの我々のゴールは、簡単に使えるインタラクティブなプロダクト分析を提供することです。それによって、すべての人が自分たちのプロダクトについての疑問の答えを得ることができるようになります。素晴らしいユーザエクスペリエンスを提供するために、Amplitudeは答えを迅速に提供する必要があります。ある顧客から Amplitude UI でイベントプロパティのドロップダウンリストのロードに時間がかかると苦情が来たため、その調査を開始しました。

2017年8月25日

【告知】9月9日(土)に関西DB勉強会で講演します

9月9日(土)に関西DB勉強会で講演します。

「PostgreSQLエンジニアにとってのデータ分析プロジェクト:テクノロジーとその実践(仮)」というタイトルで、ここ3~4年のテクノロジーやスキル、経験、そこからの学びなどをごった煮でお送りする予定です。他にも面白そうなセッションが目白押しとなっております。

既にキャンセル待ちとなっておりますが、都合の付く方はぜひご参加ください。私からのトークだけではなく、いろいろな方と意見交換をできればと思っています。

よろしくお願いします。

2017年6月8日

技術文書「PostgreSQL 10 Beta1 新機能検証結果」が公開されました

少し前の話になりますが、みなさんお馴染みとなりつつある日本HP篠田さんから PostgreSQL 10 beta1 の資料が公開されました。
今回、私も事前レビューに参加させてもらいました。

本ドキュメントは全体で100ページ以上あり、以下のような構成になっています。

1. 本文書について
2. バージョン表記
3. 新機能解説
3.1 PostgreSQL 10における変更点概要
3.2 パーティション・テーブル
3.3 Logical Replication
3.4 パラレル・クエリーの拡張
3.5 アーキテクチャの変更
3.6 モニタリング
3.7 Quorum-based同期レプリケーション
3.8 Row Level Securityの拡張
3.9 SQL文の拡張
3.10 パラメーターの変更
3.11 ユーティリティの変更
3.12 Contribモジュール
参考にしたURL

2017年5月14日

Azure Database for PostgreSQLにアクセスしてみた

5/11のMicrosoft Build 2017で、PostgreSQLのDBaaSがAzureで提供されることが発表されました。
現時点ではプレビューのようですが、ちょっと興味があったので軽く触ってみました。

ちなみに、Azureは普段使っていないのでそんなに詳しくありません。

■PostgreSQLのリソースを作成する


まず、Azureのダッシュボードで「PostgreSQL」と検索すると、PostgreSQLのリソースが出てきます。

2017年5月9日

Hecatoncheir: The Data Stewardship Studio 0.8を公開しました

本日、「Hecatoncheir: The Data Stewardship Studio」という最近開発していた新しいツールをOSSとして公開しました。
本ツールは、データベースのメタデータおよび実データの統計情報やプロファイルを用いることで、データ品質マネジメントおよびデータガバナンスを実施するデータスチュアードを支援することを目的としたソフトウェアです。

既に某所のデータウェアハウスのシステムの周辺で稼働しています。

本エントリでは、このツールの紹介をさせていただきます。(本ツールはPostgreSQLにも対応しております)

■本ツールを開発した背景


最近は、データウェアハウスの設計から構築、データマネジメント(ガバナンスやスチュアードシップと呼ばれることもありますが)を手掛けることが多くなってきました。

データベースエンジニアですから、新しい情報系システムの領域であってもテクニカルな作業もそれなりにこなせるのですが、いくつかの案件を手掛ける中で気付いたことがありました。

それは、どのような局面であっても、データの調査や確認のために同じような作業(クエリの実行など)を何度も何度も繰り返して行わなければならない、ということです。そして、データは日々変化していくため、そのタスクを毎日のように繰り返さなければなりません。

2017年2月21日

In-database Analyticsの集い #1を開催します

3月10日(金)に「In-database Analyticsの集い #1」というMeetupを開催することになりました。

「In-Database Analytics」というのは、データベースに蓄積されたデータに対して、「データを取り出さずに」データベース内部で分析処理をする技術の総称だと思っていただければいいかと思います。

データベースに蓄積されるデータはどんどん大きくなっている昨今ですが、それに伴ってデータベースからデータを取り出してから分析処理をする、というのが難しくなりつつあります。そのため、データベースからデータを取り出さずに分析処理をする「In-Database Analytics」の重要性がより高まってくると感じています。

今回のMeetupでは、ソフトウェアによるIn-Database Analyticsの話から始めて、昨今注目されているハードウェアアクセラレーションの活用(GPGPUやFPGA)などについて情報交換する場にできればと思っています。

というわけで、この辺の話に興味がある方はぜひご参加いただければと思います。お待ちしています。

では。

2017年1月24日

コサイン類似度に基づくソート処理の実装方法とその性能比較

文書の類似度を計算する方法に「コサイン類似度」を用いる方法があります。

これは、出現する単語を出現回数などで数値化して、空間ベクトルに変換した上でベクトル同士の類似度を計算する、という手法です。
最近、このコサイン類似度を使って、似ているデータを検索するWebアプリを試しに作っていたのですが、ふと、

「このコサイン類似度を使ったソート処理をPostgreSQLでどのように実装するともっとも高速な実装になるのだろうか。また、現実的なパフォーマンスを考えた時にデータ量や次元のサイズはどこまで増やせるのだろうか」

ということが気になりました。

PostgreSQLは、その拡張性の高さがウリの一つですが、そのため「UDFを作る」ということを考えても、実装方法にもいろいろあります。

今回は、PostgreSQL内部でデータ処理を実装するに当たって、どのような実装方法があるのか、それぞれどのように性能が違うのか、そしてその時にデータサイズがどのように影響するのかを見てみます。

■前提条件


今回は以下の前提条件で実装と性能比較を行います。
  • ソート処理するデータはPostgreSQLに蓄積されているものを対象とする
  • 空間ベクトルを表すデータは、PostgreSQL の float8 の配列で1カラムに保持する
  • コサイン類似度による類似度を計算し、もっとも類似度の高いレコードをN件取得する

2016年12月24日

オープンデータ+PostGIS+Google Maps で観光マップを作ってみた

本エントリは PostgreSQL Advent Calendar 2016 の Day24 のエントリです。昨日は @mazudakz さんの「pg_stats_reporter をしくじった話」でした。読み応えあって面白かった。

さて、先日(と言っても結構前)、地理情報をPostgreSQLで扱う例として、巡回セールスマン問題をPostgreSQLで解きつつGoogle Mapsで可視化するエントリを書きました。
今回は、もう少し進んでPostgreSQLにおける地理情報の検索とGoogle Mapsの動的な可視化を連動させてみましたので、その内容を紹介します。

実現したいことは、
  • 観光に関連する情報をPostgreSQLに取り込んで、
  • Google Mapsで地図上にマッピングして可視化しつつ、
  • 地図上をブラウジングしながら、
  • 興味のある場所があったらそのままGoogle検索に飛ぶ
という仕組みです。

年末年始のお出かけの検討に、または雑談のお供にご活用いただければと思います。

■オープンデータ「国土数値情報 観光資源データ」とは


まず、今回使うデータですが、国土交通省が公開している「国土数値情報」の中から「観光資源」のデータを使います。
このデータは各都道府県が「観光資源」として登録しているデータで、以下のような項目が含まれています。
  • 観光資源_ID
  • 観光資源名
  • 都道府県コード
  • 行政コード
  • 種別名称
  • 所在地住所
  • 観光資源分類コード
  • 観光資源(地理情報)
そのため、これらをうまくPostgreSQLに取り込んでやる必要があります。

このデータは地理情報のデータフォーマットとして広く使われている「シェープファイル(Shape File)」と呼ばれる形式で配布されています。

2016年12月1日

Logical Decodingを使ったCDC(Change Data Capture)の実現方法を考えてみる

今年も風物詩である PostgreSQL Advent Calendar の時期がやって参りました。Day1担当のデータマエショリスト @snaga です。
去年もDay1を担当した気がしますが、それはさておき。

余談ですが、今年のAdvent Calendarは
にも参加しております。また、
というのにも(個人的に)チャレンジしていますので、この辺に興味のある方はよろしければどうぞ。

■Logical Decoding?


閑話休題。

皆さんご存知の通り、「Logical Decoding」と呼ばれる機能がPostgreSQL 9.4で導入されました。

PostgreSQLでは「新しい機能入ったらしいが一体何にどう使えばいいんだ?」というような機能が稀によくあります。そのため、2年前にリリースされた機能にも関わらず誰かが使っているという話を聞いたことがない、といったことが起こります。

Logical Decodingにもその空気を感じます。

2016年11月6日

Jupyter NotebookからPostgreSQLに接続してデータを可視化する

最近、なんだかんだとデータに触る機会が増えてきております。

Unix系エンジニア兼DBAとしては、CLI(コマンドラインインターフェース)が生産性が高くて好きだけど、一方で可視化もお手軽にやりたい、というケースが多々あります。

Jupyter Notebookでデータベースに接続して可視化できる、という話は以前から聞いたことがあったのですが、実際に試してみたことがありませんでした。

今回、軽くPostgreSQLで試してみたのでその手順を簡単にご紹介します。

■セットアップ


以下の3つのモジュールをpipでインストールします。
  • jupyter
  • psycopg2
  • ipython-sql

2016年10月1日

PostgreSQL 9.5日本語マニュアルの検索システムをリリースしました(追記あり)

PostgreSQL 9.5の日本語マニュアルの検索システムをリリースしたので、ご紹介します。
少し前からPostgreSQLのマニュアルを細かく調べる必要性が出てきたのですが、ご存じの通り、PostgreSQLのオンラインのマニュアルはGoogleと相性が良くありません。

本当はgrep -cでもいいくらいの機能なのですが、公開されているフォーマットがHTML、マニュアルのソースファイルはSGMLファイルなので、実際にそのままgrepしても、見栄え的にあまり嬉しくありません。

そのため、自分の開発の練習もかねてWebアプリとして作ってみました。

■マニュアル検索システムの機能


検索システムのURLは以下です。
検索対象となるのは、日本PostgreSQLユーザ会が翻訳して以下で公開しているPostgreSQL 9.5の日本語マニュアルで、リリースノートと索引を除いたページです。