第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にない？

■所感■

スライドを見ながら

なるほど・・って感じたけど

自分じゃ絶対かけない・・・

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

うさぎコレクター　～PostgreSQLで画像データ管理～

Ayumi ishiiさん

■資料

http://www.slideshare.net/ayumiishii31/postgresql-56075750?from_m_app=android

■問題

変化の激しい世の中において常に技術を追いかけ高いパフォーマンスが求められる

→　癒しが重要

　→　ペットのうさぎが癒し業をボイコットしてる

■仮説

うさぎ画像をみれば癒されるのではないか

■やってみる

うさぎ画像の検索結果から画像を抜き出す

→　ローカルに画像を保存

→　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を使おう

※スライドみててメモとってなかった・・

■資料

http://www.slideshare.net/toshiharada/pgunconf-20121212postgeres-fdw

■所感■

postgres_fdwって聞いたことしかなくて

調べるにはいい機会になった。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

パラレルシーケンシャルスキャンの検証　snagaさん

9.6に実装される機能？

パラレルシーケンシャルスキャンのデモ

資料は以下

http://pgsqldeepdive.blogspot.jp/2015/12/parallel-seq-scan.html

■所感■

シーケンシャルスキャンが高速化するなら、みんな幸せになりそう。

ただ、まだまだ検証段階なのでこれからどうなるのか楽しみ。

場合によりIndexよりも速くなったりするのかなぁ。

以上

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カンファレンス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 Tokyo/Fall に参加しました（2日目）

ごきげんよう。

オープンソースカンファレンス2015　Tokyo/Fall　に参加しました（2日目）

掲題の通り
2015年10月24日、25日に開催の
オープンソースカンファレンス2015　Tokyo/Fall　に参加しました。

25日（2日目）の参加報告を簡単に記載します。

OSC2015 Tokyo/Fall公式ハッシュタグ：#osc15tk



＜＜2日目＞＞

■高機能アクセス解析ソフト Piwik の紹介・活用法

Piwikってまったく聞いたことなかったので、試しに聞いてみました。

「ぴーうぃっく」

と読むそうです。

OSSなWeb＋モバイルアクセス解析プラットフォーム

らしいです。

コミュニティが毎月活発らしい

リファナースパム？に対策をGithubで公開中

結局よくわからなかったので

とりあえず公式サイトを貼っておきます。

http://www.piwikjapan.org/

■PostgreSQL 9.5の新機能紹介

10月6日のSRA OSS社のイベントとほぼ同じスライドでした。

いろいろ新機能はありますが

スライドを見た方が早そうなのでリンクを貼っておきます。

https://www.sraoss.co.jp/event_seminar/material.php

■分散処理基盤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トラブルシュート

アシストさんはプレゼン資料を印刷して配布してくれるので
とても助かります。

・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」って言葉は変にバズってて
「温度センサーを設置して温度測定しました」
って話ばかりなのは気のせいでしょうか。
他のイベントでもそんな話だったんですけど。。。


以上

PostgreSQLのslackのご紹介

ごきげんよう。


少し時間が経ってしまいましたが
私の尊敬するエンジニア　そーだいさん　が
PostgreSQLのSlack（大雑把に言うとチャット部屋）を開設してくれました。

詳しくはこの記事（そーだいなるらくがき帳）
http://soudai1025.blogspot.jp/2015/09/stackpostgresql.html

「Slackってなに？」って方はこちらを参考にすると良いかもしれません。
http://matome.naver.jp/odai/2140816727781771801


コミュニティ活動とかやったことない・不安って人も
Slackの方々はみなさん親切なので、歓迎してくれると思います。

PostgreSQLの初心者の方のための #bebinners という部屋や
もはやメシテロ用の雑談部屋 #random という部屋
もありますので
まずはそちらから体験してみてはいかがでしょうか。

情報処理技術者試験 システムアーキテクトを受けた

ごきげんよう。

おひさしぶりです。

10月18日の情報処理技術者試験システムアーキテクトを受験したので
それについて書き留めます。

ただし、たぶん午後Ⅰで落ちてるので、鵜呑みにしてはいけません。

現時点での試験結果を記載すると
午前Ⅰ、午前Ⅱともにそれなりに得点を稼いで合格してました。


で、何をしたかというと
8月のお盆を過ぎた頃から対策開始

本屋さんでシステムアーキテクトの対策本をみたけど意味不
午前問題も応用情報を受けた数年前ぶりなので、やっぱり意味不

というわけで、まじめにやらないと何もできんとなり、勉強しました。

使った教材はこれ。

