札幌Java Conference2012 - 午前中

札幌Java Conference2012 - 午前中

2012/11/17に開催された札幌 Java Conference 2012 に参加してきましたのでその忘備録の午前中分です。

Lambda への道（桜庭さん）
つくって学ぶデータベース〜まずスモールデータからはじめよう（きしださん）

@skrb 桜庭さん - Lambda への道

Java SE8で追加される予定のラムダ式自体の紹介＋ラムダ式が入った経緯とその真価についての話でした！

ついにJavaにもfilter, map, reduceが入るのかー。最近の流れに乗ってる感じ！

なぜラムダ
クロージャがなぜなくなったか
ラムダ式、APIの話

自己紹介あった

Java in the Box
連載もってるよ ÏTPro java技術最前線

Lambda のバックグラウンド

クロージャを2005年に開始、Java7で検討するぜー発言
仕様が2006年に出た - BGGA

この時点では本物のクロージャだった
・・・大激論！
Gafter と Joshua Block の間で決別
ちなみにJoshuaはGoogleでDARTを作っているらしい
2008まで収集がつかなかった

JavaのリードのReinholdがクロージャの中止を宣言
2009年にProject Lambdaとして復活

7に間に合わなくて8に入ることになった
何故復活した

何故Lambdaは復活した？

目的があった

時代はマルチコア
2000年代後半にマルチコアになってきた
Fine Grained Parallelism

小さいタスクをパラレルに動かしたい

大きいタスクの並列化は無駄が多い
CPU の遊んでる時間を使うには小さいタスクが望ましい

SE7 の fork/join frameworkで実は実現できている
でも使い所がない

Iterator で使えるといいよね！

できればループの一つひとつをパラレルにやりたい
従来のJava は for 文による外部イテレーター
forEachによる内部イテレーターを使って並列処理したい

外部とのやり取りがなければ独立してる
でも以前だと書きづらかった
そこでLambdaですよ

Lambda

lambdaはFunctionalInterfaceを表すためのものになった

実装すべきメソッドが１つだけのインターフェース
実はComparatorもFunctional

equalsはObjectが実装を持っている
compareだけを実装すれば良い

関数型インターフェースを実装した無名クラスのインスタンしエーション記法

(引数, 引数) -> { 処理 }
引数の型は省略可能

SE7からのダイヤモンド演算子を使って実装

処理が1行であれば波括弧と return を省略可能

（ここまで来るとかなり関数型っぽい）
（というか Scala っぽい）

引数が1つであれば、丸括弧も省略可能
でも Clojure ではない

レキシカルスコープを持っていない

新しいスコープを持たないという条件が必要

なのでJavaはクロージャではない

Effectively final（見なしfinal）が導入された

実質的に代入していなければ final とみなしてくれる
（これ、混乱しそう・・・）

Default Methood が追加された

abstract のフィールドなし版みたいな感じ
IterableにforEachを追加したときにdefaultにしておくと全クラスに影響が及ばない

APIをいじりやすくなった

でも実はforEachはまだ並列に処理してくれない
Streamインターフェースが追加された

filter, sorted, map, reduce が追加された
Stream といいつつ Collection
このあたりが使えるとlambdaの意義が出てくる
（かなり関数型寄りな感じ！）

Collection#parallel メソッドを使うと並列化して実行してくれる！

（すげー！）

Developer Preview 見れるよ！

@kis きしだなおきさん - 作って学ぶデータベース〜まずスモールデータから始めよう

きしださんがデータベースをJavaで実装してみたよーって話でした！詳しいことはご自身のブログに書かれているっぽいです。すげい

（資料が手書きだ！すごい！）

"みんなデータベースとかひとつくらい実装してるじゃないですかw"

"みんなPostgresとかソース読んでるじゃないですかw"

きしだなおきさん
「きしだ」でぐぐって一番上
福岡のフリーランスの方

きょうのはなし

RDBてきなものを作った
楽しかった
みんなつくってみるといいですよ

スモールデータ時代の到来

ビッグデータの流行

ひとつのデータを確実に扱えるようにするのが大事
スモールデータに注目

10日かけて作った

（なんか野望みたいなところがあったのだろうか？）

1日目 - 3日目

1日目

リレーショナルモデルとリレーショナル演算
（IDEで使っている文字がかわいい）

2日目 - サブクエリと構造変更

1日目の構造を変更したらサブクエリができるようになった
Query - Relation - Table という構造にしてみた

3日目 - 頑張って実装したよ

4日目

4日目 - インデックス

山場
大きくツリーインデックスとハッシュインデックスがあるよね
JavaのHashMapとTreeMapを使うよ
IndexをRelationの一つとして定義した
B木を実装するのはつらいから後回し

5日目 - 集計処理でのインデックス
6日目 - 更新・削除

そんなに難しくなかった

7日目 - ユニオン

更新・削除までで満足感高かった
ユニオンは利用者としては使わないけどDBは使いまくっている

8日目 - insert時のトランザクション

トランザクションを実装するのが目的だった

9日目 - MVCC トランザクション

マルチバージョン同時実行制御

データにバージョン番号をつける
今実行している環境（コンテキスト）が必要
古い更新データの保存

見えるデータだけ見せる

データを更新している人以外の人から見えるデータも必要

10日目 - 隔離レベル（分離レベルとも呼ばれたような）

めんどくさそうって思った
いままでわからなかった隔離レベルがわかった

これからつくるもの

"ぼくのかんがえる最強のデータベース"
ストレージとログ

WAL（Write ahead log）をやってみたい

クエリと実行計画

パーサーをどうするか

JavaCCとかめんどい
scala で書くか、簡単なPEGパーサーを作る？

実行時最適化
Join 戦略

ネストループ結合とかインデックス結合とかソートマージ結合
実は20とか30とか戦略はある

実行計画の作成

複数の戦略が使えるときにどうするか
ルールベースとコストベース
コストベースは実はルールベースを含んでいる

JDBC対応

めんどくさそう
並列実行が必要、今は並行実行なのでロックが必要

ロック

書き込みロックはあったほうがいい

インデックスで必要
今のハッシュマップだと効率悪い
B木にしてやる必要がある

ブロックごとのアクセス、Diskと相性が良い

（インデックスにロックをかけるのにB木が必要だったのかー）

デッドロック検出

まじめにやるとロックグラフを作ってやる必要がある
単純な戦略だと10秒たったら解放というのがある

コメント