Thursday, March 23, 2017

DBスキーマの問題

一般的に、Webサービスが稼働して時間が経つにつれ以下の事象が発生する。

1. テーブルが多くなる
2. 関係(Relations)が多くなる
3. 結果として、全体のデータの複雑係数が上がりまくる

リレーショナルなモデルの運用性は、これらが増えて行くたびに増幅し、以下のようなすごいSQLができる

select (....) from
  (select .... (select.... (select .... (select ...))))
where
(.... )
(....)
(select....)
  
これは技術的負債の最たるものと言ってよい。Railsはこれらの問題をもっと簡単にしてくれる画期的なパラダイムを含んではいるものの、過度な密結合を前提としたことからくる副作用の非予見性というリスクが大きい。複雑になっていくものに一度慣れていってしまうと、それが本来あってはならないという事実を忘れてしまう。結果、不要な工数を等比級数的に使用している、というのは割と大企業の開発とかで目に見る光景だ。

Neo4j などのグラフDBというのは、一見色物に見えるが非常に有用な代物に思える。というのは、例えばRailsのFixtureなんかを一度紙に書いて整理して行ってみると、それがまさに GraphDBだからだ。

GraphDBは直感的であり、関係性を非常に上手に抽象化している上、複雑なものが非常に絵的にわかりやすく把握できる。
 

僕はこの10年間でおそらくこっちの方が最終的にはRDBを圧倒して主流になるんじゃないかと踏んでいる。参照の速度も断然早い。

事実、ウォールマートなどではすでに導入済みである。

など、ちょっと思ったことでした

No comments:

Post a Comment