2009年4月8日開催のセミナー「Extreme Search! 次世代検索エンジンSedue 24が実現する驚異のパフォーマンス」における、セッション「SSD向け全文検索エンジン」の配布資料。Read less
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (2009/03/25) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (本記事) MySQL 5.1.38から本体に同梱されるようになった、InnoDB Pluginの性能検証結果です。前回ご紹介したようにInnoDB Pluginには以下の強化点がありますが、本日はこのうちバックグラウンドI/Oスレッドの増加に焦点を当ててみたいと思います。 高速なインデックス作成。従来InnoDBのCREATE INDEXはテーブルの再作成を伴っていました テーブルとインデックスの圧縮 (検証結果その1、その2) INFORMATION_SCHEMAによるロック競合の検出 (検証結果) CPUスケ
SSDを使うとDBMSはどう変わる?徹底検証した記事を書きました! WEB+DB PRESS Vol.52 予約受付中です。 実際に最新最速のSSD、Intel X25-Eを使ってDBMSのパフォーマンスを計測するなど、わくわくしながら記事を書くことができました。SSDの実力に驚きつつも、使い方を間違えるとHDDより遅くなる? など新しい発見もあり。 そして、SSDとHDDの違いがどのようにデータベースの性能に影響するのか?ディスク上のデータ構造(ヒープ、B+-treeなど)からバッファ管理など、データベースシステムの中身を解剖してわかりやすく解説しています。読みやすくなったのは丁寧に添削してくださった担当様のおかげです。感謝。 ディスクを活用したデータのソーティング(External merge sortなど)に加え、2009年6月にEdgar F. Codd Innovation Aw
In 1987, Jim Gray and Gianfranco Putzolu published their now-famous five-minute rule15 for trading off memory and I/O capacity. Their calculation compares the cost of holding a record (or page) permanently in memory with the cost of performing disk I/O each time the record (or page) is accessed, using appropriate fractional prices of RAM chips and disk drives. The name of their rule refers to the
Writing small volume of data (Bytes-MBs) with sync (fsync()/fdatasync()/O_SYNC/O_DSYNC) is very common for RDBMS and is needed to guarantee durability. For transactional log files, sync happens per commit. For data files, sync happens at checkpoint etc. Typically RDBMS does syncing data very frequently. In this case, overwriting is much faster than appending for most filesystems/storages. Overwrit
I recently did a disk bound DBT-2 benchmarking on SSD/HDD (MySQL 5.4.0, InnoDB). Now I'm pretty confident that storing tables on SSD, redo/Binlog/SYSTEM-tablespace on HDD will be one of the best practices for the time being. This post is a detailed benchmarking report. (This post is very long and focusing on InnoDB only. If you are familiar with HDD/SSD/InnoDB architecture and understand what my b
移行が完了したら、HDD を SSD に換装です。 ここのネジを取って HDD を取り出します。 オープン。 このビニールのビラビラを引っ張って HDD を抜きます。 抜かれちゃいました。 両脇についてたゴムのやつを取ります。 HDD がついてたケース的なものを取り外します。 SSD にさっきのケースを取り付けます。 両脇のゴムのも SSD に取り付けます。 奥まで入れます。ビラビラは元通り中に入れます。 フタを閉めたら完了です。 と、ここまで作業が完了したら、いよいよ期待の「激速 OS 起動」です! …しかし、ThinkPad の起動画面の後、画面左上にプロンプトが点滅したままで、うんともすんとも言わず、起動しませんでした。。。 起動しなおして、ThinkPad 起動画面の時に ThinkVantage ボタンを押したら、SSD 内のリカバリ領域 (別パーティション) から ThinkV
消息筋からの情報によれば、SSDによる高速化も限界が見えていて、RAIDなどで横に並べた際に、バスクロックなどがボトルネックになって2GB/s以上はどう頑張っても出ないらしいです。逆に言えば、それくらいまでは速度が出ている。なのに、それらのハードが実用化された話をあんまし聞かないのは、SSDにするメリットがあんまし多くないからかな?単純に分からない。 「B木 - naoyaのはてなダイアリー」で触れられているようなSSDがB+-Treeを駆逐するイノベーションというのはどうも感じられていません。 個人的には、SATAはHDDを前提にしていたインターフェースなので、SATAインターフェースじゃないやつ(これとかこれ)に期待しています。そこで初めてSSDの鬼のような速度の威力が発揮されるのだと思います(なので、今はまだまだみんな技術開発中)。で、IOがボトルネックになることはなくなる。そういう
少し前にチューニングしたデータベースで さらにパフォーマンスアップする必要が出たので 最近流行?のSSDを使ったデータベースの高速化について検討してみたのでメモ。 ここ間違ってない?等フィードバック下さると嬉しい。 現在のサーバー構成 パフォーマンスアップ対象のデータベースサーバーは データベースファイルをNAS(NFSv3接続)においている。 数TBレベルの比較的大規模なデータベースサーバー。 SSDの特性 リードは早いがライトが遅い 基本的にはエンタープライズ向け製品であればリード/ライトスピード両方ともがHDDより数倍向上するが 一般向け製品の中にはランダムライト速度がHDDより劣る製品もある。 SLCタイプはMLCタイプに比べてライト速度が早いためデータベース用途ではSLCタイプを選択したほうが良い。 書き換え回数に上限がある ウェアレベリング(書き込み分散化技術)やキャッシュメモ
X25-M、SSDで検索してくる方が非常に多いので、本ブログ内のSSD関連記事をリストしておきます。 MySQLのベンチマークを用いたIntel X25-M SSDの評価 (本記事) SSDの真の性能を引き出す MySQL 5.1.38 InnoDB Plugin (2009/09/07) 先週末IntelのSSD、X25-Mが突然7,000円ほど値下がりしたので、ついに我慢できず手を出してしまいました。初めてのSSD導入です。 SSDのベンチマーク記事は国内・海外問わずたくさんありますが、実際にデータベースを乗せて計測した記事はそれほど多くありません。そこで、先日ご紹介したtpcc-mysqlを用いてベンチマークテストを行ってみました。 データベースサーバ OS : Windows XP SP3 32bit CPU : Core2 Duo T7300 2.0GHz (EIST OFF)
PCI Express経由のSSDドライブが色々登場 2009-04-28 (Tue) 15:21 SSD 色々出てきましたね。現状で1T 約50万円ぐらいの価格のようです。 容量1.2TB、転送速度1.5GB/秒の超高速SSD 「ioDrive Duo」 PCI Express型SSDの予価が出る、OCZ製 リード 1000MB/sのPCI-EXPRESS専用SSD G-Monster PROMISEの予価 来年が楽しみです。 Similar Posts: あ、でも最後に もうすぐテスト SC08 Older: Baidu.comの検索サーバーはSSD Comments:0 Comment Form Name (必須) Mail address (非公開) (必須) URI Remember personal info Yes No Commentスタイル指定用の一部の HTMLタグが
脊髄反射。 Oracle や MySQL など近年の RDBMS はインデックスのデータ構造にB木 (の変種) を採用していますが、その理由はここにあります。 SSD がコモディティになると状況は変わる (中略) 二次記憶上での検索用のインデックスにはこれまで B木のようなディスクに最適なデータ構造が必然的に選択されてきましたが、SSD に変わると、現実的に利用可能なデータ構造にも幅が出て、アプリケーションによっては劇的な改善が可能になるというわけです。 この先 SSD の普及によって、色々なソフトウェアで、驚くような改善が行われる機会を目にすることが多くなるのではないかと思います。その時、単に SSD に変わったから速くなったと捉えるのではなく、どのようなデータ構造が選択されて、そのデータ構造の特性が SSD とどのようにマッチしたのかという視点で見ていくことが大切ではないかと思います。
Using Intel.com Search You can easily search the entire Intel.com site in several ways. Brand Name: Core i9 Document Number: 123456 Code Name: Alder Lake Special Operators: “Ice Lake”, Ice AND Lake, Ice OR Lake, Ice* Quick Links You can also try the quick links below to see results for most popular searches. Product Information Support Drivers & Software
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く