Shibuya.pm#12 に行って来た。本物の宮川さんを見れた！（ミーハー）。難しくてわからないところがたくさんあったけど、刺激になった。また行きたい。
最近DB(Oracle)のお勉強しているので、「 NoSQL vs. NoKVS ライトニングディスカッション」が面白かった。特定の目的に特化したデータベースを自分で作られていて、すごいと思った。
以下、とても断片的で不正確なメモ。
特別講演
- 宮川達彦(id:miyagawa)さん - "Tatsumaki" I/O bound HTTP clients in web frameworks
- Tatsumaki at Shibuya.pm Tech Talks #12 - bulknews.typepad.com
- まず、PSGI/Plack がわかってない。
- Perl web applications と web servers のインタフェースってどういうことだろう？
- web server の上に PSGI という層をかぶせることで、WAF から web server の層を隠蔽するってことかな。
- 例えば、PSGI という層があることで、mod_perl で運用している Catalyst の Web アプリを CGI でも動かせるみたなことではないかと思う。
- そうであれば、とても便利だと思う。
- 世の中には mod_perl 使うほどトラフィックがないサイトがほとんどだと思うし、トラフィックが増えたときに Web アプリはそのままで、mod_perl に移行できたりするとステキ。
- PSGI/Plack の説明じゃないけど、以下の説明がとてもわかりやすかった。
HTTP::Engineは，RubyのRack，PythonのWSGIなどと同じように，CGI／mod_perlといったバックエンドの違いによるアプリケーションの実装の違いを吸収してくれるライブラリで，これを使用すると開発者はバックエンドの違いを意識することなくWebアプリケーションを開発することができます。
つまり，Arkアプリケーションは，同じコードでさまざまな環境で動作させることが可能です。
第1回 Arkって何だ？ ―Ark が生まれるまで：ついに出た！最新Perlフレームワーク「Ark」徹底解剖｜gihyo.jp … 技術評論社
-
- 次に Non-blocknig がわからない。
ノンブロッキング通信とは、データの送受信を行なう際に、送受信の完了を待たず、他の処理を開始する通信方法。並列処理の一種。
ノンブロッキング通信では、通信機器・プログラムが行なう実際の通信処理と並列に、通信が完了していなくとも可能な処理を進め、通信が完了していないとできない処理にたどりついた場合には、そこで通信の完了を待つことになる。これに対し、正常に送信できたかどうか通信の結果を待ち、通信が完全に完了してから残りの処理を行なう方式をブロッキング通信(ブロッキングモード)という。
通信相手との同期を取らない点では一種の非同期通信といえるが、いわゆる非同期通信が単に通信相手からの返事を待たない(同期を取らない)というニュアンスであるのに対し、ノンブロッキング通信では主に、通信処理の完了を待つことによって他の処理の進行を妨げないことを表わしている。
ノンブロッキング通信（ノンブロッキングモード）とは - IT用語辞典
-
- なるほど、処理の先行・後続関係をキメ細かく制御して、進めてよい処理はどんどん進めて、本当に待たないといけない処理だけ待つってことか。
- で、Non-Blocking をサポートしているフレームワークが Tatsumaki。
- Tatsumaki は Python のフレームワーク Tornado(Tornado Web Server — Tornado 5.1.1 documentation) にインスパイアされて作られた。
- I/O bound !CPU bound。そうか、WebサーバはCPUの処理がおいつかないというよりは、I/O待ちが多いから Non-Blocking なフレームワークを使うことで、効率的に処理され、結果的に高速になるのか。
- この図わかりやすい → Plack/PSGI Ecosystem - bulknews.typepad.com
NoSQL vs. NoKVS ライトニングディスカッション
- 平林幹雄(mikio)さん - Tokyo (Cabinet|Tyrant)
- たしか奥さんから「fsync してないという批判に対する反論などあれば聞かせて欲しい」の質問に対して、「ディスク故障ではfsyncしても無駄。電源を抜いたようなケースではデータロストが発生するが、fsync してるとハイトラフィックをさばけない。必要なら別のプロダクトを使ってください。」とのこと。
- 参考
- 山田浩之(id:mogwaing)さん - Lux IO 的な何か
- 鶴岡直也(halt)さん - 毎秒11万回更新できるのはRedisだけ
- 作る側ではなく、使う側として発表。
- ベンチマーク結果によると、Redis は速いらしい。
- Redis はインストールが簡単。
- 参考
- 古橋貞之(id:viver)さん - えとらぼで kumofs 作って運用してみた
- 小泉守義(id:moriyoshi)さん - golang で KVS 作ってみた
- 見ていて、go をいじってみたくなった。
- 参考
- 奥一穂(id:kazuhooku)さん - NoKVS な RDBMS sharding 作ってみた
- ベンチマークテストを行う時は、リモートホストから測定すべし。
- ホスト間の通信はTCPのバッファが有効に機能するため、ブロックサイズによる速度の変化はほぼないが、単一ホスト内でのTCP通信では送信プロセスがwrite(2)を呼ぶたびにコンテクストスイッチが発生するため、ブロックサイズが小さいとコンテクストスイッチが頻発してパフォーマンスが低下するとのこと。
- つまり、ホスト間のTCP通信ではデータを運ぶ箱のサイズが一定なので、アプリケーション送信するブロックサイズの違いによってパフォーマンスが変わることはないが、単一ホスト内でのTCP通信の場合はアプリケーションが送信するたびに実際に送信されるので、同じ量のデータを送信する場合でも、ブロックサイズが小さいと送信回数が多くなり、コンテクストスイッチの回数が多くなり、コンテクストスイッチのオーバーヘッドでパフォーマンスが低下するということだと思う。
- OSはTCPのバッファを使うかどうかはどうやって判断してるんだろ？ループバックインターフェース or not で判断してるとか？
- Incline & Pacific は OSS RDBMS を束ねてスケールアウトするためのもの。
- Pacific は高速・安全なシャード分割ツール。
- Incline
Incline は一言でいうと、RDBで構成されるshard群の上で read-only かつ eventually consistent な materialized view を実現するためのツールです。
Kazuho@Cybozu Labs: 高度に進化した分散データストアは RDBMS と見分けがつかない？ (shibuya.pm #12 スライド)
-
- てか shard ってなんだ？
shardは、かけらという意味
http://thinkmot.com/?p=84
正規化のようにカラムを分割するのではなく、レコードを意味のある形で複数のテーブルに分ける。Wikipediaの例ではUSカスタマーとEuropeカスタマーにテーブルを分割。
利点はテーブル行数が減少すること。これによりReindexingなどのロックを長時間保持する処理が短時間化される。これは私も実際に運用しているときに何とかならないかと考えていた点なので参考になる。大きなテーブルになると土日のダウンタイムだけではReindexingが終わらないときがある。また、複数DBサーバの分散環境におけるアクセス効率の向上も大きな利点。
- 斯波健徳(shiba)さん - Spider Storage Engine 作ってみた
- チームラボのストリーミングサイトで使われている。
- 参考
LT
- 松野徳大(id:tokuhirom)さん - Perl で Golang のような Channel を実装する方法
- そもそも「構文木って何？」ってレベルなので難しかったけど、面白かった。
- 参考
- 藤吾郎(id:gfx)さん - Metaprogramming in XS
- 「perly.yをハックしてブロック付きメソッド呼び出しを可能にする」というお話。
- なんかすごそうということだけわかったw
- 参考
- ゼットオオナミ(id:z.ohnami)さん - CouchDBで作る薄々レイヤーアプリケーション
う〜ん、浅せぇメモだ。