• うかる！秋期硬度試験　午前Ⅰ・Ⅱ　2015年度版　Android版（翔泳社）
• システムアーキテクト　2015　専門知識＋午後問題の重点対策（iTEC社）
• システムアーキテクト　合格論文の書き方・事例集　第4版（iTEC社）

あと、このサイトが良かったです。

過去問WEB問題集 情報処理技術者試験　合格への道

http://www.qeq.jp/jouhou/kakomon/index.html

で、午前は電車内でAndroidアプリをポチポチやって、上記サイトでもポチポチしてました。

他の教材はまったく使ってないですが、結果午前Ⅰ、午前Ⅱはクリアできました。

午後Ⅰはタイムマネジメントに失敗して自爆したんですけど、参考書はとてもよかったです。

来年また受ける際には同じ参考書を買おうかと思ってます。

午後Ⅱも参考書がいい感じでしたが、何度か写経しました。実際に書いてみてなんぼだと思います。

で、試験会場は比較的新しい建物らしく、机も椅子もがたがたしないで集中して受験できました。

受験者が座席の1/3くらいしかいなかったので、皆さんが問題冊子をパラパラめくる音も気にしないで受験できました。

というわけで、情処が終わったので

しばらくはまたデータベース絡みのことができそうです。

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に追加されました。

PostgreSQL（Postgres Toolkit） pg_hba.confファイルの設定 ユーザ”postgres”のIdent認証に失敗しました

2015年6月9日

ごきげんよう。
タイトルが長い・・



今回は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というファイルで認証を管理してます。

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でハマることはないと思うのですが・・・なんでなんだぜ？？

PostgreSQL ロケールとLIKE述語そしてpgAdminでの注意

2015年6月6日

ごきげんよう。


前回の記事
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で記事になってました。

ご興味がある方はご参考までに。

Let's Postgres 国際化と地域化

では、今回はこれにて失礼します。

何か補足や「何言ってんだこいつ」ってのがありましたら

コメント欄にご記入をお願いいたします。

PostgreSQL B-treeインデックスの動作検証

2015年6月5日　その2


ごきげんよう。

今回は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での注意

Javaで重複なしのランダムな値をファイル出力する

2015年6月5日

ごきげんよう。 

PostgreSQLで試験用のサンプルデータが欲しかったので、
Javaでデータ用CSVファイルを出力するコードを書きました。
重複しないランダムの整数値がポイントです。
#　Qiitaにもあげてみました。

欲しいデータの形としては 
昇順の数値,重複なしのランダムな数値,重複なしのランダムな数値を含めた文字列 
です。

とりあえず 1000000行出力します。

ところで SyntaxHighlighter ってのを使ってソースコードを表示してみました。
Chromeだと表示までに時間がかかるかもしれないです。

/*
 * 2015年6月5日作成
 *
 * 作成者：show
 *
 * 以下のCSVファイルを出力する。
 *
 * 1から1000000の値を順番に出力,
 * 1から1000000の値を重複なしでランダムな値を出力,
 * 1から1000000の値を重複なしでランダムな値と文字列と組み合わせて出力
 *
 */

import java.io.BufferedWriter;
import java.io.FileWriter;
import java.io.IOException;
import java.io.PrintWriter;
import java.util.Random;

public class RandomValueFileCreate {

    public static void main(String args[]) {

        try {
            //出力先を作成する
            FileWriter fw = new FileWriter("C:\\temp\\sampleData.csv", false);
            PrintWriter pw = new PrintWriter(new BufferedWriter(fw));


            String str = "hoge"; //出力する文字列
            final int n = 1000000; //要素数
            boolean num[] = new boolean[n]; //重複判定用
            Random rand = new Random(); //ランダムな数値


            // すべての重複判定用配列をfalseにしておく
            for(int i=0; i<n; i++){

             num[i] = false;

            }

            //要素数回数をループ
            for(int i=0; i < n ; ){

             int p = rand.nextInt(n);

             if(num[p] == false){ //まだ使ってない値か判定

              pw.println((i+1) + "," + (p+1) + "," + str + "," + (p+1)); //初めて使う値ならファイル出力

              num[p] = true; //使った値はtrueにしておく

              i++; //ループ用の値をインクリメント

             }

            }

            //閉じる
            pw.close();

            //終了メッセージを画面に出力する
            System.out.println("出力が完了しました。");

        } catch (IOException e) {
            //例外時処理
            e.printStackTrace();
        }
    }

}

PostgreSQL COPY文のちょっとした罠

2015年6月2日


ごきげんよう。

先日、PostgreSQLでCOPY文を使って
テーブルにCSVファイルのデータを投入する際に
ちょっとした罠にハマりましたので備忘録を。

#　既知の方も多いと思いますが。。



