アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
導入コストがすごそう… (スコア:1)
でも信頼性やランニングコストの実績として有効なデータが取れそうですね
Re: (スコア:2, すばらしい洞察)
チップ製造元に直接依頼してるので、それ相応の価格にはなるかと思います。
しかし、HDD→SDDとなるとPCシステムとしてのボトルネックの一つが解消されるので、
またCPUパワーを上げなくても良くなりますね。
一昔前のCPUでもまったく問題ないような状況が今以上に加速されるように思えるんですけど、
当のIntelはナニ考えているんだろうなと。
#NAND部門とCPU部門って別なんだろうけどね・・・
本当にボトルネックは解消されるのか!? (スコア:4, 興味深い)
自分でも CrystalDiskMark 等でベンチ取ってみてる限りにおいては、
相当に高価なフラッシュメモリーでもない限りは、
フラッシュメモリが HDD に勝るのは
シーク速度がボトルネックとなる 4K read のみと言う結果になる。
はっきり行って、ストライピングとかしない限りにおいては
フラッシュメモリのシーケンシャルアクセスはたいして速くない。
同じくシーク速度がボトルネックとなりそうな 4K write に至っては
write cache による遅延書き込みが効くぶん HDD のが 2 桁以上も高速という結果もしばしばで、
フラッシュメモリのランダムライトは、絶望的に遅いんじゃないかと思う今日此頃。
ぶっちゃけ、数 GB 程度のキャッシュ積んで
先読みとライトキャッシュ効きまくりの HDD に
バッテリーバックアップで遅延書き込み保障してやる方が
よっぽど高速なんじゃないかって気がしてる。
# 電力効率は悪そうだけど
と言う訳で SSD には過剰な期待はしない事に。
# あと FDD、HDD と来てるわけだから
# SDD と書きたくなる気持ちは分らんではないが、、、
uxi
Re:本当にボトルネックは解消されるのか!? (スコア:1)
SDDに遅延ライトキャッシュ搭載しちゃえば解決することだったりして。
要は今がどうかではなく、こうしたいという力が働けば
既存技術の組合せで実現できることは、割と簡単にできてしまうと思いますね。
問題は・・・まーけてぃんぐ とか せいじ とか、ちょっとよく分からないゾーンで
あって技術的な問題じゃない気がします。
#ええ・・・
#あくまで、そんな気がするだけですよ・・・
Re:本当にボトルネックは解消されるのか!? (スコア:1)
それほど短期間で解決できる問題とは思えない。
ある程度長い期間で、と考えると、
素性がよろしくないんじゃないかと思えてしまうフラッシュメモリよりは、
MRAM のが本命じゃないか?と思う。
# まぁ見た目 SSD と言うくくりにはけど
# 中身的には MO と HDD くらいの差はある事になる。
とりあえず、最近の 3.5in 7200rpm の HDD の場合、
シーケンシャルで 80MB/s くらいは普通に出る。
シーケンシャルなので書き込みキャッシュは無視できるとすれば、
つまり、シークなしで 4KB の書き込みに必要な時間は 1/(80*1024)≒1.2e-5[s]
シークタイムはおおよそ 12[ms] = 1.2e-2[s] くらいなので、
4KB ランダムアクセスではシーク速度が大半であり、
有効数字2桁ならデータ転送速度は誤差の範囲。
結局シーク速度で計算した4KBランダムアクセスの理論値は
1/1.2e-2*4e-3=0.33MB/s
くらい
結局、現状のランダムアクセス性能は
リードはフラッシュメモリがHDDの10倍程度高速だが
ライトはHDDがフラッシュメモリの10倍程度高速と考えられる。
キャッシュを積んでも、ランダムライトの性能差は埋まらないだろう。
シーケンシャルに関しては、言わずもがな。
シーケンシャルはストライピングでどうにかなるだろうけど。
当面、ランダムライトが糞みたいに遅くても足を引っ張らないという状況でしか
SSD によるパフォーマンス改善は望めない。
省電力、省スペースという点に魅力を見出せたとして、
もう3~5年くらいしないと容量単価的に苦しいものがあると思われ。
uxi
Re: (スコア:0)
> もう3~5年くらいしないと容量単価的に苦しいものがあると思われ。
容量単価とかランダムライトのパフォーマンス云々って、そういった全般的なSSDの話であって、この記事や引用先、及び、親コメントの内容と関係あります?
情報ソースから判断できることとしては、まずは一部のサーバ(何サーバだかよくわかりませんが)への省電力化が目的なのだし、さらに、リードが多く発生する類いのサーバに用いるのなら、複数側面のパフォーマンス改善が望めると思います。
っていうかそもそも、その程度の効果やパフォーマンスの試算もせず、Googleがそういう動きをするはずないんじゃ。。。
Re: (スコア:0)
CFやSDやUSBメモリとかしょぼいコントローラのなら低消費電力も
メリットですが高速なコントローラ積んで内部でストライピングしてるようなSSDは
それなりの電力を食うらしいので消費電力的にもちょっと微妙なんですよねぇ…
ランダムリードを必要とする用途に使うなら良いデバイスだし必要としてない
ならHDDでいいんじゃないですか?
当たり前の話ですが適材適所ってことで.
Re: (スコア:0)
「Googleを支える技術」
http://gihyo.jp/book/2008/978-4-7741-3432-1 [gihyo.jp]
まだ全部読んでませんが実質書き換え無しのようですし、これだけ目的特化したシステムを構築できるなら
SSDのパフォーマンスを最大に引き出す構成での導入を行うのではと考えます。
Re: (スコア:0)
このベンチは・・・。
最近のSSD知らないんだね。