ぶろぐ

日記です

お腹空いたー


オープンソースカンファレンス2011 沖縄に行ったきたぜ
OSC2011に
いやー沖縄までわざわざお越しいただき、ありがとうございます、という感じです。
一人でひっそりといって、ささっと帰ったのが私です。

感想

  • 会場が寒い
  • あ、知り合いいなくてもいけるや
  • 色々絡むとためになりそう
  • 自分から情報得に行かないと意味ないかも
  • ふ、黙っとけば情弱なのばれないぜ

って感じ。
タイムラインみてたらなんかやってるなーと思い、ふらっと行ってみた。

見たやつ

もっと話し聞けばよかったー

ぐおー

NetBSDの人たちが大好きすぎた。何あの人達面白い。
かなり突っ走った感じが。
ケータイの上でNetBSD動かすとか変態すぎる
そしてMySQLの人すげー
レベル高すぎて半分ぐらいしかわからなかったぞ。

内容

  • 5.5
    • マルチコア移行で激アツですよ
    • SysBenchっつーベンチツール使ってた
    • 同期レプリケーションは5.5からなのかな？
      • スレーブへレプリケートが完了してからトランザクション終了
      • んーレプリケーション組んだら、意外とスレーブ側でクエリエラー？が出そう（多分）あ、その時はエラーでトランザクション閉じてアラート出すのか。
      • スレーブは好きにマスターにデータ取りに行くイメージだけど、同期レプリケーション組んだ場合「すべてのスレーブにデータ行き渡ったよ」ということを感知する必要があると思うので、マスター側でスレーブの管理が必要なんじゃないかなーなんて思った。じゃあマスターの設定増えるのかな？
    • 遅延レプリケーションなるものがあるらしい。あるタイミングでスレーブが一度に差分を取りに行くのか、毎回クエリ受け取るけど実際のデータベースへのコミットは遅延させるよ、なのかどっちなのか気になった。
  • 5.6
    • 色々やってるよ☆
    • （メモってない）
  • MySQLクラスター
    • おいMySQLクラスターヤバい使えるレベルだぞ、Oracle RACじゃなくたって、MySQLだってクラスター組めるんだぜ！って感じがした。
    • MySQLがおもちゃ？この実例を見てハイパー高可用なのはわかるだろう。
  • memcachedとの絡み方
    • アプリケーション側でくもー
      • キャッシュあるならそれ使うー、無かったらDBアクセス＆キャッシュに登録ーって感じでー
      • まーDAO辺りにラッパーして書けば、大したコストには並んじゃろと思った
      • なんかORマッパーが勝手にやってくれるとか無いのかな 笑
      • memcached操作ライブラリは、memcachedの操作だけでこのへんのことはやってくれないよー
    • MySQL側でmemcachedと仲良くする
      • アプリケーションからは普通にSQLで操作する
      • MySQLがmemcached使う
        • なんかそういうMySQL関数を作る
        • トリガーをかます
        • MySQLを改造する（まじか
    • キャッシュはディスクI/O減らす、MySQLの負荷を減らす、って目的で。
      • データの一貫性を保つために、更新系のクエリを走らすときはmemcachedとDBの両方のデータを更新する（アプリケーションロジック(DAOに書くなおいらなら）で実装するのか、MySQL側で仕組みを作るのかは好きにでいいはず）
    • おいパーサーとかオプティマイザ通さずにストレージエンジン操作するぞ
      • これがMySQLのNoSQL化の肝だ
      • ストレージエンジンへのアプローチをもう一つ儲けようか、って感じにみれたよ
      • memcachedが更新されたら、ストレージエンジンも更新するよ
      • SQL以外のアプローチでストレージエンジンを操作する、とは面白い！

そんなしらないので用語の使い方とか意味とか履き違えているかも。信用しないでね☆

あ、あとあれだ。分散キャッシュサーバーっつーことで、サーバー複数でひとつのクラスターを形成するイメージを自分は持っているんだが、それどうやるんだ？memcachedロードバランサーとか管理サーバーとか聞いたこと無いぞ、と思ったらKeyのハッシュ値から格納先サーバーを算出するらしい。
なるほど。
んまーその処理はライブラリがやってくれているらしい。
多分ハッシュ値が1〜1000ならサーバーA,1001〜2000ならサーバーB、という感じだろう。うまく値が分散されるような、いいハッシュ関数じゃないとあれだな！
ということはサーバーリストが必要だな！稼働中にサーバー増やすことって出来るのかなー
いやーマジでメモリの代わりだ。メモリサーバー。メモリはシンプルな仕事しかしない。


あ、あと軽くレプリケーションの構成も話していた
双方向レプリケーションは、テーブルがかぶらないなら使ってもOK的な。
まーそうすればリソース節約になるしいいなー。
いざ止まったときに正常によゆーで稼働させたいなら、異常があってサーバーをフェールオーバーさせた後はリソース半分にななった状態で稼動し続けなければならなくなるので、やぱマスター・スレーブの一対一のレプリケーションがいいんじゃないかなーなんて思ったよん。
障害が起きても、最悪データが壊れなければいい、ならちょー気をつけて双方向レプリケーションもありかもしれない。でも、そんな構成にするなら、SQLのミス射撃があったとき弾くような仕組みがないと精神衛生上よくないなー。
テーブルAへの更新処理はユーザーAしかできない。
テーブルBへの更新処理はユーザーBしかできない。
A拠点のアプリケーションはユーザーAを使う。B拠点のアプリケーションはユーザーBを使う、みたいな感じでテーブルAへの更新処理はDB側で弾くような構成にしればいいのかな？絶対うんこプログラマ（俺）がミスる。そんな構成は嫌だ。俺が安心してクエリ投げれない。




うん、オープンソースエンジニアさんかっけーーーーーーーー！！！！！！

あとあれだ

NetBSDの人がちょーかっこいいこと言っていた。
メモってないから忘れたんだが、
「オープンソースの開発っていうのは、みんなとの協力が必要。ある機能をコミットするにしても、政治的な感じでみんで裏で（？）手をつないでコンセンサス取らないと行けない。そうしないと使ってもらえない。技術的な背景とかなんたらとかを知って、共通の言葉（用語）で話す、ということも大切だが、それ以上になぜ自分はこういう機能をコミットしたいのか、どう技術的に優れているのかをしっかりと説明できて、みんなに分かってもらわないといけない。しかも世界中にコミッタがいるオープンソースなら、英語で説明したりチャットで話しあったりしないといけない。
こういう技術が必要なんだが、せいぜい大学レベルではこういうことを教えない。どこかでこういう技術の習得が必要だ。だから何かオープンソースの開発に参加し、その力をつけることは今後の自分の力になるよ。
ソースコードを公開して、はいオープンソースでーす、そういうのもいい。でもみんなで話しあって作るのがオープンソースの楽しいところなんだ」
的な。ちょっとオレフィルター入っているかも。
なぬ、あの人作っている人なのか？
まじか、まじか。Geekはやっぱ本当にいい格好しないんだな。偉そうにもしていないし、威張ってもいない。
かっこよすぎだろ。

行ってよかった

こういう系の集まりって初めて参加するし、知っている人もいないし一人で行くの心細すぎる。
と思ったけど、言ったら実際楽しかった。
変態さんがいっぱいいた!笑
学生っぽい人多かったし、女性の方（かわいい）でMBA持参できている人とかもいた。
うん、こんな系行ってみよう次も。