非常に同意です。その制約をいったりきたりです。 RT @guutara: @shot6 @tamagawa_ryuji...
2011-06-10 01:01:35@shot6 仮想化技術ってさぁ、VM一個だけ、作って動かしたら、物理サーバの資源は、ふるに使える、って、のが、目指す単純な目標だと、おもうんでありますが、凡人は。。なかなか、難しいですよねぇ。。
2011-06-10 01:02:33@Guutara それを究極的にめざしているのがGoogleさんですよね。んー。1980年頃のコンピュータ・サイエンスの理想でもあると思うんですが。「それはちょっと無理ポ」ってとこからスタートしている、ある意味現実路線を行っているのが最近のイノベーションってやつなのかなあと。
2011-06-10 01:05:48これは逆で弱み。I/Oを効率的に使っていないと思います。@tamagawa_ryuji @okachimachiorz1 Hadoopって、物理I/O(ディスクやネットワーク)を使い切る仕組みが強みの1つだと思うんで、
2011-06-10 01:05:53@guutara 難しいですねえ。しかしそのオーバヘッドを払っても、運用管理や状態の複製がしやすいなら有意義なソリューションだとは思います。物理層に近い部分を触れば触るほど特化するし、抽象度の高いリソースにすればするほど汎用的におおざっぱに多くのものを扱えます。一般的な話ですが。
2011-06-10 01:06:41@tamagawa_ryuji どうなんだろう? 昔のGoogleはよくわからないなぁ。あ、最近は、わかりやすくなってる。w 飛んでったきり、かえってこない、と、おかしな人で、飛んでった後、帰ってきて、行動するのが、天才なんでしょうねぇ。どちらも、おなじなのは、高くとぶってこと。
2011-06-10 01:12:12@tamagawa_ryuji いえいえ。MapReduceって可用性の保証を単純化するために余計なI/Oをいっぱいするでしょ。それにノード数が増えることで並列性は上げるけど、データ転送量の効率は下がるでしょう。いいアーキテクチャはノード数が少ないよ。たとえば、SFのPodとか。
2011-06-10 01:14:01Hadoopは、Stupid だから、とりあえず、はやってる? w がんばれ! みたいな。。
2011-06-10 01:16:13分散処理フレームワーク界の "Keep it simple, stupid" Hadoop... 怒られそうだ。。ねよ。
2011-06-10 01:18:18@masayh ああ、なるほど…数式で示せと言われると困りますが(苦笑)、感覚的には分かります。Hadoop/MRは「最善のアーキテクチャ」ではないけども、「これまでは不可能だったレベルの性能を、(使う側のスキルも含めて)現実的なレベルで達成できるシステム」って感じに思えます。
2011-06-10 01:19:14いえいえ、言い得て妙じゃないですか。RT @Guutara: 分散処理フレームワーク界の "Keep it simple, stupid" Hadoop... 怒られそうだ。。ねよ。
2011-06-10 01:19:47何かを単純化すれば、別に犠牲を払う必要がある。Hadoopだと可用性と開発の単純化のために、I/O効率を犠牲にしている。よって、必要なノード数が増えて運用管理がたいへんになるのをツールやプロトコルが補っている。それが合理的な問題領域なら使う価値はあるが、いずれ優れた技術に代わる
2011-06-10 01:20:38たしかに分散処理と仮想化は相反してる。でも常に物理リソースが潤沢にあるわけじゃないので、そんなこんなでAmazonEC2でクラスタ作ってHadoopをぶんまわしています。仮想化とクラウドは別物だろうし、EC2に至っては別次元のサービスな気がします。
2011-06-10 01:21:43その点での貢献はとても大きいと思います。同意します。@tamagawa_ryuji 、「これまでは不可能だったレベルの性能を、(使う側のスキルも含めて)現実的なレベルで達成できるシステム」って感じに思えます。
2011-06-10 01:22:23また新たなブレークスルーがきっとでてくるってことですよね。楽しみがつきないです。多少なりともその端っこくらいにはいたいものです。精進せねば。 @masayh それが合理的な問題領域なら使う価値はあるが、いずれ優れた技術に代わる
2011-06-10 01:25:18@Guutara ブレークスルーって、やっぱりしがらみをバッサリきったところから出てくることが多いと思うんです。でも、ブレークスルーが一般に普及してくると、またどうしても別のしがらみがまとわりついてきてしまうのは、もうしかたないんだろうなと思いますねえ。
2011-06-10 01:27:35Hadoopと仮想化の議論が盛り上がってるなぁ。まぁ、性能で不利なこともあるけど、収容設計の前提条件がなかなか成立しないので、相性はよくない。
2011-06-10 09:14:26仮想化でI/O性能が5%違うとすると、1000台のクラスタで50台分、300台で15台分がロスになる。普通は許容されない。 でも、クラスタサイズが10台くらいなら、仮想化で得られる運用上の利便性のメリットの方が大きくなることもある。 結局はクラスタサイズとか用途によるって話。
2011-06-10 09:19:47Hadoopをデータ蓄積プラットフォームとしても使いたいか、それとも比較的中小容量のデータ対するバッチ処理基盤として使いたいかにも寄る。 大容量データの蓄積をするなら、まず仮想化は都合が悪い。
2011-06-10 09:23:38小規模Hadoopクラスタを仮想化上で構成する場合、よーく設計しないと可用性を大きく失う。多重故障に対する耐性が変わるので、当たり前だけど。
2011-06-10 09:27:04そもそも、Hadoopってインテリジェントな仕組みというよりは、スマートなアイデアに基づいているものの、最後はパワーで押し切る仕組みなんだよね。
2011-06-10 09:31:26同意。ということは、ボリュームにはフレキシビリティが必要とは思います。 RT @hamaken: そもそも、Hadoopってインテリジェントな仕組みというよりは、スマートなアイデアに基づいているものの、最後はパワーで押し切る仕組みなんだよね。
2011-06-10 09:44:00