#scalive で海未ちゃんのステマをしてきた
Scalive # 1.414 @ 西麻布ベース - connpass
という勉強会の体を装った肉会で海未ちゃんについて話してきました。とりあえず生ハムとかピザ食べながらビール飲んでダラダラやる最高にクールな勉強会で良かったです。開催、場所を提供してくださった皆様ありがとうございました。
発表資料
会場の様子
社内LT大会でMySQLのスケールについて話してきた
最近月1で社内LT大会をやっている。酒を飲みながらワイワイやる感じ。
最初は個別に声がけして発表者を集めたりしたけど、今回は募集かけたら10名ほどLT枠が集まったので市民権得てきたかなという感じでとても良い。
今回は第2回でMySQLのスケールについて話してきた。ちなみに前回は社内プロダクトとかのオフレコっぽい話をしたので資料は公開してない。
MySQLで高トラフィックに立ち向かう // Speaker Deck
所感
- 普段話さない人の発表を聴けて普段考えていることなど見えてくるので良い
- 前回は前の人のLT聴きながら資料作るというワイルドな感じになってしまい、今回も当日に資料出来たてほやほやで発表したので次回は前日までに資料用意しておきたい
あけましておめでとうございます
新年あけましておめでとうございます!
昨年は大変お世話になりました。今年もよろしくお願いします。
めでたさをプラスするために10分くらいで干支を描きました。
以下新年の抱負です。
積ん読を無くす
技術書30冊くらい積んでるので全部読みたい。
月1以上ブログ書く
2014年はポスト数6しかなく2ヶ月に1本ペースだったので、今年は最低でも月1ペースで書いていきたい。
外で発表する
2014年は内/外向け含めて社内で開催した勉強会では話したんだけど、外では話さなかったので何か話したい。
golangやる
2015年はgolangの年だと全俺の中で話題になっているのでやる。毎月5の付く日に勉強会したりする予定。
ただし本命はもちろんScalaちゃんです!!
数学と英語やる
数学はモナモナした言語とかの理解のために、英語はインプット/アウトプットの幅が広がるのでやる。
Droneで遊ぶ
面白そう
FPV Racing drone racing star wars style Pod racing are back! - YouTube
Scalaでgree/auroraを使って複数DB
この記事はScala Advent Calendar 2014の19日目です(遅れてしまってスミマセン…)。18日は ysksuzuki さんの Apache SparkのScala shellを試す - Qiita でした。
はじめに
先日 Rails複数DB Casual Talks - connpass が開かれるなど、複数DBの機運が高まっております。そこで今回はauroraというライブラリを使ってMySQLをシャーディングする例について書こうと思います。
auroraについて
GREEが公開しているJava/Scala向けのシャーディングライブラリです。Scala Matsuriで紹介されていました。 [ScalaMatsuri] グリー初のscalaプロダクト!チャットサービス公開までの苦労と工夫
設定ファイルに接続先のDBサーバの情報を書いておき、アプリケーション側からヒントを渡すことでそれに応じたデータソース/テーブル名を解決することが出来ます。
テーブル分割してみる
https://github.com/gree/aurora/blob/develop/README.md が充実しており、データソースをシャーディングする場合についてはそちらを参照してもらうのが早いかと思います。そのためここではREADMEで言及されていなかったテーブルをシャーディングする場合について見て行きたいと思います。
前提
以下のようにテーブルが準備されていることを想定します。ユーザIDの10で割った余剰に基づきテーブルを分割し、それぞれ異なるDB上に定義されています。
DBは2つ用意しており、DB1が 192.168.33.10:3306
、DB2が 192.168.33.10:3307
で稼働しています。
- DB構成
DBサーバ | DB名 | テーブル名 |
---|---|---|
DB1 | user | user_0 |
DB1 | user | user_1 |
DB1 | user | user_2 |
DB1 | user | user_3 |
DB1 | user | user_4 |
DB2 | user | user_5 |
DB2 | user | user_6 |
DB2 | user | user_7 |
DB2 | user | user_8 |
DB2 | user | user_9 |
- 各user_xテーブルの定義
mysql> desc user_0; +-------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-------+-------------+------+-----+---------+-------+ | id | int(11) | NO | PRI | NULL | | | name | varchar(45) | NO | | NULL | | +-------+-------------+------+-----+---------+-------+
- 投入されているデータ
INSERT INTO user.user_0 VALUES (1000, 'user_1000'); INSERT INTO user.user_5 VALUES (1055, 'user_1055');
設定ファイルの定義
テーブル用の定義は以下のようになります。
https://github.com/takashabe/aurora-sample/blob/master/conf/application.conf
- 抜粋
aurora { table-name-configs { patterns = [ "user_[0-9]" ] } }
リゾルバの追加
https://github.com/takashabe/aurora-sample/blob/master/src/main/scala/com/example/Main.scala#L37
テーブル名を解決するためのリゾルバです。これに目的のuser_idを渡せば、そのデータが入っているテーブル名を取得出来ます。
private val tableNameResolver = new AbstractTableNameResolver[Int]("user") { override protected def getSuffixName(userIdHint: Int): String = { "_" + "%d".format(userIdHint % 10) } } private val auroraTableNameService = AuroraTableNameService(tableNameResolver, new File("./conf/application.conf"))
リゾルバの利用
https://github.com/takashabe/aurora-sample/blob/master/src/main/scala/com/example/Main.scala#L46
val table = auroraTableNameService.resolveByHint(userId).get
リゾルバで取得したテーブルを println
すると以下の様な感じです。
TableName(name = user_1)
ユーザを引いてみる
https://github.com/takashabe/aurora-sample/blob/master/src/main/scala/com/example/Main.scala#L84
println(findByUserId(1000)) println(findByUserId(1055)) println(findByUserId(9999)) // 結果 Success(User(1000,user_1000)) Success(User(1055,user_1055)) Failure(java.io.IOException: entity is not found.)
まとめ
- 普段仕事でauroraの元?となったPHP向けの gree/cascade · GitHub を使っていますが、大体似たような感じで使えそう
- ライブラリ自体ではデータソースとテーブル名の解決を行っているだけなので、他のフレームワークやライブラリと併用する場合も楽そう
- ある程度以上の規模で利用する場合にはリゾルバ用のレイヤを1つ追加して、抽象化してあげると楽かなと思いました
- スケーラビリティは置いといて、複数DBしないのが一番楽だと思います
20日目は taketon_ さんの Finagleでサーバープログラミング です。
GitHubの良さについて喋ってきた
若手エンジニアが語る、GitHub社内活用勉強会 - connpass
こんな勉強会で業務でGibHub使ってて感じた良さとか喋って来ました。若手です。
発表資料
所感
- 懇親会でいつの間にかmasterに意図しない変更が取り込まれててリリースされてた〜、みたいな話を聞いてブランチ戦略大事だなぁと思うなどした
- よくgit-flow複雑だから初心者には辛いといった話を聞くけど、逆に慣れてないからmasterを安全に保ちたいといった場合には採用した方が良いなと考えている
- 何故かBitbucketを使っている方が割といらっしゃって、その辺りの知見を得られたりして良かった
- 最近はBitbucketでもGitもプルリクも使えるしアリなのかなーって感じだけど、GitHubと比べてどちらにすべきかというのが良く分かってない。課金体系の違い(リポジトリ数かアカウント数か)があるので、組織体制に合わせて合った方を選択するというのも良いかもしれない
- 喋る前にビール1本開けておくと緊張がほぐれて良い