ようこそ!浜村拓夫の世界へ

    ブログ内検索

    最近の記事

    ブックマーク数の多い記事

    Blog Translation

    Powered By FC2ブログ

    Powered By FC2ブログ
    ブログやるならFC2ブログ


    FC2ブログ LOGIN

    with Ajax Amazon

    ドキュメント指向データベース「CouchDB」

    このエントリーを含むはてなブックマーク はてなブックマーク - ドキュメント指向データベース「CouchDB」 あとで読む
    CouchDBというドキュメント指向データベースが紹介されていた。

    ドキュメント指向って何だろ?

    オブジェクト指向が、物事をオブジェクトとして扱うことを目指す技術であるとするならば、ドキュメント指向とは、物事をドキュメント(文章)として扱うことを目指す技術のことなのだろうか?
    データベースエンジニアのテキストには、出てこなかったような気がする。
    さっぱりイメージが湧かん。

    CouchDB を探る - IBM

    ●CouchDB とは何か
    ・「Couch」という言葉は「Cluster Of Unreliable Commodity Hardware」の頭字語。
    ・データの保存方法として、スキーマなしのドキュメント指向データベース・モデルと呼ばれる方法を採用。
    JavaScript ベースのビュー・モデルを使用。
    ・データへのアクセスには RESTful JSON (JavaScript Object Notation) API を使用。
    ・元々 C++ で作成されていたが、2008年4月、Erlang に移植された。
    ・Linux や Mac OS X に公式対応。Windows用の非公式なインストーラーも用意されている。

    プログラミングErlangプログラミングErlang
    (2008/02/23)
    Joe Armstrong

    商品詳細を見る


    ●ドキュメント指向データベースとリレーショナル・データベースとの違い
    ・ドキュメント指向データベースでは、ドキュメントに関するデータはすべて、そのドキュメント自体の中に保存される。
    ・ドキュメント指向データベースにはスキーマがなく、データベースを実際に使う前に厳密なスキーマを定義する必要がない。
    ・ドキュメント指向データベースでは、各ドキュメントが使用フィールドを定義することができます。

    ここでいう「ドキュメント」っていう単語の用法は、RDBでいうところのレコードに相当するものかな?
    =一意のデータ。
    ぶっちゃけ、XMLデータベースのデータ保存形式をJSONに変えたものがCouchDBっていうことなんだろうか?
    ・XML → モッサリ、遅い
    ・JSON → サクサク、速い
    というイメージで。

    ・オート・インクリメント機能やシーケンス機能がない。
    ・代わりに、すべてのドキュメントに UUID (Universally Unique Identifier: 汎用一意識別子) を割り当てる

    ドキュメント指向のデータベースが結合をサポートしていない点です。
    これは CouchDB には主キーも外部キーもないことによる結果です。
    結合の元となるキーがないのです。これは CouchDB データベースから相互に関連する一連のデータを取得することはできないという意味ではありません。
    ビューと呼ばれる機能を利用すると、実際にはデータベース自体の中で定義されていない任意の関係をドキュメント間に作成することができます。
    これはつまり、データベース・レイヤーの中で事前に関係を定義しなくても、典型的な SQL の結合クエリーの利点をすべて利用できるということです。



    ●CouchDB の動作
    B木によるストレージ・エンジンで構築されている。

    B木 - Wikipedia

    B木(びーき、B-tree)は、コンピュータサイエンスにおけるデータ構造、特に木構造の一つ。
    ブロック単位のランダムアクセスが可能な補助記憶装置(ハードディスクドライブなど)上に木構造を実装するのに適した構造として知られる。


    基本情報処理技術者の勉強で、アルゴリズムの話で出てきたやつかな?
    データベースの実装って、ツリー構造が使われてると。

    Map/Reduce を使用。
    ・並列処理のためのロック・メカニズムがない。
    ・代わりに、各クライアントにデータベースの最新スナップショットが与えられる MVCC (Multiversion Concurrency Control) と呼ばれる方法が使われている。
    =トランザクションがコミットされるまで、他のユーザーには何も変更されていないように見える。

    最近のデータベースには、MVCCという機能が使われているらしい。
    いろいろ工夫されているんだな。

    MVCC(多版型同時実行制御)

    データベースへの問い合わせ実行の際、各トランザクションは処理の基礎となっているデータの現在の状態を関知せず、現在から遡ったある時点におけるスナップショット(データベースバージョン)を参照する、というものです。
    これは、並行する(別の)トランザクションが同じ行を更新することによって引き起こる、整合性を欠いたデータの参照からトランザクションを保護し、個々のデータベースセッションに対してトランザクションの隔離を提供するものです。

    多版方式とロック方式との最大の相違点は、MVCCでは問い合わせ(読み込み)ロックの獲得と、書き込みロックの獲得が競合しないことです。
    したがって、読み込みは書き込みを絶対にブロックしませんし、書き込みも読み込みをブロックすることがありません。


    MVCCってのは、現在よりもちょっと前の時点で確定している状態(=スナップショット)のデータを利用する仕組みらしい。

    ・ロック方式 → マンガの編集者が、今描き直している最中の原稿が仕上がるのを待つ。
    ・MVCC方式 → マンガの編集者が、昨日までに描き終えている原稿をすぐ受取る。

    いちいち読み書きをロックして更新するより、速くて便利と。
    最新の状態じゃなくてもOK~細けえことは気にすんな!というのがMVCCだと思う。

    ●ドキュメント: CouchDB データベースを構成するブロック

    CouchDB データベースのすべてのデータはドキュメントの中に保存され、各ドキュメントは任意の数のフィールドで構成されます。

    CouchDB ドキュメントが変更されると、その変更が実際に既存のドキュメントに加えられるのではなく、そのドキュメント全体の新しいバージョンが作成されます (新しいバージョンは「リビジョン」と呼ばれます)。



    新しいデータで次々と置き換えていく仕組み…この仕様は、変数の値を変更しないErlangで実装するのが最適というわけだろうか?

    ●ビュー: CouchDB から有用な情報を取得する

    リレーショナル・データベースの場合、普段使用するアプリケーションにとっては、厳密に定義されたテーブル間の関係が重要であり、その関係によってデータに意味を持たせます。
    ただし、ハイパフォーマンスが要求される場合にはマテリアライズド・ビューを作成することでデータを正規化されていない状態にします。
    ドキュメント指向のデータベースの場合、多くの点でこの逆を行います。
    つまりドキュメント指向のデータベースはデータをフラットなアドレス空間に保存します。
    これはまったく正規化されていない状態のデータ・ウェアハウスとほとんど同じです。
    そしてビュー・モデルを提供することでデータに構造を追加し、そのデータを集約することで有用な意味を持たせるのです。



    データを操作しやすい状態で溜め込んでおいて、データ同士のひも付けは使うときにやればOKと。

    MapReduce の概念を使ってクエリーを実行します。
    ビューの Map 関数はドキュメントを引数に取り、一連の計算を実行することで、ビューに表示するデータを判断します。
    ビューに Reduce 関数がある場合には Reduce 関数を使って結果を集約します。
    ビューには一連のキーと値が渡され、ビューはそれらを組み合わせて 1 つの値にします。



    MapReduceって、どんな仕組みなんだ?

    MapReduce - Wikipedia

    MapReduce(マップリデュース)はコンピューター機器のクラスター上で、巨大なデータセットに対し分散並列処理を行うのを支援する目的で、Googleによって考案されたソフトウェアフレームワーク。



    plaggerとMapReduce - YuichiTanakaの日記

    大量の分散したデータそれぞれにある処理を加え、その後に(必要に応じてフィルタリングしてから)それらを一つにまとめる、というプログラミングモデルの事

    MapReduceという手法はスケルトン並列プログラミングという、並列処理でよく使われる処理を抽象化してそれらを組み合わせる事で並列処理プログラムを簡単に作りましょう、という研究で以前から提案(というか既にあるものに名前を付けた?)されていたもの(の一部)と同じもの。



    MapReduce - Radium Software Development

    関数型プログラミングを会得しない限り, Google に強大なスケーラビリティをもたらしたアルゴリズム ― MapReduce を発明することはできないだろう。 -- Joel Spolsky

    MapReduce は Google 社の Jeffrey Dean らによって開発された分散処理のためのプログラミングモデルである。
    "MapReduce" という名称は,大規模データの処理を「map タスク」と「reduce タスク」の2段階から構成することに由来する。
    map タスクは,膨大な量の元データを分解し,必要な情報を抽出し,有用な形へと変換し出力する,いわゆる「フィルター」の役目を担う。
    reduce タスクは,抽出された情報を集約し,一塊のデータとして出力する,いわゆる「アグリゲーター」の役割を担う。
    このうち map タスクが純粋にフィルターとして振舞う(副作用が無い)ならば,この処理を複数のマシンで手分けして行うことができる。



    CouchDB→MapReduceを使う→mapタスクは副作用が無い→Erlangで実装OK、ということか?

    MapReduce - naoyaのはてなダイアリー
    具体的なコードを提示して、MapReduceが紹介されていた。
    すぐに飲み込めないけど、大量のデータを扱うのに便利ということらしい。

    ●RESTful JSON API

    CouchDB にはデータベースからデータを取得するための手段として API が用意されています。
    この API を利用するためには HTTP の GET リクエストと POST リクエストを使うことができ、こうしたリクエストに対して API は JSON を使った JavaScript オブジェクトの形でデータを返します



    JSONでデータを扱うのがCouchDB(カウチディービー)と。

    Lisp、JavaScriptの次は、Erlangかな?
    ScalaよりもErlangの方が実務に投入できそう。
    Erlangを勉強したら、CouchDBのソースコードを眺めてみて、MapReduceも勉強してみると。
    関連記事

    コメント

    参考になりました

    次はErlang。来そうですね。
    私はウェブの技術者をやっていることもあり、NoSQL関連の技術にも興味が尽きません。

    浜村さんのプロフィールにバイオインフォマティクス技術者とあります(初めて目にしたので少し調べました)が、こういった技術的(コンピューター言語やツール)な面での土台は共通したものがありますね。

    並行計算とNoSQL

    コメント、どうもありがとうございます。
    新しい技術が登場するたびに、私も勉強する毎日です。

    「プログラム=データ+処理」
    という観点で考えますと、近年、コンピューターの利用機会増加にともない、データとその処理は、量がどんどん増えてますね。

    (1)データの増加
    大量のデータを扱う場合、その入れ物として、RDBの代わりにNoSQLのタイプが利用される事例が増えてますね。
    例:GoogleのBigTable等。

    RDBとNoSQLには、それぞれ一長一短があると思いますが、どういう場合に使い分ければ良いか理解したいです。

    (2)処理の増加
    CPUのマルチコア化が進んでいるので、今後ますます、並列計算(CPUをたくさん使う)や並行計算(同時にたくさんの処理を行う)の重要性が増してくると思われます。
    そうなると、プログラム言語も、多数のプロセス/スレッドの処理を簡単に記述できるものが望まれます。
    処理の考え方も、旧来の「構造化プログラミング」や「オブジェクト指向プログラミング」のみならず、「アクターモデル」のような並行処理に適したパラダイムを導入していくことになると思います。
    並行処理に着目して言語を比較すると、ErlangやScalaの評価が高くなるのでしょうか?
    例:TwitterのGizzard等。

    実務ですぐに使う機会がなかったとしても、自宅で行う趣味プログラミングで、いろいろ試してみたいです。(^^)/

    コメントの投稿


    管理者にだけ表示を許可する

    トラックバック

    トラックバックURL:
    http://hamamuratakuo.blog61.fc2.com/tb.php/347-d4693e10

    FC2Ad