Cassandra

授業の方法では読み切れなかったので、Cassandra (Key Value Store)は、別に読んでいるんですが、こっちは、どちらかと言えば、古くさかった Hadoop / hdfs とは、かなり差がある。

Thread Pool Executor が多用されていて、様々な段階が Blocking Queue でパイプラインステージ化されているらしいです。Java Concurreny 本を忠実にやっている感じ。

Bigtable の論文とかに忠実に実装されているらしいんですが、実際の実装の中身は論文では読めないよね。

これは、全部読むのは大変そう。と言うか、今時のサーバは、こういう風に書かないとダメってわけね。

Sony にいた時に考えていたファイルシステムでも、「じゃぁ、まず、Multi thread scheme を作ってからにしよう」みたいな感じで始めていたので、それが Java になったような感じか。Scheme と Multi thead は絶望的に相性が悪いってのは、その時にわかったので、今のCbCをやってたりするわけですが。

Python のGIL (Global Intrpreter Lock)とかは意味的には簡単だし、Full continuation とかと両立させるには良いのだが、まぁ、マルチコアな今は時代遅れになりつつあるってところでしょうね。

Script 言語は、言語自体は遅いが、(サーバ)アプリケーション自体は高速に走るなんて言う話もあるんですが、Cassandra みたいなKVSで、Single Threaded な Script 言語ベースのアプリケーションが本当に早くなるかどうかは、全体の組み方によるんだろうな。

まだ、Cassandra は読み始めたばかりですが、授業でこれを読むのは無謀だったっぽい。ただ、本編は、まだ読んでないので、意外に読みやすい可能性もあるけど... Set は、ほとんどは 1 stage で終るっぽい。