-
- いいね！4
Masayoshi Hagiwara
@masayh
RDBからクラウドのデータモデルに変化した今日、関係データモデルの原理とRDBMSの機構の理解こそが重要です。RDB脳であることではなく、むしろ、RDB脳を変えるために、もう1度内部を振り返る感じです。
2010-11-22 14:18:00
Masayoshi Hagiwara
@masayh
自分で管理不能なコードをキーとするのはよくないです。@okachimachiorz1 JANコードは一見すると商品のキーに格好の材料だ。何しろ各商品にユニークについているし、ダブりなく管理もされている。んで、初心者のSE（そして大抵のSE）はいそいそと、こいつをキーにする。
2010-11-22 22:40:30
Masayoshi Hagiwara
@masayh
実はここにRDBがデータモデル上の定義で、本質的に間違っている点のヒントが隠れています。@okachimachiorz1 商品の切り替わり、というのは認識論的に非常におもしろい。「それは前と同じ商品ですか？」YESでもあり、NOでもある。微妙に属性が変わっているのはよくあるし、
2010-11-22 22:42:33
Masayoshi Hagiwara
@masayh
この予想にもRDBのデータモデルの意味は深いところで関係しますね。将来を洞察するというのはそういうことです。@imoriya Google社のCFOがソーシャルメディアはほんの序章に過ぎないとか言っていますね。その先に何が来るのかな？ http://bit.ly/dpUIk7
2010-11-22 23:03:03
Masayoshi Hagiwara
@masayh
間違いではありません。NULLという複雑な問題を簡単化している点は問題を含みますが。答えは別にあります。@keisyun NULL の扱いでしょうか？RT @masayh: RDBがデータモデル上の定義で、本質的に間違っている点：
2010-11-23 00:07:48
Masayoshi Hagiwara
@masayh
いいえ、違います。既存のDOAはストックしか扱わないので、それには改善は必要ですが。フローをもっとまともに扱う設計です。しかし、クラウドは基本的にデータは意味論ベースでなければだめです。@Bizuayeu 「もの」にも「こと」のように時間の概念が必要という…こと？
2010-11-23 00:09:25
Masayoshi Hagiwara
@masayh
NULLは人間の英知の限界を示しています。つまり、YESともNOともとれないことを示したい。僕が知る限り、IT技術で人間の限界を明示的に工学が示した例はほかには知らないです。それくらい画期的なことなのです。結果、関係モデルは複雑化しました。
2010-11-23 00:30:33
Masayoshi Hagiwara
@masayh
以前のtweetで、情報を行で扱うのは人間の意味の認識と深くかかわるので、避けて通れない自然の発想、概念です。それ自体は何も制約がない。がRDBでは実現できないのです。
2010-11-23 12:30:09
Masayoshi Hagiwara
@masayh
RDBがデータモデル上の定義で、本質的に間違っている点： RDBは情報をテーブルの行にしてそれを関係づけます。一方、本来は意味の関係づけがあって、情報の行ができるのです。そこに大きな誤りがあります。
2010-11-23 12:31:54
Masayoshi Hagiwara
@masayh
例、人間を表現する情報には非常に多様な属性があります。無数とも言っていいでしょう。その人間が何かの行為をするから、その属性が決まるのです。属性を決めてから行為をするため、属性と行為がジョインされるのではありません。概念モデル定義は属性を決めないで抽象化される理由です。
2010-11-23 12:34:11
Masayoshi Hagiwara
@masayh
IT技術の教え方には根本的な誤りがあると思ってます。OO、モデリング、分散、データ処理、あるいは、クラウド。本質的に重要な原理が教えられていないので、RDBで見られる、モデリング、テーブル設計、キー、NULLなどもよく考えられていない。本を読む前にもっと考えることが大事です。
2010-11-23 12:38:51
Masayoshi Hagiwara
@masayh
RDBやOOのクラスを設計段階で決定するために要求の合意がステークホルダー間で必要になるんです。しかし、設計段階で認知の対象を決めるのは難しい。なぜなら、情報やそれを処理するコードの意味は関係づけという動的なもので決まるから。その意味で、要求の合意形成というのは開発のための手段。
2010-11-23 12:42:18
Masayoshi Hagiwara
@masayh
クラウドで使われるデータモデルには2種類があります。1つのシステムの入出力用。もう1つはデータ交換やデータ処理の実行用。前者はNoSQLの大半。後者はHiveなど。この2つは要求が異なる。
2010-11-27 13:28:42
Masayoshi Hagiwara
@masayh
HDFS上のHBaseは前者の例。MapReduceに対して入出力の支援。一方、MapReduce上にtupleやpartitionを構成して、クエリーの最適化を行うデータモデルは後者の例。いずれも物理ファイルシステム、ストレージとは独立している。
2010-11-27 13:31:09
Masayoshi Hagiwara
@masayh
ASCII technologiesのHadoopの記事読みました。よく書けていると思います。ただ、僕ならスキーマ定義の導入、DSLの方向性、データ分析での設計法はもう少し突っ込んで書くと思う。今ある技術をどう解説するかでなくて、技術は自分ならこう進めるくらいの自負があってもいい
2010-11-27 23:48:47
Masayoshi Hagiwara
@masayh
ASCII technologiesのHadoopの記事： データ間の時間順序関係の分析と、演算子とMapReduceとの対応関係の2つが興味深かった。いずれもまだ技術的には検討事項が多いけれど、こうした問題はより大きな本質的な問題に対するヒントとなる点で注目しなければならない。
2010-11-27 23:55:04
Masayoshi Hagiwara
@masayh
いずれにしてもスキーマやデータモデルの導入をDSLや分析手法で考え、それに基づく最適化を考えていくことが重要。これはRDBの歴史が教えていること。
2010-11-27 23:56:24
Masayoshi Hagiwara
@masayh
MapReduceでのデータフローはDAG（非循環グラフ）がキーになる。Dryadは、ギリシア神話に登場する木の精霊。http://bit.ly/gbBCKd
2010-11-27 23:59:42
Masayoshi Hagiwara
@masayh
クラウドで効率的に並列処理をする原則はデータの同一場所で処理を実行すること。つまり、データ処理の並列化となる。並列処理の実装は一般に困難なので並列DBの実装技術を隠ぺいし、それを宣言的ないし問題指向といった高レベルの記述で利用するのが今後とトレンドと思える。
2010-12-01 01:00:20
Masayoshi Hagiwara
@masayh
NoSQL入門で何を執筆すべきかを考えることにする。NoSQLとRDBは動的言語と静的言語の関係だから、適材適所に使うべき原則がある。どっちか一方を主張すると宗教戦争の繰り返しになってしまう。
2010-12-01 15:37:43
Masayoshi Hagiwara
@masayh
タスクパラレルはMapReduceの実行機構に関する並列化、データパラレルはMapReduceのデータ設計とバッチアプリケーションに関する並列化。一般人は後者だけを考えればいい。
2010-12-01 15:39:44
Masayoshi Hagiwara
@masayh
12/8（水）午後の大手町でクラウドアーキテクチャに関して限定ラウンドテーブルを開催します。私もクラウドのスケーラブルアーキテクチャの話をします。その他、アジャイル開発、クラウド開発の評価法など、外人アーキテクトもまじえて。ご興味があればメールアドレスを含めて私にDMをください。
2010-12-01 17:20:03
Masayoshi Hagiwara
@masayh
クラウドによってユースケースの粒度が変わる。これまでのユーザの役割によるセグメント化から、個々のユーザの時間による役割の変化になる。前者はこれまでのマーケティングのセグメント化の手法、後者はCEPのtime windowに関係する。情報爆発に対応できるクラウド能力を拡張できるため
2010-12-02 12:28:59