ラベル Advent Calendar の投稿を表示しています。 すべての投稿を表示
ラベル Advent Calendar の投稿を表示しています。 すべての投稿を表示

2019年12月1日

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

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

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

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


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

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

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

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


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

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もあるイメージになってしまいましたが、まぁそこはご愛敬、ということで。

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にもその空気を感じます。

2015年12月1日

PostgreSQL 9.6のパラレルシーケンシャルスキャンを検証する

今年もこの季節になりました。PostgreSQL Advent Calendar 2015のDay1の記事です。

今回は、現在開発中のPostgreSQL 9.6に実装されたパラレルシーケンシャルスキャンについて、動作確認とフラッシュストレージでの簡単な性能検証をしてみようと思います。

なお、現在開発中の機能ですので、正式リリースされる時には仕様や動作などが変わっている可能性があることをご了承ください。

■「パラレルシーケンシャルスキャン」とは


「パラレルシーケンシャルスキャン」は、その名の通り、シーケンシャルスキャンを並列処理する機能です。

今まで、PostgreSQLでは1つのCPUを使ってシングルスレッド(というかプロセス)でしか処理をすることができませんでした。

しかし、直近のPostgreSQLのメジャーバージョンの拡張を見ていた方はご存じの通り、PostgreSQLではパラレル処理に向けての基本的な機能(開発者たちは infrastructure と呼んでいますが)が少しずつ実装されてきました。

そして、先月、PostgreSQLの待望のパラレル処理の一つ目の機能として、パラレルシーケンシャルスキャンがGitの最新版のコードにコミットされました。
このコードツリーは「9.6devel」と呼ばれており、約1年後にリリースされる予定のメジャーバージョン9.6から利用できるようになる予定です。

2014年12月2日

PostgreSQLカンファレンス2014開催のお知らせと見どころのご紹介 #pgcon14j

この記事はPostgreSQL Advent Calendar 2014の12/3の記事です。

12月5日(金)にPostgreSQLユーザの方にはおなじみのPostgreSQLカンファレンスが開催されます。
私も企画に少しかかわっていますので、このエントリでは今回のカンファレンスの見どころをご紹介してみようと思います。

■5トラック同時進行で多彩なセッション

今回のカンファレンスは、レギュラーセッションに加えてさまざまな企画系のセッションがあります。
  • キーノートセッション
  • ハンズオンセッション
  • レギュラーセッション
  • チュートリアルセッション
  • インターナショナルセッション
キーノートやレギュラーセッションは通常通りと言えますが、それ以外にも、豪華講師陣による「ハンズオンセッション」、PostgreSQLの初学者でも半日で効率良く学べる「チュートリアルセッション」、海外から参加する講師による英語のみの「インターナショナルセッション」など、さまざまなセッションがあります。

2013年12月15日

【9.3新機能チェック】データチェックサムの機能とパフォーマンスへの影響

このエントリは、PostgreSQL Advent Calendar 2013のDay15の記事です。

データベース管理システムにとって、「データを保護する」というのは非常に重要な役割のひとつです。

PostgreSQLには、9.3から「データチェックサム」という機能が追加されました。これは、ハードウェア障害などによってデータが壊れた時に、そのことを極力早期に検出しよう、という仕組みです。

今回は、このデータチェックサムについて、その仕組みと使い方、性能への影響について紹介します。

■「データチェックサム」とは

「データチェックサム」というのは、PostgreSQLのデータブロック内のデータのチェックサムのことで、PostgreSQLのデータブロックの中身が万が一壊れた時に、早期に検出できるようにするための仕組みです。

9.2まではこの機能が無かったため、「(メモリやディスク不良が起因で)データブロックの中身が壊れていることにかなり後になって気付く」ということもありました。

2013年12月3日

Apache JMeterでPostgreSQLの負荷試験をする

このエントリは、PostgreSQL Advent Calendar 2013のDay3の記事です。

「データベースの負荷試験」を考える時、皆さんはどのような方法で実施することを検討するでしょうか。自前のテストスクリプトでしょうか。あるいは、データベース単体の負荷試験は行わず、Webシステム全体の負荷試験として実施するでしょうか。

PostgreSQLには、pgbenchというベンチマークツールが付属しており、このツールのシナリオを作成することで多少は独自のシナリオでの試験を行うことも可能ですが、状況によってはそれだけでは自由度が不足することがあります。

今回は、Webシステムの負荷テストでよく使われるJMeterを使って、自由なシナリオでPostgreSQL単体の負荷試験を行う方法を紹介します。

(なお、JMeterは非常に多機能な負荷生成ツールですので、今回はJMeterの網羅的な説明ではなく、あくまでもPostgreSQLのテストをする際の観点に絞って紹介します。JMeterの詳細については、他の情報を参考にしてください)

■事前準備