【環境】
OS：Windows8.1
PostgreSQL：9.4.2
pgAdmin：1.20.0
テキストエディタ：TeraPad 1.09



こんな普通のテーブルを作ります。

CREATE TABLE copy_test
(
  id integer PRIMARY KEY,
  num integer NOT NULL,
  moji text NOT NULL
)

こんな変哲もないCSVデータを作ります。

で、挿入しようとしてCOPY文を実行したところエラーが・・・



ERROR:  型integerの入力構文が無効です: "1"
CONTEXT:  copy_testのCOPY。行番号 1。列 id: "1"
********** エラー **********

ERROR: 型integerの入力構文が無効です: "1"
SQLステート:22P02
コンテキスト:copy_testのCOPY。行番号 1。列 id: "1"

お前は何を言ってるんだ・・（゜ω゜；）
1
が無効ってなんだ・・・



で、いろいろ調べた結果
UTF-8のCSVファイルに　BOM　ってのが含まれてるので
エラーを吐いているとのこと。

#　BOMについては各自検索してあげてください


というわけで
テキストエディタ（今回はTeraPad）でUTF-8NにCSVファイルを変更して上書き保存。

これでCOPY文を再度実行したら、うまくいきました。

地味にハマったので気を付けましょう。

PostgreSQLアンカンファレンス＠東京に参加しました

2015年5月30日　
PostgreSQLアンカンファレンス＠東京　に参加してきました

PostgreSQLアンカンファレンス＠東京
https://atnd.org/events/64543%22

Twitterのハッシュタグは　#pgunconf


メモした内容を記載しておきます。
話を聞くのが精一杯でメモがしょぼいです・・・


アンカンファレンスは初めて参加しました。
参加者が各自発表したいことを持ち込んで
ホワイトボードの時間割にポストイットを貼って
1人約20分で発表する形式でした。

会議室3スペースを区切って、発表は2スペースで順次行われました。


発表者の方によってはスライドを公開するようですので
詳細はそちらをご確認ください。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


■PostgreSQL9.5の新しいGROUP BY

発表者のサイト
http://kenpg.bitbucket.org



Google Analyticsでブログのアクセスを解析
→　JSONでデータを取得できる

pg_read_file 関数でローカルのファイルを読み込んでJSONBにキャストする


GROUPING SETS:GROUP BYを集計行に変える　or 足す

総計行を足した出力が、GROUPING SETSで簡単になる（らしい）

GROUPING はSETS(1,())って書くだけ

GROUP BY GROUPIN SETS ((1,2),1,())

CUBEとROLLUP：ある種のGROUPING　SETSの短縮形


地方の方がFireFoxが多いｗ



＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■マイグレーションの切り札　多機能データ同期ツール　SymmetricDSを使ってみましょう


#プロジェクタ不具合でスライド出力できず口頭でプレゼン
スライドをどこかで公開する。


JDBCがあってトリガー機能がある

異なるDB間でもやりとりできる

移植するときに使える？
　Oracle→PostgreSQL


やってみて苦労した件
　ロジカルレプリケーションは遅い
　細かいトランザクションが山ほどあるとレプリケーションが遅い
　SymmetricDSはトランザクションをまとめて処理できる　1万を100個ずつとか


　エラー処理が雑で　ぬるぽがよくでる
　設定が間違っている場合にぬるぽがでる
　異常系の設計がしょぼい

マルチDBレプリケーターだけじゃなくて
カスケードもできる？らしい


マルチマスタのレプリケーションをもってくるのは難しい



＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■9.5の新機能　CustomSCan / Custom Join


9.5でHookが追加されました

set_rel_pathlist_hook

set_join_pathlist_hook

CustomPath構造体に追加する


JOINするところにCustomScanを追加する
　2つのテーブルをJOINしたのをスキャンしたようにみえる実行パス

自作のJOINを実装して、その実行コストと既存のJOINのコストを比較して
もし、自作JOINの方がコストが低ければ、自作JOINが選択される



＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■　性能比較　XML、Hstore、JSON、JSONB

スライド後日公開？


JSONB
　部分更新入るかも　9.5から

pgbench_XX　で測定

XML型はとにかく遅い


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■　YCSBベンチマーク　JSONBとMongoDBの比較

スライド後日公開？


CPUが少ないならMongoDBの方が有利？
PostgreSQLはCPUがないと性能でないとのこと



＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■　PostgreSQLで日本語全文検索　LIKE、pg_bigm、PGroonga


●LIKE文

メリット
　標準で使える
　インデックス作成不要
　データが少なければ速い

デメリット
　データが多いと遅い


どんくらいなら少ない&速いのか
→　計測結果と要件で判断


pg_bigmでいろんなデータを日本語検索してみよう！


