KVS再考

KVS

前日の日記に続き、KVSについて、もう少し考えてみることにしました。
KVSは、これまで登場したDBMSと比べると管理システム（Management System）を持たない分、機能縮退しています。では、なぜ機能縮退したKVSが価値を持ちはじめたのか？
これについては次の2点が考えられます。

  • KVSには暗黙の了解として、高速処理に加え、高いスケーラビリティと可用性を持つシステムが想定される。
  • DBのように固定したスキーマを持たない。key-valueのvalue部にはアプリケーションが自由にスキーマを設定できる。

後者から、KVSは機能縮退したのではなく、DBMSが2層に分割され、下層が独立したものと見ることができます。下層は、型（スキーマ）付けされる前のバイナリー値を扱うためのシステムで、これはユーザが自由に型付け可能であることを示しています。しかし、これだけではKVSの説明として不十分です。スタンドアローンなシステムでは、スキーマ設定はDBMSがやってくれていたからです。
これについては利用要件の変化が考えられます。以下が新しく出てきた利用要件です。

  1. KVSを占有するが複雑なスキーマ設定が不要な場合。
  2. KVSを占有し、scale outが求められる場合。この場合、scale outを阻害するDBMSは選択から外れる。1のような利用形態が多い。
  3. KVSを大多数のユーザで共有する場合。大多数のユーザに提供するKVSには、scale outと高可能性が求められる。また、KVSの各key-valueを再利用させるためにはスキーマを固定的に割り付けることはできない。

1だけのケースは例外と考えて、KVSがDBMSのManagement Systemをはずした状態で価値を持つためには、scale outと高可能性は必須の条件になると考えられます。

先にも書きましたが、KVS（key-value store）という言葉には、key-valueの組を格納する入れ物としての意味しかありません。拡大解釈すると、アドレスを使って値の読み書きができるメモリやディスク装置などもKVSと呼ぶことができます。このままだと、KVSという言葉が必要以上に広く使われてしまう恐れがあります。上での考察を元にすると、KVSは以下の文脈で使用されるべきと言えそうです。

  • DBMSの下層を機能として切り出したもの。アプリケーションがスキーマを設定して使用する前提。
  • scale outと高可能性を備える。


KVSについてTwitterで盛り上がった後、日経BP社の中田さんから、Cassandraは、"A highly scalable, eventually consistent, distributed, structured key-value store" だよ、と教えていただきました。修辞句はいろいろつくとして（私には冗長に見えますがw）、こういう使われ方が一般的なんでしょうね。

Bigtableの場合

Bigtableの場合ですが、これは、提供される表に対して、ユーザがスキーマを設定してアクセスできる、という機能が用意されています。次の2点が純粋なKVSと異なるところで、KVSの発展形と見ることができます。

Google Bigtableに限らず、Amazon SimpleDB, Windows Azure Tableも同様な形態になっています。クラウドの商用サービスはこの形態に固まるのではないかと考えています。これをKVSと呼ぶかどうかは、まだ？ですが。。

関連資料

KVSについて理解を深めるためには、次の資料も参考にされるとよいと思います。

KVSの定義とDBMSの再レイアリング

KVS NoSQL

気がついたら、KVSの定義から始まって、NoSQLの自然なニーズ、そして、DBMSの再レイアリングの必要性についてつぶやいてました。

    • -
  • 某所で、 BigTableはKVSか議論勃発なう。私個人はvalueを入れる箱があって、それに対してkeyを介したアクセスが可能ならKVSでいいと思っている。箱を2次元に構成できるのがBigTableで、key指定に範囲が使えるのがSkip Graphを応用したもの。
  • valueを入れる箱同士の関係を定義したり、整合性を保証したりするのはKVSの上位概念かと。箱を表形式に編成し、関係を決めているのがRDBで、それに従い整合性を保証するための手段としてトランザクションがある。
  • NoSQLが出てきたのは自然な流れだと思います。KVSが登場する前からそのニーズはとても高かった。1990年代に登場したオブジェクト指向DBやその後続くXMLDBはNoSQLの前身のようなもの。
  • SQLを使ってて困るのは、DB層より上のデザイン（通常はオブジェクト指向デザイン）とDBそのもののデザイン（ERD）のギャップ（セマンティックギャップと呼んでました）。トランザクションを必要としないケースでもRDBを使っていた。
  • SQLが有用なのは、データスキーマが表形式に決まる定型的な業務システム。厳格なデータスキーマの元には表間の関係があり、トランザクションにより関係の整合性を保つことが必須の条件となる。
  • 情報システムには護りのシステムと攻めのシステムの2種類がある。顧客や商品データを扱うような基幹業務システムが前者で、Webを活用し、サービスを多方面に展開するシステムが後者。SQLは前者に向いたが、後者には向かない。
  • RDBスキーマが向かない攻めのシステムでも実際にはRDBMSが使われていた。しかも、ほとんどKVSとして。それは選択肢がこれしかなかったため。考えてみればとてもロスの多い話だ。
  • システムにおける一貫性および耐障害性の保証はシステム実装者にとってとても頭の痛い課題。RDBMSはこの部分を担うことで価値を高めてきた。（2フェーズコミット、リプリケーション管理、バッチ処理を運用中に行うなど）
  • RDBMSが維持してきたこの付加価値を脅かすものとして出てきたのがscale outという概念。実用的なKVSの登場により、DBMSが内包していた一貫性と耐障害性について、scale out前提の基盤の上で捉え直す必要が出てきた。
  • KVSの登場を契機に、RDBMSの分解と一歩進んだDBMSへの再構成（再レイヤリング）が行われようとしていることを感じる。
    • -