事前準備として、以下のインストール、設定を行う必要があります。
  • Java SE
  • Apache JMeter
  • PostgreSQL JDBCドライバ
  • PostgreSQL
今回は、Java SEとPostgreSQLそのもののインストールについては割愛します。

2012年12月25日

PostgreSQL用MPPミドルウェア「Stado」の導入

PostgreSQL Advent Calendar 2012(全部俺)のDay 25です。

Advent Calendar最終日の今回は、少し大物としてPostgreSQLのMPPミドルウェア「Stado」の導入方法を紹介します。

Stado: The Open Source MPP Solution
https://launchpad.net/stado

■「MPP」とは何か


皆さんは「MPP」という言葉を聞いたことがあるでしょうか。

コンピュータの世界で「MPP」と言えば「Massive Parallel Processing」、日本語で言うところの「超並列処理」のことを指します。

Massively parallel (computing) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Massive_parallel_processing

データベースの世界で「MPP」と言うと、通常は「シェアードナッシング・アーキテクチャ」のスケーラブルな並列処理用のコンピュータアーキテクチャのことを指します。ベンダ製品で言うと、Teradata、Netezza、Greenplumなどが有名どころでしょう。

2012年12月24日

テーブルパーティショニングツール「pg_part」を使ってみる

PostgreSQL Advent Calendar 2012(全部俺)のDay 24です。

前回のエントリでは、PostgreSQLのテーブルパーティショニングの基本的なしくみとその使い方を解説してきました。

前回解説した通り、PostgreSQLのパーティショニングの機能は「理屈としては」確かに動くのですが、実際にはそのためにいろいろなコマンドを実行したりしなければならず、なかなか手間がかかるのも事実です。

■テーブルパーティションを操作するpg_partパッケージ


テーブルパーティショニングは、特に分析系の処理をしている時には便利なのですが、PostgreSQLの場合、作成や管理に結構手間がかかるため、なかなか手を出せない、という方もいるのではないでしょうか。(私も以前はそうでした)

そのため、パーティション操作のための処理を一括して実施してくれる関数群を提供するpg_partパッケージを作成しました。

uptimejp/pg_part
https://github.com/uptimejp/pg_part

今回は、このpg_partパッケージに含まれるSQL関数の使い方を紹介します。

2012年12月23日

テーブルパーティショニングを使って実現するパフォーマンス向上

PostgreSQL Advent Calendar 2012(全部俺)のDay 23です。

今回は、PostgreSQLにおけるテーブルパーティショニングの機能を取り上げます。

BigDataやデータ分析といったキーワードが多く聞かれるようになってきましたが、PostgreSQLでも大きなデータに対する集計処理のパフォーマンスを向上させるための機能が提供されています。

■「テーブルパーティショニング」


RDBMSにおける「テーブルパーティショニング」と呼ばれる機能には、ディスクへのアクセスを「局所化させる」、または「分散させる」ために提供されている機能です。これらの機能を使うことによって、大規模なデータを対象とした集計系の処理のパフォーマンスを向上させることができます。

RDBMSにおけるパーティションの種類には大きく分けて3つの種類があります。(正確には、2つとそのコンビネーションですが)

・レンジパーティショニング

レンジパーティショニングというのは、連続的な値(と連続的な意味)を持つカラム(日付など)をパーティションキー(分割のキー)として指定することで、テーブルスキャンなどのアクセスを「局所化」させることを目的としたパーティショニングです。「垂直方向のパーティショニング」と呼ばれることもあります。

2012年12月22日

データブロックサイズの変更と分析系クエリへの性能影響(SSD編)

PostgreSQL Advent Calendar 2012(全部俺)のDay 22です。

最近、PostgreSQL上でデータ分析処理をよく行うようになってきました。また、いろいろなところでSSDも使うようになってきました。

PostgreSQLとデータ分析とSSD、という組合せを考えた時、どのようにチューニングするのが望ましいのか、あるいはどのようなチューニングができるのか、個人的にはまだまだ試行錯誤中だったりします。

SSDはハードディスクと比べてブロックサイズが大きいという特徴があります。また、DWH系のデータベースでは大きいブロックサイズを使うとパフォーマンス上のメリットがある、と言われています。

今回は、SSD上でPostgreSQLを使ってデータ分析系の処理を行う時に、データブロックのサイズを変えるとクエリのパフォーマンスにどのような影響を与えるのか、実際にクエリを実行しながら見ていきます。

■ブロックサイズの変更方法と確認方法


PostgreSQLでデータブロックのサイズを変更するには、PostgreSQLのブログラムバイナリをビルドする際にブロックサイズを指定する必要があります。

具体的にはconfigureスクリプトのオプションに--with-blocksizeというオプションを与えて、ここでブロックサイズを指定します。

2012年12月21日

pgTAPを使ってPostgreSQL上でデータベースの単体テストを行う