青空文庫　十分速い
住所データ　十分速い
Wikipedia　十分速い？


十分速ければLIKEでOK



●pg_bigm　　ぴーじーばいぐらむ？

データが増えても高速
ストリーミングレプリケーション可


別途インストールしないといけない
インデックス作成が遅い
ヒット数に比例して遅くなる


日本語版Wikipediaの本文
200万件
1レコード3777バイト


いんでっくす作成
　元データのロード時間16分　
　インデックス作成時間6時間

　　　遅い？そうでもない？


●PGroonga

メリット
　インデックス作成が速い
　データ量やヒット数が多くても高速

デメリット
　ストリーミングレプリケーション使えない（INDEXの作り直しが必要）
　別途インストールしないといけない

PGroongaの方がめっちゃ速い
インデックス作成がめっちゃ速い


●発表者からのおねがい
　同じベンチマークを実行して結果を貼ってください



●まとめ

データが少ないならLIKEで十分
　1レコード数十バイトなら100万件はいける
　
　データ量が多いならpg_bigmかPGroonga


[参考情報]
pg_shardとPGroongaを使ったレプリケーション対応の
高速日本語全文検索可能な
PostgreSQLクラスタの作り方


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■　Postgres Toolkitのご紹介


PostgreSQLのサーバ運用・管理するための
スクリプト・ツールのコレクション

複数のSQLやコマンドを組み合わせて実施する作業を
１つのスクリプトで実行できるようにしたもの

PostgreSQL DBA業務をこなすため

GPLｖ2ライセンス

スライドアップしてくれるらしい


すっごい便利そう！
使いたい！


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


■　PgAdminⅢを使いこなそう

チョコレートバーさん
#　同姓同名の方がいらっしゃるのでチョコレートバーと名乗る

PgAdminⅢの操作の話

SJISがなぜかサポートされてない？


PostgreSQLをバージョンアップするとPgAdminもバージョンアップされる
が！！

設定項目のパスが自動更新されないで古いバージョンを参照し続ける！
なので手動で直してあげてください。


タブも実はSQLエディタとかでタブのスペースをコピーして
指定区切り文字のタプルにペーストするとは実はできるｗ


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■　Migr8.rb　DBスキーママイグレーションツール


マイグレーションツール自作しました。

#　スライドの図がないとわかりにくいので公開されるといいなぁ


Migr8.rbとは
　PostgreSQL　SQLite3 MySQLをサポート
　要Ruby


マイグレーションツールの使い方の説明


マイグレーションツールは従来どんな問題があったか

　Ruby on Railsだとタイムスタンプ順で管理するため
　複数人でマイグレーションする場合は古いのが最新になる

　マイグレーションの適用順序を変えにくい


　自作ツールは
　マイグレーションの適用順序を変えやすい


Case2
　他人のマイグレーションが未適用なのに気づかない


　Railsの場合は
　　未適用のマイグレーションがあっても気づけない
　　どのマイグレーションが未適用なのか調べられない


　Migr8.rbの場合は
　　未適用のマイグレーションに気づきやすい
　　　→　コンフリクトが発生してくれる


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

■次回について

今回は前回より間が空いてしまったが
半年に1回ペースでアンカンファレンスを続けていきたいとのこと。
次回開催は11月ごろを考えているので
みなさんそれまでにネタを考えておきましょう。


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝


【参加してみて】
各自が自由に発表できるスタイルはすごいいいと思いました。
発表者の方々のレベルが非常に高く感じました。
私がへぼいのでしょうが・・・がんばろう・・

CROSS2015参加

2015年1月29日に開催されたCROSS2015に参加しました

http://cross2015.peatix.com/



自分用の議事メモを兼ねて記録を残しておきます。



■開会挨拶

・いろんな人たちと交流することが大事
・色んなことをCROSSして商品開発を明日からがんばろう


■
C会場：
俺はどうしてそのデータストアを選択したのか

銀河と小宇宙を語る会


桑野さん
サイバーエージェント
MongoDBを使っている

宍戸さん
サイバーエージェント
Cassandraを使っている

久森さん
フリックアウト社？
MySQL、分散DBをいくつか体験

冨田さん
富士通システム社


・データストアってなんでしょう？
MySQL NoSQL objectstore


・導入前に十分検証しましたか？
Webのサービスなので負荷を考えた
データストア自体が要件にあっているか
MongoDBを使ったのはシャーディング・JavaScriptとの連携・レプリケーション・負荷検証

Cassadraを選んだ理由
単一障害点がなしに動く　スケールするか

