予告通り、去年に続いてMySQLユーザコンファレンス行って来ました。
もうすでにいくつか報告があがっておりだいぶ遅れを取っています。
気になる方ははてなブックマークの注目エントリー辺りをご覧になると良いかと思われます。
なのでこのエントリーも使えそうでしたら同じくタグ「mysql」を付けていただければと思います。

今回私は別の予定もあったため、2日間とも午後から参加しました。
事前登録できなかったセッションも見られるだろう、と甘く見ていましたが、
会場は去年より狭く、立ち見でも見られないセッションがあったのは非常に残念でした。
もっと早く登録しておけば良かったです。

もうすでにセッションの内容が抜粋されたようなエントリーはあちこちあるのでまずは概要の感想ですが、
MySQL5.1では、の話が行われていたのは去年と同様でした。結局5.1が出てないですから。
一方、去年はMaster-SlaveのレプリケーションとMaster-MasterをDR:BDで繋ぎHeartbeatで監視、という組み合わせが
推薦されていたと思うのですが、今年はその方式もありつつも、
Slaveは持たずにMemcachedを用いる方法が新たに紹介されていました。

こちらMySQL(Sun)が力を入れ始めたのは最近なので、まだこなれていないと思われるのと、
アプリ側の変更が多くなりそうなのがネックですが、積極的に使うと非同期レプリケーションのデメリットをつぶせるので
今後も要チェックという感じでした。

あと、Masterから単一のSlaveに流し、そこから多数のSlaveに流す構成もあるという話を聞いて、
終わったあと少し聞きに行ったり考えたりした。
梶山さんによると、実はMasterの負荷は大して減らず、実験的な部分もあるとのこと。
無理やり利点を考えた。
Slaveを足すときにMasterを止めずに済むかも？
あとは、最初のSlaveにてエンジンを変えたりindexを足したりの指令を行うこともできそうかな？
Masterをblackholeにする手もあるかも。binlog死んだらサービス止めてslaveから復旧させることになってしまうが。
そう言う意味ではレプリケーション構成のMaster用として、ディスク保存だけど書きが超速くて読みが若干遅いエンジンがあっても良いのかなとか思った。

一日目のアメブロの件を聞きにいけなかったのでブースで発表者の方とお話しました。
とにかくUsing Indexにするためにがんばった模様です。
例えばエントリー一覧を取るときに、普通ならselect一回で済ませて適切にindex貼ってあれば済むところを、
あえてpkだけをselectしてusing indexさせ、各エントリーのその他の情報は別途selectしたら高速化した、とのことでした。
内部的に行っている処理を考えると、そこで高速化するのは考えにくいかもしれませんが、経験上思い当たる節はあります。
想像ですが、selectを分けることで、各スレッドが表を占有している時間を極小化できるので良い効果を生んだのではないでしょうか。
アメブロではMyISAMを使っているとのことで、エンジンが違うとまた違う挙動と思われます。

その他見たエントリーで取っていたメモから抜粋。

Sun梶山さん

切り口・・高可用性（クラスタリング）、拡張方式（性能、ストレージ）、セキュリティー、バックアップ、監視、メンテナンス方式（データ、ログ、時刻）
信頼度の低い順にreplication - DRBD - Shared Disk - Cluster - Carrier Grade
digg.comでは95%がreadアクセス
user, db, table, column, proc単位でsecurity設定可能
MySQL Proxyは興味深いですが、可用性があがるわけではない（Proxyが落ちたら止まる）のでいまいちかもと思った。

HP水野さん

個人的にはBackup手順について良い復習になった。網羅されていて良い資料。
折角レプリケーションしているのに破損するとMasterを止めなければならない場合が多いのが痛いと思った。

Backup/Recovery Sun

mysqldumpで--single-transaction --master-dataはかなり使えそうと思った
OS Copyは物理的にバックアップするので速いだろうなと思った
バックアップの各種方法を比較した表があったがこの表欲しいと思った

野村総研寺田さん

基幹DBへのMySQLの導入例
200件/秒、data=1TB、冗長化、10分で復旧させたい金融機関とかへの導入事例。
正直ガッツあるなと思いました。
DB1台。RedHat クラスターソフトと共有ディスクで対応とのこと。
MySQL5.0だったので、表分割や表のパーティション機能が欲しい。
MySQL5.1に期待している

