スクリプト言語の息の根を止めるのは案外 SSD かもな - kwatchの日記
大変たいへん興味深い記事。全プログラマーにとって。 HDDの代わりにSSDを利用したら、リレーショナルデータベースの性能はどれだけ向上するのでしょうか？ オラクルと富士通が共同検証を行い、その結果をホワイトペーパーとして先週発表しました ...(snip)... HDDは200スレッドで性能が頭打ちなのに対し、SSDは200スレッドから300スレッドになってもまだ性能は上昇。ただし、300スレッド時にはCPU利用率が100％に近づいており、先にCPU性能の方がボトルネックとなってしまったようです。 HDDをSSDにしたらデータベースはどれだけ速くなるか？ オラクルと富士通が実験 － Publickey 動的なスクリプト言語 (Ruby や Python など) と静的なコンパイル型言語 (C++ や Java など) では、だいたい 5 倍から 10 倍ぐらいの速度差がある。それでもスクリ
SSD がコモディティになっても状況はかわらない - kazuhoのメモ置き場
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
SSD とストレージの将来 - kazuhoのメモ置き場
SQL に痛痒感を感じる日々を過ごしている身としては、RDBMS がレガシーだというのは、まったく同感ですが。 SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。 2008-12-12 そんなことないと思います。理由は以下の２点。 フラッシュの書き換えブロックサイズは数キロバイト以上 トランザクションは意識して実装せざるを得ない フラッシュメモリはランダムリードできますが、DRAM のようにランダムライトできるわけではありません。書き込みが非常に遅いのに加えて書き換え回数の制限もあるので、メインメモリと同様のプログラム手法を使うのは難しいと思います。 次にトランザクションについてですが、組み込み型データベースとして
Kazuho@Cybozu Labs: ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性
« Filter::SQL でデータベースを叩くワンライナーを簡単に書く方法 | メイン | ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法) » 2008年10月28日 ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性 実際に試してみた結果については、ウェブサービスの SSD 化について話してきましたをご参照ください。 検索エンジンや小さな行が多いデータベース等で使用する目的での SSD (Intel X25-M) のベンチマーク結果については、Kazuho at Work: Benchmarking SSD for MySQL をご覧ください (InnoDB の話をしていますが、Senna / Tritonn でも基本的に同じ) Sun が SSD 製品の投入を表明 (マイコミジャーナル) したり、Google
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Flash-Based DBMSの最前線