(追記) KVSの定義について
その後、kazunori_279さんより、Google App Engine - How Entities and Indexes are Stored に "Bigtable, a large, distributed key-value store" の記載があることを教えてもらいました。でも、Bigtableの持つ表としてスキーマはKVSをやっている人達には受け入れにくいようにも感じます。例によって用語の定義は定まらない予感が...

スキーマレスかどうかは意見の分かれるところではありますが、KVSが技術用語として生まれた背景を考えると、分散形態であること、それによるscale out、冗長構成を使った高可用性の3つはKVSを特徴付ける性質であると思います。けれど、KVS（key-value store）という用語からは、分散もスケーラビリティも可用性も読み取れません。用語が一人歩きすると、そのままの意味で使われることになるだろうとも思います。（うーん）
あと、KVSがKVDBやKVDBMSと呼ばれなかったことも用語の定義を探る鍵になると考えています。
これ以上は偉い人に...

Windows Azureの本気

workshop cloud

クラウド研究会（プライベート研究会なので公開URLはありません。m(__)m）で、Windows Azureの動向について勉強してきました。以下はAzureについてのつぶやきです。

    • -
  • 昨日のクラウド研究会では、Azureを通してMSの本気を感じました。SQL Azure, PLINQによる互換路線と社内および複数のDCを連携させるAppFabric。まさに全方位戦略。
  • Googleの形がインフラと一体化したクラウドで、thinクライアント（ブラウザ）からアクセスする形態を前提にしているのに対して、MSのAzureはエンドユーザのシステムが対等にクラウドサービスと連携することが前提になっている。つまり、インタークラウドを想定したシステム
  • しかもAzureのKVSはGoogle、Amazonよりもスケールアウト性が高い。Consistent Hashingからより分散化を進めたDHTを採用している。
  • これだけやってもMSは勝ちを手中にできたと思っていないだろうね。後から追いかける者のつらいところ。逆にそれだから本気が見える。水面下では耐障害性の問題や手続き型から関数型への移行パスやエンジンの置き換えとかやっかいな問題と戦わないといけない。
  • .@maruyama097先生の受け売りですが、クラウドについてあーでもないこーでもないとか言ってますが、クラウドを契機に技術が変化し、企業システムといえどシステムの構築形態が分散の方向に移行していることに目を向ける必要があります。
  • Azureが用意している分散のための機構を見ていると不連続な変化を強く感じますね。企業はそう簡単にSLAのないパブリッククラウドにはいかないよ、なんて悠長なこと言ってると本質的な流れを見失いますよ。
  • 釈然としませんか。私は関数型というより宣言型であることが重要と思ってます。副作用によって計算が進むモデルでは分散並行は大変なので変えたいということ。RT @kumagi: そもそも分散環境を使い倒すには関数型言語しかない、みたいな流れになること自体が釈然としない。ソースコードから

Go

lang

GoogleのGo言語についてつぶやいてみました。

本家：The Go Programming Language
＠IT：グーグル、C／C++に代わる新言語「Go」をOSSで公開

    • -
  • 軽くGo言語のspecをなめてみた。なんでもアリアリのD言語と比べるとだいぶスリム。配列の扱いに工夫があって、D言語同様にstringを組み込み型に入れている。
  • 面白いのは並行処理。たぶん実装はthread じゃなくてcoroutine。goroutineなんて呼んでいる。threadよりはスタック消費の面で軽量。plan9のCコンパイラでは、 segmented stackが扱えるそうで、plan9との親和性は高そう。
  • 一応、オブジェクト指向。でもinterfaceしかない。抽象型だけ入れてある感じ。coroutineといい、私にはModula-2に見える。
  • 関数が複数の値を返せるのにびっくり。これほしかった。func f() (i int, j int); v1, v2 = f();
  • generic typesもないし、exceptionも扱えません。性能上の理由があるらしい。性能命のGoogleの姿勢が見える。
  • operator overloadingがないのは当然として、method overloadingもありません。
  • Go言語、do/while文もない。どうしてるかは、ドキュメント参照。
  • Windowsに載っける気はさらさらないらしい。LLVMで動かす気もないみたい。遅くなるのがいやだと。さすがGoogleさま。"it was too large and slow to meet our performance goals."
    • -

