2015年6月9日火曜日

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


なので、この子を編集してあげます。
-bash-4.2$ vi /var/lib/pgsql/9.4/data/pg_hba.conf

ここの
# IPv6 local connections:
host    all             all             ::1/128                 ident

これはIPv6のループバックアドレスですが ident になってます。
この ident を 例えば trust にすれば無条件で認証してくれます。
md5 にすれば二重MD5ハッシュ化パスワードで認証できます。
# 他にも、アドレスの欄をlocalhostにすると幸せになれるかもしれません。


ちなみに、私の場合IPv4は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述語の前方一致でインデックスが動かないという現象がありましたが、
ありがたいことに記事にコメントをいただきました。


ごきげんよう。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年初版発行


この本によると
以下の場合はインデックスが利用できないと記載されています。
  • インデックス列に演算を行っている
  • 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();
        }
    }

}

2015年6月2日火曜日

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文を再度実行したら、うまくいきました。



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


2015年5月31日日曜日

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が多いw



================

■マイグレーションの切り札 多機能データ同期ツール 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やコマンドを組み合わせて実施する作業を
1つのスクリプトで実行できるようにしたもの

PostgreSQL DBA業務をこなすため

GPLv2ライセンス

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


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


======================


■ PgAdminⅢを使いこなそう

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

PgAdminⅢの操作の話

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


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

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


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


======================

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


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

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


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


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


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

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

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


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


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


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


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


======================

■次回について

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


======================


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




2015年1月30日金曜日

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が高い
帯域が死ぬ
エッジスイッチのアップリンクが1Gで死ぬ


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

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

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

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


<<所感>>
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割の蟻になるための方法

 自分で考えろw

 学び方を学ぼう

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

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

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

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

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

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

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

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

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

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

 
・質疑応答

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

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



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