2010年11月23日

なぜテーブルを定義し、ジョインしなければいけないのか? - RDBがデータモデル上の定義で、本質的に間違っている点

7
Masayoshi Hagiwara @masayh

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

2010-11-17 16:57:24
Y.Katsumata @y_kats

考えたこともないし、そんな課題に気づけもしない。ぱっと思いつくのは、名前の通り「データ(テーブル)同士の関係性を維持するための仕組みが処理を分散しにくいため」とかかな。う~ん分からない。RT @masayh RDBがスケールしない本質的な理由を考えてみたことがありますか?

2010-11-18 00:32:06
Masayoshi Hagiwara @masayh

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

2010-11-18 14:21:30
Masayoshi Hagiwara @masayh

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

2010-11-18 14:22:30
ビズアイユ @Bizuayeu

I/Oコストはオンメモリにすれば良いと思うので、ノード間でトランザクションを保障するためのオーバヘッドですかね。CPU的にもネットワーク的にも。 QT @masayh RDBがスケールしない本質的な理由を考えてみたことがありますか?正規化、ディスクベース、join...なぜ?

2010-11-18 20:11:57
Masayoshi Hagiwara @masayh

残念ですが違います。@Bizuayeu I/Oコストはオンメモリにすれば良いと思うので、ノード間でトランザクションを保障するためのオーバヘッドですかね。

2010-11-19 00:45:01
Y.Katsumata @y_kats

データアクセスとデータの処理両方をDB自身がやる前提で設計されているため?NoSQLでは、データそのものの処理はHadoop使うかアプリ自身に組み込むイメージ。 RT @masayh RDBがスケールしない理由: ヒントはNoSQL

2010-11-19 07:28:14
Masayoshi Hagiwara @masayh

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

2010-11-19 11:38:40
Masayoshi Hagiwara @masayh

行指向は人間が情報を扱う点でシステムのどこかで必ず出現し、主に入口で使われるので避けて通れません。ただ、RDBはそれをシステム全体で使っている点が制約で、その優れたアルゴリズムだけを取り出して、並列エンジンに乗せてNoSQLと組み合わせ、入口以外のところに適用していくのがいい。

2010-11-19 11:41:05
Masayoshi Hagiwara @masayh

情報を行で扱うのは人間の意味の認識と深くかかわるので、避けて通れない自然の発想、概念です。それ自体は何も制約がない。

2010-11-19 11:42:27
Masayoshi Hagiwara @masayh

RDBMSだめと言い切る前に、なぜだめか、どこがこれからも利用可能かを考えてみましょう。同じように、OOPや既存の開発方法も振り返るのは大切です。時代が変わり、環境が変わり、要求が変わる以上、同じ技術も見方や立ち位置が変わるから。

2010-11-20 12:50:29
Masayoshi Hagiwara @masayh

まず自分で問題意識を持って、調べて、意見として考え方をまとめましょう。次にそれを技術者同士で確認しあいましょう。そして、価値を認めて広げていきましょう。そうすれば、技術は発展していくはずです。

2010-11-20 12:52:41
Masayoshi Hagiwara @masayh

RDBがスケールしない理由に続いて。RDBがデータモデル上の定義で、本質的に間違っている点を考えてみてください。なぜテーブルを定義し、ジョインしなければいけないのか?

2010-11-21 15:32:50
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

今年のIT関連のベストTweetではないでしょうか。RT @masayh: RDBがスケールしない理由に続いて。RDBがデータモデル上の定義で、本質的に間違っている点を考えてみてください。なぜテーブルを定義し、ジョインしなければいけないのか?

2010-11-21 16:14:44
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

「なぜテーブルを定義し、ジョインしなければいけないのか?」なるほど。

2010-11-21 16:14:58
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

「Aというのものが、Bと同一である」ということがなぜわかるかというと、「そう決めたから」で、それは決めた人(または人たち)のルールでしかないわけよ。

2010-11-21 16:18:10
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

技術に変わり目には本質的な議論が剥き出しになる。直視してこその技術屋。・・・個々人のポリシーや考え方の問題。「いやだって、RDBはそういうものだから」どういうもの?「いや、会社で決めたからw」あぁそうですかw。

2010-11-21 16:21:56
Ikufumi Moriya @imoriya

Google社のCFOがソーシャルメディアはほんの序章に過ぎないとか言っていますね。その先に何が来るのかな? http://bit.ly/dpUIk7

2010-11-21 23:05:11
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

ちょっと流通ITでのアイテムの正規化についてつぶやく。

2010-11-22 00:22:56
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

一般に消費財にJANコードと言われるコードがつけられる。レジでスキャンされるバーコードだ。今はJANではなくGTINといって、ワールドワイドに一意に決められている。管轄は経産省の外郭団体で、GS1というグローバル標準化団体に属している。

2010-11-22 00:23:19
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

んで、このJANコードは一見すると商品のキーに格好の材料だ。何しろ各商品にユニークについているし、ダブりなく管理もされている。んで、初心者のSE(そして大抵のSE)はいそいそと、こいつをキーにする。

2010-11-22 00:23:40
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

んで、あるタイミングで即死する。実は、JANコードは切り替わるわけです。いつか?新商品が出た時。そりゃ新商品だからスペックも変わるし、メーカーも形式上は違う物として管理したい。だから実態は「同じ」商品だけど、別々のJANコードが混在する、ということになってしまう。

2010-11-22 00:24:09
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

ちゃんとした業務系の仕組みは実はJANコードは絶対にキーにしない。そういう事情を知っているからだ。(そして、そうなっていないパッケージとか結構ある。・・・・まじで関係者猛省してくれ。あとでメチャクチャなカスタマイズが大抵入る。)

2010-11-22 00:24:31
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

じゃー、JANはキーでないのか?そんなことはない。実際、ある一定時点ではユニークなキーである。レジでPLU(売価をJOINする)する時には絶対的にJANがキーになる。また、発注する時点でもJANコードでの発注は普通にある。・・・・だから正規化ってのは、本当に難しい。

2010-11-22 00:24:58
御徒町@MultiVersionConcurrentClimber(MVCC) @okachimachiorz1

商品の切り替わり、というのは認識論的に非常におもしろい。「それは前と同じ商品ですか?」YESでもあり、NOでもある。微妙に属性が変わっているのはよくあるし、その場合は厳密に言えば別商品。でも「後継商品だから、実際は前の商品と同じ」なんてことは普通にある。

2010-11-22 00:25:23
残りを読む(35)

コメント

Y​S​R​@​サ​ノ​バ​戸​隠​ル​ー​ト​ク​リ​ア @YSRKEN 2020年6月3日
スケールしない理由……よくある理由としてはトランザクションでしょうか
0