smallpalace's blog

鯖缶主婦の日々の記録です

jawsug20131004(DB祭り)に参加してきました

こんにちは。smallpalaceです。

季節の変わり目で涼しくなってきましたね。

私はちょっと風邪をひいたっぽいです。皆様もどうぞご自愛ください。

 

さて、タイトルどおり行ってきたのでそのメモです。

あんまりメモれてないとこも多いので追ってスライドリンクはります。

 http://jawsug-tokyo.doorkeeper.jp/events/5939

ハッシュタグ

とぅぎゃった: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縛りあり)

移行用のプロシージャが最新版で利用可能に

Oracle

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のさっきの手順がベストらしい

気をつけること3つ

ロードとIndex作成の順番をまもる

tmpdirに作業用の一時ファイルが作成されるので空き容量がひつようDBのテーブルサイズくらい

Amazonでtmpdirはルートパーティションとデータボリューム普通分けることになるのでちっさいからきをつけよう

テーブルの再編成について、フラグメントしたテーブルをなおす

5.6ではベストではないことに。ALTER TABLEなにも考えないでうつと古い内部手順でうごくP2

FaceBookのMark Callaghanがパフォーマンス問題に大体噛み付いてるので彼のブログを見てると大丈夫

http://mysqlha.blogspot.jp/

サービス運用中にきったらひどいことになると(外部キーの話だった気がする)

・宿題

 テーブルにデータが入ってないところから最適化する手順。

 もともと入ってるところに追加する場合はどのような手順が最適でしょうか??

 

----

ながやすさん 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で使えるようになった

 インスタンス2つ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の勉強会的なネタになる気がします。たぶん。