BP Study22 memo

走り書き
scala/lift関係はtwitterで#BP22をどうぞ。

発表者：佐藤一憲(スティルハウス)
事実上フリー。

http://www.sth.co.jp


アジェンダ
ご都合ドットコム
GAEのサーバ構成とスケーラビリティ
BigtableとDatastore

おまけ
- Smalltable


tmatsuoさんが会場にいる。

GAEのすごいところ。
無償で使える。
bigtableが簡単に使える
サーバ構築不要、デプロイ簡単


GWにご都合どっとこむを作った。
2000UU


FLEXクライアント
GAE/J
BlazeDS <- AirとJavaをつなぐミドルウェア
ビジネスロジックのクラス
Entity クラス

５日間で作れた。設計・実装テスト・ドキュメント


BlazeDSを動かすには？
iMartinzoldano.blogstop.com 200904 appengine-adboe blazeds


ki
gaenogennjou
8万人以上がしよう

140M PV/day

GAEの特徴
スケーラブルなアプリを構築するための慣習を促すための制限
ここのリクエストが使える処理時間(30秒)とリソースは制限されている。
statelessが強要される
Datastoreによるパーティション化されたデータモデルの利用

スケーラビリティをもつクラスタ環境を利用できる。
アプリ間の隔離性を維持。

使い手ががんばらなくていい。


GAE Stack の構成
[絵]

App Master
deploy managment,version managment


FrontEnd
HTTP req/res
clientにいちばん近いgoogle DCに到着
リクエストは10MBまで
コンテンツは、スタティックとダイナミックは別途ハンドルされる。

App Server
隔離性


APIのサーバ、DataStore Memcache, Mail, URL Fetch, Image, Taskqueue, Users, XMPP(To be added)

Queueはparallelに処理することもできる。workerしだい。


Client VM

App Server
Stateless, fieldをもてない。
make distributed and fail over easy.

session info are shared in DataStore
need to clean up with cron or TaskQueue

state
maybe we can put it into memcache. they will spill (LRU) or expire.
memcache is coherent cache, not storage.


API Proxy ThreadLocal
API callをフックしている。

30<


Dependency Injection
Aspect J Sprint AOP

Web frameworks
google web toolkit, tapestry, Blaze DS(Flex)
Grails

Alternate JVM Lang


GAE Scale out
On High load longed around 50min, new App server will be added.
even very light weighted app are distributed in 2 or 3 instances

There are safety limit. Ask for unlimit


Open For Questions
google moderator.
100k questions 3.6 million
700 queries per second

out of box GAE google has no work for it.

around deadline there are 700 submissions/second.
(queries to datastore)

Java. vs. Python
not big difference

No comet, no steaming

Bigtable

distributed datastore for structure data
able to handle PByte.

7manyear to build it.
production from 2005

Google uses more than 60

distributed multi dimension sorted map.
each cell is versioned, but not used in datastore.

bigtable is HUUUGe key-value store

kys are sorted in dictinary order

single low is atomically changed.
multi lows are not atomically changed.


key based crud
key based scan(prefix or/adn range)
they are sorted.

value based can NOT be done.

bigtqble cluster:
388 cluster
24500 tablet server(slave)


shceduler master
chubby (distributed lock server)
GFS master
bigtable master


Tablet 100~200MB
single server hold 100 tablets
they are replicated

bigtable master controls load balance among tablet server.


it is like DNS hiarchy
chubby file -> root tablet -> Meta data tablet -> tablet

they are cached, in ave 100ms < to find tablet

memcache -> commit log
||
\/
cache (mem table)
||
\/
SSTable (on disk, GFS)

on dist data are sorted immutable map
major compaction, GC.

GFS
more than 2 server folds (replication)
local GFS chunk server + non local lack.


Why need to have counter?


What is Datastore?
GAEにおけるデータ保存用API、ビッグテーブルで保存
エンティティグループ単位でACID
クエリ　JDOQLまたはGQL

GAE/JでのAPI
JDO 永続化API (一番ドキュメントされている
JPA ORMなAPI
低水準API (Java doc only) Performanceがほしいとき使う。
JDOだとbatchのputができない(matsuo)

DataNucleausベース

PersisitenceManagerをcloses

kind
entity
propery
key


entity table
read/write with key
entity has property(s)
properys are serialized in single column



キー
アプリID、パス、エンティティID

パス
entity group のルートエンティティまでのパス

/Grandparent:Alice/Parent:Sam
~~~~~~~~~~~~
kind

protocol bufferでserializeされている。

property
entityごとにpropertyがもてる。schema less
entityごとに

クエリ
name="Foo"
とすると、プロパティ内にマッチするものがあればヒットする。

max 1000items to retrieve

range requestして1200-1500はできない。
1200番目がわからない。

1000番目のkeyを覚えておいて、そこから1000個とるとか。
先にproperty上に連番を振ってしまう。


python pagingではuserland paging できる

100件ずつ表示では100+1とってくる。
1は次のhead keyにつかう。

user landのpropertyでは注意が必要。
#キーとproperty

query is implemented with index and scan
need to create index on property


query つかったら負け？
crudがおそくなる。リストプロパティは要注意

index explosion
list with 1000item in property
query にlistが含まれているとだめ。

5000 index per entity (quota)


composit index.


entity group and transaction

entity has hiarchy. this hiarchy is NOT class hiarchy.

JDO "owned" relation <-- not eq --> Relation(RDB)


CAP theorem
Consistency
Availablity
Partition

optimistic lock
time stamp based check

in race
auto matic retry(python)
Java : user must implement it for loop


make small entity group
... lock size

a. message index root entity
b. timestamp + userid + message hash etc.

Entity
Entity update : 1~ 10 times/sec

distributed entity group

no table join
de normalize , prejoin them

no aggrigation function.
there is no group by, count, max, min,

function, stored proceedure.

no full text search
pre-process text


big application.
open social
buddy poker
giftal?


だめだということはない。