HP WORLD Tokyo 2007に行ってきた

mysql

mixiの中の人がやる、MySQL Clusterの検証のセッションだけに行ってきた。


つーか、あまり面白くなかった。　あまり参考にはならんかった。


mixi内で検証したMySQL Clusterの報告ならばもっと良かったんだが、
なんか、HPから頼まれて、HPのサーバ使ってCluster構成作って、
やってみましたー、その報告ーって感じだった。


だいぶ駆け足的な内容で30分くらいで終了。


http://www-jp.mysql.com/products/database/cluster/
↑MySQL Clusterはココ。


まあ、いろいろ問題も多いみたい。


クエリを処理するSQLNodeはオンラインでのNode追加/削除は問題なく、16台程度追加が可能だとか。
データを蓄積するDataNodeのほうはオフラインで
Node追加/削除をやらなくてはいけないところがイケてないらしい。
64台まで増やせるらしい。


というわけで、Cluster適用箇所ってのは、

  • Cache的な利用
  • SQLのリソースが高めなとこ
  • DISK I/Oの高いとこ(これはインメモリだからという理由)
  • 消えてもそれほど支障のない箇所(インメモリなだけに揮発性が高いからという理由)

で、実際に考えれる箇所ってのは、

  • セッションDB(セッション値を保存しとくとこ)
  • ClusterをSlaveとして(詳細は失念)
  • メモリストレージ的利用（Cache的な利用、memcachedの代用）


システムの基幹部分でなく、短期保存的な部分になら、十分に導入可能だということだった。
めでたし、めでたし。


↓MySQL Clusterに関してはこの資料も参考になりそうだ。
http://www.scs.co.jp/mysql/docs/prezen_expo2006.pdf


で、講演終了後質問大会にて、
今、mixiはどのくらいのサーバが稼動しているの？という問いには、
「アプリケーションサーバが300〜400台。DBも同程度。全体で約1000台くらいが稼動している」
とのこと。


今回の検証はディスクのほうはやっていないのか？という問いには
「今回はメモリのみで検証した」
とのこと。
(MySQL Cluster 5.1からはメモリデータベースとディスクデータベースの双方が選択できる)


また、この検証はどのようなデータを使ってやったのか？という問いには、
「現在の日記と似たような構成のデータを作ってやって、同じクエリを発行して試した」
とのことだった。