スラッシュドット・ジャパン

サーバーで運用する上でのノウハウの蓄積も相当なものになることが期待できそうです。
以前発表された HDD 故障率の論文のように、世間に還元してもらえれば、
ますます普及に拍車をかけることも有り得るでしょう。

参考までに

EMCがハイエンド向けフラッシュドライブ発表 [atmarkit.co.jp]

特徴は高性能と低消費電力。1万5000回転のファイバチャネルディスクと比較してI/O性能は30倍高速。応答速度も10倍高速という。対して、消費電力はドライブ当たり38％の削減が可能。1秒当たりのトランザクションで比較すると98％の消費電力の削減になるという。

　これが本当なら、対費用効果としてペイするのかもしれませんなぁ。
　Googleお得意の分散処理でGB単価が一番安い価格帯のSSDを大量に並べてストレージ化するんだろうし、コストパフォーマンスは現段階でもさほど悪くないのかも。

　昨年の記事ですが、すでに電気代はサーバー代を上回ろうとしています。 深刻化する消費電力問題--シリコンバレーでイベント開催：ニュース - ZDNet Japan [zdnet.com] 　ウチのサーバーはラックあたり４０Ａでとっくに電気代のほうがサーバー代より高くなってます。さらに、今年に入ってデーターセンターからは電気代仕入れ分の上昇分の負担を求められています。 　本気で検討するべき時期なのかも。

Akiba PC HotlineのSSD価格情報 [impress.co.jp] の価格情報を見ると、導入にかかる費用が恐ろしいことに！？
でも信頼性やランニングコストの実績として有効なデータが取れそうですね

記憶データが Web の文書・画像であることを考慮すると、データが飛んでも
全く痛くないですから(クロールしなおせばよい)、ビット単位でデータ化けが
発生するような現象は目をつむることが可能です。

ビットエラーの発生レートが通常の SD, USBメモリなどのと比較し高い状態
でもよいため、Google 専用ロットでは、メーカ側の品質の歩留まりも高い
水準を保てるでしょう。

したがって、かなり安く供給できるようになるのではないでしょうか。

つ「ボリュームディスカウント」
チップ製造元に直接依頼してるので、それ相応の価格にはなるかと思います。

しかし、HDD→SDDとなるとPCシステムとしてのボトルネックの一つが解消されるので、
またCPUパワーを上げなくても良くなりますね。
一昔前のCPUでもまったく問題ないような状況が今以上に加速されるように思えるんですけど、
当のIntelはナニ考えているんだろうなと。

#NAND部門とCPU部門って別なんだろうけどね・・・

まとまったデータとしてはフラッシュメモリベンチマーク [todev.jp]が参考になるのだが、
自分でも CrystalDiskMark 等でベンチ取ってみてる限りにおいては、
相当に高価なフラッシュメモリーでもない限りは、
フラッシュメモリが HDD に勝るのは
シーク速度がボトルネックとなる 4K read のみと言う結果になる。
はっきり行って、ストライピングとかしない限りにおいては
フラッシュメモリのシーケンシャルアクセスはたいして速くない。
同じくシーク速度がボトルネックとなりそうな 4K write に至っては
write cache による遅延書き込みが効くぶん HDD のが 2 桁以上も高速という結果もしばしばで、
フラッシュメモリのランダムライトは、絶望的に遅いんじゃないかと思う今日此頃。

ぶっちゃけ、数 GB 程度のキャッシュ積んで
先読みとライトキャッシュ効きまくりの HDD に
バッテリーバックアップで遅延書き込み保障してやる方が
よっぽど高速なんじゃないかって気がしてる。
# 電力効率は悪そうだけど

と言う訳で SSD には過剰な期待はしない事に。

# あと FDD、HDD と来てるわけだから
# SDD と書きたくなる気持ちは分らんではないが、、、

今現状だとランダムライトが遅いという課題はあるけれど、
SDDに遅延ライトキャッシュ搭載しちゃえば解決することだったりして。

要は今がどうかではなく、こうしたいという力が働けば
既存技術の組合せで実現できることは、割と簡単にできてしまうと思いますね。

問題は・・・まーけてぃんぐ とか せいじ とか、ちょっとよく分からないゾーンで
あって技術的な問題じゃない気がします。

#ええ・・・
#あくまで、そんな気がするだけですよ・・・

やる気でやれば、技術的障壁はどうにかなるだろうという考え方には賛同するが、
それほど短期間で解決できる問題とは思えない。
ある程度長い期間で、と考えると、
素性がよろしくないんじゃないかと思えてしまうフラッシュメモリよりは、
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年くらいしないと容量単価的に苦しいものがあると思われ。

世界で一番ストレージに対する要求が厳しそうなところが導入するとなると、内外に影響が大きそうですね。
今年はSSDの当たり年だという推測を支持していますが、それ以上にちょっと投機的な動きすらありそうな…

>世界で一番ストレージに対する要求が厳しそうなところが導入するとなると、内外に影響が大きそうですね。

違いますよ。

Googleは、そこそこの信頼性のハードウェアを沢山用いる事で
サービスの信頼性を確保しているのです。
単体の性能を求めているわけではありません。
むしろ、単体で追求するのは値段でしょう。

# 上のコメントが、GFSという「ストレージ」に対してのコメントだったら
# 的外れな指摘かもしれませんが。

