第七回 中国DB勉強会
ということで、我が故郷である島根県松江市で2015-01-31に開催された、第七回 中国DB勉強会へ行ってきましたよ。
発端
- 今回の勉強会、前回の第6回中国DB勉強会 in 広島の懇親会で、そーだいさん(@soudai1025)と「勉強会、島根で開催したことないんだよねー」「私島根出身だから、島根でやるなら行ってもいいよ」みたいな話があったのが発端。
- PGCon.jpの後にも同じ話があって、しかもそのときに、自分が話すってことになったらしい。
- 酔ってると何言っちゃうかわかんないよねー てへぺろ(・ω<)
概要
- 会場は松江オープンソースラボ。
- そう、ここはRubyの聖地。なので、まつもとゆきひろさんの等身大POPが置いてあったりする。
- 来場者は28人とか行ってたかなー。そーだいさんが、しきりに「島根の集客すごい」と感心している。
- さっそくtoggterまとめがつくられていた。第七回 中国地方DB勉強会 in 松江 - Togetter
講演超要約
ドキュメント指向DBとしてのPostgreSQL
- 発表者はぬこ。
- 途中、PostgreSQL vs MongoDBの部分で、玉川さんとやりとり。
- 玉川さん曰く「MongoDBについてちょっと甘い評価になってますねー」
- MongoDBの並列性はそんなに高くない。Aggregate-FWは制約が多い＆使い方が難しい的なコメント。
MySQL最新事情
- 発表者はOracle社の梶山さん(@RKajiyama)
- 最初に(PostgreSQL JSONBの話を受けて急遽追加したという) MySQL JSON UDFの話。
- MySQLの歴史。
- MySQL 5.6の紹介。
- 開発中のMySQL 5.7の紹介。
- MySQL Workbenchによるクエリプラン編集機能の紹介。
- このセッションはQAも活発。
上下水道インフラ監視/制御システムにおけるPostgreSQL運用事例
- 発表者は廣江さん。地元枠その1。
- 最初に上下水道の監視サービスの話。
- インフラ周りのシステムって高可用性が要求されるから大変だよなあと。
- 前半は、PostgreSQL 8.3でさまざまなレプリケーションを試した苦労談。
- 後半はシステムの一部で使っているRiakの紹介。Riak vs MongoDB, ﾌｧｲｯ!
- QAタイムに、このシステムのユーザさんが乱入！感謝のお言葉を述べられた。
Amazon Redshiftを使ったデータ解析
AWSのデータベースサービス全部紹介
- 発表者は玉川さん(tamagawa_ryuji)。
- 玉川さんが翻訳した、"MongoDB イン・アクション"には今回の発表でもいろいろ参考にしました。
- 前半はAWSのデータベース系サービス(RDS, DynamoDB, ElasticMapReduce、周辺サービスなど)
- 後半はGoogle Big Queryの話。
- 前半・後半とも濃くて面白かった！
クロージング
- クロージングに、ぬこの頭のう指数が低いLTを捩じ込みましたｗ
- JSONB型＋postgres_fdwネタ
- インガオホー！ jsonb + postgres_fdw
- 最後にそーだいさんからの挨拶と、今後予定している中国地方でのイベント周知。
- 1.オープンセミナー2015＠広島のお知らせ。開催はバレンタインの日。テーマは構成管理ツール。
- 2.座駆動LT大会。2月28日。テーマはフリーダム。
ここから詳細編。
ドキュメント指向DBとしてのPostgreSQL
他の人のツイートなんかを参考に。
- @nishidayuya 列のないテーブルってどういう使い方をするんだろう
- @soudai1025 nextval()の性能が向上したけど一つのトランザクションで1000とか呼ばないと実感出来ないので実務で感じる事は少ない。
- @soudai1025 PostgreSQLのJSON型の何が嬉しいって式INDEXが使えることだよね
- @nishidayuya JSON型のカラムの特定のプロパティに対してインデックスが張れる 面白い
- @soudai1025 データをrow_to_json()でレコードからJSONに変更出来るの便利。
- @Uemmra3 JSONからPostgreSQLへの変換json_each_textは、1段階しか展開してくれない。
- @tamagawa_ryuji 純粋のJSONの扱いに限れば、まだMongoDBのほうが柔軟というか、制約が少ないかなあ。
- @soudai1025 PostgreSQLのJSONBで大事なのは値の内包を検索できる上にGINインデックスが効くのでめっちゃ速い。
- @tamagawa_ryuji ちなみにPostgreSQLのJSON拡張って、OracleのJSON関連の機能とは全く互換性なく開発されてる感じなんですよね？
- @soudai1025 GINインデックス（転置インデックス）は重複があるようなデータに対するインデックスで全文検索や配列型で使っても強力。
- @soudai1025 プロパティが可変のデータをJSONとして保存して使えばDB変更せずにデータ変更に対応出来る。
- @soudai1025 いつになったらmerge文がPostgreSQLに実装されるんですか！（ﾊﾞﾝﾊﾞﾝ
- @tamagawa_ryuji MongoDBとの比較、データベースサイズがMongoDBの方がずっと大きくなってるのは意外ですねえ。後はまあ、そんなもんかも。ただ、インデックスの使いこなしなどでいろいろ変わると思いますが。 #ChugokuDB via Twitter Web Client
- @tamagawa_ryuji レプリケーションは、特にMongoDBは扱いやすいです。 集計処理、並列処理はそんな強くないっすー。
- @soudai1025 原田さん「MongoDBの方が並列処理や集計処理は有利」玉川さん「MongoDBもどっちも制約があるし癖もあるからいまいちですよ。」触った事のある人の意見は貴重やね！
- @tamagawa_ryuji 今日の話をお聞きした限りでは、構造がある程度複雑なJSONだと、現状のPostgreSQLはちょっとつらいかな、という感じがしますね。
MySQL最新事情
MySQLの歴史
-
- Oracleに買収されたけど、OracleとMySQLは適用領域を住み分けている。
- Web系であれば、MySQL一択。Oracleは使われない。とOracle社の人が言うと説得力がｗ
- @soudai1025 OracleはMySQLにリソースを投資してる一つの指標として開発、サポート、テストのチーム人数はSunの頃より2倍以上になっている。
- @soudai1025 MySQLはスレッドタイプだしランダムIO強いからSSDとの相性も良いしレプリケーションの歴史も長いからWebのニーズとマッチする。そこでOracleDBと住み分けができる。
- あと、アプライアンスに組み込むにはOracleは敷居が高い。そういう場合にもMySQLが向いている。
- MySQLの一番の強みはストレージエンジンの柔軟さ。
- MySQL 5.1は黒歴史扱い。
-
MySQL 5.6
- レプリケーションをさらに改善。NoSQLオプション。参照専用トランザクションオプション。オンラインでの並列DDL処理?ソシャゲとかで重要。バッファプールのダンプリストアで再起動直後の暖気運転が不要に。
- 5.6のmemcached プロトコル。SQLまで使わなくて良いときに使える。SQLと比較して9倍高速なケースも。
- 5.6オプティマイザの改善。MySQLも頑張ってるなあ。レプリケーション改善。GTIDやチェックサム、遅延レプリケーションなど。
- GTIDは自動フェールオーバのための機能。多段構成も簡単に対応。
- この辺、PostgreSQLがちょい弱い(職人芸が必要)部分か。
- @tamagawa_ryuji @nuko_yokohama レプリケーション回りは、MongoDBの持っている機能をいくつか取り込んでる感じですね。遅延レプリケーションとか、自動フェイルオーバーとか。
MySQL5.7
- 5.7(開発中)の話。デフォルト値変更に関して開発コミュニティが意見募集中とのこと。
- MySQLのアイソレーションのデフォルトはリピータブルリード。リードコミッテドにするか議論中。
- 5.7では大きく性能向上(sysbench)。オプティマイザ改善。ストレージに応じた最適化など。
- おー、5.7では日本語全文検索サポートか。mecabって書いてあったから、PostgreSQLでいうtextsearch_ja相当か！？
その他
上下水道インフラ監視/制御システムにおけるPostgreSQL運用事例
- 上下水道の監視サービスの話。異常発生時に担当者にプッシュ通知など。全国で利用されている。PostgreSQL、Riakを使っている。
- このシステムはとにかく落ちないように各所を冗長化している。LBも冗長化のために。普段は東京DC、異常時に島根のDCへ切り換え。
- PostgreSQLは8.3、400GB、DBは380個、総テーブルは38000！
- ユーザ・端末・表示設定や日次月次の集計、故障履歴などをPostgreSQLで管理。
Riak
- もろもろのログや画像、センサのデータなどを保存。
- MongoDBも選定候補にあったが、運用のしやすさやバージョンアップのしやすさなどでRiakを選定。
Q&A
- QA. PostgreSQLの最新化は？⇒考えてはいるが・・・
- ぬこからコメント。PostgreSQL最新版なら、同期SR＋非同期SR＋Pacemaker構成ではとコメント。
- OSのバージョンアップは⇒フロント以外は手をつけたくない。機器更改タイミングかなと。
- QAタイムに、このシステムのユーザさんが乱入！感謝のお言葉を述べられた。
Amazon Redshiftを使ったデータ解析
- 山口さんのAmazon Redshiftを使ったデータ分析の話。
- モンスターラボの島根開発拠点は、ここテルサ別館なのかw
Redshiftの説明
- Redshift=DWH・データ分析が低額で使えるAWSサービス。
- Redshiftはソシャゲ、クックパッド「たべみる」、クラウド会計などで国内でも導入されている。
- MySQL/PostgreSQL互換インターフェース、TBオーダーでも低レイテンシ。
- Redshiftアーキテクチャ。
- リーダーノード、コンピュートノード、ノードスライスの概念。
- ノードスライスが並列性にかかわる。ノードスライスがCPU・メモリ・ストレージをもつ。
- 分散方式。均等分散、ハッシュ分散、All分散。All分散はレプリカ方式ってことか。
- 分散キーチューニングの話。特定ノードに偏って配置させない。JOIN可能にするなら結合キーを分散キーに。
- Redshiftのデモ
AWSのデータベースサービス全部紹介
AWSデータベースサービス全紹介
BigQuery
- "Google BigQuery Analysis"の本は3月に発売予定とのこと。
- BigQueryはOLAP向け。
- 追記と検索のみ。
- RDB＋配列、構造データが扱える。ちょいPostgreSQLっぽい。
- Google Cloud Storageからもデータインポート可。
- AdSenceからもデータの受け渡しができる。
- 米国の様々なサンプル(zipコードなど)もすぐ使える。
- クエリもWeb IFを使ってブラウザで実行可能。
- dry-run機能。ある意味、課金的EXPLAIN機能があるってことかw
- BigQueryはデータ量が少ないとRDBなどより遅いが、データ量が非常に大きくなってもあまり性能が変わらない傾向がある。
- しかしGoogleといAWSといい、優れたアイディアは優れたインフラから生まれるものなのかなあとも思った。(´・ω・`)
- BigQueryのハック
- クエリ実行：コンピューターノードツリーの動的生成、データのノードはフルスキャン。
- 高速NWや大量リソースのバースト実行があってこそのワザマエ！コワイ！
- クエリ結果は匿名テーブル(7日間保持)に格納される。匿名テーブルをクエリキャッシュ的に使うという、タツジンのジツもあり。
- 列指向DBだから、きちんと列指定をした方がコスト的にも実際安い。
- たぶん、追記性能向上のために、時系列ごとに格納先を分割格納、一週間後にマージみたいなことをやってるんじゃないか説。
いやー、濃いセッションで楽しかった！
