NoSQL 時代のデータモデル

Masayoshi Hagiwara @masayh

RDBMS対Hadoopという比較自体は適切ではない。正確には、RDBMSとHadoopにおける並列アルゴリズムやデータ管理技術の比較。すでにRDBMSのアルゴリズムはデータ管理技術は非RDBMS化していて、それはHadoopやその他のNoSQLにも適用可能となっている。

Masayoshi Hagiwara @masayh

たとえば、NoSQLでもスキーマや正規化の考え方を設計に取り入れた方がいいし、それを実装に入れて、現在のNoSQLの持つデータモデルの優位性を損なうことなく最適化することができるでしょう。

Masayoshi Hagiwara @masayh

関係代数や関係論理といった技術的基盤をもっと参照して、現在のNoSQLやその他のデータ管理技術が一定の理論的基盤の上に乗るのが先決ではないでしょうか。いたずらにデータモデルや一貫性、可用性の選択肢を増やして、性能だけを競ったとしても、最適な設計ができる開発が伴うとは思えません。

Masayoshi Hagiwara @masayh

これまでのデータベース知識は、DOAによる分析設計、RDB正規化、SQLチューニング、トラブルシューティング、ORMによるオブジェクト指向開発、トランザクションなどが中心。クラウドではB-treeやハッシュテーブルのデータ構造、joinやsort並列化など。求められる技術が違う。

Masayoshi Hagiwara @masayh

クラウドでのトランザクション扱い： 分散トランザクションを使わずに一貫性モデルを使うこと。障害の回復はトランザクションモニターではなく、クライアントベースで行うこと。なぜなら、一貫性の条件や補償はクライアント（アプリケーション）の要求で決まるから。joinや非正規化と同様に。

Masayoshi Hagiwara @masayh

KVSではパーティションキーの定義の一部として、read/writeの並列化の計画、join、aggregate、sortの機能の有無を考えること、更新には非同期キューを使うこと、一時的な非一貫性の問題を明らかにして対策を取ること。

Masayoshi Hagiwara @masayh

クラウドの状態、データにつきものの非一貫性については状態遷移図を使うこと。これ普通のUMLや開発方法論には書いてないから注意。

Masayoshi Hagiwara @masayh

クラウドでトランザクション処理が過去のものになった理由は、一貫性要求がアプリケーション依存だからというよく知られた事実とは別に、障害復旧の責任もアプリケーションにあるということがあります。TPモニターに一任という時代ではありません（続き）。

Masayoshi Hagiwara @masayh

TPモニターにエラー処理を一任したことで、ITは業務データ記録に成り下がってしまった。意思決定は主に人任せで、アプリケーションの価値が下がってしまった。クラウドはトランザクションに制約を加えて、補償の仕組みをアプリケーションに要求した。これを負担と見るのでなく、高度化と見ること。

Masayoshi Hagiwara @masayh

いままでトランザクションを使うことでエラー処理に関して楽をしていた。それがアプリケーションの価値を下げていたということ。これは開発者の一種の怠慢でもある。本来、トランザクション処理にクラウドのような制限がある方が自然で、むしろ自然に回帰しただけのこと。だからNoSQL批判は的外れ

Masayoshi Hagiwara @masayh

データ分析（バッチもCEPも）はトランザクションを使わず、人任せにしなかった一例。

Masayoshi Hagiwara @masayh

RDBではエラー時は記録を消すだけの処理を前提としてしまうと高度な要求に対して制限になってしまうということです。@gokutubusi 問題に関しては疑問も無くRDBのトランザクションを使用していた事。本来開発者が負うべき責任を、これに任せきっていた。

Masayoshi Hagiwara @masayh

今NoSQLやHadoopのデータ設計の問題はおおよそ20年前にデータベース界隈で議論されていた課題です。現在の技術者で20年前も先端で活躍されていた方はほとんどいないので、同じ課題を繰り返している状態です。インターネットやH/Wが進歩しても物理制約は超えられない例です。

Masayoshi Hagiwara @masayh

通信場をプロセスベースとするかデータベースにするかのアーキテクチャ判断。今後はデータベースを通信場とするのが主流になるでしょう。メールやSNS、バッチ処理、SOA連携、CEPなど。データベースとしては、RDB、NoSQL、分散キャッシュ。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

まず、思うのは、非同期通信を軸にしたクラウドモデル（分散では同期通信はコストが高い）では、グラフベースでのモデリング（DAGとか）が非常に有効なのは、確かめられつつあると思う。とはいえ、昔のようなDOAぶっちぎりというわけではなく、UMLの使える部分も使いつつという感じで。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

業務や処理のつながり、データのつながりをうまくグラフで表現することが肝心で、やっている実感でいうと、今まで以上に設計の意識が大事。なにを、いつ、どうやって、その意味は？ということを考えることが、今でも大事だけど、もっと大事になる。そうでないとグラフに表現できない。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

グラフ自体は、割と抽象的なものから、具体的なものまで、表現できる。しかも、数学的なものへまで変換できてしまうという便利さ。しかし、当然に「考えることが必要」で、それがないとなんじゃこりゃ？みたいなものまでかけてしまう。要は「なにがしたいのか？」ということがわりとすぐ問われる。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

「見てて美しいと思うグラフ」（DAG）　「読みやすいグラフ」「なにをしようとしているのかわかりやすいグラフ」と、そうでないグラフの出来は歴然とする。これは、ちゃんと流れやルール、粒度感がしっかりしていることが大事で、モデリングの基本とも言える。

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

さらに、きれいなグラフは、そのまま数学的な操作が可能→プログラムにコンバートが可能、ということなので、たぶん近い将来は「そのまま、実行可能もモジュールが生成される」＋「クラウドでシームレスに実行可能」ってながれになると思う。・・・っていうか、なりつつあるんじゃね？

御徒町＠MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

グラフ自体は、当たり前だけど実装非依存（正確には違うけど）なので、実装はHadoopだったり、Dryadだったり、@asami224さん のフレームワークだったり、いろいろに適応できて、ポータビリティが非常に高いと思う。・・・まー、やってみないとなんともいえないけどね。

Masayoshi Hagiwara @masayh

イベントや時間概念を表現するモデルが短期的で、長期的にはCPSとの絡みで連続系だと思います。論理型はその中で成長すると思っています。@asami224 モデリング技術は、データモデル、状態機械→OOADがあって、その次がよく分からない。

Masayoshi Hagiwara @masayh

RDBがスケールしない本質的な理由を考えてみたことがありますか？正規化、ディスクベース、I/Oコスト、join...なぜ？

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： 正規化（垂直分割の一種）、ディスクベース（有限メモリならどんんなデータモデルでもあり）、I/Oコスト（ディスクベースと同じく）、join（分割したものの複合化はデータモデルに依存しない）、トランザクション（更新系なら必要）。どれも違います。

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： ヒントはNoSQL

Masayoshi Hagiwara @masayh

RDBがスケールしない理由： 行指向であること。ページサイズがOLTPに最適化されているので分析系でのI/Oの負荷が高いこと。行指向であることは、関係代数の徹底のために、挿入、変更対象データだけでなく、処理の中間データ形式までtupleを使い、B-treeが前提となっている点。