Hatena::ブログ(Diary)

日々の記録 別館

2016-05-23

Jubatusでラーメンレビューの点数推測 - キー追加

レビュー本文だけでなく、別の要素を学習キーとして追加すれば、推測の精度が上がるのでは?と思い、以下のパターンで再検証してみた。

  • ユーザID + レビュー本文
  • スープ種別 * レビュー本文

ユーザIDを追加することで、同一人物のスコア付与の癖から特徴を抽出できないか、またスープ種別を追加することで、スープによる採点の特徴を抽出できないか試すことにした。
(例えば、豚骨醤油スープのラーメンにおいては、「こってり」や「濃厚」はポジティブに思われやすいし、逆に淡麗系の塩などでは、「あっさり」がポジティブに思われる、などの特徴があるのではと推測した)

Jubatus起動時に設定するファイルは前回のまま。
(本当はユーザIDとスープ種別のtypeを変えるほうがよりいいんだろうけど、面倒なので一旦これで)

同じデータを元に、

  • ユーザID + レビュー本文
  • スープ種別 * レビュー本文

を学習させる jubash スクリプトファイルをawkで生成。
同様に、推測対象の classify を使ったスクリプトファイルに、ユーザIDあるいはスープ種別のキーを追加して実行してみた。


レビュー対象実際の点数レビュー本文のみレビュー本文+ユーザIDレビュー本文+スープ分類
ジャージャー麺7070, 60, 5565, 70, 8070, 80, 65
ラーメン7070, 60, 070, 55, 4570, 55, 80
皆楽みそラーメン8070, 65, 6070, 65, 7570, 65, 80
五目そば6575. 70, 6570, 65, 6065, 70, 60
まぜそば7580, 60, 7075, 80, 6075, 80, 85

結果を見てみると、スープ種別の追加によって、以前より精度が改善されたような気がしないでもない。
まあ、自分の採点5件だけなので、これだけで判断するのもどうかとは思うが、こういう形でチューニングしていくのかなー。

あとは、レビュー本文からのノイズ(ラーメンの味の評価に関係しないテキスト)をどうやって、自動的に除去すればいいのかなー。ラーメンデータベースユーザの中には、レビュー本文を日記帳と勘違いしているユーザもいるしなあw【毒】

さて、次のテーマは何にしようかな。
ユーザのクラスタリングってどう?みたいなコメントがあったので、ユーザの採点傾向から、似たようなユーザのクラスタリングというのは、如何にも機械学習らしいし、面白そうでもある。

2016-05-22

Jubatusでラーメンレビューの点数推測

我が家に新しい猫が来ました。にゃー。
f:id:nuko_yokohama:20160521162845j:image:w360

ということで、うちのPCにJubatusを入れてみました。
機械学習フレームワークということで、インストールから含めてなんかやたら難しげな印象がありましたが、
インストール自体はyumって終わりだった。意外と簡単。

使う場合は、各種言語のクライアントライブラリを別にインストールして、それを使ったプログラムを組まなきゃいけないけど、最近はjubash(うちの会社のJubatusエキスパートが開発したものらしい)という対話クライアントがあるので、まずこれを使ってみることに。
ただ、Pythonに慣れていないので、Jubashを使えるようになるまで、ちょっと躓いたけど。

やってみること

手元にある、ラーメンデータベース内の結構な量のラーメンのレビューを使ってみよう。
まず、レビューの点数、レビューの本文を抜き出してみる。
レビューの点数は0点から100点までの1点刻みになっているが、今回は5点単位に集約して、0, 5, 10, ..., 100 に分類する。

で、レビューの点数と、レビュー本文(Mecab形態素解析して特徴抽出)を組として事前に学習させ、その後で別のレビュー本文のみを与えて、スコアを推測(正確にはclassifyで分類)させる。
といっても、今回は最初だから、細かいチューニングはなし。

やってみる