・検証方法
ユニークIDに紐づくデータをどれだけたくさん扱えるか
レイテンシが数ミリ秒で返却されることを要求された
エアロスパイク？の検証をはじめた
単体テストができるようにするのが大変
本番のトラフィックにクライアントから二重書き込みして、ダメならすぐ引っ込める

流通・製造などをお客様にする
スーパーのPOSはデータが多そうなイメージ
数百件のお店がある可能性がある
実績があるからデータ量・トラフィック読みやすいが、その分きっちりしなければならない


・NoSQLなら何台くらい運用してますか？
1サービスあたり60台ー70台のMongODB
更新が多いため、設定を変えたシャード？を避けたい

Cassandra99台
当初は30台で運用していた
データ量が増えて、サービスの拡大をやった
90台くらいで落ち着いていたがクラスタの一部でホットスポットができてた
担当レンジを狭くするためにノードを追加した

また、用途は別だが15台、30台使ってるケースもある


エンタープライズシステムは台数を増やしたくない
NoSQLのうまみが少ない

PosのシステムのデータをRDBに入れる意味がない

システムを組むとしたらフェイルオーバするマシンで複数台運用


・非力なメンバーで運用する勇気が欲しい
定常的に動いて、夜起こされないようにしたい
経験の少ないメンバーはどうしたら？

一番簡単な解はクラウドを使う
クラウドは物理インフラやトラフィックはお金で解決
負荷管理、設計はエンジニアの腕の見せ所、覚悟をもってやらないといけない
それがやりたくないならDB運用屋さんにアウトソーシングすればいい


・ユースケースを意識して使っていますか？
新しいNoSQLを使う際はどのようなきっかけで使い始めることがありましたか？

サービスがあっているか
既に動いていた
人に依存する

MongoDBはサービスにあっていた
全データの検索は弱いのでそのサービスがなかったから使えた

データストア自体がもっている機能、運用面を期待するか
しばらく一緒に付き合ってみてベストプラクティスが見つかるもの

ユースケースがなくてデータストアを使いたいってことはない！趣味以外。
どのようなきっかけで？
→　運用がつらい　クライアントのアルゴリズムで動くためスケールアウトできなかった


・BigQueryの話
バッチ処理したログの結果とかビッグクエリに放り込む。
深刻なバッチ処理障害がでたらメールをだすようにしている。

「レッドシフト」はスケール戦略をちゃんとすればいいが設計が大変
ビッグクエリはスケールだけ考えればいい　設計に頭を使わなくていい

ビッグクエリのいいところ
データのユースケースが変わってもそれなりに対応できる
全スキャンでいいじゃないというところが自由度高い

油断してるとクエリ単価があがっていくのが注意
でも　そんなにビッグなデータを使うことはほとんどないと思う


・どんな障害がありましたか？
グローバルロックがMongoDBとして多い
書き込み量が多い場合はスケールしないことを考える

ホットスポットがでてきた。ハード故障が続いた。
同性能なハードウェアは連番で並べてはいけない。


・アップデート
分散データストアのバージョンアップは
ローリングアップデートになる。
キャパがギリギリだと、耐え切れなくなる
間のネットワークの帯域が増えていることも忘れずに

MongoDBのアップデート
止めずにやるのがローリング
サービス的に止めていいならバイナリ置き換えてアップデート

Casandraのバージョンアップ
ローリングでやる
中途半端に間あけずに
リバランスは、ノードの追加と退避をうまくやれば良い　データストアの特性をみつつやりましょう

おっきいバージョンアップは基本的にやらない


・最近注目してるデータストアとその理由
マイクロソフトさん、富士通、オムロンで実験している
オムロンは製造の機械の会社　基盤に印刷したりはんだ付けする会社
工場の中の機械を管理する
アジュールを使った

PostgreSQLに注目中
JSON型がでてきたから

エアロスパイク
データ型があるから気になる

いろいろでているので整理したい
MongoDB2.8でストレージエンジンがつく
メモリの管理、ロックがグローバルなどの弱点がなくなる予定

「オーロラ」が気になってる
プロビジョニングが不要
MySQL互換
人柱募集中（笑）


・導入時の障壁としては何があったか（政治、技術領域など）
ジャパニーズエンタープライズカンパニーに新規導入はない
「あるもの」を使わないといけない

書籍がないとできない　という大きな問題がある。
「教えます」という環境・教育コストが障壁になりつつある

今苦しんでいるデータストアのお守りが大変

学習・教育コストがある


・ネティーザの話
ひと箱1億円
I/Oドライブ使ってる人が少ない


・データストアあるある
スモールスタートと称して
すごい台数になって運用が死ぬ

運用したことないデータストアがいろんなサービスに点在してる

ノウハウが点在してしまう

