5月28日（土）にPostgreSQLアンカンファレンスを開催します

5月28日（土）にPostgreSQLアンカンファレンスを開催いたします。

• 第7回 PostgreSQLアンカンファレンス＠東京（2016/5/28）
  https://atnd.org/events/75718

PostgreSQL関連何でもアリのごった煮感溢れるカジュアルな感じのイベントですので、PostgreSQLに興味のある方はぜひご参加いただければと思います。

技術的な知見だけではなく、コミュニティの人々と知り合いになるチャンスでもあります。お申込みは上記ATNDからどうぞ。

では。

データ分析用ライブラリ MADlib を使って PostgreSQL で機械学習する

MADlibは、現代的なデータ分析には欠かせない回帰分析やデータマイニングのアルゴリズムが実装されているオープンソースのライブラリです。

MADlibを導入することによって、これらのアルゴリズムをPostgreSQLのユーザ定義関数の形で使うことのでき、データベースサーバの内部でデータ分析の処理できるようになります。

今回は、このMADlibの導入方法から動作確認、ロジスティック回帰分析における簡単な使い方までをご紹介します。

■MADlibとは何か

MADlibは、もともとはGreenplumというPostgreSQLをベースにしたMPP製品（DWH用RDBMS）を開発していた企業が開発していたライブラリで、Greenplumで利用できるように開発されていたものでした。

2015年9月に、Greenplum（を買収したEMC）がMADlib（や他のソフトウェア類）をApache Foundationに寄贈し、MADlib は Apache Incubator のプロジェクトとなりました。

そして、4月6日に Apache Incubator のプロジェクトになって最初の GA(Generally Available) リリースである1.9がリリースされました。

• MADlib
  http://madlib.incubator.apache.org/
• MADlib 1.9 User Documentation for MADlib
  http://madlib.incubator.apache.org/docs/latest/index.html

パラレルスキャンのスケーラビリティ調査とFlame Graphsによるプロファイリング可視化

先月、弊社にデータベース系の研究をしていた中国人留学生がインターンに来ており、その彼にお願いしてPostgreSQLのパラレルクエリのスケーラビリティの調査と、プロファイリング＋可視化のツールとしてFlameGraphを使ってもらいました。

大学のスケジュールの関係上、インターンの期間が急遽、3週間から2週間に短縮されてしまったため、結果をきちんとまとめたり追試をしたりといったところまでは到達できなかったのですが、個人的にもそれなりに面白いアウトプットになったと思いますので、簡単にご紹介したいと思います。

なお、細かい手順の詳細などは、インターンに参加していた学生さんのGithubにまとまっています。参考文献に載せておきますので、興味のある方はそちらも参照してください。（本テストと直接関係のない内容も含まれています）

■テストの背景

PostgreSQLの9.6develにパラレルシーケンシャルスキャンが実装されたのは、みなさんご承知のことと思います。

• PostgreSQL 9.6のパラレルシーケンシャルスキャンを検証する
  http://pgsqldeepdive.blogspot.jp/2015/12/parallel-seq-scan.html

[翻訳] PostgreSQLの過去、現在、未来: ゴールポストを動かし続けて（Robert Haas）

PostgreSQL 9.5が正式リリースされて少し経ちましたが、みなさん既に試されたでしょうか？

PostgreSQLの主要な開発者のひとりに Robert Haas 氏がいます。Robert Haas 氏は EnterpriseDB社で働いていますが、今、PostgreSQL開発コミュニティの中で、もっともアグレッシブに開発している一人であり、開発コミュニティの中でも非常に大きな影響力と信頼を勝ち得ている一人であると言えるでしょう。

また、Robert Haas 氏は、2012年には日本のPostgreSQLカンファレンスで基調講演を行ったこともあります。

• 待望のPostgreSQL 9.2は大幅性能アップするのか？（1/2） － ＠IT
  http://www.atmarkit.co.jp/fdb/rensai/dbwatch2012/dbwatch201203_01.html

そのRobert Haas氏が9.5のリリース直後に、「これまでのPostgreSQLの5年間を振り返り、これからの5年間を考える」というブログエントリを書いていました。

• Robert Haas: PostgreSQL Past, Present, and Future: Moving The Goalposts
  http://rhaas.blogspot.jp/2016/01/postgresql-past-present-and-future.html

そのエントリが非常に興味深く、日本語でも紹介したいと本人にお願いしたところ翻訳掲載の許可をもらえましたので、本エントリではその全文をご紹介します。

PostgreSQLの主要な開発者が今何を考えているのだろうか。PostgreSQLの今後をどう考えているのだろうか。開発者の頭の中をちょっと覗いてみよう、といった趣で、PostgreSQLの今後を考える参考にしていただければと思います。

文中のリンクは原文のままになっています。

それではどうぞ。

PL/Pythonで独自の集約関数を作成する

先月、PostgreSQLアンカンファレンスで「PL/Pythonで独自の集約関数を作ってみる」という発表をしました。

本エントリでは、その詳細について紹介させていただきます。

■なぜPL/Pythonで集約関数なのか？

既に広く知られている通り、PostgreSQLではさまざまなプログラミング言語でプロシージャ／ファンクションをユーザが定義することができます。

では、なぜPL/Pythonで集約関数なのでしょうか？

まず1つ目の理由としては、Pythonとデータ処理が非常に相性が良い、ということが挙げられます。古くから統計解析でRが使われてエコシステムが発展してきたのと同じように、最近ではPythonを取り巻くデータ分析に関するエコシステムが大きくなり、データ分析に関するさまざまな処理をPythonで行えるようになってきています。

2つ目の理由としては、データ処理と集約関数というのは切っても切れない関係にあるということです。シンプルな COUNT() や AVG() から、最近ではウィンドウ関数まで、集約関数にはさまざまな処理があり、データベースにおけるデータ分析に集約関数は欠かせません。

そして、最後の理由としては、集約関数は「インデータベース（In-Database）処理」である、ということです。「インデータベース処理」というのは、データベースからデータを取り出してクライアントサイドで処理させるのではなく、データベースの内部でデータ処理をさせることを言います。こうすることによって、データの転送にかかる時間を削減したり、よりスペックの高いサーバ側で大量の処理をさせることが可能になります。

これらの理由から、これからPL/Pythonを使って独自の集約関数を作成できる意義はより高まっていくでしょう。

■PostgreSQLにおける集約関数の構造

次に、PostgreSQLの集約関数の構造を見てみましょう。

以下は、基本的なPostgreSQLの集約関数の構造および動作です。