サービス業L社も待機系を使用
Javaだとproxyがないと複数サーバーには繋ぎづらい・・・てこともないと思うのですが、
レプリケーションが非同期である辺りを気にされるお客様が結構いらっしゃる、ということでしょうか。
負荷が高いときも偏りが少ないという評価で、mod_proxy_balancer より mod_jk を採用とのこと。

MySQL Clusterについて
5.0.40以前は不安定
JOINの多いSQLで性能が遅い、といった「くせ」がある
性能のスケールアウトに期待

2日目
cocolog について

typepadベース。nifty/6apart
70万会員、数億pv。ブログサービスとしては十位前後ではないか
spam, 連続投稿の監視

2003/12- (0.04million entries)
10servers, pgsql <-typepad->nas/web
2004/12 7million
50servers, publish book(2005/5), tel support, podcast, rss,...
2006/3 12million
systems -> web-api -> memcached -> pgsql
12月にメンテ失敗...
2007/4 16millions
mobile web
2008/4 150 servers
multi mysql
DBが1 pgsqlからmulti mysqlになった
DB partitioning
user1-3, role, non-user role
typepad -> Schwartz DB (job execution system)
今もレプリケーションは使ってない
ブログサービスや、集計の性質上レプリケーションが有効だよね

pgsql 7.4-8.1
100gb超えで問題 40%がindex
auto vacuum response time
charset - reject - メンテ失敗?

今後コメントとかをjob処理にしたい
処理のダイナミック化

7.4/1.8/512 1gb
es2.1/3.2g 1*2/4gb
diskarray
as2.1/3.2/*4/12GB/DiskArray
as4 (2.6.9) kernel2.6は速い!
2007/11 as4 mp3.3/1m*4 2core*4 16g

diskarray
fujitsu eternus8000 (速いらしい)
146GB/15krpm 32disk/RAID-10
fibrechannel 4gbps
snapshot

SixApartのほかに住商情報にも入ってもらってる。

ココログの話は非常に興味深かった。
あとで質問したかったのだが見つけることができず残念。
住商情報のブースがあったから聞きに行けばよかった。
つまり、なんで普通のレプリケーションをしないんだ、ということ。
PostgreSQLのレプリケーションソリューションは（少なくとも当時は）月間数億PVには絶えられなかったのかな？

MySQL Database replication
I/O Threadは動かしたままSQL Threadだけ止めてlogの読み込みだけ進めることもできる
(MySQL)Clusterはjoinの性能がでないのでWebよりテレコム向き
Full Text / InnoDB
検索リクエストでDOS攻撃的な状態になりうる

sun松信さん
innodbでは、主キーのindexに残りの列の値が入っている
secondary以降には主キーの値しか入っていないので主キーのが速いよ

multi column index が使われるケース。
Extra: Using index が速い話。これは実感済み。
using filesort については、sort_buffer_size以下ならディスクにはかれない。
と言うことは、rowsが少なければokなのかな？

IPA DBT-1がinnodbのcpu scaleが悪いと言っているが、ignore indexをつければscaleする。

innodbのauto incrementは5.0以前では一瞬table lockなので、
同時アクセス数が100とかだと急に遅くなってくる

DB以外の方法。
memcached (crash時にデータ消えるので注意)
q4m engine (mixi echo, pathtraq) q4m.31tools.com 遅延のためにmemcachedにも入れておくとか

長いデータのインデックス方法prefix index (index col(5))
hash columnをindexに。( where hash = CRC32('http://ww') and url = '...' )

memoryは=検索しか出来ない
create table working_table (c1 int, index using btree(c1)) engine=memory;
とすれば良いが、memoryだから・・・

開発サーバーでデータに偏りがあるとキャッシュされてしまうので
ユーザー10人とか、商品一種類しか買わないとかだと、あとで困るよ

昇順insertの効果について。

抽選は途中まで見ていたのですが、残念ながらその時までには当たらずでした。
後であたまソフトさんがサーバー当てていたらショックです。

以上乱文失礼しました。読みづらかったら、他の方のエントリーもどうぞ。私の出ていないセッションのご報告もありますし。
アメブロの件。ニフティよりよっぽどがんばって見える
複数エントリーあります
Performance Tuningなど
プロトコルの件とか
トラブルシューティングとか
はてなブックマークタグ「mysql」を含む新着エントリー