jawsug20131004（DB祭り)に参加してきました
こんにちは。smallpalaceです。
季節の変わり目で涼しくなってきましたね。
私はちょっと風邪をひいたっぽいです。皆様もどうぞご自愛ください。
さて、タイトルどおり行ってきたのでそのメモです。
あんまりメモれてないとこも多いので追ってスライドリンクはります。
http://jawsug-tokyo.doorkeeper.jp/events/5939
ハッシュタグ#jawsug
とぅぎゃった：http://togetter.com/li/572518
Ust録画：http://www.ustream.tv/recorded/39510713
個人的にきょう大事なのは平塚さんのやつくらいかなと思ってたら他も意外と面白かったです。
------
AWSアップデートDB縛り（5分）中の人堀内さん
http://www.slideshare.net/horiyasu/aws-db-in-18-jawsug
5.6対応
レプリカを30個つくれるように
5個同時につくれるように
CR1のスペックいままでの2倍くらいの性能が選べるように（5.6縛りあり）
移行用のプロシージャが最新版で利用可能に
ErastiCache
Redisがつかえるように
DinamoDB
トランザクションライブラリとジオライブラリをサポート（JAVA)
ある位置から矩形、円形検索が可能、近くのお店を検索といったアプリの開発を容易に
ローカルが使えるように
Redshift
whatsNewをみてね
-------
MySQLにおける大量データロード時の考慮事項
平塚さん
http://h50146.www5.hp.com/products/software/oe/linux/summary/mwtech/files/mysql-loaddata-v02.pdf
バックアップレストアが遅いのをなんとかしたい
整列ずみのデータを使う（2008年）
データロードの最適手順がバージョンごとに違うらしい
HPさんの検証からわかったはなし
FastIndexCreation 5.5の新機能です
（ぜんぜんはやくなくて普通になっただけ）
オンラインDDL 5.6の機能 制限事項が山ほどあるのでマニュアルを確認しましょう
処理時間を測定してみた
外部キー制約に違反してる場合は動かしてからエラーになるので注意
測定環境は、自宅
5.1はなにしてもおそい
5.5はFastIndexCreationと一度に作成(セカンダリインデックス)が早い
5.6はFK後作成もはやい
5.7に期待しましょう
主キーソートしてもセカンダリキーがソートされてないのでぐちゃっと。
5.5でFastIndexCreationつかうとそこはかいけつする
5.6のさっきの手順がベストらしい
気をつけること３つ
ロードとIndex作成の順番をまもる
tmpdirに作業用の一時ファイルが作成されるので空き容量がひつようDBのテーブルサイズくらい
Amazonでtmpdirはルートパーティションとデータボリューム普通分けることになるのでちっさいからきをつけよう
テーブルの再編成について、フラグメントしたテーブルをなおす
5.6ではベストではないことに。ALTER TABLEなにも考えないでうつと古い内部手順でうごくP2
FaceBookのMark Callaghanがパフォーマンス問題に大体噛み付いてるので彼のブログを見てると大丈夫
サービス運用中にきったらひどいことになると(外部キーの話だった気がする)
・宿題
テーブルにデータが入ってないところから最適化する手順。
もともと入ってるところに追加する場合はどのような手順が最適でしょうか？？
----
ながやすさん PostgreSQLのおはなし
http://pgsqldeepdive.blogspot.jp/2013/10/aws-multi-az-postgresql-replication.html
10分でくみあげるAWS-multiAZ postgres chefで
NWつながってるか心配
ErasticIPはENIでつけて切り替えてる
あとでブログにあげます
ローンチインスタンス済み
AWS的な話が最初に。
AWS上でPostgreSQLを実行するホワイトペーパーが出たというはなし
http://aws.typepad.com/aws_japan/2013/07/running-postgresql-on-aws.html
スケーリングさせるアーキテクチャのはなし
事前に考えようとかそういうの
ProvisionedIPOSでRaid0とか（Raid0は内部的にEBSが冗長化されてるので可能になるらしい）
最大4000IOPSまでいくらしい
バックアップ
pg_なんとか。メモりきれなかったので上記リンク先でどうぞ。
スナップショット
デモ
Chefが走って動くようになった
pgadminでマスタに接続
DBも作れてreplicaitonされました。
この手のデモを生でできるのもスゴイっす。
-----
DWHはこわくないRedshiftを開発DBとしてでカジュアルに利用するはなし ALBELT（統計分析の会社) 池内さん
好きなAWSはErastiCache
http://www.slideshare.net/iktakahiro/dhwredshiftdb
ユーザとクライアントのいろんなデータをRedshiftにためこんで活用している
fluentd＞s3>Redshiftは結構つかわれてるらしい
圧縮アルゴリズムについて調べてみたのであとでスライドみてみてね
基本
価格的には24時間稼動させて$30+α
AWSの土地勘とSQL経験があれば大丈夫。PostgreSQLだとなお可。そんなに難しくない
開発オフィスのIP許可してDBとUSERつくれば大丈夫
GUIこんなのつかってますみたいな話
Postgresqlにつながるツールなら大体OK
ターミナルからpsqlコマンド発行してもいいけどGUIもありますね
SQLWorkBenchだいじょうぶ
PostgreSQL Studio最近でたっぽいJavaWebアプリGUIがいい感じ風tomcatのwarファイルを置けばつながる
→つながらんかった。。というオチ。9.2からだから？
Navicat お勧めただし有償。ローカライズ版と本家でだいぶちがう
IntelliJ Database Tool 結構協力なマネジメントツール
RDBのつもりで気軽に使える
GUIも色々あるので好みに合うものを選ぼう
Redshift特有のテーブル設計もデータの出し入れは簡単にできるので失敗したとしても重く受け止めない
ソートキーとディストキー(分散させるためのキー)の設計がキモだけど
ダメだったらまた出して入れればいいよねーみたいな感じだそうで
(一億レコードでsmallインスタンスで20分くらい)
------
ここからsmallセッション
------
AmazonRedshiftの開発者がこれだけは知っておきたい10のTips 藤川さん hapyrusという会社の人
Redshift 藤川で検索するといろいろでてくるそうです
http://www.slideshare.net/fujibee/18-aws-user-group-japan-amazon-redshift10tips
・カラム毎に独立
・1行とってくるのも数秒かかる
・そんかわり大規模データのjoin/groupby/sortが早い
distkeyはjoin時のキー1こだけ
sortkeyはwhere句の条件カラム（400個可能
あとで変更できない
変更できないのでつくりなおしが必要
カラムナデータの圧縮は大事
最初にテーブル作ってかってにやってくれる
データロードとクエリ実行はどうするの
クエリ実行はPostgreSQLと同とう
中級
SQL制約
uniqueとか実はきかない
not nulllはきく
UTF8一部マルチバイト文字コードがつかえない
リサイズあれこれ
操作はconsoleから数クリック
最初にreadonlyになり数時間後、DNS切り替わる関係で数分readもできなくなって数時間後につかえるようになる
内部的には別クラスタを作り直してるからデータ量しだいで結構時間かかるので検証しないと
Postgresqlの関数は半分くらいしか使えない
とか色々制限がある
copyコマンドのオプティマイズ
一度に処理するデータ量が多ければおおいほど。。
そんな色々が面倒ならFlyDataをつかおう（宣伝）色々考慮してるよ
gihyoで連載してるのでもっと詳しく書いてあります
http://gihyo.jp/dev/serial/01/redshift/0001
HadoopとHiveを全部置き換えられるらしい。
そうなんだ。つかったことないのであんまピンとこないけど楽になるってことかしら。
-----
Redshiftを利用したエンタープライズDWH構築の勘所 ウルシステムズ吉田さん
技術的な内容以外の話
Redshiftのみで効率的なDHWを構築するのはできない
データはさまざまな場所と形式で存在するので連携しなければならない
差分取り込みの仕組みも必要
データを可視化するひつようがあるBIツールの選定とかひつよう
データは見やすく魅力的でないとだめ
分析結果をさまざまなデバイスで見る必要が
安心運用がひつよう、障害対応迅速にセキュアに
データ分析補助、知識がなくても傾向や特徴が抽出できる仕組みが必要
過去データを分析し現在を知るだけにとどまらず未来予測も必要
WhiteEyeというのがいまのを解決しまーす（宣伝だった）
-----
Oracle onAWSサービス無停止でインスタンスタイプ変更 システムサポートのよしださん
Oracleプラチナの人だそうで
タイプ変更するとリスナーとつながらなくなったりとかしがち(接続要求をうけつけるとこ）
StatsPackが使えなかったけどRDSで使えるようになった
インスタンス２つRMANというバックアップリカバリ用のツールで同期させてしまうようにして
切り替える
両方アクティブにならないように切り替える
シーケンスや順序データがかぶらないようにトリガーで制御する
コネクションぷーリングしてなくても大丈夫
トリガーで制御とかめっちゃ腕がすごそうです。
----
インメモリDBでつくるWebDBアプリ SAPハナキさん
http://www.slideshare.net/TeruYoshikoshi/hana-one-tokyo
http://www.sapjp.com/blog/archives/author/Hanaki
SyBaseではたらいてたこともあるそうで。
フロント側もインメモリにして早くしたら早いんじゃないかみたいなことで
全部インメモリでやるのがHANAというシステムらしいです
ロジックをDB自体がもってる
テキストサーチとテキスト分析もおなじとこでできる
GUIももてるよみたいな。
SAP HANAだって、足りない部分はRedshiftと組み合わせることができるらしい
HDDつかわないNWつかわないので高速ってことみたいです。
メモリどんだけつんでどのくらいのことができるのかなあと思いました。
------
RedisOnEC2 クックパッドの星野さん @con_mame
http://www.slideshare.net/conmame/redis-on-ec2
コンマメさんは星野さんだったのを初めて知りました。
クックパッドのRedis、マスタはENIもってる
ELBからスタンバイとスレーブに接続してる
マスタが死んだらバックアップRedisにHeartbeatで切り替える
センティネルRedisエンジンつかってもいいけど安定してなかったのでHBになってる
トラブル
ある日突然コネクション数はねあがる
オートスケーリングのせいだった
terminate時にクローズしないと接続維持するのでmaxいっちゃう
接続元でプーリングしてる場合はreconnectとか
設定によるがIOが多くなるのでPIOPS EBSのが安定かつ安くなる場合も。特にAOF ON
バックアップはdb or aofファイルをS3に転送するといい
xen上だとfork遅いといわれてるけど
メンテナンスWindowきになるならEc2で
IOやbackupケアして
AutoScalingはtimeoutも気をつける
slaveの分散はInternalELBでらくらく
----
fluentdとRedshiftの素敵な関係 @just_do_neet
変なTシャツのネタがところどころにはさまれていました。
Redshift便利だけど不満なところも
データをS3/Redshiftまではこぶところどうするとか
大量データだと時間かかるめんどい
fluentdつかうとべんり
豊富なプラグインがあっていい
s3とredshiftのプラグインも。
入力フォーマットも色々あって便利
3つの項目を設定すればいいかんじ
nginxのログの保存設定の解説など
加工データ付与とかできるgeoipというプラグインとかで都市名とかとってきて入れる
fluentdをつかうデータ
Flydataをつかうと楽をできるよ（宣伝）
----
おしまい！
おもしろかったです。DB縛りだからかネタ中心の人がいなくてjawsugに参加した中では過去最高というか初めてすごく勉強になった回だった気がします。（あんまり参加してないから過去の神回を知らないだけかもしれません）LTはredshiftのプロダクト宣伝多かったかな。
懇親会は娘がまってるのでいつも参加できません。残念！といいつつ別に酒飲めないし人見知りだしいいやとも思っています。(勉強会に出てる時点で趣味で時間外労働してる感じですし)技術的にどうしても懇親会にもぐりこんで聞いておかないと仕事上やばいことになる可能性があったら出なきゃってなるかもしれません。まあ子供がでっかくなって機会があればそのうち～。
では読んでいただいてありがとうございました。
次は娘の誕生日ネタのあとにmysqlの勉強会的なネタになる気がします。たぶん。