SSDが高い
帯域が死ぬ
エッジスイッチのアップリンクが１Gで死ぬ


・これだけは言っておきたい
転んでも泣かない

辛くないデータストアはない
できるだけ消耗しないやり方で選定していくのがいい
機械は壊れたら買えるけど、人は買えない

選んだら勇気をもって探究していく

新しいものを使うなら覚悟が必要


＜＜所感＞＞
MongoDBやCassandraの導入事例が聞けたのは良かった。
教育コストがかかるというのはごもっともだと思う。


■
D会場
インフラエンジニアの睡眠時間を確保する方法
 ～Infrastructure as a Code時代のインフラ運用～


くららオンライン　寺尾さん、宇野さん
フィックスポイント　三角さん
ハートビーツ　馬場さん


・まず最初に睡眠時間は何時間とってますか？
→　会場の大半は6－7時間くらい


・インフラ運用で大事な事ってなんでしょう？
「無理をしない」
「自分の時間を犠牲にしない」
「属人化をしない」
気合い　夜中に電話もメールもきていた　→　長持ちしない
　安定的にサービスを提供しないといけない


・運用（定型業務・アラート対応）の自動化についてのアプローチ
ドキュメントに残す
ツールに頼る


・自動化について
人はいるけどキャパを超えないようにしたい
pythonとパブリック（ファブリック？）というツールを使ってる
pythonを使うことが多い　初学者にも使いやすい

自動化のツールはたくさんあるけど
bashを使い続けてる
ansibleやchefで補いきれないこともある
ある程度はパッケージしたい
スクリプトを書いてしまうとほかの人はわかりにくい

人手の運用が続いているカルチャーがある？
自動化するためのモチベーションがあがってこない
どういう風に自動化して効果をだしていくのか考えることが重要


・冗長化しているシステムのサービス断が発生しないメンテナンスは
　昼やるべきか　夜やるべきか

できるだけ昼にやるようにしている。
昼の方がエンジニアが多いしクヲリティが高いしリカバリもしやすい

お客さんに「うん」と言ってもらう言葉を言う
【有料になります、夜は高いです】

基本的には昼にやった方がよい　エンジニアが豊富だから
どうしてもミッションクリティカルなど決まってる場合は夜にやる

「昼」にやれるために仕事をしましょう。
運用でなんとかする　はやめましょう。


・Infrastructure as a Codeって実際どうですか？
サーバスペックを使ったテストをノウハウためてテンプレート化する
プロビジョン側はあんまりやってない
Chefソロでできることはやる

ちょっと合わない
自社のシステムを大量に抱えているところはやっている
異なるサーバ、システムを使っていると使いずらく、最終的にシェルになる

自動化しても効果が小さい場合がある
OSやアプリのバージョンがバラバラなことが多々ある


・インフラエンジニアはプログラムができるようになるべきか？おすすめの言語は？
pythonが必須
好みはあるが言語は特徴がある　これしかできないって人は少ない


楽しくなる方面でプログラミング部みたいなのがあって
業務に関係ないものを作る
意味のないbotを作ったりしてる
もういいから勉強しろ

前までは何でもいいから言語をやれ
今はpythonをやるようにしている

シェルを覚えなさいとは言う

くららオンラインのくららカフェという勉強会で
発表する機会を若者に与える


・最後に一言ずつ
インフラエンジニアの方はもう少し表にでてもいい

日本発の自動化のツールを作りたい


＜＜所感＞＞

たしかに属人化してる面も多々あると思う。
自動化ツールも結果的に属人化してしまう可能性もあるかと。
pythonが推されてるのはなんでかわからなかった。


■D会場：
Webエンジニアなら抑えておきたい最近のOSS事情

MOONGIFT　中津川さん

@masuidrive  TORETA社

@moongift 宛に質問OK
資料はアップするらしい

Ruby on Rails
Node.js
mruby
MobiRuby

@yosuke_furukawa DeNA

BizReacn社
　GitBucket 
Githubを極力パクる

Scalaのエンジニアが少ない


・2014年の振り返り

fc2ブログがOSS化した
LICEcap 使ってみたらよかった
Atom　期待はずれ　キーバインドを覚えられなかった

io.jsは2014年驚き

io.jsについて知っていること

Node.jsのfork

Node.jsは
リリーススケジュールの不透明さ
issue/feature管理ができてない

io.jsとNode.jsに大きな機能的な違いはない
一番の違いはプロジェクトの進め方

io.jsではオープンガバナンスモデル
→　コアチームがISSUEやFeatureの追加をオープンにする

議事録がGithubで管理公開することでnon-nativeにも優しい

OSSという特殊なプロダクトをどうするのがいいか
これからのOSSプロダクトを考えていきましょう

