http://surumegohan.hatenablog.com/
はてなブログに引っ越しました
過去記事はここで残しておきます
2018年4月13日金曜日
2017年5月24日水曜日
JJUG CCC 2017 Springに参加しました。
2017年5月24日
ごきげんよう。
2017年5月20日（土）に新宿で開催されたJJUC CCC 2017 Springに参加してきました。
参加メモを残しておきます。
参加目的は最近Java界隈からはすっかり離れているので、世の中の動向を知りたいというものです。
JJUG CCC 2017 Spring
Twitterハッシュタグ：#jjug_ccc (セッションごとにハッシュタグあり)
====================
10:00-10:45 JHipsterで学ぶ！Springによるサーバサイド開発手法
発表者：SHINICHI KOZAKEさん
Twitterハッシュタグ：#ccc_f1
スライドはこちら
https://speakerdeck.com/kozake/jhipstertexue-hu-springniyorusahasaitokai-fa-shou-fa
そもそも「JHipsterって何？」という状態で聴講しました。
Spring BootとAngularは便利だけど学習コスト高いよね。というお話。
サンプルコードが充実しており、Webアプリがローコストで作れるらしい。
登壇者のこざけさんの現場ではJHipsterのコードを真似しているとのこと。
あと個人的によさげだと思ったのが監査証跡がDBに保存されるので便利ってところ。
聴いてる限り結構便利そうなので機会があれば使ってみたいなぁ。
====================
11:00-11:45 Vue.js + Spring Bootで楽しくフルスタック開発やってみた
発表者：うらがみさん
Twitterハッシュタグ：#ccc_g2
スライドはこちら
http://backpaper0.github.io/ghosts/spring-boot-doma-vue/#1
ほぼ満席で後ろの席にいたのでスライドが遠くなってしまった。。
今流行りのフレームワークとかがちらっと紹介されてて調べるにはいいかも。
デザインパターンの話とかもあった。
DBアクセス？に「Doma」ってやーつがあるらしい。
気になるので調べておこう。
====================
13:30-14:15 JavaエンジニアのためのPostgreSQLステップアップ
発表者：喜田 紘介さん
Twitterハッシュタグ：#ccc_m1
スライドはこちら
https://www.slideshare.net/kkida85/jjugccc2017springpostgrescccm1
13時には部屋に入ったけど、すでに混んでいて超満員状態。
入れなくて諦めた人もちらほらいた。
喜田さん曰く「参加者10人くらいだと思った」とのこと。
SQLをちゃんと理解しようってお話が前半。
PostgreSQLだけじゃなくてMySQLやOracleも少し話してた。
肝心なところは「DBに任せられる処理はDBに任せましょう」ってところ。
あとDBAの仕事内容と、「こういうことを共有してください」というお話。
すごくまとまっててわかりやすい発表＆資料だった。
====================
14:30-15:15 Javaエンジニアに知ってほしいRDBアンチパターン
発表者：Soudai Soneさん って書いてあるけど、「たけとも」さんです。
Twitterハッシュタグ：#ccc_g4 と #RDBアンチパターン
スライドはこちら
http://soudai.hatenablog.com/entry/jjug_ccc
そーだいさんの発表は笑いをとるところは面白いし、真面目なところは真面目ですごいと毎度のことながら思う。
SoftwareDesign5月号の記事の内容もあった。
・DBの寿命はアプリケーションよりも長い
・いつか直したいの「いつか」は一生こない
・「データベースの死はサービスの死」解決できる人は英雄
などなどの名言がでてた。
あと、「DBもモニタリング監視しよう」というのが、「たしかに！」ってなった。
DBのリファクタリングのしんどさがとても伝わってきた。
設計大事だよなぁ。
====================
15:45-16:30 Javaで実装して学ぶOAuth 2.0！
発表者：多田真敏さん
Twitterハッシュタグ：#ccc_e5
スライドはこちら
https://speakerdeck.com/masatoshitada/javadeshi-zhuang-sitexue-buoauth-2-dot-0
私はセキュリティ方面には疎いので勉強のために聴いてみた。
「認証」と「認可」は違うらしい。
OAuth2.0とOAuth1.0はStruts2とStruts1と同じくらい違うらしい。
スライドに各用語がまとまってたり、丁寧な図解があるので、なんとなーく、やんわりと伝わった。
この分野を調べるきっかけには良かった。
====================
16:45-17:30 劇的！データベース・ビフォーアフター 時代はディスクからインメモリーへ
発表者：漆原 茂さん / 山河 征紀さん
Twitterハッシュタグ：#ccc_c6
スライドみつからなかった。
まず「インメモリーデータグリッドは、メモリキャッシュではない」らしい。
とにもかくにもRDBをディスってた。。。
事例が3パターンあったんだけど、インメモリーデータグリッドで処理すれば速くなるだろうって話。
ただ、
・アーキテクチャを変更したアプリの影響
・DBの書き込みは非同期
・運用はどうするんだろう
とか気になるところがあった。
メモリだからすんごい速いんだろうけど、データの同期とかトランザクション処理をアプリで頑張るっぽくて、すごく大変そうな気がする。
====================
17:45-18:30 Java × Arduinoで始めるIoT / フィジカルコンピューティング
発表者：YUSUKE YAMAMOTOさん
Twitterハッシュタグ：#ccc_i5
スライドはみつからなかった。
「あるでぃーの」って読むらしい。
電子工作のお話でした。
LEDをチカチカさせたり、Twitterと連動させたり
なんかこう、わくわくする感じだった。
Arduinoの実演販売みたいだったｗ
登壇者がすごく活き活きとしていたｗ
ある意味で一番面白かったセッションだった。
====================
18:30-21:00 懇親会
LINEさんが寿司スポンサーとなったらしくて、会場で回転すしが回ってた。
とてもおいしかったです。
登壇者の方々に軽くご挨拶して、LT大会を聴きました。
LTはみなさん2－3分という時間で勢いがあって面白かった。
個人的には しょぼちむさん のバスの時刻表アプリの話が面白かったなー
====================
総括
今ではJavaをほぼ書かなくなってしまった身としてはすごく楽しかった。
今のJava界隈を少しでも知れたので良かった。
知らない技術、フレームワークとかたくさんでてきて勉強になったし、
各登壇者のプレゼンの仕方も参考になった。
これだけ充実して参加費・懇親会費無料ってすごい。
ごきげんよう。
2017年5月20日（土）に新宿で開催されたJJUC CCC 2017 Springに参加してきました。
参加メモを残しておきます。
参加目的は最近Java界隈からはすっかり離れているので、世の中の動向を知りたいというものです。
JJUG CCC 2017 Spring
Twitterハッシュタグ：#jjug_ccc (セッションごとにハッシュタグあり)
====================
10:00-10:45 JHipsterで学ぶ！Springによるサーバサイド開発手法
発表者：SHINICHI KOZAKEさん
Twitterハッシュタグ：#ccc_f1
スライドはこちら
https://speakerdeck.com/kozake/jhipstertexue-hu-springniyorusahasaitokai-fa-shou-fa
そもそも「JHipsterって何？」という状態で聴講しました。
Spring BootとAngularは便利だけど学習コスト高いよね。というお話。
サンプルコードが充実しており、Webアプリがローコストで作れるらしい。
登壇者のこざけさんの現場ではJHipsterのコードを真似しているとのこと。
あと個人的によさげだと思ったのが監査証跡がDBに保存されるので便利ってところ。
聴いてる限り結構便利そうなので機会があれば使ってみたいなぁ。
====================
11:00-11:45 Vue.js + Spring Bootで楽しくフルスタック開発やってみた
発表者：うらがみさん
Twitterハッシュタグ：#ccc_g2
スライドはこちら
http://backpaper0.github.io/ghosts/spring-boot-doma-vue/#1
ほぼ満席で後ろの席にいたのでスライドが遠くなってしまった。。
今流行りのフレームワークとかがちらっと紹介されてて調べるにはいいかも。
デザインパターンの話とかもあった。
DBアクセス？に「Doma」ってやーつがあるらしい。
気になるので調べておこう。
====================
13:30-14:15 JavaエンジニアのためのPostgreSQLステップアップ
発表者：喜田 紘介さん
Twitterハッシュタグ：#ccc_m1
スライドはこちら
https://www.slideshare.net/kkida85/jjugccc2017springpostgrescccm1
13時には部屋に入ったけど、すでに混んでいて超満員状態。
入れなくて諦めた人もちらほらいた。
喜田さん曰く「参加者10人くらいだと思った」とのこと。
SQLをちゃんと理解しようってお話が前半。
PostgreSQLだけじゃなくてMySQLやOracleも少し話してた。
肝心なところは「DBに任せられる処理はDBに任せましょう」ってところ。
あとDBAの仕事内容と、「こういうことを共有してください」というお話。
すごくまとまっててわかりやすい発表＆資料だった。
====================
14:30-15:15 Javaエンジニアに知ってほしいRDBアンチパターン
発表者：Soudai Soneさん って書いてあるけど、「たけとも」さんです。
Twitterハッシュタグ：#ccc_g4 と #RDBアンチパターン
スライドはこちら
http://soudai.hatenablog.com/entry/jjug_ccc
そーだいさんの発表は笑いをとるところは面白いし、真面目なところは真面目ですごいと毎度のことながら思う。
SoftwareDesign5月号の記事の内容もあった。
・DBの寿命はアプリケーションよりも長い
・いつか直したいの「いつか」は一生こない
・「データベースの死はサービスの死」解決できる人は英雄
などなどの名言がでてた。
あと、「DBもモニタリング監視しよう」というのが、「たしかに！」ってなった。
DBのリファクタリングのしんどさがとても伝わってきた。
設計大事だよなぁ。
====================
15:45-16:30 Javaで実装して学ぶOAuth 2.0！
発表者：多田真敏さん
Twitterハッシュタグ：#ccc_e5
スライドはこちら
https://speakerdeck.com/masatoshitada/javadeshi-zhuang-sitexue-buoauth-2-dot-0
私はセキュリティ方面には疎いので勉強のために聴いてみた。
「認証」と「認可」は違うらしい。
OAuth2.0とOAuth1.0はStruts2とStruts1と同じくらい違うらしい。
スライドに各用語がまとまってたり、丁寧な図解があるので、なんとなーく、やんわりと伝わった。
この分野を調べるきっかけには良かった。
====================
16:45-17:30 劇的！データベース・ビフォーアフター 時代はディスクからインメモリーへ
発表者：漆原 茂さん / 山河 征紀さん
Twitterハッシュタグ：#ccc_c6
スライドみつからなかった。
まず「インメモリーデータグリッドは、メモリキャッシュではない」らしい。
とにもかくにもRDBをディスってた。。。
事例が3パターンあったんだけど、インメモリーデータグリッドで処理すれば速くなるだろうって話。
ただ、
・アーキテクチャを変更したアプリの影響
・DBの書き込みは非同期
・運用はどうするんだろう
とか気になるところがあった。
メモリだからすんごい速いんだろうけど、データの同期とかトランザクション処理をアプリで頑張るっぽくて、すごく大変そうな気がする。
====================
17:45-18:30 Java × Arduinoで始めるIoT / フィジカルコンピューティング
発表者：YUSUKE YAMAMOTOさん
Twitterハッシュタグ：#ccc_i5
スライドはみつからなかった。
「あるでぃーの」って読むらしい。
電子工作のお話でした。
LEDをチカチカさせたり、Twitterと連動させたり
なんかこう、わくわくする感じだった。
Arduinoの実演販売みたいだったｗ
登壇者がすごく活き活きとしていたｗ
ある意味で一番面白かったセッションだった。
====================
18:30-21:00 懇親会
LINEさんが寿司スポンサーとなったらしくて、会場で回転すしが回ってた。
とてもおいしかったです。
登壇者の方々に軽くご挨拶して、LT大会を聴きました。
LTはみなさん2－3分という時間で勢いがあって面白かった。
個人的には しょぼちむさん のバスの時刻表アプリの話が面白かったなー
====================
総括
今ではJavaをほぼ書かなくなってしまった身としてはすごく楽しかった。
今のJava界隈を少しでも知れたので良かった。
知らない技術、フレームワークとかたくさんでてきて勉強になったし、
各登壇者のプレゼンの仕方も参考になった。
これだけ充実して参加費・懇親会費無料ってすごい。
2016年9月5日月曜日
Oracle Master Gold 11g 合格体験記
ごきげんよう。
先日、Oracle Master Gold 11gに合格したので受験記を残しておきます。
受 験 日 ： 2016/08/15
合 否 ： 合格
受験科目 ： 1Z0-053
受験言語 ： 日本語
取 得 点 ： 66%（合格点ぴったり）
合 格 点 ： 66%
問 題 数 ： 78
出題形式 ： 単一選択,複数選択
試験時間 ： 120分
勉強期間 ： 2ヶ月くらい
受験目的 ： キャリアアップ
勉強形態 ： 独学
実務経験 ： ちょっとだけ
勉強前のレベル ： Silverの知識が薄れかけている程度
本試験のレベル ： ある程度の知識が必要な中級者向け試験。でもしっかり勉強すれば合格できる。
何度目の挑戦か ： 1回目
【 使用教材 】
・ORACLE MASTER Gold［Gold DBA11g］（試験番号：1Z0-053）完全詳解＋精選問題集
→ いわゆる白本
・iStudy
一押し >>> 白本
【 勉強方法 】
通勤中にiStudyをぽちぽちやってましたが
ほとんどの時間は白本に充ててました。
本来は実機で確認すべきことが多いですが
今回は机上が大半になってしまいました。
夏休みを利用して白本を3週、iStudyを2周しました。
【 試験の感想 】
もっと高得点を予想してましたが蓋を開けてみればギリギリ合格。
白本でみたことのある問題がちらほらあり、白本サマサマでした。
【 受験者へのアドバイス 】
白本をまずは読んでしまいましょう。
途中わからないことがあっても、後半の章でわかったりするので
まずは全体を一読してしまった方が良いと思います。
【 次のチャレンジ 】
DB系はOracleのパフォチュー
2016年3月21日月曜日
Oracle Master Bronze 12c SQL基礎 合格体験記
2016年3月21日
ごきげんよう。
Oracle Master Bronze 12c SQL基礎に合格したので記録しておきます。
受 験 日 ： 2016/03/21
合 否 ： 合格
受験科目 ： 1Z0-061
受験言語 ： 日本語
取 得 点 ： 73点
合 格 点 ： 65点
問 題 数 ： 75
出題形式 ： 単一選択,複数選択
試験時間 ： 120分
勉強期間 ： 40-50時間程度
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： チョットダケ
勉強前のレベル ： OSS-DB Goldは持ってる。実務経験もあるけど12cはほとんどなし。
本試験のレベル ： ちょい難しい
何度目の挑戦か ： 2回目
【 セクション毎の正解率 】
非公開
【 使用教材 】
「【オラクル認定資格試験対策書】ORACLE MASTER Bronze[12c SQL基礎](試験番号:1Z0-061)完全詳解+精選問題集(オラクルマスタースタディガイド)」
「徹底攻略 ORACLE MASTER Bronze 12c SQL基礎問題集[1Z0-061]対応」
「最強WEB問題集Oracle Master 12c Bronze SQL基礎(1Z0-061)」
一押し >>> 【オラクル認定資格試験対策書】ORACLE MASTER Bronze[12c SQL基礎](試験番号:1Z0-061)完全詳解+精選問題集(オラクルマスタースタディガイド)
本屋さんで中身をみて白本を購入。
その後問題集を購入。
【 勉強方法 】
白本を1週解いてからping-tのWeb問題集にチャレンジしたら全然わからなくて撃沈。
ping-tをほぼ全問銀にしてから1度目の受験をしたが5点足りず不合格。
なので、黒い徹底攻略問題集を購入して1週。
その後、白本の模擬試験を再度実施。
【 試験の感想 】
120分が長いようで、受験すると短い・・・
あまり時間があまらなく焦りました。
見直そうと思っても見直せず・・
1問1.4分しかかけられないので、即答できる問題は即答して
SQLを眺めないといけない問題に時間を使うべきでしょう。
【 受験者へのアドバイス 】
PostgreSQLの資格をもってるから余裕でしょと思ったら大間違いだった・・
Oracle特有の記述方法がもりだくさん。
かつ12cは難易度高いという噂は本当でした・・・
2016年3月現在では、Oracle Master Bronzeの合格条件に
11gとSQL基礎も選べるので
認定だけ狙うならそちらの方がいいかもです。
【終わりに】
1回目の受験時なめてました。。
ちゃんと模擬試験を繰り返してようやく合格しました。
再受験無料キャンペーン中ですが本気で取り組まないと落ちますね・・
以上
ごきげんよう。
Oracle Master Bronze 12c SQL基礎に合格したので記録しておきます。
受 験 日 ： 2016/03/21
合 否 ： 合格
受験科目 ： 1Z0-061
受験言語 ： 日本語
取 得 点 ： 73点
合 格 点 ： 65点
問 題 数 ： 75
出題形式 ： 単一選択,複数選択
試験時間 ： 120分
勉強期間 ： 40-50時間程度
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： チョットダケ
勉強前のレベル ： OSS-DB Goldは持ってる。実務経験もあるけど12cはほとんどなし。
本試験のレベル ： ちょい難しい
何度目の挑戦か ： 2回目
【 セクション毎の正解率 】
非公開
【 使用教材 】
「【オラクル認定資格試験対策書】ORACLE MASTER Bronze[12c SQL基礎](試験番号:1Z0-061)完全詳解+精選問題集(オラクルマスタースタディガイド)」
「徹底攻略 ORACLE MASTER Bronze 12c SQL基礎問題集[1Z0-061]対応」
「最強WEB問題集Oracle Master 12c Bronze SQL基礎(1Z0-061)」
一押し >>> 【オラクル認定資格試験対策書】ORACLE MASTER Bronze[12c SQL基礎](試験番号:1Z0-061)完全詳解+精選問題集(オラクルマスタースタディガイド)
本屋さんで中身をみて白本を購入。
その後問題集を購入。
【 勉強方法 】
白本を1週解いてからping-tのWeb問題集にチャレンジしたら全然わからなくて撃沈。
ping-tをほぼ全問銀にしてから1度目の受験をしたが5点足りず不合格。
なので、黒い徹底攻略問題集を購入して1週。
その後、白本の模擬試験を再度実施。
【 試験の感想 】
120分が長いようで、受験すると短い・・・
あまり時間があまらなく焦りました。
見直そうと思っても見直せず・・
1問1.4分しかかけられないので、即答できる問題は即答して
SQLを眺めないといけない問題に時間を使うべきでしょう。
【 受験者へのアドバイス 】
PostgreSQLの資格をもってるから余裕でしょと思ったら大間違いだった・・
Oracle特有の記述方法がもりだくさん。
かつ12cは難易度高いという噂は本当でした・・・
2016年3月現在では、Oracle Master Bronzeの合格条件に
11gとSQL基礎も選べるので
認定だけ狙うならそちらの方がいいかもです。
【終わりに】
1回目の受験時なめてました。。
ちゃんと模擬試験を繰り返してようやく合格しました。
再受験無料キャンペーン中ですが本気で取り組まないと落ちますね・・
以上
2016年1月6日水曜日
MySQL徹底入門 第3版～5.5新機能対応～ を読んだ
2016年1月6日
ごきげんよう。
年末年始でちょこちょこ読んでた
「MySQL徹底入門 第3版～5.5新機能対応～」
が読み終わりました。
読んでみた感じとしてはMySQL初心者にはオススメです。
5.5なのでちょっと古いけど。
ただ、データベースってなんぞや？ってレベルの方の場合は
「おうちで学べるデータベースのきほん」
を先に読んだ方が良いかもしれません。
MySQLに関しては私はトーシローなので、都度ぐぐりーのしながら今までやりくりしてたんですけど、真面目にやらんとダメだなと常々思ってました。
で、ひとまず本を読みながらやっていくかーということでこの本を1冊目にチョイスしました。
CentOS7にMySQL5.5をインストールするところから手を動かしてちくちくやってました。
本の中身としては「徹底入門」らしく、一通りのMySQLの勘所は広く浅く書いてありました。
インストール
→ 環境設定
→ テーブル作る
→ SQLを打つ
→ PHPとかJavaとかでのデータベースプログラムを作る
って一通りの流れができていてわかりやすいです。
レプリケーションについても最低限の設定方法が書いてあります。
準同期はなんで「準」なのよ。ってところも触れてあります。
ただ、バックアップについても記載があったんだけど、リストアについては記載が少なかったかなーという印象です。
レプリケーションとバックアップ&リストアについては運用面を考えると重要なので、そこらへんの知識が欲しい場合は自分で調べながら補完すると良いかもです。
あと、文字コードの注意点と巻末のFAQがなかなか良かったです。
文字コードはハマることも多いので気をつけたいところです。
というわけで、MySQLを徹底入門しました。
次に読むMySQLの本は下記のどれかかなー。
・エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド
・実践ハイパフォーマンスMySQL 第3版
・詳解MySQL
以上
ごきげんよう。
年末年始でちょこちょこ読んでた
「MySQL徹底入門 第3版～5.5新機能対応～」
が読み終わりました。
読んでみた感じとしてはMySQL初心者にはオススメです。
5.5なのでちょっと古いけど。
ただ、データベースってなんぞや？ってレベルの方の場合は
「おうちで学べるデータベースのきほん」
を先に読んだ方が良いかもしれません。
MySQLに関しては私はトーシローなので、都度ぐぐりーのしながら今までやりくりしてたんですけど、真面目にやらんとダメだなと常々思ってました。
で、ひとまず本を読みながらやっていくかーということでこの本を1冊目にチョイスしました。
CentOS7にMySQL5.5をインストールするところから手を動かしてちくちくやってました。
本の中身としては「徹底入門」らしく、一通りのMySQLの勘所は広く浅く書いてありました。
インストール
→ 環境設定
→ テーブル作る
→ SQLを打つ
→ PHPとかJavaとかでのデータベースプログラムを作る
って一通りの流れができていてわかりやすいです。
レプリケーションについても最低限の設定方法が書いてあります。
準同期はなんで「準」なのよ。ってところも触れてあります。
ただ、バックアップについても記載があったんだけど、リストアについては記載が少なかったかなーという印象です。
レプリケーションとバックアップ&リストアについては運用面を考えると重要なので、そこらへんの知識が欲しい場合は自分で調べながら補完すると良いかもです。
あと、文字コードの注意点と巻末のFAQがなかなか良かったです。
文字コードはハマることも多いので気をつけたいところです。
というわけで、MySQLを徹底入門しました。
次に読むMySQLの本は下記のどれかかなー。
・エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド
・実践ハイパフォーマンスMySQL 第3版
・詳解MySQL
以上
2016年1月2日土曜日
「精神科医が教える読んだら忘れない読書術」を読んだ
2016年1月2日
ごきげんよう。
初詣のおみくじは末吉だったので。今年はほどよく頑張っていこうと思います。
さて、今回はIT技術的な話ではなく、先日読んだ本について書きます。
精神科医が教える読んだら忘れない読書術です。
年末年始休みにいくつか本を読む予定だったのですが、当方忘れっぽいのでこの機会にこの本を読みました。
すると「読んだらレビューを書きましょう」ってあったのでレビューとまではいかないけど、感想でも書こうと思った次第です。
で、この本は「精神科医が教える」って書いてありますが精神科医っぽさはほとんどなく、著者が読書をたくさんする人なので、その人が実践してることが書いてあります。
精神科医だからすごいのか？って期待で読むと釣られるんで注意。
読書しまくってる人がやってることって感じです。
はい。中身の話。
1章を自分なりに要約すると。
「読書は楽しみながらやること。で、読んだら行動することが重要。」
たしかに読んでそのままだと忘れちゃうし、行動を伴わないと「おもしろかったー」で終わってしまうのでとても腑に落ちた。
巷によくあふれてる自己啓発本を私も数冊読んだことがありますけど、基本的にどれも「グダグダ言ってないで行動しろ」って書いてあるものだと認識しています。
今回は読書に関してなので、読みっぱなしにしないで読んで気づいたことがあったら行動に移してみましょうってことを言ってるんだと思います。
2章は忘れないためにやることが書いてある。
「本を読んだら10日以内に3回アウトプットすること。」
「議論（飲み屋で話せるくらい）できるくらい読まないと効果が薄い。」
ということだそうです。
要するにインプットだけだと忘れちゃうってことですね。
読む前からアウトプットを意識して読むと良いそうです。
3章はアウトプットについてもう少し書いてある。
「具体的にどこがためになったのかを要約して誰かに伝えること」
「感想は読んだ当日でもいいけど、書評やレビューは次の日にする。なぜなら当日だと感情的になっちゃうから」
私からすると「これはどうなんだろうな？」と感じた。
本の種類にもよると思うんですよ。
小説とか自己啓発本とかはわかるんだけど、技術書の類はどうなのかなと。
技術書を読むときはたいてい手も動かす（はず）なので、視点が違うのかもしれない。
4章から忘れない読書術はどっか行っちゃってる。
「面白そうと思って本を買ったらすぐに読み始める。熱が冷めちゃうから」
これはその通り、、積み本はよろしくないね。。私はたくさん積んでます。。。
「著者に直接会う」
ってのもあった。
たしかに自分にとって良かった本の著者は実際に会ってみたい。
PostgreSQLの場合はJPUGのイベントとかアンカンファレンスとかに著者がいらっしゃることがある。
5章はどんな本がいいの？って話になってる。忘れない読書術はどこ行ったんだ。
「なりたい人が書いてる本、推薦してる本を読む」
これは最近自分でも気づいていて、技術書を読むときに、（自分の中で）すごい人が書いてる or 話題にしている本はいい感じなことが多い。
最近だとそーだいさんが「SQLアンチパターン」という本をオススメしてた。
ので、早速買った。
25章あってまだ私は5章くらいまでしか読んでないけど、すごく良い本。
データベース設計する人は読んでおいて損はない本。一部の人たちが名著と呼ぶのも納得。
6～8章は「電子書籍すげー」って話と「著者（樺沢 紫苑さん）のオススメ本の紹介」です。
オススメ本に精神科医っぽい視点が入ってるんだけど、一般の人はそれを読むか？って感じの本がいくつか紹介されてる。
あと読書好きにはKindleが便利で、いかに便利かってのがながーーく書いてあった。
まぁ、電子書籍便利だよね。って感じです。
総括：
「アウトプットを意識して本を読む」ってのと「レビューを書きましょう」ってのはとても納得。
これは今後実践していきたいところ。
なのでブログに書いてみた。
以上です。
2015年12月13日日曜日
第6回 PostgreSQLアンカンファレンス＠東京（2015/12/12）に参加しました
2015年12月13日
ごきげんよう
第6回 PostgreSQLアンカンファレンス＠東京（2015/12/12）
に参加しましたので、その際のメモを参加報告として記載します。
Twitterハッシュタグ：#pgunconf
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■ウィンドウ関数とplv8、PL/R 国府田 諭さん
ウィンドウ関数はWindowsじゃない！ｗ
から始まりました。
PostgreSQLのウィンドウ関数はドキュメントがわかりにくいとのこと。
たしかにドキュメントがちょっとわかりにくい
3章、4章、9章、リファレンスにまたがってる。
というわけで
plv8でウィンドウ関数を自作した
Q.
Window関数をごりごり使う時は分析が多い
Rとかで実装する方がよくない？
plv8はフィット感どうなの？
A.
大量のデータはRでやるには荷が重い
Web系の人が必要かもしれない？
■所感■
たしかにWindow関数のマニュアルは読みにくいかもしれない
plv8 は初耳単語なので調べます・・
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■2016年にしたいこと 桑田さん
１、libpgなしでもDBにアクセスしたい
問題点
・DBドライバが配列型やJSON型に未対応
・libpgのバインディングを言語ごとに作るのは面倒
・新しい言語を試したくてもDBアクセスできないから実用性が低い
解決策
・DBサーバにhttp1/2機能（I/F）を追加
どの言語でもhttpには対応している
非同期アクセスもしやすい
２、SQLの静的解析を評価したい
SQLのテストは少々困難
→ テストデータを用意するのが面倒
データ型や制約を活かしきれてない
例；スカラサブクエリになることを表現できない
JavaはCheckStyleやFindBugsみたいなツールがあるけど
SQLだと静的解析するツールが（そんなに）ない！
JSONはちょっと難しい
→ 時刻や日付のデータ型がない
JSONの欠点は「全部」をパースしないと解析できない
http2をDBサーバに組み込むの誰かやってくれたら嬉しい
■所感■
http2のI/Fが追加されたら確かに面白いかも
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Kei Hibioさん
Haskellを使ってSQLを組み立てるDSLを作りました
■資料
https://htmlpreview.github.io/?https://github.com/khibino/haskell-relational-record/blob/master/doc/slide/PostgreSQL-Unconference-201512/Query.html
あれやこれや作ってみたようです
・inner Join
・Left Outer Join
・group by
・order by
Q 普段これ使うの？どう使うの？
A SQL生成するところだけ発表したけど、結果も生成されるんです
HaskellのI/FがPostgreSQLにない？
ごきげんよう
第6回 PostgreSQLアンカンファレンス＠東京（2015/12/12）
に参加しましたので、その際のメモを参加報告として記載します。
Twitterハッシュタグ：#pgunconf
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■ウィンドウ関数とplv8、PL/R 国府田 諭さん
ウィンドウ関数はWindowsじゃない！ｗ
から始まりました。
PostgreSQLのウィンドウ関数はドキュメントがわかりにくいとのこと。
たしかにドキュメントがちょっとわかりにくい
3章、4章、9章、リファレンスにまたがってる。
というわけで
plv8でウィンドウ関数を自作した
Q.
Window関数をごりごり使う時は分析が多い
Rとかで実装する方がよくない？
plv8はフィット感どうなの？
A.
大量のデータはRでやるには荷が重い
Web系の人が必要かもしれない？
■所感■
たしかにWindow関数のマニュアルは読みにくいかもしれない
plv8 は初耳単語なので調べます・・
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■2016年にしたいこと 桑田さん
１、libpgなしでもDBにアクセスしたい
問題点
・DBドライバが配列型やJSON型に未対応
・libpgのバインディングを言語ごとに作るのは面倒
・新しい言語を試したくてもDBアクセスできないから実用性が低い
解決策
・DBサーバにhttp1/2機能（I/F）を追加
どの言語でもhttpには対応している
非同期アクセスもしやすい
２、SQLの静的解析を評価したい
SQLのテストは少々困難
→ テストデータを用意するのが面倒
データ型や制約を活かしきれてない
例；スカラサブクエリになることを表現できない
JavaはCheckStyleやFindBugsみたいなツールがあるけど
SQLだと静的解析するツールが（そんなに）ない！
JSONはちょっと難しい
→ 時刻や日付のデータ型がない
JSONの欠点は「全部」をパースしないと解析できない
http2をDBサーバに組み込むの誰かやってくれたら嬉しい
■所感■
http2のI/Fが追加されたら確かに面白いかも
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
Kei Hibioさん
Haskellを使ってSQLを組み立てるDSLを作りました
■資料
https://htmlpreview.github.io/?https://github.com/khibino/haskell-relational-record/blob/master/doc/slide/PostgreSQL-Unconference-201512/Query.html
あれやこれや作ってみたようです
・inner Join
・Left Outer Join
・group by
・order by
Q 普段これ使うの？どう使うの？
A SQL生成するところだけ発表したけど、結果も生成されるんです
HaskellのI/FがPostgreSQLにない？
■所感■
スライドを見ながら
なるほど・・って感じたけど
自分じゃ絶対かけない・・・
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
うさぎコレクター ～PostgreSQLで画像データ管理～
Ayumi ishiiさん
■資料
■問題
変化の激しい世の中において常に技術を追いかけ高いパフォーマンスが求められる
→ 癒しが重要
→ ペットのうさぎが癒し業をボイコットしてる
■仮説
うさぎ画像をみれば癒されるのではないか
■やってみる
うさぎ画像の検索結果から画像を抜き出す
→ ローカルに画像を保存
→ PostgreSQLで画像情報を管理する
＜コンプライアンス注意＞
非営利目的での再利用が許可された画像に限定
取得した画像は個人で癒しに使うのみ
Googleに非営利目的での再使用が許可された画像を表示する機能がある
→ 非営利目的用のURLになってる
→ 正規表現で地道にこれを抽出する！
ただし、うさぎ画像を非営利目的用画像にしぼると
かわいい画像が減る問題発生
画像をどうやって管理する？
・bytea → データ量が多くなると性能劣化
・ラージオブジェクト → io_import()などを使う
・外部ファイル → 画像の更新がDB管理でできない
PHPを使うとこんな感じになる
insert into image values(Io_import('/home/postgres/1')
■結果
画像フォルダがうさぎ画像でいっぱい！
手元にうさぎ画像がいっぱい！
ローカルなのでオフラインでもうさぎ画像がいっぱい！
何が起きてもうさぎ画像がいっぱい！
Q
このシステムの欠点がある。
このシステムにより飼ってるうさぎが癒し業を完全に放棄してしまうのでは？
A.
うさぎに気づかれないように使いますｗ
■所感■
こういうの好きｗ
他の画像でもできそうだし、応用が効きそう
アンカンファレンスらしい発表だった
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
9.5で追加されたGroup by機能の使い方 喜田さん
GROUP BY GROUPING SETS
1クエリで複数の集計を組み合わせて取得
標準SQLへの対応したと考えてる
・GROUP BY GROUPING SETS
・GROUP BY ROLLUP
・GROUP BY CUBE
→ CUBEはクロス集計ができる
■Group byの新機能で嬉しいこと
1クエリで結果を得られるのでAPとDBのアクセス回数を削減できる。
SeqScanの回数を削減できる。
■注意点
ソートが激増してDISKソートになるので、WORKメモリを増やしましょう
→ クイックソートになります
grouping関数の存在と役割。
9.5では使えたがマニュアルに書いてないし、pg_procなどからも定義が探せない。
関数じゃなくて修飾子っぽい？
■所感■
Group byはたしかに何回もやらないと
欲しい集計が今までできなかった気がする。
複数列を一気に対象にできるなら便利そう。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
PostgreSQL CLUSTER計画 久田正樹さん
ウィーンに行ってきました
PostgreSQL Conference Europe 2016
世界最大の401名の参加で世界最大
PGConf.EU Cluster Summitで何が決まった？
PostgreSQL TODOに更新があった
FDW、パラレル実行、パーティショニング、おそらくGSM/GTMを拡張し、ビルドインのShardingソリューションのPOCを作る
議事録公開されてるけど、参加みんな言いたい事いっててよくわからないｗ
シャーディングをする ＝＞ PostgeSQLがCLUSTER化されることが決まった！
ひとまずShardingでクラスタのPOCを作りますよ
Postgres-XCを拡張する？
※よくわからなかった
Q：
クラスタ化のマイルストーンありましたか？
A：
ありません
■所感■
クラスタ化されるのが早ければ２～３年後かも？
という話もでていた。
たしかにそろそろクラスタ化とか、こういう話がでてくるんだろうなと思った。
Postgres-XCの発展も個人的には期待したい。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
postgres_fdwを久々に使ってみた ぬこさん
AWS RDS PostgreSQL上では実質的に日本語全文検索できねーじゃねーか！
→ postgres_fdwを使おう
※スライドみててメモとってなかった・・
■資料
■所感■
postgres_fdwって聞いたことしかなくて
調べるにはいい機会になった。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
パラレルシーケンシャルスキャンの検証 snagaさん
9.6に実装される機能？
パラレルシーケンシャルスキャンのデモ
資料は以下
■所感■
シーケンシャルスキャンが高速化するなら、みんな幸せになりそう。
ただ、まだまだ検証段階なのでこれからどうなるのか楽しみ。
場合によりIndexよりも速くなったりするのかなぁ。
以上
2015年12月6日日曜日
OSS-DB Gold 合格体験記
2015年12月6日
ごきげんよう。
この記事はPostgreSQL Advent Calendar 2015 - Qiitaの6日目の記事です。
5日目はnuko_yokohamaさんに書いていただきました。
テクニカルな話題はみなさんにお任せして
ついさっきOSS-DB Goldに合格したので
その合格体験記（受験体験記）を記載します。
OSS-DB Goldの記事なネットにあんまりないので、少しでもお役にたてば。
受 験 日 ： 2015/12/06
合 否 ： 合格
受験科目 ： OSDBG-01
受験言語 ： 日本語
取 得 点 ： 73点
合 格 点 ： 70点
問 題 数 ： 30
出題形式 ： 単一選択,複数選択
試験時間 ： 90分（同意書・アンケート含む）
勉強期間 ： 30-40時間程度
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： チョットダケ
勉強前のレベル ： Silverの内容すら忘れている状態。contribってなんですか？
本試験のレベル ： 簡単ではない。受験するなら本気になった方がいいです。
何度目の挑戦か ： 1回目
【 セクション毎の正解率 】
運用管理 ・・・77%
性能監視 ・・66%
パフォーマンスチューニング・・・66%
障害対応 ・・・83%
【 使用教材 】
「PostgreSQL運用管理トレーニング」
「PostgreSQL 高度技術者育成テキスト」
「iStudy for OSS-DB技術者 OSS-DB Gold（Android版）」
「OSS-DBのサイトからダウンロードできる過去の対策講座資料」
「内部構造から学ぶpostgresql 設計・運用計画の鉄則」
「PostgreSQL日本語マニュアル」
一押し >>> PostgreSQL運用管理トレーニング
まず、OSS-DB Goldの対策本が他の試験のようにありません。
Silverの出版社に問い合わせましたが
出版予定はないってバッサリ切られました。
# 出せば売れそうなのに
なので、OSS-DBの公式サイトに載っている対策本をやるしかなかったです。
ただ、
「PostgreSQL運用管理トレーニング」
は4万円するという高価なテキストです。
私はたまたま入手経路がありましたが
多くの人は手に入らないんじゃないかと思います。
なのでその場合は
「PostgreSQL 高度技術者育成テキスト」
を確実に制覇しましょう。
数千円で手に入りますし、実務にも使える感じです。
あと
iStudyですが
PC版はwindows8.1以降に対応してないし（するつもりもないって言われた・・）
16000円くらいします。
スマホ版だと
まったく同じ問題、同じ構成で4000円（2000円×2）で手に入ります。
なのでこちらをオススメです。
【 勉強方法 】
試験勉強をする前に
この試験を受験する方はSilver合格済みと思いますが
結構忘れていませんか？
「内部構造から学ぶpostgresql 設計・運用計画の鉄則」
をまずは読みました。
この本はPostgreSQL9.3ベースですが、一通りのPostgeSQLの知識がまとまっており
知識ベースの持ち上げに最適です。
さて、ここから試験対策本題です。
まずはOSS-DBの公式サイトで試験範囲を確認。
その後、OSS-DBの公式サイトにあるOSS-DB Goldの講座（セミナー）の資料を確認。
資料に書いてある用語で初耳なのはぐぐりーのします。
「PostgreSQL運用管理トレーニング」を一通り読んでから
「iStudy for OSS-DB技術者 OSS-DB Gold（Android版）」を全問正解（バグあるけど）できるまで
やりつくす。（私は移動時間にポチポチしてました）
ここがポイントで1度ある程度の知識まで自分を持っていきます。
そのあとに
「PostgreSQL 高度技術者育成テキスト」
を読み直して知識を補填します。
そして公式サイトに公開されている問題や
手に入る問題はひたすら解きます。
iStudy の問題レベルはやや低いですが
「PostgreSQL 高度技術者育成テキスト」
の問題レベルはやや高いです。
しかし、手に入る問題が少ないため、可能ならばどちらもやりましょう。
【 試験の感想 】
問題数30問で試験時間は事実上80分です。
合格基準が70％なので9問ミスまで許されます。
情処試験やTOEICのように時間に追われる試験ではないので1問1問確実にやりましょう。
特に「適切な答え」と「誤った答え」のどちらを問われているかを間違えないように！
計算問題もありますが、その場合はその問題のみ使える電卓機能があるので
手書きでひっ算したりしなくて済みます。
問題を解く際に、自信がない問題はフラグを付けておきましょう。
一通り丁寧に解き終わった時点で残りが30分程度だったので
フラグをつけた問題をじっくり考えました。
で、どーしてもわからないものはラッキーを信じて埋めて置きます。
時間があまるなら、自信をもって解答した問題も見直してください。
9問ミスまでしか許されません。
1問が致命的になるためです。
【 受験者へのアドバイス 】
「試験に合格さえすればいい！知識を詰め込んでやる！試験なんて覚ゲーだろ！」
って考えはやめておいた方がいいです。
試験を受けて実感しましたが
各種参考書に載ってない問題がわんさかでます。
なので、この試験を勉強する際には
実際に実機でインストールして環境を構築して
ポチポチやりながら勉強することをお勧めします。
「それがめんどくさい！合格すりゃあいいんだ！」
という方は
もうとにかく問題を解いて、マニュアルを読みましょう。
そして繰り返しますが
これだけの本や資料を読んでも
まったくみたことないコマンドなり用語なりが試験には出ます。
（マニュアル制覇すれば別かもですが）
なのでつまずいたり、自信がないってところは
マニュアルみるなり
ぐぐるなりした方がいいです。
【終わりに】
というわけで、何とか合格しました。
ひとまずPostgreSQLの試験はこれが最上位ですが
ここでようやくスタートラインです。
ここで得た知識をもとに、PostgreSQLの実務経験を積んでいきたいところです。
明日の PostgreSQL Advent Calenderの担当はnoborusさんです。よろしくお願いします。
以上！
ごきげんよう。
この記事はPostgreSQL Advent Calendar 2015 - Qiitaの6日目の記事です。
5日目はnuko_yokohamaさんに書いていただきました。
テクニカルな話題はみなさんにお任せして
ついさっきOSS-DB Goldに合格したので
その合格体験記（受験体験記）を記載します。
OSS-DB Goldの記事なネットにあんまりないので、少しでもお役にたてば。
受 験 日 ： 2015/12/06
合 否 ： 合格
受験科目 ： OSDBG-01
受験言語 ： 日本語
取 得 点 ： 73点
合 格 点 ： 70点
問 題 数 ： 30
出題形式 ： 単一選択,複数選択
試験時間 ： 90分（同意書・アンケート含む）
勉強期間 ： 30-40時間程度
受験目的 ： 自分のスキルアップ
勉強形態 ： 独学
実務経験 ： チョットダケ
勉強前のレベル ： Silverの内容すら忘れている状態。contribってなんですか？
本試験のレベル ： 簡単ではない。受験するなら本気になった方がいいです。
何度目の挑戦か ： 1回目
【 セクション毎の正解率 】
運用管理 ・・・77%
性能監視 ・・66%
パフォーマンスチューニング・・・66%
障害対応 ・・・83%
【 使用教材 】
「PostgreSQL運用管理トレーニング」
「PostgreSQL 高度技術者育成テキスト」
「iStudy for OSS-DB技術者 OSS-DB Gold（Android版）」
「OSS-DBのサイトからダウンロードできる過去の対策講座資料」
「内部構造から学ぶpostgresql 設計・運用計画の鉄則」
「PostgreSQL日本語マニュアル」
一押し >>> PostgreSQL運用管理トレーニング
まず、OSS-DB Goldの対策本が他の試験のようにありません。
Silverの出版社に問い合わせましたが
出版予定はないってバッサリ切られました。
# 出せば売れそうなのに
なので、OSS-DBの公式サイトに載っている対策本をやるしかなかったです。
ただ、
「PostgreSQL運用管理トレーニング」
は4万円するという高価なテキストです。
私はたまたま入手経路がありましたが
多くの人は手に入らないんじゃないかと思います。
なのでその場合は
「PostgreSQL 高度技術者育成テキスト」
を確実に制覇しましょう。
数千円で手に入りますし、実務にも使える感じです。
あと
iStudyですが
PC版はwindows8.1以降に対応してないし（するつもりもないって言われた・・）
16000円くらいします。
スマホ版だと
まったく同じ問題、同じ構成で4000円（2000円×2）で手に入ります。
なのでこちらをオススメです。
【 勉強方法 】
試験勉強をする前に
この試験を受験する方はSilver合格済みと思いますが
結構忘れていませんか？
「内部構造から学ぶpostgresql 設計・運用計画の鉄則」
をまずは読みました。
この本はPostgreSQL9.3ベースですが、一通りのPostgeSQLの知識がまとまっており
知識ベースの持ち上げに最適です。
さて、ここから試験対策本題です。
まずはOSS-DBの公式サイトで試験範囲を確認。
その後、OSS-DBの公式サイトにあるOSS-DB Goldの講座（セミナー）の資料を確認。
資料に書いてある用語で初耳なのはぐぐりーのします。
「PostgreSQL運用管理トレーニング」を一通り読んでから
「iStudy for OSS-DB技術者 OSS-DB Gold（Android版）」を全問正解（バグあるけど）できるまで
やりつくす。（私は移動時間にポチポチしてました）
ここがポイントで1度ある程度の知識まで自分を持っていきます。
そのあとに
「PostgreSQL 高度技術者育成テキスト」
を読み直して知識を補填します。
そして公式サイトに公開されている問題や
手に入る問題はひたすら解きます。
iStudy の問題レベルはやや低いですが
「PostgreSQL 高度技術者育成テキスト」
の問題レベルはやや高いです。
しかし、手に入る問題が少ないため、可能ならばどちらもやりましょう。
【 試験の感想 】
問題数30問で試験時間は事実上80分です。
合格基準が70％なので9問ミスまで許されます。
情処試験やTOEICのように時間に追われる試験ではないので1問1問確実にやりましょう。
特に「適切な答え」と「誤った答え」のどちらを問われているかを間違えないように！
計算問題もありますが、その場合はその問題のみ使える電卓機能があるので
手書きでひっ算したりしなくて済みます。
問題を解く際に、自信がない問題はフラグを付けておきましょう。
一通り丁寧に解き終わった時点で残りが30分程度だったので
フラグをつけた問題をじっくり考えました。
で、どーしてもわからないものはラッキーを信じて埋めて置きます。
時間があまるなら、自信をもって解答した問題も見直してください。
9問ミスまでしか許されません。
1問が致命的になるためです。
【 受験者へのアドバイス 】
「試験に合格さえすればいい！知識を詰め込んでやる！試験なんて覚ゲーだろ！」
って考えはやめておいた方がいいです。
試験を受けて実感しましたが
各種参考書に載ってない問題がわんさかでます。
なので、この試験を勉強する際には
実際に実機でインストールして環境を構築して
ポチポチやりながら勉強することをお勧めします。
「それがめんどくさい！合格すりゃあいいんだ！」
という方は
もうとにかく問題を解いて、マニュアルを読みましょう。
そして繰り返しますが
これだけの本や資料を読んでも
まったくみたことないコマンドなり用語なりが試験には出ます。
（マニュアル制覇すれば別かもですが）
なのでつまずいたり、自信がないってところは
マニュアルみるなり
ぐぐるなりした方がいいです。
【終わりに】
というわけで、何とか合格しました。
ひとまずPostgreSQLの試験はこれが最上位ですが
ここでようやくスタートラインです。
ここで得た知識をもとに、PostgreSQLの実務経験を積んでいきたいところです。
明日の PostgreSQL Advent Calenderの担当はnoborusさんです。よろしくお願いします。
以上！
2015年11月28日土曜日
PostgreSQLカンファレンス2015 に参加しました。
ごきげんよう。
PostgreSQLカンファレンス2015 に参加しました。
https://www.postgresql.jp/events/jpug-pgcon2015/
参加報告を簡潔に記載します。
■ハッシュタグ #pgcon15j
#敬称は略
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
1、【 基調講演 】PostgreSQL 9.5 について
PostgreSQL 開発者
Michael Paquier
1-1、講演内容
(1)
掲題の通り、PostgreSQL9.5について講演なさってました。
(2)
来月中に9.5.0が出る見込みらしいです。
(3)
ここでも目玉機能は UPSERT でした。
INSERT文の拡張だと私はとらえていますが、
INSERT...ON CONFLICT文により
データ格納時に衝突が起きたらどんな動きをするか指定することができます。
かなり便利な機能かと。
(4)
あとの話は
・BRINインデックス
・GROUPING SETS
・JSONBの拡張
・RLS（Row-Level Security）
など
RLSはユーザによって検索できる行を制御できるというもの。
(5)
Streaming standbyとして
archive_mode = 'always'
が追加されます。
WALを制御するコマンドですが、この効果により
WALの欠損を防ぐことができる・・？ ような認識をしました。
(6)
pg_rewind
ベースバックアップをとったあとに
マスタとスレーブでWALの内容が異なっていく
そしてマスタが何らかの理由でマスタじゃなくなり
スレーブが昇格する際に
マスタのWALをRewind（巻き戻して）、ベースバックアップした時間まで戻り、
そこから昇格したスレーブのWALをたどっていくようです。
# 文字で表現するのがとても難しい・・
(7)
他にも
checkpoint_segmentsがなくなり
max_wal_sizeでコントロールするようになったらしいですが
これはソフトウェアでの制御になるので
実際は流れてくるwalの塊の量によって
サイズオーバーしてしまうことがあるので注意するべしとのこと。
■所感
WALまわりの変更が多い印象を受けました。
ストリーミングレプリケーションの欠点や
ベースバックアップの考慮などに力をいれている印象です。
RDBとしての機能として大きな変更はないように見受けられたので
PostgreSQLとしてどういう方向に今後力を入れていくかが
垣間見られた気がします。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
2、【 基調講演 】
企業における Postgres Way はこれだ
～ 6 年間の取り組みから語る失敗事例と成功パターン ～
株式会社アシスト
データベース技術本部
徳原 茂之
★スライドは後日アップロードされるそうです。
注意：
アシストさんは
「PostgreSQL」も「PostgresPlus」も
「Postgres」と呼ぶので、そこは注意が必要です。
聴いててどっちなのかわからないことが多々あり・・
＜＜議事メモそのまま載せます＞＞
2-1、講演内容
(1)
●アシスト社のPostgresへの取り組みの紹介
・パフォーマンスセラピー
Oracleの性能情報をグラフで可視化するサービス
・勤怠管理
社内の勤怠管理をPostgresを使ってシステム化した
(2)
●採用傾向の変化
OSS-DBを採用する動きが活発化
・ご相談傾向推移
2013年は新規システムの検討が多い
2015年は移行が多い
どういうケースでPostgresを使うのか、
どういう設定にするのか基準を作りたいという要望が多い
・ANAシステムズ様 事例
Postgresの選定・構築・運用の基準を確立
・大和総研ビジネスイノベーション様 事例
社会インフラ等クリティカルなシステムでの採用
電力の管理、分析システムの根幹のエンジンにPostgres
(3)
●ヨーロッパにおけるPostgreSQLの取り組み
EU全体におけるPostgreSQL開発と普及活動
AXLEプロジェクト
各種イベント
カンファレンス
Meet Up MTG
・大規模データベースへの対応
AXLEプロジェクト
10～100TBのデータベースを対象
BI処置を高速かつセキュアに
9.5以降の機能開発に貢献
BRINインデックス
Tablesample
双方向レプリケーション
列単位での格納・圧縮（COAST）
・主要都市でのイベント開催
PGDay UK
イギリス国内のカンファレンス1日
2015年度100名
物事をオープンにすることが、物事がよくなることだ
'Make things open: it makes things better.'
London Meet up
年3-4回
・PostgreSQL Conference Europe
ヨーロッパで最大のカンファレンス 4日間
2015年度400名 過去最高
多くの主要デベロッパーが参加
・主要都市でのイベント開催
FOSDEM
OSCみたいな感じ 無料 オープンソース全体のイベント2日間
5000-6000名
PostgreSQL、MySQL、Virtulalization etc..
・ドイツ Zalando社
ヨーロッパ最大のオンラインショッピングサイト
導入背景
処理性能確保のためPHP+MｙSQLだったのがJava+PostgreSQLへ書き換え
データ規模 5TB （12GB/1日増加）
・Adspert社ドイツ
SaaS型のWeb広告系サービス
導入背景
OLTP/OLAP用別のデータベースをPostgreSQLで統合
データ規模：3TB
導入効果
顧客ユーザ事にデータベースを分割することでデータを水平分散
5台のサーバに1TBずつに分割してる
PostgreSQLはOracleのマルチテナントの思想を元からもっている
・TanTan社 中国
スマートフォン向け出会い系アプリケーション
PostGISの機能性を評価し、PostgreSQLを採用
メモリ256GB ストレージSSD データ規模3TB
8インスタンスへデータを水平分割し、ストリーミングレプリケーションで参照処理の負荷を分散
大量の日時処理 1億6千万のINSERTや1200万のSELECT処理の性能を確保
(4)
■Postgreｓの製品評価
柔軟&フレンドりなライセンス
学びやすいDBアーキテクチャ
エンタープライズ向け機能進化
活発なコミュニティ活動
1500件/年の問い合わせ
障害解決率が高い
(5)
■なぜ企業への浸透・活用は進まないのか
失敗事例
A社 採用が進まない
OSSの積極的な採用を会社方針としている
失敗要因
稼働実績の多さからSIerが商用DBを提案する
DB選定に対する基準があいまいなため、提案内容への指摘ができない
スキル習得に要するコストが読めない
担当者が責任を負いたがらない
B社 コストメリットが得られない
パッケージソフトのリポジトリを商用DBからPostgresに変更
失敗要因
アプリケーション改修カ所が想定より多い
改修コストがライセンスコストの減額分を上回ってしまう
パッケージソフトの販売展開が見通せていない
C社 ヨコ展開が進まない
展開効率化のため、事前に共通ドキュメントを整備（ガイドライン）
失敗原因
推進役が不在
共通ドキュメントを効果的にアピールする場を作れない
ドキュメントが陳腐化し、メンテナンスに追われる
(6)
■企業・情報システム部門が抱える課題
慢性的なヒト不足
工数・スキルに対する不安
「技術課題」以上に「ヒト課題」を解決することが企業への浸透に大事
展開に向けたステップ
小さなハードルをまずはこえる
(7)
まとめ
最初の一歩を踏み出そう
一発もので終わらない
サービスや製品をうまく活用しよう
■所感
タイトルが大げさすぎたような印象。
「失敗パターン」とはPostgresの導入ができなかったケースを指し
Postgresを入れてシステムを構築してからの失敗事例ではなかった。
また、
ヨーロッパ最大のオンラインショッピングサイトでも
データ規模は5TBで、データの増加も1日12GB程度とのこと。
1日数TBくらい増加するのかなと個人的には思っていたので
少し拍子抜けしました。
これらの数値は今後のシステム開発の指標として参考になるかもしれません。
================================================================
【K1】
3、あなたの知らない PostgreSQL 監視の世界
TIS 株式会社
中西 剛紀
3-1 講演内容
スライドがかなりしっかりしてるので
詳細はそれを確認してください。
# 公開されるかは不明
スライドが手に入らない場合は
pg_monz
を調べると良いと思います。
(1)
PostgreSQLの監視をどうするかという話
(2)
まずは「正しく動いてんの？」を監視する
(3)
PostgreSQLの監視に使える情報
・PostgreSQLの標準機能
-コマンド：pg_isready など
-関数：pg_is_in_recoverry()など
-稼働統計情報：pg_stat～～～
-ログ
(4)
PostgreSQLの監視に使えるツール
・pg_stat_statements
・pg_statsinfo（Oracleのstatspackのようなもの）
・pg_monz
(5)
ツールをうまく組み合わせましょう
・pg_monzは「監視」ツール
・pg_statsinfoは「性能分析」ツール
・PostgreSQLのサーバログ
■所感
このセッションではpg_monzが便利ということが伝わりました。
Zabbixと連動して監視が視覚的にできるようです。
pg_monzのページ
http://pg-monz.github.io/pg_monz/
================================================================
【M2】
4、PostgreSQL セキュリティ総復習
アップタイム・テクノロジーズ
永安 悟史
スライドはこちら
http://www.slideshare.net/uptimejp/postgresql-54761353
4-1、講演内容
スライドが公開されているのでメモを記載します。
(1)
PostgreSQLカンファレンスはSIerが多い
(2)
狙われてるのはデータベース
→ セキュリティが重要
(3)
クラウドになってDBサーバがいろんなところにある場合
平文でパスワード認証はネットの海に流れるので注意！
(4)
PostgreSQLはOracleほど細かくセキュリティ設定できない
Oracleは1台のインスタンスをみんなで使う設計？
PostgreSQLは1台のサーバを使うことは想定していない？
(5)
権限の棚卸、クリーニングはセキュリティの基本
(6)
いかにして「想定していないSQLの実行」を防ぐか
→ 実行できるSQLを制限してしまえばいい
→ sql_firewallを作った
学習していないSQLの実行を防止することができる
(7)
バックアップファイルは暗号化されないし
置きっぱなしになることが多々あるため気をつけましょう！
■所感
SQLの実行そのものを制御してしまおうという発想はなかった。
しかし、たしかにそれによってセキュリティは向上しそうです。
また、クラウド上にDBサーバを設置している場合は
ネットの海にさらされてるということを忘れてはいけません。
sql_firewall
使ってみたいと思いました。
================================================================
【M3】
5、監査要件を有するシステムに対する PostgreSQL 導入の課題と可能性
日本電信電話株式会社
NTT オープンソースソフトウェアセンタ
DBMS 担当
大山 真実
5-1、講演内容
(1)
DBの監査は重要
(2)
DBAの1割が
DBに格納されている情報を売却するかもしれない、改ざんするかもしれない、破壊するかもしれない。
つい、むしゃくしゃしてしまうｗ
(3)
PostgreSQLには監査ログの出力機能がない？
→ log_statement = all がある
(4)
しかし
・監査するのが大変なログ問題
・性能低下問題
・運用ログと監査ログが混ざっちゃう問題
・スーパーユーザなんでもできちゃう問題
があげられる。
(5)
そこで
PostgreSQLの監査ログ出力ツール
pgaudit
の出番
(6)
pgauditはPostgreSQL9.5対応
※ 複数のpgauditやpg_auditが存在しているので注意
(7)
pgauditの特徴
・サーバログより粒度の細かいログ出力が可能
・サーバログで取得できない情報を取得可能
・ログはサーバログに出力される
・設定値はすべてGUC
■QA.
(1)
pgauditいろいろある問題 それぞれの違いは？IFは同じ？
→ 2ndはセッションログ
使うにはどれが適するか確認してから使うこと
(2)
pgまじゃー？を使ってる ログを解析するツール
それと合わせて使いたい
ログラインプレフィックスはPostgreSQLのログと同じ？
→ 同じ
(3)
PostgreSQL本体がだすログと、auditのログをわけるには？
→ AUDITプレフィックスがつくのでそれで区分けしてください
(4)
auditは性能ダウンがどれくらい抑えられる？ むしろCPU負荷があがるのでは？
→ 要件による フィルタのオーバヘッドは測定してないI/Oが1番ネックなので多少マシにはなるはず
(5)
監査ログをだすとたくさんログがでる。ローテーションはできるの？実際に監査が必要な企業で使われてる事例
→ ローテートはサーバログのローテーション サーバを起動したままできる
使ってる企業はあるかに対しては、むしろお客さんの要望があって作った。日本は言えない
■所感
ログ機能の強化としてpgauditを使うことは
十分に選択肢になりうると感じました。
いろいろと細かい設定で、多数の出力項目を有しているので
本当に詳細なログを出力・取得することができそうです。
スライドがかなり作りこまれていて
細かい情報が記載されているので
もし公開されるなら確認しても良いと思います。
================================================================
【K4】
6、PostgreSQLアンチパターン
JPUG 中国支部支部長
曽根 壮大
スライドはこちら
https://www.slideshare.net/secret/3GPc5Zqug0gIJk
6-1、講演内容
詳細はスライド参照
(1)
・削除フラグは悪
・配列型、JSON型を使うより、まずは正規化
・マテビューはリフレッシュの影響が大きい安易に作りすぎないこと
(2)
ちゃんと正規化・設計をしましょう
■所感
削除フラグのカラムの作成、配列やJSON型、マテビュー
どれも使う前には設計が怪しいと疑うこと。
正規化をめんどくさがらないで、ちゃんとやることの大切さを再認識しました。
================================================================
■全体的な所感
今年のPostgreSQLカンファレンスはセキュリティの話が多かった印象です。
これはPostgreSQLのRDBとしての機能も大事ですが
運用において注意するべき点が注目されてきたということであり
PostgreSQLがある程度成熟した技術になってきたのかと感じました。
以上
2015年10月25日日曜日
オープンソースカンファレンス2015 Tokyo/Fall に参加しました（2日目）
ごきげんよう。
オープンソースカンファレンス2015 Tokyo/Fall に参加しました（2日目）
掲題の通り
2015年10月24日、25日に開催の
オープンソースカンファレンス2015 Tokyo/Fall に参加しました。
25日（2日目）の参加報告を簡単に記載します。
OSC2015 Tokyo/Fall公式ハッシュタグ：#osc15tk
＜＜2日目＞＞
オープンソースカンファレンス2015 Tokyo/Fall に参加しました（2日目）
掲題の通り
2015年10月24日、25日に開催の
オープンソースカンファレンス2015 Tokyo/Fall に参加しました。
25日（2日目）の参加報告を簡単に記載します。
OSC2015 Tokyo/Fall公式ハッシュタグ：#osc15tk
＜＜2日目＞＞
■高機能アクセス解析ソフト Piwik の紹介・活用法
Piwikってまったく聞いたことなかったので、試しに聞いてみました。
「ぴーうぃっく」
と読むそうです。
OSSなWeb＋モバイルアクセス解析プラットフォーム
らしいです。
コミュニティが毎月活発らしい
リファナースパム？に対策をGithubで公開中
結局よくわからなかったので
とりあえず公式サイトを貼っておきます。
■PostgreSQL 9.5の新機能紹介
10月6日のSRA OSS社のイベントとほぼ同じスライドでした。
いろいろ新機能はありますが
スライドを見た方が早そうなのでリンクを貼っておきます。
■分散処理基盤Apache Hadoop入門とHadoopエコシステムの最新技術動向
Hadoopとはなんぞや？
からの説明と下記2点の紹介
Apache Hive：
HiveQLというSQLライクな言語でMapReduceを実行
Apache Pig：
Pig Latinという独自の言語でMapReduceを実行
また新たな並列分散処理エンジンの出現として下記の紹介
Apache Spark：
大規模データの分散処理をオンメモリで実現
スライドがすごくよかったんで、メモをあんまりとってなかったです。。
公開されたら嬉しいです。
■pgpool-II 入門！ ～PostgreSQL 用クラスタツールの使い方を基礎から学ぼう～
資料が公開されるようです。
なので簡単に記載します。
pgpool-IIとはPostgreSQLのクラスタツールです。
データベースクラスタリングの目的は3つ。
１．高可用性の確保
サービスを停止させたくない
1つのデータベースが故障しても別のデータベースが肩代わり
２．参照負荷分散
大量のアクセスをさばきたい
３．並列処理
大量のデータを解析したい
で、PostgreSQLのストリーミングレプリケーションには課題がある。
ストリーミングレプリケーションの課題
負荷分散 更新クエリ・参照クエリの振り分け
DBサーバに障害が発生したら手動で対応するのか
プライマリがダウンしたら更新ができなくなる？サービスが停止してしまう？
pgpool-IIとは
アプリケーションとPostgreSQLの間に入ってクラスタリング機能を提供するミドルウェア
アプリケーションからみると普通のPostgreSQLに見える
BSDライセンス
・参照負荷分散
クエリの自動振り分け
更新クエリはプライマリサーバへ
参照クエリはサーバ間で振り分け
・自動フェイルオーバー
プライマリサーバに障害が派生した場合
負荷分散からの切り離し
スタンバイをプライマリに自動昇格
・オンラインリカバリ
ダウンしたスタンバイをプライマリに同期させる
同期中も更新が可能
・インメモリクエリキャッシュ
SELECTクエリの結果をメモリ内にキャッシュする機能
同じクエリが着た時に再利用する
DBへのアクセスが減り、性能向上
などなどの便利な機能が使えます。
ちなみに
pgpoolAdminというGUIツールもあるそうです。
▲各展示ブースをまわる
空き時間に各展示ブースを巡ってました。
前日と大きな変更はなかったです。
ただ、
「IBM Cognos」
というBIツールを某ブースで教えていただきました。
BIツールはたくさんありますが、この子はなかなか簡単操作でできるっぽいので
別途調べてみようと思います。
★2日目の所感
初日とは違って、初めて聞くOSSやツールについていくつか知ることができました。
どれも便利そうなので、別途調べて使ってみたいと思います。
★★全体の所感
セッションでも各展示ブースでも、あちこちで
「fluentd」
を使ってることが多くて、これが一番ホットなんじゃないかと思いました。
ログの収集ツールとしてデファクトスタンダードにまでなっている？
実際に触ったことがないので、fluentdは要チェックしようと思います。
で、2日間参加させていただきましたが
とても楽しく充実してました。
明星大学は都心からやや遠いですが
それでも参加する意味は大いにあると感じました。
以上
オープンソースカンファレンス2015 Tokyo/Fall に参加しました（1日目）
ごきげんよう。
掲題の通り
2015年10月24日、25日に開催の
オープンソースカンファレンス2015 Tokyo/Fall に参加しました。
24日（1日目）の参加報告を簡単に記載します。
OSC2015 Tokyo/Fall公式ハッシュタグ：#osc15tk
＜＜1日目＞＞
アシストさんはプレゼン資料を印刷して配布してくれるので
とても助かります。
・PostgreSQLの問い合わせの傾向
・ロック/ハングによる迷宮入りを防ぐために
・サポート事例
・まとめ
の構成でした。
年間1500件以上のPostgreSQL製品の問い合わせの傾向を教えてくれました。
PostgreSQLの問い合わせにおいてトラブルの問い合わせは全体の2割程度のようです。
再現待ちの避け方や調査の手がかりについて展開されておりました。
また、pg_stat_activity、pg_locksなどから原因を切り分ける具体的な方法を展開していてとても役立ちそうです。
EXPLAIN ANALYZEを使った実行計画の確認方法も具体的な例が資料に記載されており、保存版になりそうです。
お昼を食べながらLTを聞いてました。
宮原さんの日本最東西南北端の話がとても面白い。
「東に行き過ぎると銃撃される」
Hinemosが5.0になったのはメール等で認識していたのですが
詳しく調べてなかったので、このセッションに参加しました。
Zabbixと比較して、Zabbixは設定をゴリゴリ書けるけど属人化しやすい。
なのでGUIでパラメータを埋めるだけで、閾値を設定して監視することができるようになった。
また、ジョブ管理に力を入れたとのこと。
さらに目指しているのChefとかの環境構成らしいです。
設定が楽ちんっぽいですし、日本のOSSなので日本語ドキュメントもあります。
使ってみたくなりました。
このセッションすごかったです。
トラブルシュートと同じくアシストさん。
・Oracle to Postgresの移行ステップと活用ツール
・Oracle to Postgres移行手法と検証結果
・Postgres Enterprise Managerによる運用デモ
マイグレーションするなら移行ステップがあります。
そんな時に「Oracle Migration Assesment(OMA)」というツールが使えます。
これ、移行対象のOracleスキーマに対して、移行難易度を診断する有償のサービスですが、
使用している機能やオブジェクト、データ量などを分析して、
移行難易度をスコア化してくれるそうです。
使ってみたい。。
移行の段階になったら、そこで使う移行ツールと管理ツールが必要になります。
移行ツール：SI Object Browser ER
→ Oracle、MySQL、Sybase、SQL Serverからのデータ移行が可能なGUIツールです。
デモで簡単にポチポチしてたら、あっという間にテーブルの型とかを変換とかして移行しちゃいました。
すっごい便利そうです！欲しいです！！
管理ツール：SI Object Browser for Postgres
→ GUIでデータ操作、SQL発行、パフォーマンス向上などの行うことができる開発支援ツールです。
こちらもデモでポチポチしてたらあっという間にデータ操作してしまいました。
なにこれ魔法？って感じです。
あとはCUIになりますが
Postgres Plus Migration Toolkit(MTK)ってのもありました。
他のRDBMSからPostgres Plus Enterprise Edition（PPEE)へのデータ移行ツールらしいです。
で、ちらっとおっしゃってたのですが
「おら つー PG」
というツール？が別途あるみたいです。
OSSかもしれません。
近いうちに探してみて、OSSなら使ってみようと思います。
他にも
EDB*Loader とか xDB Repplication とかデータ移行ツールがたくさんでてきました。
アシストさんの有償ツールが大半のような気がしましたが、後日別途詳しく調べたいと思います。
IOT絡みのセッションも聞いておこうかなと思って聴講したんですけど
なんかよくわかりませんでした。
身の回りの回数？をカウントするメカを2か月で作って、
あとは各種OSSでデータを収集してクラウドに投げてます。
って話だったんですけど、「へぇ・・・」って感じでした。
個人がIOTを実施するPersonal IOTという考え方を説いていらっしゃいました。
「個人」IOTを作りませんか？
だそうです。
リアルタイムデータ処理をなぜやるか？
「情報」は天文学的な量に膨れ上がりつつあるからだ。
2020年には30ゼッタバイトを超える。だそうです。 ゼッタバイト・・初耳な単位です。
で、
これまでのバッチ処理ではデータを保存した後に個別の処理を行うスタイルが一般的でした。
でもバッチはデータの加工等がたいへん。
なので今流れているデータを即時に処理し、次のアクションへつなぐ！
そこで
リアルタイムデータ処理の基盤としてGUSTという製品を開発したらしいです。
ところが
「Amazon KinesisやApache Stormと何が違うの？」
って言われるので比較したそうです。
・Amazon Kinesisとは
大量なデータのアルタイム処理をサポートするAWSのフルマネージメントサービス
データをバッファ処理するかしょを担っている
Kinesisにはデータを処理する機能がない
・Apache Stormとは
リアルタイム分散処理の「フレームワーク」です
バッファリングされたデータ取得から集計処理までの処理全体をプログラミング
入力処理から解析、出力処理まで自由にプログラミングできるが、全部つくらないといけない
・GUSTはどういうものか
今流れているデータを適切に迅速に活用するためのリアルタイムデータ処理「アプリケーション」
多様なルールエンジンを標準搭載したAP
プログラミングレスで導入可能
カスタマイズによる処理ルールIFの拡張可能
オンプレミス・クラウドどちらでも設置可能
処理ユニットのスケールアウト可能
中継キューとしてKVS
GUSTはアプリなんで、手軽に使えるよって話らしく、プログラミングもしないでいいですとのこと。
わかるようなわからないような感じでしたが、とりあえず便利そうでした。
目玉セッション。
日本MySQLユーザ会のyoku0825さんの講演でした。
5.7.9がGAしたので、遊んでみました。
まず
パスワードがないと入れない
エラーログにある
var/log/mysqld.log を grep password してあげるそうです。
っていろいろやってたので
これはスライドを各自で確認してください。
yoku0825さんが先ほどスライドを公開していたので、探せばでてくるはずです。
▲各ブースにお邪魔しました
11時から1時間と、セッションの合間に各展示ブースを巡ってました。
今回もたくさんグッズがもらえました。
個人名は控えさせていただきますが
JPUG、MyNA、アップタイムテクノロジー社などなど
普段お世話になっている方々にご挨拶できました。
名刺を提示したら
「あ、そのアイコンの人ですか！」
「PostgreSQLの人ですよね」
などなど、ありがたいお言葉をたくさん頂けました。
★初日を振り返って
多くの方々にご挨拶できて良かったです。
アシスト社さんのPostgreSQLの2つの講演が非常に有意義でした。
資料をありがたく活用させてもらおうと思います。
また、yoku0825さんのMySQLの話、とても面白かったですｗ
MySQLも今後は今より接していこうと再認識できました。
あと「IoT」って言葉は変にバズってて
「温度センサーを設置して温度測定しました」
って話ばかりなのは気のせいでしょうか。
他のイベントでもそんな話だったんですけど。。。
以上
掲題の通り
2015年10月24日、25日に開催の
オープンソースカンファレンス2015 Tokyo/Fall に参加しました。
24日（1日目）の参加報告を簡単に記載します。
OSC2015 Tokyo/Fall公式ハッシュタグ：#osc15tk
＜＜1日目＞＞
■PostgreSQLトラブルシュート
アシストさんはプレゼン資料を印刷して配布してくれるので
とても助かります。
・PostgreSQLの問い合わせの傾向
・ロック/ハングによる迷宮入りを防ぐために
・サポート事例
・まとめ
の構成でした。
年間1500件以上のPostgreSQL製品の問い合わせの傾向を教えてくれました。
PostgreSQLの問い合わせにおいてトラブルの問い合わせは全体の2割程度のようです。
再現待ちの避け方や調査の手がかりについて展開されておりました。
また、pg_stat_activity、pg_locksなどから原因を切り分ける具体的な方法を展開していてとても役立ちそうです。
EXPLAIN ANALYZEを使った実行計画の確認方法も具体的な例が資料に記載されており、保存版になりそうです。
■[飲食OK]（発表者募集中！）1日目-ライトニングトーク（by OSCスポンサー）
お昼を食べながらLTを聞いてました。
宮原さんの日本最東西南北端の話がとても面白い。
「東に行き過ぎると銃撃される」
■監視もジョブもDevもOpsも「Hinemos」で ～監視・ジョブ機能を併せ持つ唯一のOSS 最新「Hinemos ver.5.0」のご紹介～
Hinemosが5.0になったのはメール等で認識していたのですが
詳しく調べてなかったので、このセッションに参加しました。
Zabbixと比較して、Zabbixは設定をゴリゴリ書けるけど属人化しやすい。
なのでGUIでパラメータを埋めるだけで、閾値を設定して監視することができるようになった。
また、ジョブ管理に力を入れたとのこと。
さらに目指しているのChefとかの環境構成らしいです。
設定が楽ちんっぽいですし、日本のOSSなので日本語ドキュメントもあります。
使ってみたくなりました。
■Postgresへのスマートなデータ移行とアプリケーション開発
このセッションすごかったです。
トラブルシュートと同じくアシストさん。
・Oracle to Postgresの移行ステップと活用ツール
・Oracle to Postgres移行手法と検証結果
・Postgres Enterprise Managerによる運用デモ
マイグレーションするなら移行ステップがあります。
そんな時に「Oracle Migration Assesment(OMA)」というツールが使えます。
これ、移行対象のOracleスキーマに対して、移行難易度を診断する有償のサービスですが、
使用している機能やオブジェクト、データ量などを分析して、
移行難易度をスコア化してくれるそうです。
使ってみたい。。
移行の段階になったら、そこで使う移行ツールと管理ツールが必要になります。
移行ツール：SI Object Browser ER
→ Oracle、MySQL、Sybase、SQL Serverからのデータ移行が可能なGUIツールです。
デモで簡単にポチポチしてたら、あっという間にテーブルの型とかを変換とかして移行しちゃいました。
すっごい便利そうです！欲しいです！！
管理ツール：SI Object Browser for Postgres
→ GUIでデータ操作、SQL発行、パフォーマンス向上などの行うことができる開発支援ツールです。
こちらもデモでポチポチしてたらあっという間にデータ操作してしまいました。
なにこれ魔法？って感じです。
あとはCUIになりますが
Postgres Plus Migration Toolkit(MTK)ってのもありました。
他のRDBMSからPostgres Plus Enterprise Edition（PPEE)へのデータ移行ツールらしいです。
で、ちらっとおっしゃってたのですが
「おら つー PG」
というツール？が別途あるみたいです。
OSSかもしれません。
近いうちに探してみて、OSSなら使ってみようと思います。
他にも
EDB*Loader とか xDB Repplication とかデータ移行ツールがたくさんでてきました。
アシストさんの有償ツールが大半のような気がしましたが、後日別途詳しく調べたいと思います。
■オープンソースをベースとしたIOTの活用方法について
IOT絡みのセッションも聞いておこうかなと思って聴講したんですけど
なんかよくわかりませんでした。
身の回りの回数？をカウントするメカを2か月で作って、
あとは各種OSSでデータを収集してクラウドに投げてます。
って話だったんですけど、「へぇ・・・」って感じでした。
個人がIOTを実施するPersonal IOTという考え方を説いていらっしゃいました。
「個人」IOTを作りませんか？
だそうです。
■ビッグデータをリアルタイムに処理するための、 Amazon Kinesis、Apache Storm、かもめ GUSTを比較してみました！
リアルタイムデータ処理をなぜやるか？
「情報」は天文学的な量に膨れ上がりつつあるからだ。
2020年には30ゼッタバイトを超える。だそうです。 ゼッタバイト・・初耳な単位です。
で、
これまでのバッチ処理ではデータを保存した後に個別の処理を行うスタイルが一般的でした。
でもバッチはデータの加工等がたいへん。
なので今流れているデータを即時に処理し、次のアクションへつなぐ！
そこで
リアルタイムデータ処理の基盤としてGUSTという製品を開発したらしいです。
ところが
「Amazon KinesisやApache Stormと何が違うの？」
って言われるので比較したそうです。
・Amazon Kinesisとは
大量なデータのアルタイム処理をサポートするAWSのフルマネージメントサービス
データをバッファ処理するかしょを担っている
Kinesisにはデータを処理する機能がない
・Apache Stormとは
リアルタイム分散処理の「フレームワーク」です
バッファリングされたデータ取得から集計処理までの処理全体をプログラミング
入力処理から解析、出力処理まで自由にプログラミングできるが、全部つくらないといけない
・GUSTはどういうものか
今流れているデータを適切に迅速に活用するためのリアルタイムデータ処理「アプリケーション」
多様なルールエンジンを標準搭載したAP
プログラミングレスで導入可能
カスタマイズによる処理ルールIFの拡張可能
オンプレミス・クラウドどちらでも設置可能
処理ユニットのスケールアウト可能
中継キューとしてKVS
GUSTはアプリなんで、手軽に使えるよって話らしく、プログラミングもしないでいいですとのこと。
わかるようなわからないような感じでしたが、とりあえず便利そうでした。
■MySQL 5.7で遊んでみよう
目玉セッション。
日本MySQLユーザ会のyoku0825さんの講演でした。
5.7.9がGAしたので、遊んでみました。
まず
パスワードがないと入れない
エラーログにある
var/log/mysqld.log を grep password してあげるそうです。
っていろいろやってたので
これはスライドを各自で確認してください。
yoku0825さんが先ほどスライドを公開していたので、探せばでてくるはずです。
▲各ブースにお邪魔しました
11時から1時間と、セッションの合間に各展示ブースを巡ってました。
今回もたくさんグッズがもらえました。
個人名は控えさせていただきますが
JPUG、MyNA、アップタイムテクノロジー社などなど
普段お世話になっている方々にご挨拶できました。
名刺を提示したら
「あ、そのアイコンの人ですか！」
「PostgreSQLの人ですよね」
などなど、ありがたいお言葉をたくさん頂けました。
★初日を振り返って
多くの方々にご挨拶できて良かったです。
アシスト社さんのPostgreSQLの2つの講演が非常に有意義でした。
資料をありがたく活用させてもらおうと思います。
また、yoku0825さんのMySQLの話、とても面白かったですｗ
MySQLも今後は今より接していこうと再認識できました。
あと「IoT」って言葉は変にバズってて
「温度センサーを設置して温度測定しました」
って話ばかりなのは気のせいでしょうか。
他のイベントでもそんな話だったんですけど。。。
以上
2015年10月20日火曜日
PostgreSQLのslackのご紹介
ごきげんよう。
少し時間が経ってしまいましたが
私の尊敬するエンジニア そーだいさん が
PostgreSQLのSlack（大雑把に言うとチャット部屋）を開設してくれました。
詳しくはこの記事（そーだいなるらくがき帳）
http://soudai1025.blogspot.jp/2015/09/stackpostgresql.html
「Slackってなに？」って方はこちらを参考にすると良いかもしれません。
http://matome.naver.jp/odai/2140816727781771801
コミュニティ活動とかやったことない・不安って人も
Slackの方々はみなさん親切なので、歓迎してくれると思います。
PostgreSQLの初心者の方のための #bebinners という部屋や
もはやメシテロ用の雑談部屋 #random という部屋
もありますので
まずはそちらから体験してみてはいかがでしょうか。
少し時間が経ってしまいましたが
私の尊敬するエンジニア そーだいさん が
PostgreSQLのSlack（大雑把に言うとチャット部屋）を開設してくれました。
詳しくはこの記事（そーだいなるらくがき帳）
http://soudai1025.blogspot.jp/2015/09/stackpostgresql.html
「Slackってなに？」って方はこちらを参考にすると良いかもしれません。
http://matome.naver.jp/odai/2140816727781771801
コミュニティ活動とかやったことない・不安って人も
Slackの方々はみなさん親切なので、歓迎してくれると思います。
PostgreSQLの初心者の方のための #bebinners という部屋や
もありますので
まずはそちらから体験してみてはいかがでしょうか。
情報処理技術者試験 システムアーキテクトを受けた
ごきげんよう。
おひさしぶりです。
10月18日の情報処理技術者試験システムアーキテクトを受験したので
それについて書き留めます。
ただし、たぶん午後Ⅰで落ちてるので、鵜呑みにしてはいけません。
現時点での試験結果を記載すると
午前Ⅰ、午前Ⅱともにそれなりに得点を稼いで合格してました。
で、何をしたかというと
8月のお盆を過ぎた頃から対策開始
本屋さんでシステムアーキテクトの対策本をみたけど意味不
午前問題も応用情報を受けた数年前ぶりなので、やっぱり意味不
というわけで、まじめにやらないと何もできんとなり、勉強しました。
使った教材はこれ。
おひさしぶりです。
10月18日の情報処理技術者試験システムアーキテクトを受験したので
それについて書き留めます。
ただし、たぶん午後Ⅰで落ちてるので、鵜呑みにしてはいけません。
現時点での試験結果を記載すると
午前Ⅰ、午前Ⅱともにそれなりに得点を稼いで合格してました。
で、何をしたかというと
8月のお盆を過ぎた頃から対策開始
本屋さんでシステムアーキテクトの対策本をみたけど意味不
午前問題も応用情報を受けた数年前ぶりなので、やっぱり意味不
というわけで、まじめにやらないと何もできんとなり、勉強しました。
使った教材はこれ。
- うかる！秋期硬度試験 午前Ⅰ・Ⅱ 2015年度版 Android版（翔泳社）
- システムアーキテクト 2015 専門知識＋午後問題の重点対策（iTEC社）
- システムアーキテクト 合格論文の書き方・事例集 第4版（iTEC社）
あと、このサイトが良かったです。
過去問WEB問題集 情報処理技術者試験 合格への道
で、午前は電車内でAndroidアプリをポチポチやって、上記サイトでもポチポチしてました。
他の教材はまったく使ってないですが、結果午前Ⅰ、午前Ⅱはクリアできました。
午後Ⅰはタイムマネジメントに失敗して自爆したんですけど、参考書はとてもよかったです。
来年また受ける際には同じ参考書を買おうかと思ってます。
午後Ⅱも参考書がいい感じでしたが、何度か写経しました。実際に書いてみてなんぼだと思います。
で、試験会場は比較的新しい建物らしく、机も椅子もがたがたしないで集中して受験できました。
受験者が座席の1/3くらいしかいなかったので、皆さんが問題冊子をパラパラめくる音も気にしないで受験できました。
というわけで、情処が終わったので
しばらくはまたデータベース絡みのことができそうです。
2015年6月9日火曜日
CentOS7のpostgresユーザのホームディレクトリ（PostgreSQL9.4.1）
2015年6月9日 その2
ごきげんよう。
先ほどの記事で
Postgres Toolkitについて記載しましたが
いちいちパスを通すのでめんどかったので
永続化することにしました。
というわけで
postgresユーザのホームディレクトリに行こうとしたら
/home/postgres
なんて存在しなかった。
で、最初にログインしたディレクトリが
ホームディレクトリなんじゃない？
と思ったらその通りでした。
CentOS7 PsotgreSQL9.4.1の場合、
ホームディレクトリは
/var/lib/pgsql/配下になる模様。
なので、ここにいる
.bash_profile君に
# postgres-tooklit
export PATH=$PATH:/opt/uptime/postgres-toolkit-0.2.1/bin
と末尾に追記してあげて
source .bash_profile
とコマンドを打ってあげましたら
無事にPATHに追加されました。
ごきげんよう。
先ほどの記事で
Postgres Toolkitについて記載しましたが
いちいちパスを通すのでめんどかったので
永続化することにしました。
というわけで
postgresユーザのホームディレクトリに行こうとしたら
/home/postgres
なんて存在しなかった。
で、最初にログインしたディレクトリが
ホームディレクトリなんじゃない？
と思ったらその通りでした。
CentOS7 PsotgreSQL9.4.1の場合、
ホームディレクトリは
/var/lib/pgsql/配下になる模様。
なので、ここにいる
.bash_profile君に
# postgres-tooklit
export PATH=$PATH:/opt/uptime/postgres-toolkit-0.2.1/bin
と末尾に追記してあげて
source .bash_profile
とコマンドを打ってあげましたら
無事にPATHに追加されました。
PostgreSQL（Postgres Toolkit） pg_hba.confファイルの設定 ユーザ”postgres”のIdent認証に失敗しました
2015年6月9日
ごきげんよう。
タイトルが長い・・
今回はPostgreSQLで
ユーザ”postgres”のIdent認証に失敗しました
なんてエラーがでちゃいましたので
それについて記載します。
結論から記載すると
pg_hba.confファイル
でひっかかりました。
# 暫定対処なのでそこはご注意ください
さて突然ですが
ごきげんよう。
タイトルが長い・・
今回はPostgreSQLで
ユーザ”postgres”のIdent認証に失敗しました
なんてエラーがでちゃいましたので
それについて記載します。
結論から記載すると
pg_hba.confファイル
でひっかかりました。
# 暫定対処なのでそこはご注意ください
さて突然ですが
Postgres Toolkit
をご存知でしょうか。
先日（2015/05/30）のPostgreSQLアンカンファレンスで
永安さんが発表なさっていたツールです。
スライドによると以下のように記載されています。
Postgres Toolkitとは
- PostgreSQLのサーバを運用・管理するためのスクリプト・ツールのコレクション
- 複数のSQLやコマンドを組み合わせて実施する作業を、ひとつのスクリプトで実行できるようにしたもの
- PostgreSQL DBAの業務の品質向上や負荷低減を目的として、頻繁に実施する作業にフォーカスして機能提供
- オープンソースライセンスで提供（GPL v2）
私の解釈では
PostgreSQLで業務を行うとき、
頻繁に使うSQLやコマンドをツール化して
メンテナンス性を向上した素敵ツール
なのです。
で、この子で遊んでみた際に私が勝手にひっかかったので
備忘録を書いておきます。
【仕様環境】
OS：CentOS7
DB：PostgreSQL9.4.1
ひとまずチューニングなし
【でてきたエラー】
ユーザ”postgres”のIdent認証に失敗しました
【経緯】
Postgres Toolkitの
pt-index-usageコマンド
をpostgresユーザで実行した際に、上記エラーが発生
まず、CentOS7で
postgresユーザになり、
Postgres ToolkitのPATHを通してあげます。
[root@localhost ~]# su - postgres
最終ログイン: 2015/06/08 (月) 16:44:50 JST日時 pts/1
-bash-4.2$
-bash-4.2$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin
-bash-4.2$
-bash-4.2$ export PATH=$PATH:/opt/uptime/postgres-toolkit-0.2.1/bin
-bash-4.2$
-bash-4.2$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/opt/uptime/postgres-toolkit-0.2.1/bin
で、
pt-index-usageを
マニュアル通り実行してあげます。
-bash-4.2$ pt-index-usage -n public -d postgres
[2015-06-09 11:03:01] ERROR: Failed to execute psql. (psql -A -h localhost -p 5432 -U postgres -d postgres)
[2015-06-09 11:03:01] ERROR: psql: FATAL: ユーザ"postgres"のIdent認証に失敗しました
-bash-4.2$
どういうことだオイ！
postgresユーザがはじかれたぞ！！
# 私のせいなんですけど
で、この場合の対処法です。
PostgreSQLはpg_hba.confというファイルで認証を管理してます。
なので、この子を編集してあげます。
-bash-4.2$ vi /var/lib/pgsql/9.4/data/pg_hba.conf
ここの
# IPv6 local connections:
host all all ::1/128 ident
これはIPｖ6のループバックアドレスですが ident になってます。
この ident を 例えば trust にすれば無条件で認証してくれます。
md5 にすれば二重MD5ハッシュ化パスワードで認証できます。
# 他にも、アドレスの欄をlocalhostにすると幸せになれるかもしれません。
ちなみに、私の場合IPｖ4はtrustにしてました。
なので・・気づくのが遅かった・・・
# IPv4 local connections:
host all all 127.0.0.1/32 trust
で、
# IPv6 local connections:
host all all ::1/128 md5
に試しに変更してあげました。
pg_hba.confファイルは変更したらPostgreSQLを再起動してあげます。
[root@localhost ~]# service postgresql-9.4 restart
Redirecting to /bin/systemctl restart postgresql-9.4.service
さて、
これでもう一度
Postgres Toolkitの
pt-index-usageコマンドを試してあげます。
# コマンドのオプションを変更してtestdbデータベースを確認するようにしてます
-bash-4.2$ pt-index-usage -n public -d testdb
+-------+----------+--------+------------+-----------------+------+------+--------+--------+--------+-------+--------+------------+
| OID | OWNER | SCHEMA | TABLE | INDEX | BLKS | SCAN | T_READ | T_FTCH | B_READ | B_HIT | STATUS | TABLESPACE |
+-------+----------+--------+------------+-----------------+------+------+--------+--------+--------+-------+--------+------------+
| 16391 | postgres | public | index_test | index_test_pkey | 1 | 0 | 0 | 0 | 1 | 0 | | pg_default |
| 16393 | postgres | public | index_test | index_num | 1 | 0 | 0 | 0 | 0 | 0 | | pg_default |
| 16394 | postgres | public | index_test | index_moji | 1 | 0 | 0 | 0 | 0 | 0 | | pg_default |
+-------+----------+--------+------------+-----------------+------+------+--------+--------+--------+-------+--------+------------+
ひとまず無事に動作したようです。
今回の場合、暫定対処となるので、そこはご注意ください。
各自のセキュリティポリシーで対応してください。
通常postgresユーザは自動的に作られるので
identでハマることはないと思うのですが・・・なんでなんだぜ？？
2015年6月6日土曜日
PostgreSQL ロケールとLIKE述語そしてpgAdminでの注意
2015年6月6日
ごきげんよう。
前回の記事
PostgreSQL B-treeインデックスの動作検証
記事中に、LIKE述語の前方一致でインデックスが動かないという現象がありましたが、
ありがたいことに記事にコメントをいただきました。
ごきげんよう。
前回の記事
PostgreSQL B-treeインデックスの動作検証
記事中に、LIKE述語の前方一致でインデックスが動かないという現象がありましたが、
ありがたいことに記事にコメントをいただきました。
ごきげんよう。LIKEの前方一致ですが、
CREATE INDEX index_moji ON index_test(moji text_pattern_ops);
と、列名の後に text_pattern_ops を付けてインデックスを作り直してみて下さい。
こちらでやったら、ロケールが「C」のDBなら初めからIndex Scanで、
ロケールがJapanese_Japan.932のDBでは記事と同様で、…ops付けたらインデックスが使われました。
kenpg / koda さんありがとうございます！
というわけで
データベースのロケールを見てみました。
・・・・・
ご指摘の通り
Japanese_Japan.932
になってました・・・・
で、提示していただいたインデックスを作り直して再度検証してみました。
CREATE INDEX index_moji ON index_test(moji text_pattern_ops);
これで前方一致のクエリを再投入してみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE 'hoge12345%';
"Index Scan using index_moji on index_test (cost=0.42..8.45 rows=100 width=18) (actual time=0.292..0.440 rows=11 loops=1)"
" Index Cond: ((moji ~>=~ 'hoge12345'::text) AND (moji ~<~ 'hoge12346'::text))"
" Filter: (moji ~~ 'hoge12345%'::text)"
"Planning time: 4.006 ms"
"Execution time: 0.484 ms"
おおおお！
無事にIndex Scanが使われました！
さて、ここで疑問。
ロケールに
Japanese_Japan.932
なんて指定した覚えがないぞ？
まさか・・・デフォルトがこうなってる？
そこで、新しくデータベース（new_db）を
pgAdminのデフォルトのまま、ほいほい作ってみます。
データベースを作る際に「定義」のタブをみてみると
コーレーションと文字型が空白ですね。
ここでOKボタンを押下して、データベースを作ると・・・
なんと！
コーレーションと文字型がJapanese_Japan.932になってます！
ぐぬぬぬ・・・って感じです。
なので、新しくデータベースをロケールCで作ってみます。
定義タブで
コーレーションと文字型にCを選択します。
ちなみに
ここでOKを押してもエラーがでます。
これはTemplateにtemplate0を選んであげれば動いてくれます。
# Templateについては
# ひとまずデータベース作成の際の雛形みたいなものだと認識してください。
# 詳細は各自で検索をお願いします。
で、Templateにtemplate0を選んであげてOKボタンを押下してあげると
コーレーションと文字型がCの新規データベース（testdb_c）が出来上がります。
ここで前回記事と同じように
テーブルとインデックスを作ってあげます。
COPY文で再びデータをindex_testテーブルに入れてあげて
前方一致のLIKE述語のクエリを実行してみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE 'hoge12345%';
"Index Scan using index_moji on index_test (cost=0.42..8.45 rows=100 width=18) (actual time=0.074..0.195 rows=11 loops=1)"
" Index Cond: ((moji >= 'hoge12345'::text) AND (moji < 'hoge12346'::text))"
" Filter: (moji ~~ 'hoge12345%'::text)"
"Planning time: 15.047 ms"
"Execution time: 0.225 ms"
おおおお！！
無事にIndex Scanが選ばれました。
というわけで
PostgreSQL9.4.2をpgAdminⅢ（1.20.0）で使用する際に
ロケールも気を付けないといけません。
# 設定や初回起動等によるのでしょうが
ちなみに、今回ご指摘をいただいた
ロケールとtext_pattern_opsについては
Let's Postgresで記事になってました。
ご興味がある方はご参考までに。
では、今回はこれにて失礼します。
何か補足や「何言ってんだこいつ」ってのがありましたら
コメント欄にご記入をお願いいたします。
2015年6月5日金曜日
PostgreSQL B-treeインデックスの動作検証
2015年6月5日 その2
ごきげんよう。
今回はPostgreSQLのB-Treeインデックスについて検証してみました。
データベースについて勉強した方は
以下の本を読んだことがあるかもしれません。
達人に学ぶDB設計徹底指南書 初心者で終わりたくないあなたへ
著者：ミック
2012年初版発行
この本によると
以下の場合はインデックスが利用できないと記載されています。
# 他にもあるんですが、とりあえずこの3つをピックアップしました
LIKE述語の件は知ってたんですが、
演算とORについて知らなかったので合わせて検証してみました。
【環境】
OS：windows8.1
DB：PostgreSQL9.4.2
PostgreSQLのチューニング一切なし（デフォルトのまま）
【事前準備】
テーブル環境
CREATE TABLE index_test
(
id integer PRIMARY KEY,
num integer NOT NULL,
moji text NOT NULL
)
データは前回記事
Javaで重複なしのランダムな値をファイル出力する
http://show-surumegohan.blogspot.jp/2015/06/java.html
で作成した
100万件のCSVファイルです。
中身は以下のような感じです。
1,742983,hoge742983
2,903173,hoge903173
3,738660,hoge738660
：
：
999998,761436,hoge761436
999999,927983,hoge927983
1000000,128247,hoge128247
【検証1：インデックス列に演算を行っている】
num列の値を演算して検索してみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num * 2 > 8000000;
"Seq Scan on index_test (cost=0.00..21370.00 rows=333333 width=18) (actual time=110.917..110.917 rows=0 loops=1)"
" Filter: ((num * 2) > 8000000)"
" Rows Removed by Filter: 1000000"
"Planning time: 0.081 ms"
"Execution time: 110.938 ms"
Seq Scan（シーケンススキャン）が走ってしまっています。
# Seq Scanはテーブル内のデータをすべて参照する
で、この場合の対応策としては
WHERE句はあくまでnum列をそのまま呼び出して
同値の式変形をします。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num > 8000000 / 2;
"Index Scan using index_num on index_test (cost=0.42..8.44 rows=1 width=18) (actual time=0.004..0.004 rows=0 loops=1)"
" Index Cond: (num > 4000000)"
"Planning time: 0.120 ms"
"Execution time: 0.019 ms"
無事にindex_numインデックスが使用されました。
演算が必要な場合は列を呼び出すときはそのままの状態で呼び出してあげましょう。
【検証2：ORを用いている】
本によると
ということでやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num = 12345 OR num = 67890 OR num = 987654;
"Bitmap Heap Scan on index_test (cost=13.30..25.16 rows=3 width=18) (actual time=0.030..0.032 rows=3 loops=1)"
" Recheck Cond: ((num = 12345) OR (num = 67890) OR (num = 987654))"
" Heap Blocks: exact=3"
" -> BitmapOr (cost=13.30..13.30 rows=3 width=0) (actual time=0.024..0.024 rows=0 loops=1)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.012..0.012 rows=1 loops=1)"
" Index Cond: (num = 12345)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.007..0.007 rows=1 loops=1)"
" Index Cond: (num = 67890)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.004..0.004 rows=1 loops=1)"
" Index Cond: (num = 987654)"
"Planning time: 0.105 ms"
"Execution time: 0.064 ms"
PostgreSQL9.4.2だと、
Bitmap Heap Scan
が動きました。
で、OR句はBitmapOr が走ってるようで
さらにその中で
Bitmap Index Scan
がORの回数だけ走っているようです。
つまり
ORでもインデックスは作用する
ようです。
# 本が発行された2012年の段階だとダメだった？
ちなみにミックさんは
こういうときはINにすればよいと記載しています。
なのでやってみました。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num IN (12345,67890,987654);
"Index Scan using index_num on index_test (cost=0.43..25.33 rows=3 width=18) (actual time=0.008..0.018 rows=3 loops=1)"
" Index Cond: (num = ANY ('{12345,67890,987654}'::integer[]))"
"Planning time: 0.173 ms"
"Execution time: 0.052 ms"
ORに比べてINだとシンプルに
Index Scan
が走ってますね。
中をよく見てみると
Index Cond: (num = ANY ('{12345,67890,987654}'::integer[]))
となっていてANYでまとめられてるようです。
ただ、今回のケースだと実行速度はそんなに変わらないみたいです。
もっと複雑な条件が重なるとINの方がはやいんでしょうかね？
【検証3：後方一致、または中間一致のLIKE述語を用いている】
これは私も知ってたんですが
やってみたら意外な結果がでました。
まずは後方一致から。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE '%ge12345';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=7.713..135.400 rows=1 loops=1)"
" Filter: (moji ~~ '%ge12345'::text)"
" Rows Removed by Filter: 999999"
"Planning time: 0.079 ms"
"Execution time: 135.419 ms"
Seq Scanが選ばれてしまっています。
インデックスが作用してませんね。
次に中間一致をやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE '%ge12345%';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=1.423..134.443 rows=11 loops=1)"
" Filter: (moji ~~ '%ge12345%'::text)"
" Rows Removed by Filter: 999989"
"Planning time: 0.101 ms"
"Execution time: 134.470 ms"
この場合もSeq Scanが選ばれてしまっています。
さて、本にはこんなことが書いてあります。
LIKE述語を使うときは前方一致検索の場合のみ索引が使用されます。
私もその知識だったのですがひとまずやってみました。
前方一致をやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE 'hoge12345%';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=1.395..119.152 rows=11 loops=1)"
" Filter: (moji ~~ 'hoge12345%'::text)"
" Rows Removed by Filter: 999989"
"Planning time: 0.104 ms"
"Execution time: 119.177 ms"
あれ・・・
前方一致のクエリを投げたつもりなのですが
結果はSeq Scanが走っています。
なんでなんだぜ？？
前方一致で似たようなクエリを何パターンかやってみたんですが
Seq Scanが走りました。
これはなんでなんでしょう？？
誰か教えてください。。。
というわけで
検証の結果、本の内容と若干異なる結果がでちゃいました。
2012年の本なので、2015年現在ではRDBも進化してるということでしょうか？
LIKE述語の前方一致の件、、誰か教えてください・・・
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
追記：
ありがたいことにコメントをいただけました。
次の記事でいただいたコメントをもとに再検証しました。
PostgreSQL ロケールとLIKE述語そしてpgAdminでの注意
ごきげんよう。
今回はPostgreSQLのB-Treeインデックスについて検証してみました。
データベースについて勉強した方は
以下の本を読んだことがあるかもしれません。
達人に学ぶDB設計徹底指南書 初心者で終わりたくないあなたへ
著者：ミック
2012年初版発行
この本によると
以下の場合はインデックスが利用できないと記載されています。
- インデックス列に演算を行っている
- ORを用いている
- 後方一致、または中間一致のLIKE述語を用いている
# 他にもあるんですが、とりあえずこの3つをピックアップしました
LIKE述語の件は知ってたんですが、
演算とORについて知らなかったので合わせて検証してみました。
【環境】
OS：windows8.1
DB：PostgreSQL9.4.2
PostgreSQLのチューニング一切なし（デフォルトのまま）
【事前準備】
テーブル環境
CREATE TABLE index_test
(
id integer PRIMARY KEY,
num integer NOT NULL,
moji text NOT NULL
)
CREATE INDEX index_num ON index_test(num);
CREATE INDEX index_moji ON index_test(moji);
データは前回記事
Javaで重複なしのランダムな値をファイル出力する
http://show-surumegohan.blogspot.jp/2015/06/java.html
で作成した
100万件のCSVファイルです。
中身は以下のような感じです。
1,742983,hoge742983
2,903173,hoge903173
3,738660,hoge738660
：
：
999998,761436,hoge761436
999999,927983,hoge927983
1000000,128247,hoge128247
【検証1：インデックス列に演算を行っている】
num列の値を演算して検索してみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num * 2 > 8000000;
"Seq Scan on index_test (cost=0.00..21370.00 rows=333333 width=18) (actual time=110.917..110.917 rows=0 loops=1)"
" Filter: ((num * 2) > 8000000)"
" Rows Removed by Filter: 1000000"
"Planning time: 0.081 ms"
"Execution time: 110.938 ms"
Seq Scan（シーケンススキャン）が走ってしまっています。
# Seq Scanはテーブル内のデータをすべて参照する
で、この場合の対応策としては
WHERE句はあくまでnum列をそのまま呼び出して
同値の式変形をします。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num > 8000000 / 2;
"Index Scan using index_num on index_test (cost=0.42..8.44 rows=1 width=18) (actual time=0.004..0.004 rows=0 loops=1)"
" Index Cond: (num > 4000000)"
"Planning time: 0.120 ms"
"Execution time: 0.019 ms"
無事にindex_numインデックスが使用されました。
演算が必要な場合は列を呼び出すときはそのままの状態で呼び出してあげましょう。
【検証2：ORを用いている】
本によると
ORを用いた場合はインデックスが利用できません。と明記してあります。
ということでやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num = 12345 OR num = 67890 OR num = 987654;
"Bitmap Heap Scan on index_test (cost=13.30..25.16 rows=3 width=18) (actual time=0.030..0.032 rows=3 loops=1)"
" Recheck Cond: ((num = 12345) OR (num = 67890) OR (num = 987654))"
" Heap Blocks: exact=3"
" -> BitmapOr (cost=13.30..13.30 rows=3 width=0) (actual time=0.024..0.024 rows=0 loops=1)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.012..0.012 rows=1 loops=1)"
" Index Cond: (num = 12345)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.007..0.007 rows=1 loops=1)"
" Index Cond: (num = 67890)"
" -> Bitmap Index Scan on index_num (cost=0.00..4.43 rows=1 width=0) (actual time=0.004..0.004 rows=1 loops=1)"
" Index Cond: (num = 987654)"
"Planning time: 0.105 ms"
"Execution time: 0.064 ms"
PostgreSQL9.4.2だと、
Bitmap Heap Scan
が動きました。
で、OR句はBitmapOr が走ってるようで
さらにその中で
Bitmap Index Scan
がORの回数だけ走っているようです。
つまり
ORでもインデックスは作用する
ようです。
# 本が発行された2012年の段階だとダメだった？
ちなみにミックさんは
こういうときはINにすればよいと記載しています。
なのでやってみました。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE num IN (12345,67890,987654);
"Index Scan using index_num on index_test (cost=0.43..25.33 rows=3 width=18) (actual time=0.008..0.018 rows=3 loops=1)"
" Index Cond: (num = ANY ('{12345,67890,987654}'::integer[]))"
"Planning time: 0.173 ms"
"Execution time: 0.052 ms"
ORに比べてINだとシンプルに
Index Scan
が走ってますね。
中をよく見てみると
Index Cond: (num = ANY ('{12345,67890,987654}'::integer[]))
となっていてANYでまとめられてるようです。
ただ、今回のケースだと実行速度はそんなに変わらないみたいです。
もっと複雑な条件が重なるとINの方がはやいんでしょうかね？
【検証3：後方一致、または中間一致のLIKE述語を用いている】
これは私も知ってたんですが
やってみたら意外な結果がでました。
まずは後方一致から。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE '%ge12345';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=7.713..135.400 rows=1 loops=1)"
" Filter: (moji ~~ '%ge12345'::text)"
" Rows Removed by Filter: 999999"
"Planning time: 0.079 ms"
"Execution time: 135.419 ms"
Seq Scanが選ばれてしまっています。
インデックスが作用してませんね。
次に中間一致をやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE '%ge12345%';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=1.423..134.443 rows=11 loops=1)"
" Filter: (moji ~~ '%ge12345%'::text)"
" Rows Removed by Filter: 999989"
"Planning time: 0.101 ms"
"Execution time: 134.470 ms"
この場合もSeq Scanが選ばれてしまっています。
さて、本にはこんなことが書いてあります。
LIKE述語を使うときは前方一致検索の場合のみ索引が使用されます。
私もその知識だったのですがひとまずやってみました。
前方一致をやってみます。
EXPLAIN ANALYSE SELECT * FROM index_test WHERE moji LIKE 'hoge12345%';
"Seq Scan on index_test (cost=0.00..18870.00 rows=100 width=18) (actual time=1.395..119.152 rows=11 loops=1)"
" Filter: (moji ~~ 'hoge12345%'::text)"
" Rows Removed by Filter: 999989"
"Planning time: 0.104 ms"
"Execution time: 119.177 ms"
前方一致のクエリを投げたつもりなのですが
結果はSeq Scanが走っています。
なんでなんだぜ？？
前方一致で似たようなクエリを何パターンかやってみたんですが
Seq Scanが走りました。
これはなんでなんでしょう？？
誰か教えてください。。。
というわけで
検証の結果、本の内容と若干異なる結果がでちゃいました。
2012年の本なので、2015年現在ではRDBも進化してるということでしょうか？
LIKE述語の前方一致の件、、誰か教えてください・・・
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
追記：
ありがたいことにコメントをいただけました。
次の記事でいただいたコメントをもとに再検証しました。
PostgreSQL ロケールとLIKE述語そしてpgAdminでの注意
登録:
投稿 (Atom)