PostgreSQL Advent Calendar 2012(全部俺)のDay 21です。

PostgreSQLはその拡張性の高さが大きな特徴となっており、「プロシージャ言語」、いわゆる「PL」として、一般的なSQLやPL/pgSQLだけではなく、PerlやPython、RubyやV8なども使うことができます。

これらのPLを使うと、自分の馴染んだ言語、特に広く一般的に使われているLLで簡単にロジックを書き、これをデータベース内で実行することができるようになります。このことが、最近PostgreSQLがアプリケーション開発プラットフォームとして注目を集めてきている大きな理由の一つでしょう。

一方で、ロジックを実装するということは、そのロジックが正しく動くことを確認するためのテストを行わなければなりません。

というわけで、今回はPostgreSQL上で開発を行う場合にユニットテストに使えるツール「pgTAP」を紹介します。

■単体テストツール「pgTAP」とは


pgTAPは、David E. Wheeler氏によって開発されているPostgreSQL用の単体テストツールです。

pgTAP: Unit Testing for PostgreSQL
http://pgtap.org/

単体テストを実行するのに必要なさまざまなSQL関数を提供しており、テストスクリプト内でこれらのSQL関数を使うことで、スキーマの構造やプロシージャ(ユーザ定義関数)のロジックの正しさなどをテストすることができます。

2012年12月20日

次期バージョンの9.3で実装された更新可能ビューを試してみる

PostgreSQL Advent Calendar 2012(全部俺)のDay 20です。

先日、ネット上でも少し話題になっていましたが、開発中のPostgreSQLの次バージョン(9.3)に「更新可能ビュー」をサポートするコードがコミットされました。

pgsql: Support automatically-updatable views.
http://archives.postgresql.org/pgsql-committers/2012-12/msg00154.php

今回はこの更新可能ビューについて、その制約なども含めてどのようなものなのかを見てみたいと思います。

なお、今回は開発中のバージョンで試しますので、試してみたい方はPostgreSQLのGitレポジトリからソースコードを取得して自身でビルドしてください。

Working with Git - PostgreSQL wiki
http://wiki.postgresql.org/wiki/Working_with_Git

■「更新可能ビュー」とは


「更新可能ビュー」とはどういった機能でしょうか。

RDBMSにおけるビューのしくみを理解している方は、それを思い浮かべていただければ分かるかと思いますが、ビューの定義が「十分に簡単」である場合、ビューに対するINSERTやUPDATE、DELETE処理は、元テーブルに対する更新処理に書き換えることが可能になるはずです。

この「ビューに対する更新処理を、元テーブルに対する更新処理へ自動的に書き換える」という機能が、「automatically updatable、自動的に更新できる」ビューと言われる機能になります。

2012年12月19日

PostgreSQLのストレージアーキテクチャ(FILLFACTOR編)

PostgreSQL Advent Calendar 2012(全部俺)のDay 19です。

昨日までのエントリで、PostgreSQLの追記型アーキテクチャの基本的な仕組みと、「追記型であるがゆえの課題」にどのように対処しているのかを解説してきました。

ストレージアーキテクチャ小咄シリーズの最終回である今回は、「FILLFACTOR」と呼ばれる仕組みについて、その動作している様子を見ながら解説します。

(他のRDBMSをご存じの方のボキャブラリーに直すと、OracleやDB2で言うところのPCTFREE、SQL ServerのFILLFACTORと似たような役割の機能になります。)

■ブロックに空き領域が無い時の更新処理


ブロック内部が既にいっぱいで空き領域が無い時にレコードを追加または更新しようとした場合、特に前々回に解説したPage Pruningを実施しても空き領域が無かった場合、PostgreSQLではどのように処理されるのでしょうか。

結論から言うと、同一ブロック内に新しいレコードを追記する領域が無いため、他のブロックに新しいレコードを書き込むことになります。

テーブルのブロック構造を思い出しながら、具体的な例で見てみましょう。


2012年12月18日

PostgreSQLのストレージアーキテクチャ(HOT編)

PostgreSQL Advent Calendar 2012(全部俺)のDay 18です。

前回のエントリでは、PostgreSQLのストレージアーキテクチャのうち、特にPage Pruningについて実際の動作状況を見ながら、その仕組みを解説しました。

ここまではテーブルのみの解説をしてきましたが、実際には(ほとんどのテーブルには)インデックスもありますので、レコードを更新する場合にはインデックスについてのケアも必要になります。

というわけで、今回はレコードに対する更新が行われている間に、インデックスがどのように動作しているのかを、具体的な動作例を交えて見てみます。

■インデックスの内部構造

B-Treeのリーフノードの内部構造は以下のようになっています。


前々回のストレージアーキテクチャの基本編で、pageinspectというcontribモジュールを紹介しました。