そもそもNode.jsが課題だらけで不透明なのはなんで？
　コアコントリビュータが辞めちゃってる

フロントエンド用のOSS


・キーワードで話すOSS
マテリアルデザイン
スタイルガイド
フラットUI
Web Font
管理画面　Bootstrapを使ったものが多い

管理画面はBootstrap　ピュア　

フラットデザインだとボタン押したかどうかわからない


・セキュリティ

インシデントがたくさんあった
Fingerprint　Cookieを使わずブラウザを特定
サンドボックス　JavaScriptを安全に実行
WAF　パケットではなくWebアプリケーションを保護
情報漏えい/侵入

Node.jsに関して
　脆弱性を伝えるBotがTwitterアカウントがいる

どうやってセキュリティを担保するのか考える

セキュリティの心構え
→　ミッションクリティカルのシステムは有名なプロダクトを使おう
　　脆弱性の報告はされるから

情報収集をしっかりすること

OSSを使うときは古いバージョンのメンテナンス情報を気にする

不要な情報を持たない
個人情報と他の情報はわける

ワードプレス
PHPなどのセキュリティが怖い


・HTML5の話

仕様化準拠はあまり気にしてない
WebView→CromeViewになった

TiZenが復活してほしい

互換性でフロントエンドが動かないことがある
新しいブラウザができるとギクッとする

Single Page Application


・フレームワークのおすすめ
バックボーンがしっかりしてるところ
新しいフレームワークは古い端末が動かない

アンゲラ→IE8が切られた


・仮想
Vagrant
Docker
VR Oculus Rift

Dockerは便利だけど
分散環境を今まで作ってたのが1台で済むようになった

OSから上ごと仮想化することが流行ってる
過剰な期待をしすぎてる

Dokerだけあってもサービスが作れない


・2015年はどうなるか？

マイクロサービス
フルスタックフレームワーク離れ

VR/ウェアラブル
IoT

セキュリティ
　Let's Encrypt　無料SSL/TLS

マイクロサービスは並列処理していく流れになる

Scala普及期になってきている

ギットバケットをよりよくしたい
プラグイン作れるようにしたい
コミッターに参加してほしい

SinglePageApplication　+　Ajax
　Node.js

io.jsも使えるんだということを示していきたい

1つくらいオープンソースをだす。
言語は英語から逃げられない　英語やりたい


・HTTP/2についてはどうなのでしょう？

Webアプリケーションの書き方がかわってくる。
→　本当に必要かは別

ipv6みたいに流行らないかも



＜＜所感＞＞
Node.jsについて語ってる時間が多かった
もっと他のOSSについても触れてほしかった印象


■
大会場：
先輩に聞くこれからのエンジニア像


山口さん
及川さん Googleの人
伊勢幸一　@ibucho
よしおかひろたかさん


・第一部
　じわじわした漸進的な進歩でなく不連続な進化をしたと感じたのはどんなとき？
　その時の進化圧とは？

　その時はわからない、後で考えるとターニングポイントに気づく
　過去4回くらいあった
　転職・部署移動

　環境が変わった時
　転職も一つ
　前の会社でオープンソースに出会った時
　今までの価値観と180度かわって、産業構造が変わる予感がした

　ターニングポイントが先にくる。
　あえて「やります」といって一生懸命になる

　できないことをやれと言われてしょうがなくスタートする

　年をとると自分で変えられないので環境を変えろ

　追い込まれないとやらない
　宿題は期日3日前から

　快適なゾーンから出た時に成長する
　あえて厳しい時にゾーンからでる

　無理強いを受ける


・生存戦略
　自らのバリューについて意識して心がけている点は？
　個の戦略としての転職とは？　巨人からおもちゃ屋へ

　会場にいる人は積極的にカンファレンスに来てるので「いい」
　会社に戻ると、自分から学ばないで仕事をする人が8割
　日々の経験から学ぶこと
　学び方を学ぶ。
　学校は「学び方」は教えてくれない。
　勉強会で学ぶか、先輩に導かれるか
　もう少し、学び方のイノベーションを考えると良い

　最近、師匠がいない？
　ある分野の師匠は必ずいる　とんがっている人は絶対会社にいる
　すげーところを言語化してコピーしていく

　常に転職できるようにしたい。
　1年に1回転職コンサルに　自分の価値を聞く
　自分は商品としてどんな価値があるか
　危機感を感じて、学んで、人脈をつくる
　自分がどういう市場価値か、弱点は何か客観的に考える

　来たボールは全部打ち返す。
　「できない」「やったことない」は言わない。
　
　
・第二部　遺伝子生存戦略