（追記）
GoのGCは、Recycler algorithm といい、Javaで培われた技術とのこと。

  • David F. Bacon, Clement R. Attanasio, Han B. Lee, V.T. Rajan, and Stephen E. Smith,
    "Java without the Coffee Breaks: A Non-intrusive Multiprocessor Garbage Collector," ACM SIGPLAN PLDI'01, May 2001. （pdf, ppt）

Mac OS X Java6 の src.jar のありか

Mac java

Leopard の初期インストール状態で、Java5が使えるようになっていて、Eclipse から Javaクラスライブラリのソースコードも確認できるのですが、Java6（64bit）に切り替えるとソースコードの確認ができなくなります。
これは、/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home 配下にはsrc.jarが置かれているのに対し、/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home 配下にsrc.jarが置かれていないことが原因です。

解決方法は2つあります。


後者の手順は次のようになります。ADC Member Site に会員登録している必要があります。

  1. ADC Member Site に入る。
    Mac Dev Center のページから、"Mac Developer Program"の下に見える"Member Site"をクリックし、loginする。
  2. Downloads > Java とクリックを進め、Java関係資料のダウンロードページに入る。
  3. Java for Mac OS X 10.5 Update 4 Developer Documentation （dmgファイル）をダウンロードし、インストールする。

現時点で、Update 5 が最新なのですが、インストールに失敗しました。含まれるファイル構成は Update 4 と同じなので、これで十分と思います。このインストールによって、1.4.2, 1.5.0, 1.6.0 のJavaの各バージョンのdocs.jar, appledocs.jar, src.jar がそれぞれのJavaVMのHome配下に置かれます。尚、Update 2, Update 4, Update 5 は、1.4.2, 1.5.0, 1.6.0 のjarを含んでいるのに対し、Update 1 は、1.6.0 のみとなっています。


せっかく、docs.jar も入手できたので、Eclipseに外部Javadocとしてセットする方法も書いておきます。SunのJava APIサイトを外部Javadocとして利用する場合は必要ありません。

  1. Preference > Java > Installed JREs で、"JVM1.6.0" の行をダブルクリック。
  2. 該当するライブラリのリストをすべて選択して、Javadoc Location ボタンを押す。
  3. Javadoc in archive をチェックして、External file がチェックされている状態で、以下を入力
    • Archive path:に /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home/docs.jar をセット
    • Path within archive: に docs/api をセット
  4. 参照する場合は、参照したいクラス名やメソッド名にカーソルを置き shift-F2 を押す。


ところで、ADC Member Site に置かれている Java for Mac OS X 10.5 Documentation の方には次の3つのドキュメントが含まれています。Xcodeを使う場合はこちらもインストールしておくとよいでしょう。

  • Java Reference Library
  • Java 1.4 Reference Library
  • J2SE 5.0 Reference Library
    • -

（09/09/28記）せっかく探した src.jarですが、Snow Leopard だと最初から入っているとのことです。ということで、一番簡単な方法は、Snow Leopard にアップグレードする、でした。orz

Mac miniを8GBにする

Mac

river24さんから情報いただいたのがきっかけで調べてみました。元情報はこちら（Mac mini でメモリ8GB）。

まとめるとこんな感じ：


この際ちょっと古い Mac mini（Mid 2007版）も、と思ったのですが関係なさそう。でも、この機種はファームウェア・アップデートと関係なく増設可能のようです。

Mac全機種の最大メモリについてはこちら（デスクトップ、ノートブック）によくまとめられていまして、Mac mini (Mid 2007) は3GBまでいけるみたいです。Mac mini (Early 2009) で余るだろうメモリ（DDR3 SODIMM）が使えないのは残念ですが。

実行は、落ち着いてからにしようと思います。

Mac Java のディレクトリ構成

Mac java

Mac OS X において、Javaの関係ファイルがどのように管理されているかについては、次のページに詳しく書かれています。先の記事と併せてご参照ください。

Mac Java の複雑な階層構成のまとめと管理
http://apribase.net/images/2008/2008111601-lightbox.png