たしかに書き換えより読み込みの方が圧倒的に多そうだし、壊れてもレプリカがあると考えると。 でも、導入費用の元は取れるのかな？（値下がり期待？） Windowsでも、例えば\Windows（swapは移動）と\Program FilesだけSSDにしてみたいなあとか、思うことが。

記事を読んだ瞬間、（根拠はないですが）フロントエンドになる大量のWEBサーバ向けのストレージではないかと思いました。量が多いし、書き換えはそれほど多くないでしょうから、機械的動作がない分、通常のHDDよりは信頼性が高くなりそうですしね。

ウェブキャッシュ関係とか良さそうですね。書き換えが少ないのにランダムリードがたくさん入るようなデータを置けば、電力も性能もかなり効率よくなるんじゃないでしょうか。その辺の境界を自動的に判定して、これはSSD行きこれはHDD行きと勝手に割り振ってくれるアルゴリズムとか、超優秀な中の人なら実装してそう

> Intelは第2四半期の終わりごろまでにフラッシュメモリチップを、Marvellはコントローラチップを供給する

製品ではなくて部品で供給を受けるのはなんか理由があるからなんでしょうけど、よくわかりません。

ケーブル/コネクタ接続じゃなくてオンボードに実装したいとかかな。

調べてみた。

60(Mbps) * 4 * 10(y) = 9460800000 MBytes = 約 8.81 PBytes

Googleのストレージ容量は知らないけど、 一日のデータ流量が20PB [niallkennedy.com]とのことなので、元ACの言うストリームの22年分強が一日に処理されています。

Googleのサーバ台数は、昨年末の時点で「100万台を超えているだろう」 [zdnet.com]とガートナーの人が推測しています。
仮に100万台だとして、それぞれ16GBのHDDを搭載していたとするなら、

16GB * 1000000台 ≒ 15.3PB

となりますね。
正確な数字は分かりませんけど、「世界最大『規模』」は飛躍とまでは言えないのではないかと。

容量以前に、元AC氏の例は、「貯め込んでる」という書き方からテープライブラリのような気がします。

（その仮定が正しいとして）そりゃあテープもストレージですけど、ここでの話はデータセンタのHDDをSSDに置き換えようというものなので、「ストレージ」と言うくくりだけで「テープならそれ以上の容量のところがあるぜ」というのはちょっと違うんじゃないかと思います。

# テープじゃなかったらゴメンナサイ。

いえ、たぶんその計算は少なすぎると思いますよ。
100万台規模のサーバがあってもHDDをそれぞれどれだけ積み込んでるかはわからないですし。
最大で考えるなら1台のサーバに付き4基のHDDを搭載してるとして、1基あたり500GBくらいで計算した方がいいかもです。

http://gurl.jp/g/A87JAplMsHC7YcBbsXqZ7Q

そうすると1.8エクサバイトとかアホみたいな容量が出てきます。

EeePCが100万台だから影響は少ないという方もいらっしゃいましたけど、同じ100万台でも1台あたりに積み込まれるHDDの容量は全然違うわけで。まさか4GBぽっちで足りるわけありませんから、もっと大容量のものを使うか複数台装備するでしょう。

下手したらEeePCの100倍から数百倍規模のチップを消費することになるかもしれませんね。

少し古い言及になりますが、2001年の@IT記事でドットコム崩壊をものともしないGoogle、そのシステムに迫る [atmarkit.co.jp]という話がありました。

　

大規模なWebサイトが、データ保存のストレージシステムとしてRAIDシステムやSANを用いているが、Googleでは典型的なディスク型のストレージシステムを用いている。その理由を「その方が速いから」とFelton氏は言う。

　Googleのストレージデバイスの多くはMaxtorの80GBハードディスク・ドライブだ。Maxtorの製品は、ハードディスクドライブ1台につきコントローラを1台、PC1台につきハードディスクドライブ2台を持つ。場合によっては、同社は2倍規模のPCを使用する。コントローラは4台、ハードディスクドライブは4台、プロセッサ2基、RAMは2倍となる。

# 7年も前の話ですから現状とは異なる可能性もありますが。

計算に使った16GBはかなり控えめな数字ですし、いずれにしてもペタバイト級のストレージが存在することは間違いないところだと思われます。

>60Mbps×4本のデータを365d×24h×10y

60(Mbit/s) / 8 x 60(s) x 24(h) x 365(d) x 10(y) x 4(stream) = 150TByte

じゃない?

この手の計算は、人間がやると間違えやすいので、Google電卓（いまHDDで運用中(はぁと)）に任せるに限ります。単位の変換までやってくれるので。

60Mbps*4*10年 = 8.81690326 ペタバイト [google.co.jp]

ぎゃあああああ
お恥ずかしい、有り難うございます。。
Googleすごいですね。まさか単位変換までやれるとは。。。

# どちらにぶら下げるか迷いましたがこちらに。1344068のACさまへの返事でもあります。

容量だけなら，こう言う製品があります：
Storage Solutions | S-AITテープライブラリ [www.sony.jp]
５年くらい前からある製品だったと思います．

だよね。
いくら１組織で多く持ってたって、全体から見れば僅かなんだし
例えサーバが１００万台あるとしても、全世界のPCの数はそれより遙かに多い訳だし

昔の話で恐縮じゃが、たかがインベーダーゲーム本体だけの為に一部のTTLが、超品薄になっての……