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件取得する