KINGJIM デジタルメモ「ポメラ」
【Slim3 on Google App Engine/Java】
Google App Engine
- 新しいから良いというわけではないが、
- 今まで出来てたXXができないからだめ～ってのは老害じゃん？
- 制限は意味がある
- GAEはスケーラビリティを確保するため
slim3
- GAEに最適化されたフルスタックのフレームワーク
- ホワイトリストの機能だけを対象にしている
- 今までのは捨てて一から作りなおした
- less is more
- 無駄なものを根こそぎ落としていく
- その過程で本質がみえてくる
- DIとかもそぎ落とした
- Google Developer Dayの話
- 既存のRDBMSはでか(重)すぎる
- G社の人曰く、ただデータをいれたかったんだ
- JavaEEにあるようなフレームワークはでかすぎる
- ただWebアプリが作りたかったんだ
- TDD
- コントローラ作ったらテストクラスまで作って
- サーブレットもエミュレートできてテストが楽
- メモリ上でテスト(Googleが提供)のためBigTableまでいかなくてもてすとできる
- HOTリロード
- 再起動しないで確認できる
- タイプセーフクエリ
- 実行するまでエラーがわからないのが文字列ベースのGQLの開発
- GQLをタイプセーフにしたデモ
- コンパイラがエラーを教えてくれる
- MetaData
- Javaのコードをセーブしたときに自動でaptが動いて裏で生成
- タイプセーフを実現。# どゆこと？？
- BigTableはスキーマレス
- モデルのTDDが快適
デモ
- antでコントローラを自動生成
- ついでにJSPも自動生成される
- f:hでHTMLエスケープ
- テスト
- パラメータはparamってので突っ込んで
- レスポンスはrequestScopeってので取り出して
- 楽々アサートって感じ
まとめ
- シンプルでLess is more
- ホットデプロイ、Lessコンフィグ、Lessラーニング
感想
- 最近ちょこちょこGAEいじってて、生サーブレットとか書いてたのですが、
- こいつは熱い。何倍もサクサクやれそうです。
【事例発表1】
Seasar2の使用状況について
- 毎月1000ダウンロードくらい
- ヒト月100万PVくらい
- mlは5000人が登録
電通国際情報サービスにおける事例
- ほぼ昼寝の時間になってしまったが、
- 公門さんって人が出てきてから面白かった
- 数億のお金を取り扱うシステムの中身を垣間見れて
- 他システム連携が重要ってことで。
- が、Springでもノリだすと変わらないｗ
- 感想
- 自分も昔は数百人月の開発プロジェクトの基盤チームとかやってたけど、
- 大変だったもんなぁ、、なんていろいろ思い出しました。。
【45分で動かせるBuri/escafeFlow入門】
- Buriの本当の名前はescafeFlowっていうらしい
- 開発してる人でもescafeFlowって呼んでる人はいないらしい･･･
- ワークフローって言うと堅苦しい決まりがあるらしい
- ワークステートって呼んでるらしい
- xpdlってので、フローをかくらしい。XML。BPELとはまた違う。
- エディタ
- escafeflowエディタ
- 考え方
- if, フラグを減らす
- ループもwhere句も条件なんだからifだろう
- フローにだけ使う。
- バリデーションとかはその場その場で最適なの作ればいい
- テーブルにフラグがいらなくなる
- buriはburiでDB持つ
- シンプルな実装になる
【BigTable】
- Google的にはArrayとか呼んでるけど、HashMap的なもの
- HashMapって言ったらKey-Value
- Keyはソートされてる
- KeyはString。辞書式でソート
- 基本的にはKeyで引っ掛けて値を取得する感じ
- Key は Row と カラムグループ と timestampに
- Row
- イメージ通り
- カラムグループ
- デフォルトでアクセスするのと、たまにしかアクセスしないのと分けたり
- JDOではデフォルトカラムグループとして扱ってるらしい。
- timestamp
- 基本追記型っていうこと。
- Row
- データの格納方法
- 根っこはGFS
- SSTableがのっかってて、データとインデックスを保持。んでログも持ってる
- 毎回ディスクI/Oはキツイから、タブレットのmemtableっていうのメモリ上に保持
- データ増えてくるとタブレットを分割したり、複数サーバで扱ったり
- memtable上ではインデックスはソートされて保持さてるんじゃん？BTreeとかで
- アプリからの問い合わせはChubbyが受ける
- どのサーバにどのデータがあるかをタブレットサーバーで判別して、
- タブレット(メモリ)に問い合わせる
- メモリにもなかったら、仕方ないからGFS上のSSTableに問い合わせる
- 根っこはGFS
- Chubby
- ルートタブレットのIPアドレス
- タブレットサーバー
- どこに何のデータがあるのか？
- タブレット
- ある程度のデータのかたまり。100メガくらい。10～1000個くらいを1サーバで
- 1回の問い合わせで3段階(Chubby⇒タブレットサーバ⇒タブレット)
- SSTableへの書き込み
- SSTableはアプリからみるとReadOnly
- 書き込むのはマイナー/メジャーコンパクション
- マイナーコンパクションはREDOログがでかくなってきたら
- memtable⇒SSTableへ書き込んでログをクリア
- メジャーコンパクション
- スケジューラーなどで一定間隔でSStableへ書き込み
- アクセサビリティ
- 世界中どっからアクセスしてもKeyでのアクセスなら10ミリ秒くらいで返ってくるらしい
- データ保持
- こんな感じ
Parent:aaa
Parent:bbb
Parent:ccc/Child:aaa
Parent:ccc/Child:bbb
Parent:ddd/Child:aaa/GrandChild:aaa ←Entityグループ
- Entityグループ単位でしかトランザクションをかけられない
- 行がわかれちゃったらトランザクションかけられない
- Scan
- Prefix:Bだったら、B1,B2,B3がひっかかる
A
B1
B2
B3
C
- Range:B～Dだったら、B,C,Dがひっかかる
A
B
C
D
E
- Index
- Kind
- テーブル名。エンティティ。INSERTで作られる
- Single Property Index
- プロパティ(カラム)のインデックス
- INSERTする時に作られる
- デフォルトで全部のカラムにインデックス持ってる！
- 質問したら、細かい設定でインデックス作らないってのもやろうと思えばできるけど、
- プロパティごとにインデックスは持ってるのが前提
- 2つのプロパティをキーでの検索は2回クエリが流れてマージジョインって感じ
- データ取得後のソートとかはアプリでやる感じで
- スケールするための制限
- Composit
- war/datastore-index.xml ←のファイルに記載するらしい。
- GAEはインデックスが必要なのに存在しない場合は例外になるはずらしい
- Kind
- クエリ1回で1000行まで
- count(*)とかできないから、件数用のテーブルとか必要
- 非正規化を恐れるな！
- 自分の会社の人はまるで恐れてないので馴染みやすいかも。。。
- 感想
- すっげー色々とよくわかりました。
- Google社員の人で達人級の人が会場にいたら最高だったのになぁ。
【LT】
- NPOとは？
- 特定非営利活動 と 法人 にわかれる
- 特定の非営利活動は14種で非課税
- Seasarは国際貢献、高度情報、経済発展のためのってことで特定
- NPO社員(法律的に。要は会員)
- 著作権とか持ってる主体。入会拒否できない。
- 会費の大小で議決権の差はない
OSAC
- 地方自治体系
OBCI
- OSSプロダクトの評価でApacheに不満といってる人の他の選択肢をきいてみたい。。
S2コンフィグ
- 1.0リリースしたらしい
- 前のカンファの時いいなって思ってたやつ
- 来週使ってみようかな
—-
完全に今回はGoogleAppEngineネタが聞きたくて参加したのですが、
予想以上に収穫が多くて、行ってほんと良かったです。
久しぶりに前の会社で一緒にアーキテクチャチームやってた友人と会いました。
やっぱ嬉しいですね。そういうの。
コメント