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