[2015-03-24 18:50]
潜入。キリンのやわらか天然水をいただく。椅子はプラスチックの一体成形だが低反発クッション付き。
[2015-03-24 18:59]
amazon コジマサン 挨拶
[2015-03-24 19:01]
- モノリシック: SQL-transaction-caching-logging
- scale outしない
- 1970年代とはちがった設計になるはず
- サービス指向・マルチテナント(まずストレージレイヤで)・MySQL5.6互換
- Aurora: HDD版はないSSDのみ
- 再起動してもキャッシュは生きたまま
- read only レプリカ
- メモリは244GBつかえるのでキャッシュに載る
- 100msでレプリカ更新
- データベースをクラウド上のサービスの結合として再構築
- OSのファイルシステムとデータベースはちがう。OSのファイルシステムは歴史的なもの。
- amazon RDSはモノリシックな構成。
- shared nothingではない
- レプリケーションはlog-structuredを拡張して実現しているのではないか？
- レプリカからプライマリへの昇格は1分くらい
- AZまたいでPrimaryInstanceがReplicaに自動的にwriteすることはないのではないか？
- GFS, MSAzure, MegaStore
- Quorumを満すようにAZまたいでコピーするだけか？
- セグメントは10GB単位でオートスケーリング (25年前の論文ではセグメントサイズは512KBだった)
[2015-03-24 19:51]
休憩
[2015-03-24 20:03]
- log-structured file system: 大量のキャッシュとSSD.
- LFS: 発表1988年、実装1991年。
- 大きなキャッシュがあればreadは遅くてもok、writeもバッファリングしちゃえ
- ffsではディスクの5%しか帯域をつかえてない。同期書き込みのせい
- Directory change log: logの中にlog! refcount管理用。
- auroraでGCはどうなってるか不明。セグメントサイズ10GBだし。
- GC: threading log(compactionなし)とcopy and compact
- sprite lfsではcheckpoint書き込み後にroll-forwardでセグメントをスキャンして書き込みそこねたのを更新。
- LFSをつかえばロックが不要になる(整合性が維持されるため)
- writeをoptimistic concurrencyでつかう。データのポインタが変更されてなければ書き換え成功。
- BigTableもlog-structuredになっている(tablet log)。
- log書いたらmemtable更新。memtableが溢れたらSSTableを書く。SSTableもmemtableもソート済なのでマージは高速。
- LevelDBも似てる(log structured merge trees)
- facebook: real-time analytics system: WAL。tailingアーキテクチャ。ログは後ろから処理される。
- SSDもlfsとおなじような構造をもっている。
[2015-03-24 20:59]
質疑応答の時間はなく。
シャレオツなロビーで菓子パンでも食おうとおもったら飲食禁止だった。
帰りの行人坂がきつい。
目黒駅で。
写真とりながらちんたら帰ってきたので、相模線25分待ちトラップ。
