データ構造(wide, tall, fat)によるデータストアの分類
NoSQLの争いは、実際のデータ構造についてwide, tall, fatどれに需要があるのかにかかってくる。(´・ω・`)
2010-04-25 21:58:12なるほどねえ。wideは非正規化データ全般、tallはKVSに特化したシンプルなデータ、fatはHadoopに処理させたいような巨大データってことかな。現実解っぽいのはwide > tall > fatじゃないかなあ
2010-04-25 22:03:52wideはRDBMSをみて、tallは最初からKVSみて、fatはBLOBとかのバイナリデータなどの大きいデータ、ってことかな。
2010-04-25 22:07:10@shot6 あらま。こちらの感覚はtall > fat > wideだったりします。時間が経てばはっきりすることですが・・・。(´・ω・`)
2010-04-25 22:08:08@nsharp_2ch あら。最初からKVSが使える状況かどうかってとこですねー。fatが実はあんま思いつかないのですが、どういう状況下で有効と考えますか?
2010-04-25 22:11:42オンラインな業務アプリケーションはwideか。hBaseは若干お呼びでないし、とりあえず代えがなくて困った現状。Oracleで回すか。ログ解析系はtall。Hadoopがぴったりで嬉しい。fatはRDBMSに入れるのはツライとはいえ、アイシロンは高いしなぁ。。。みたいな印象。
2010-04-25 22:13:53@frsyuki ほぼ同様の想定で、wide/tall/fatですね。wideまわりなら、書き込みはACIDにOracle側でそこからキューを介してwideなデータ構造に展開、かなあと。
2010-04-25 22:17:30@nsharp_2ch ですよね。HDFSというかDFS主体で考える点は同意です。結構使いどころむずかしー気がしますです。
2010-04-25 22:18:39この分類でいくと、ROMAやkumofsはwideに当たるのかな。若干ずれている気もする。shortが欲しくなるか。楽天ARIAはfat狙い。HBase/BigTableは完全にtall。Cassandraはwideかtallか微妙な線? 儲かるのはtallかfatか…
2010-04-25 22:19:08HBaseはtall(かな?)、Cassandraはwideですね。ちなみにVoldeomrtはtall。あれ、kumofsってtallじゃないんですか?
2010-04-25 22:22:51@shot6 HBaseは原理主義的にはwideで使いたいのですが、パフォーマンス上tallに強いのが現実だったりします。(´・ω・`)
2010-04-25 22:27:16@shot6 BigTable が tall の分類だとすれば、kumofs は tall ではない…と思います。列指向DBではないので。少数の列を大量の行に渡って高速に取り出すのは得意ではないです。Voldemort も同じだと思いますが。
2010-04-25 22:27:52@frsyuki そうですね。列指向がtallという事ならば、kumofsはwideですね。Voldemortも同じです。
2010-04-25 22:32:18この辺に少しコメントでありますね。 > http://www.roadtofailure.com/2009/10/29/hbase-vs-cassandra-nosql-battle/
2010-04-25 22:35:51