Jubatusサーバを分類機能(classify)で起動する。
起動時の設定ファイルは以下のようなJSONファイルを指定する。
(このファイルは、QiitaにあったJubatusでテキストに含まれる特徴語の傾向を学習し、入力テキストをカテゴライズするを参考にした。

{
  "method": "AROW",
  "parameter": {
    "regularization_weight": 0.001
  },
  "converter": {
    "num_filter_types": {
    },
    "num_filter_rules": [
    ],
    "string_filter_types": {
    },
    "string_filter_rules": [
    ],
    "num_types": {
    },
    "num_rules": [
    ],
    "string_types": {
        "bigram":  { "method": "ngram", "char_num": "2" },
        "mecab": {
          "method": "dynamic",
          "path": "libmecab_splitter.so",
          "function": "create"
        }
    },
    "string_rules": [
        { "key": "*", "type": "mecab", "sample_weight": "bin", "global_weight": "idf" }
    ]
  }
}

[nuko@localhost jubatus]$ jubaclassifier -f rdb.json 
2016-05-22 07:15:46,379 28285 INFO  [server_util.cpp:376] starting jubaclassifier 0.9.0 RPC server at 192.168.9.143:9199
    pid                  : 28285
    user                 : nuko
    mode                 : standalone mode
    timeout              : 10
    thread               : 2
    datadir              : /tmp
    logdir               : 
    log config           : 
    zookeeper            : 
    name                 : 
    interval sec         : 16
    interval count       : 512
    zookeeper timeout    : 10
    interconnect timeout : 10
(中略)
2016-05-22 07:15:46,395 28285 INFO  [server_helper.hpp:226] start listening at port 9199
2016-05-22 07:15:46,396 28285 INFO  [server_helper.hpp:233] jubaclassifier RPC server startup

サーバが起動したので、さっそく学習データを jubash に食わせてみる。

train 点数 "レビュー本文"

こんな感じのフォーマットで10000件ほどのラーメンレビューの点数と、レビュー本文を組にして学習させる。
例えば、数年前に俺がレビューしたもの(http://ramendb.supleks.jp/review/300073.html)だと、

train 70 "【入店状況】1954入店。先客4〜50名程、後続も数名あり。【注文】胡麻味噌ラーメンセット(1080円)。セットには半ライス、焼売3つ、ザーサイが付く。【待ち時間】7分。【麺】中程度の太さ、軽い縮れを残した麺。茹で加減は普通。麺の量も普通というところ。【スープ】少し甘みのある味噌スープ。といっても味噌の風味は控えめで、代わりに胡麻風味が強く感じられる。これはこれで悪くない。ご飯にも良く合う味のスープになっている。【具】チャーシュー、もやし&ニラ炒め、コーン、海苔。チャーシューは煮豚タイプで脂少なめ・固めの食感。あまり好みのチャーシューではない。もやしとニラは軽く炒めてある。結構、具の量も多い。【感想】胡麻味噌風味で少し変わった味わいの一杯だったが、なかなか悪くなかった。ご飯&焼売のセットをつけて、おかずラーメンとして食べたのも良い選択だったかもしれない。ご飯も一緒に食べたこともありボリュームも十分。食堂のラーメンとしては頑張っているのではないかと思えた。【備考】肉味噌ラーメンはメニューからなくなり、この胡麻味噌ラーメンに変更されたようだ。"

こんなふうにtrainコマンドを使う。
これをざっと10000件ほど登録しておく。

やってみた

登録させた状態で、登録したものと別のレビュー本文を与えて、学習結果からどの点数に分類されるか試してみる。
例えば、別レビュー(http://ramendb.supleks.jp/review/290716.html)のレビュー本文から、点数の分類をやってみる。

classify review "【入店状況】1345入店。先客なし(客だと思ったのは店員だった)。 【注文】ジャージャー麺(750円) 【待ち時間】6分。 【麺】細目の麺。茹で加減は少し柔目。麺の量は普通。もう少し固めに仕上げてあ るとなお良かったかもしれない。 【具】肉味噌、胡瓜、葱。肉味噌はやや緩めに仕上げ てあり、普通のジャージャー麺とジャージャースープ麺との中間形態になっている。肉味噌の量は十分に多く、丼になみなみと盛られている。肉味噌内の具は挽肉と刻み玉葱。味付けの強さは中庸。胡瓜と刻み葱は食感に適度な変化をあたえてくれた。 【感想】なか なか悪くない一杯。ジャージャー麺にも色々な形態があるものだ。この一杯はまさに肉味噌が主役。この肉味噌の味付けなら、もう少し太目の麺でも十分受けきれるだろうと思えた。"
70: 0.142693147063
60: 0.116121843457
55: 0.109682038426
50: 0.0359025709331
40: 0.01305016689
25: 0.0105530405417
20: 0.00953553896397
30: 0.00441248342395
5: 0.00240551866591
0: 0.0016572214663
45: -0.00519017456099
35: -0.01147844363
75: -0.013936586678
85: -0.0146971540526
10: -0.0233904644847
95: -0.0392095260322
65: -0.0501153841615
90: -0.0509259775281
100: -0.0881003141403
80: -0.120291739702

すると、点数と類似度(-1.0から1.0の値域)が出力される。
この結果から、類似度の値が最も高いものの分類(この場合だと70)だと判断できる。
おお、実際のレビューの点数合ってるな!

ということで、他の自分の過去レビューを何パターンかやってみた。


レビュー対象実際の点数推測された分類(上位3件)
ジャージャー麺7070, 60, 55
ラーメン7070, 60, 0
皆楽みそラーメン8070, 65, 60
五目そば6575. 70, 65
まぜそば7580, 60, 70

うーん、思ったより正解の分類にはならないものだな。
日本語の表現で、「不満はない」などの書き方だと、自分ではポジティブに書いたつもりでも、ネガティブな結果になりやすいのかもしれない。日本語は難しい。ある程度はフレーズを意識しないと精度の高い学習自体難しいのか。

自分のレビューはほぼ定型化されているのだけど、他人のレビューからの推測はどうだろう・・・?
他の人のレビュー結果を適当にサンプリングして再試行してみる。


レビュー対象実際の点数推測された分類(上位3件)備考
ウルトラタンメン7960, 85, 80 
ラーメン(ヤサイ)8080, 85, 60非常に文章が短いケース
ラーメン海苔増し味濃いめ半ライス7070, 80, 55 
豚骨らーめん(ネギ多め)9070, 60, 55 
燈郎+無料トッピング(ヤサイマシ)8180, 85, 90 

うーむ、こちらも意外と推測結果がブレるな・・・。4番目のケースなどはかなり高いスコアではあるのだが。
やはりもうちょっと、Mecab methodを使う場合のチューニングが必要なのかなあ。
もう一つのチューニングとしては、ユーザIDを学習データに組み込むことか。
結構、ユーザによってスコアの付けかた、平均点って異なるので、その傾向を加味しないといけないかも。

大訂正

  • classifyの見方を間違っていた!
    • 絶対値云々は間違いかも。
    • 正値の上位3件で集計しなおした。

2016-05-20

Neo4jユーザーグループ勉強会 #7 に行ってきたよ

ということでNeo4jユーザーグループ勉強会 #7 に行ってきましたよ。

f:id:nuko_yokohama:20160521160808j:image:w360

今回は恵比寿ガーデンプレイスタワーにあるクラウドワークスさんで開催。
久々の恵比寿です。
前回、恵比寿に行ったのって、岩合光昭氏の写真展「ネコライオン」を観に行った時以来かなあ。

最初に注意が

  • データの注意点・・・?
  • かなり個人情報に触れるデータを使っているので配布資料はなし。
  • デモ用の?データはCSVだけでなく、Neo4jフォーマットでの配布もある!

パナマ文書の概要

v3.0発表

  • Creationlineの李さんから説明

V2までのおさらい。
  • RDBMSとグラフデータベース
    • 定義はエンティティ。しかし現実のデータ処理はレコードレベルの処理、このため大変。
  • Neo4jの歴史
    • CypherQueryが入ったことがやっぱり大きいと思うな。
  • バルクデータ処理もできるよー!
  • SQLとCpypherとの対応の話。Cypher全文検索とトリガ、プロシージャが未実装なのが課題なのだよなー。

コミュニティ版とエンタープライズ
3.0の話
  • Scale and Performance
    • データ数制限が実質上なし?(340億ノード)
    • Dynamic poinnter compression.
  • インデックスフリーの隣接性改善
    • pointer hop という技法でエッジなしでもトラバース可能にする?これでウルトラ高速化!とのこと。
  • オプティマイザ改善
    • 2.0まではWriteはRuleベースだった。
    • 3.0からはRead/WriteもCostベース
  • 開発者向け機能
    • 公式SDK。3.0 Bolt+Langage Driver. JavaだけでなくPython等も。
    • Bolt + Java Stored Procedure
      • 例えばMySQLに接続してJDBC経由で情報を取得してNeo4jにデータが投入できる。
    • Neo4j Browser Sync.
  • Docker上でもクラウド上でも使えるように。
  • 座標情報関数のサポート。つまりGis対応はじまた?
  • 最短経路(shortestPath)改善。

  • 3.0への移行
    • 3.0はJDK8対応。
    • 旧バージョンからの移行はそんなに大変ではない。
    • configure fileが1つに統合された。このへんは要注意。

パナマ文書:データ分析作業の話。

  • 4種類のCSVになっていて、それをNeo4jにロード可能。
  • なお、Neo4jフォーマットでも入手できる。

  • パナマの法律事務所(Mossack Fonseca)がデータ元。
    • そこがハッキングされて外部流出している(と事務所側は主張している)。
    • ドイツの新聞社がまずそれを受け取った。
      • 新聞社で独自に解析。Nuixでメタデータ抽出を試みたが失敗。
  • そこでICIJと協業することに。
  • ETL/Neo4jデータベースか、Linkriousで可視化。5/9にデータ公開。211MB、840Kノード、1.27Mエッジ。
  • これは2ndPlatform側

  • ノードの抽出
    • クライアント、企業、住所、役員(企業、個人)
    • 属性情報(ドキュメント番号、日付等)
  • 関係柄の抽出
    • 直接的なものは、データベースそのもの見れば分かる。
    • 間接的なもの:同じ住所、メール、似たような名前。

  • 今後、ICIJで拡張を考えていること。
  • 1st Platform(イメージ、PDF等)側の分析。
    • 個人企業と関連ドキュメントの関係、人間関係の関係、企業登記情報
    • ここが機械化できない。自動化できている2nd Platformと連携。

パナマ文書の話

ETL(Talend)の話

  • Talendはオープン版、商用版の2つがある。
  • 日本の顧客、いろいろ使っている。DATAやCOMでも使っている。
  • ICIJでも使っていた。
  • 某キャリアでのNW機器情一元管理・・・どこなんだろう・・・。
  • システム移行

  • Talend Hadoop, NoSQL, DWHとの連携コンポーネント
  • GUIで開発。
  • スケールアウト(Haddopベース)
  • クラウド(AWS)でも使える
  • 新技術に積極的に対応。
  • コミュニティ活動も活発らしい。

  • Talendは単なるETLではないよ。データの統合連携基盤だよ。

  • 無償版と有償版の違い
  • Neo4jとあんまり関係なかったけど、Talendは調査しておかないといけないかな(社畜的に)

Neo4jを使用したパナマ文書データ検索デモ
  • クリエーションラインの木内さん。
  • デモに使ったデータは加工・匿名化してる。
  • 4種類のノード
    • Ofiicer(役員), Address(住所), Entity(オフショア会社・個人), Intermediary(仲介業者)

Officer ----> Addeess
  |  |
  |  +------------+
  |               |
  o               o
Entity <---- Intermediary

  • ETL済み、配布ファイルは210MB、展開後470MB
  • プロパティは実はディスク上に置かれている。ノードとエッジをオンメモリに。
    • インデックスもオンメモリに。
    • これ、知らんかった。基本、ノードとエッジがオンメモリだから探索が高速なのか。
  • CSVロードしちゃうと時間めっさかかるよー。なぜならクエリ内で変換しちゃうから。
  • リレーションはMATCH/MERGE文を使って手動でつけないといけない。エッジが多いととてつもなく時間がかかる。

  • LOAD CSV説明
  • neo4j-importはLinuxコマンドとして実行。データベースと、CSV群を指定。

  • クエリ
    • 日本人は何人いる? (2317人)
      • もっとも日本人ではない名前もあるし、逆もしかり。
  • パナマ文書で明らかになった人数は。
  • ある人間からリレーションをたどるデモ。
  • Officerが一杯・・・しかも同一住所。
  • 香港にEntityが何社あるか。
    • ただし、struck_off_date (活動停止)の会社も含む。
    • じゃあ、アクティブな会社は?
  • 香港のとある地区の活動中の会社役員の日本人の数は?

  • あるノードからあるノードを辿りつつ条件を指定できるのがCypherQueryの特徴。
    • 何らかの理由で繋がっている日本人の組


恒例:Neo4jじゃんけん大会

  • Neo4jTシャツと、Neo4j水ボトル、Neo4jガラス、Cpypher本、シール10枚
    • 残念、今回は勝てなかった。

懇親会

PostgreSQL 9.6 - 手元の環境でpgbenchった

手元の貧弱な環境でPostgreSQL 9.6 beta1とPostgreSQL 9.5のpgbench結果を比較してみた。
ついでに、今リリースされている、9.6 beta1 RPMに --enable-cassert ついてんじゃね?みたいな話を某所で聞いたので、--enable-cassert の有無によって、どのくらいpgbench結果に影響が出るのかも見てみることにした。

環境

PostgreSQL

pgbench設定

結果


バージョン 平均tps
9.6 beta1 2757.322
9.6 beta1 cassertあり 1845.260
9.5.2 3331.687

f:id:nuko_yokohama:20160520064958p:image

  • おやあ・・・この環境だと明らかにPostgreSQL 9.6 beta1のほうがtpsが落ちている
    • beta1なので、まだ性能改善の余地がたっぷりあるのか。
    • コア数が少ない貧弱な環境だと、9.6のほうが不利になるのか。
  • 当たり前だけど、 --enable-cassert を付与するとめっさ性能に影響でるのね。
  • 一応、9.6のpgbenchのクエリの実行計画も見てみたけど、基本、IndexScanしかないので max_worker_degree がデフォルト値(2)であっても、別に実行計画が変わるわけじゃない。
    • ただ、Planing Timeが9.5よりも、微妙に大きくなっているような・・・max_worker_degree = 0 にするとPlaning Timeが多少改善されたりするのかな?

2016-05-18

PostgreSQL 9.6 - みんな大好きpsql

ということで、今日はみんな大好き psql の9.6改造項目について、実際に動かして試してみましたよ。
psqlがあればGUIクライアント要らないよねw
なお、今回のエントリ、ちょい長いです。

複数のコマンド指定、複数のコマンドファイル指定

リリースノートの記述。

Support multiple -c and -f command-line options (Pavel Stehule, Catalin Iacob)
To allow this with sane behavior, one backwards incompatibility had to be introduced: -c no longer implies --no-psqlrc.

要するに、-c コマンド文字列 や -f コマンドファイル名 が複数記述可能になったっぽい。
試してみよう。

[nuko@localhost ~]$ psql postgres -c "SELECT pg_backend_pid()" -c "SELECT pg_backend_pid()"
 pg_backend_pid 
----------------
          12699
(1 row)

 pg_backend_pid 
----------------
          12699
(1 row)

どうやら、この挙動を見る限りでは、複数回 -c オプションで指定したときには、同じセッション内で動作するっぽいですね。

じゃあ、次は複数の-fオプション指定。
こんな2つのファイルを用意する。

[nuko@localhost ~]$ cat /tmp/file1.txt 
BEGIN;
SELECT pg_backend_pid();
[nuko@localhost ~]$ cat /tmp/file2.txt 
SELECT pg_backend_pid();
COMMIT;

トランザクション途中でファイルを分割していることに注目。

で、これを複数同時に指定してみる。

[nuko@localhost ~]$ psql postgres -f /tmp/file1.txt -f /tmp/file2.txt 
BEGIN
 pg_backend_pid 
----------------
          12416
(1 row)

 pg_backend_pid 
----------------
          12416
(1 row)

COMMIT

複数のファイルにまたがってトランザクションが継続しているのがわかりますね。
(そうでなければ、最後のCOMMITで"WARNING: there is no transaction in progress"と怒られるはず。

まあ、これはあると嬉しい機能ですよね。

クロスタブ集計ビュー


Add a \crosstabview command that prints the results of a query in a cross-tabulated display

面白いけど、謎機能その1。

たとえば、こんなクエリを発行して、以下の様な結果を取得する。

tmp=# TABLE sales ;
    date    | item  | sales 
------------+-------+-------
 2016-05-16 | Ramen |  1650
 2016-05-16 | Curry |  2500
 2016-05-16 | Udon  |   500
 2016-05-16 | Soba  |   600
 2016-05-17 | Ramen |  2400
 2016-05-17 | Curry |   800
 2016-05-18 | Ramen |  1400
 2016-05-18 | Curry |  1600
 2016-05-18 | Udon  |  1000
(9 rows)

この状態で、以下の様な9.6新規のpsqlのメタコマンドを発行する。

tmp=# \crosstabview date item sales
    date    | Ramen | Curry | Udon | Soba 
------------+-------+-------+------+------
 2016-05-16 |  1650 |  2500 |  500 |  600
 2016-05-17 |  2400 |   800 |      |     
 2016-05-18 |  1400 |  1600 | 1000 |     
(3 rows)

なんかクロスタブ集計っぽい結果が出てきたw

\crosstab メタコマンドは3つないし4つの引数をとる。
1つ目は縦側の列、2つ目は横側の列、3つ目はセルに相当する列を指定。
4つ目の引数にはソートしたい列名を指定する。

面白い機能なんだけど、
なぜpsql上でクロスタブ集計ぽいことしたかったのか、という疑問はある。いいぞ、もっとやれw

\errverbose

Add an \errverbose command that shows the last server error at full verbosity

直前のエラー情報詳細を表示してくれるメタコマンド。

tmp=# SELECT hoge;
ERROR:  column "hoge" does not exist
LINE 1: SELECT hoge;
               ^
tmp=# \errverbose 
ERROR:  42703: column "hoge" does not exist
LINE 1: SELECT hoge;
               ^
LOCATION:  errorMissingColumn, parse_relation.c:3090
tmp=# SELECT 1;
 ?column? 
----------
        1
(1 row)

tmp=# \errverbose 
ERROR:  42703: column "hoge" does not exist
LINE 1: SELECT hoge;
               ^
LOCATION:  errorMissingColumn, parse_relation.c:3090

現実社会でもいるよね。
いつまでも失敗を覚えてぐちぐち蒸し返す奴ってwww

\evコマンドと\svコマンド

Add \ev and \sv commands for editing and showing view definitions

\ev コマンドは、クエリエディタコマンド \e をちょい拡張したもので、ビュー編集テンプレートエディタに表示してくれる。

CREATE VIEW  AS
 SELECT
  -- something...

似たような機能として、 \ef (関数テンプレート表示)があったけど、それのView版ね。

\sv はビュー生成時のクエリを表示してくれるメタコマンド。こんな感じ。

tmp=# \sv sales_date 
CREATE OR REPLACE VIEW public.sales_date AS
 SELECT sales.date,
    sum(sales.sales) AS sum
   FROM sales
  GROUP BY sales.date

\gexec

Add a \gexec command that executes a query and re-submits the result(s) as new queries

最初はよくわかんなかったけど、最後に実行した実行結果を、SQLとして実行するというメタコマンド。
つまり、\gexec の直前に実行するクエリ
SQLを生成するクエリ
である必要がある。変態ですね。
実例を示したほうが早いかな。

まず、こんなクエリを実行する。

tmp=# SELECT 'SELECT now()' FROM (SELECT generate_series(1,2)) AS t;
   ?column?   
--------------
 SELECT now()
 SELECT now()
(2 rows)

2行の SELECT now() という文字列が結果として返却される。

この状態で、 \gexecを実行すると・・・

tmp=# \gexec
              now              
-------------------------------
 2016-05-18 20:31:06.846529+09
(1 row)

              now              
-------------------------------
 2016-05-18 20:31:06.846616+09
(1 row)

さっきの結果文字列 SELECT now() が2回実行される。
さて、この結果を見るとわかると思うけど、個々のクエリは別トランザクションとして実行されている。
が、これは \gexec の問題ではなく、psqlの自動コミットモードがデフォルトで on になっているため。
なので、自動コミットモードを off にすると、2回とも now() は同じ時刻を返却する(同一トランザクションになるので)。

tmp=# \set AUTOCOMMIT off
tmp=# ;
tmp=# SELECT 'SELECT now()' FROM (SELECT generate_series(1,2)) AS t;
   ?column?   
--------------
 SELECT now()
 SELECT now()
(2 rows)

tmp=# \gexec
              now              
-------------------------------
 2016-05-18 22:26:15.190622+09
(1 row)

              now              
-------------------------------
 2016-05-18 22:26:15.190622+09
(1 row)

おわりに

今日はネムイ(´・ωゞ)のでここまで。
psql は他にも9.6での改善項目、特にTAB補完などは次のエントリで紹介しようと思います。

それにしても、psqlって単なるSQLフロントエンドとは思えないほど、
変態的に高度な機能を実装しちゃってるよなー。
これだからpgAdminが使われなく(ry

2016-05-16

PostgreSQL 9.6 - システムカタログの差分

今度は、9.5と9.6のシステムカタログの差分を見てみる。
PostgreSQLの場合、特にDDLの追加や変更があった場合、必ずと言っていいほどシステムカタログに変更がある。裏を返せば、シスタムカタログの変更から、どんな機能追加があったのかを推測することもできる。
(まあ、リリースノート見たほうが早いのだけど)

調べ方

PostgrerSQL 9.5とPostgreSQL 9.6 beta1を起動して、PostgreSQL 9.6 beta1 のpsqlから

psql postgres -q -c "\d pg_*" > ファイル名

でファイルを生成。そのファイルのdiffを取る。シンプル。

システムカタログの差分



テーブル/ビュー名変更種別変更内容ぬこメモ
pg_aggregate列の追加aggcombinefn, aggserialfn, aggdeserialfn, aggserialtype の追加パラレル集約の関係?要調査
pg_am全面変更個々のアクセスメソッドフラグが消えて、ハンドラ関数ポインタに置き換わったみたい。インデックスのサポート能力ってSQLからどうやって見ればいいのだろう。
pg_configカタログの追加pg_config相当の情報リモートからconfigが参照可能になったってことだね。
pg_init_privsカタログの追加システム内オブジェクトの初期権限管理用のカタログ?普段使うものではない?要調査
pg_proc列の追加proparallelの追加名前からすると、関数が並列処理に対応するかどうかのフラグ?CREATE FUNCTIONに影響あるのかな。
pg_replication_slots列の追加confirmed_flush_lsn の追加。ロジカルレプリケーション利用者が受信した場所を示す列かな。
pg_stat_activity列の変更waitingがwait_event_typeとwait_eventに分離したみたい。監視方式にも影響でるのかな?
pg_stat_progress_vacuumカタログの追加VACUUM処理進捗表示のためのカタログPostgreSQL: Documentation: 9.6: Progress Reportingを見ればいいのだな。
pg_stat_wal_receiverカタログの追加名前のとおり、wal recieverの挙動に関する稼働統計情報かな。これを使うと、どういう監視が出来るようになるのかなあ。

システムカタログも結構変更が入っているな。

  • pg_am(インデックスアクセスメソッド)の詳細が見れなくなってる・・・どうやって見ればいいんだろうな。
  • pg_configの追加なんかは、ベンチマーク測定時の環境情報取得時に、ちょい楽になりそう。