　利他行動
　働き蟻の法則（技術者版）
　8割は働いてない
　　企業のうち2割が勉強会に参加する
　　参加者の2割が「参加した」以上のメリットを見だす
　　
　　・安定志向が増えることの恐怖
　　・成長志向を見抜く方法


　2：8の割合は変わらない
　母数の問題
　働いてる人の指示を受けて働くだけの人が8割

　安定志向8割が増えていく？
　→　増えないけどなくならない
　2割はすぐみてわかる

　稀にあるが2割の人たちが成長しようとする行為を妨げないこと
　8割の人を2割の中にいれることはしてない

　ハッカーセントリック
　新しいビジネスモデルを考える人
　文化的な価値
　8割は日常業務をこなすだけ
　8割の人にハッカー文化を理解してもらう仕組みが欲しい

　日本という地域はハッカー的な文化がない
　CROSSみたいなとこを面白いと思う人が増えれば面白くなる
　
　評価システムのせいかも？
　8割が働いてないなら辞めてもらえ
　簡単にクビ切れる海外ならよくある
　人間は評価が大事
　評価できる仕組みが重要

　人材の流動性と評価の仕組みを導入することで組織が変わる

　人事評価をどうシステマティックで透明性があるものにするか
　マネージャが訓練を受けているかというとそうでもない
　
　Googleは全員技術がわかる
　評価はまわりからされるもの
　すごい人は自然とリーダーになっていく
　まわりから評価・リスペクトを受けられるようになると良い

　競争が圧力になる


　いい経営者とは？
　技術者にとってよい経営者とは、また、その役割分担
　昨今のCTO議論の加熱

　いい経営者は継続的に利益を生み続けられること
　テクノロジーの会社はテクノロジーで利益を生む

　CTOは経営が先で、技術はあと。両方できないとダメ。

　経営の勉強しよう
　得意不得意はあるが勉強すりゃいい

　マネージメントが好きな人が向いている

　経営をリスペクトした方がいい

　多様性をもつとよい
　マネージメントに進まなくていいし、それだけがキャリアじゃない
　技術一本であがっていくのもあり

　経営トップの人に技術も知ってほしい

　経営は経営しながら学べる

　理想的には技術を尊敬して技術を認める経営者がベスト
　現実は違う

　わかってくれる経営者がいる会社に異動してしまえ

　経営者とCTOは別物？
　経営層は利益をあげるのが当然　会社を永遠に続けることが大事
　継続するにあたって、どういう技術を使えばいいのか考える

　経営層を狙う若い人は技術が好きでもそれ以上経営を勉強しよう
　　
　この人尊敬できるって人が経営層にいるか
　自分たちが作ったものを経営層が理解しているか
　世に出しているものを経営層が愛しているか


　【宿題】
　　自分の経営層が自社製品を使っているか確認


・第三部　これからの成長戦略
　自らを成長させるために
　8割の蟻から2割の蟻になるための方法

　自分で考えろｗ

　学び方を学ぼう

　30代くらいになって成長してないと思ったら
　今までと違う学び方をした方がいい

　自分のやりたいことをやるために、あらゆる努力をしろ
　
　やりたいことをやりたいが
　やりたくないことを2倍くらいやらないといけない

　できるだけ若い人と話す
　自分が人に「会いたい」と思われるようにならないといけない

　説教を飲み会でしちゃいけない
　何でもいいから君から何か学びたい

　エンジニアにあんまり年齢は関係ないのではないか

　アウトプットを意識する
　呼吸法は吸うのを意識する
　勉強会は参加するだけじゃなくて絶対質問すること
　LT募集してたら手をあげて必死になる
　スルー力が重要　負のフィードバックも大事　受け入れること

　大学とか大学院みたいな旧来型の学びのメソッドを再評価すると面白い
　大学には図書館があるし本がある
　もう少しアナログな世界に戻って、古い学び方を再評価するとよいかも

　日本では社会人になって大学に戻る人は2％
　他国では20％程

　何か「今」とは違うことをやる
　MBAは大人になって自らの意思で学ぶことがすごい
　新しいことを今の仕事をわきにおいてやるのがいい

　自ら学んでアウトプットをして、それを継続できるか

　
・質疑応答

　30代前半でCTOの人
　→　若い人のモチベーションをあげるにはどうすれば？
　　→　その人がどうしたいのかを持ち出す
　　　→　つまり「我慢」！

　アクロクエスト中川さん
　→　まったくやったことがないことの勉強はまずどうすれば？
　　→　MBAみたいなフォーマルなメソッドが確立しているところに行く
　　
　　アウトプットをだしてフィードバックをもらう



＜＜所感＞＞
社員の8割が指示通り働くだけで、
2割が成長するというのは納得。