KLab技術者ブログ:その5 MVCCは複雑だったもうすぐゴールデンウィークです。初の長期休暇という事で何をしようかとわくわくしています。 休みの間にMyISAMやInnoDBについて調べて勉強会で発表できるくらいになりたいものです。 けど、やっぱり遊びまわったりしてるんだろうなぁ…。 今回はベンチマークについてです。 性能調査の事と認識していましたが、dbのベンチマークとはどんなものなのでしょう？ 続きを読む
あるあるおハマり大事典 - InnoDBなのに行ロックしないの - （ひ）メモ
drop table if exists t; create table t ( iid int ,nid int ,bid binary(3) ,msg varchar(69) ,key (iid) ,key (bid) ) ENGINE=InnoDB; insert into t values (1,1,1,"ichi"),(2,2,2,"ni"),(3,3,3,"san") ,(4,4,4,"si"),(5,5,5,"go"),(6,6,6,"roku") ; なテーブルとデータで、2つ端末を用意して update しあいっこしてみます。 まず、これ↓は両方ともupdateが完了してスコっと返ってきます。行レベルロック++ begin; update t set msg = "t1" where iid = 1; と begin; update t set msg = "t2" wh
KOF2009「ウェブサービスのパフォーマンスとスケーラビリティ」 - stanaka's blog
KOF2009にて、「ウェブサービスのパフォーマンスとスケーラビリティ」と題して発表してきました。発表資料を以下に置いておきます。 Performance and Scalability of Web ServiceView more presentations from Shinji Tanaka. 概要は、「ウェブサービスのパフォーマンスを向上させスケーラビリティを高めるために、はてなでは様々な取組みを行っています。本セッションでは、はてなで採用している具体的な技術、ノウハウ、可視化手法と、それらの効果について紹介します。」というものです。 最近の、Interopやカーネル読書会あたりで話した内容をまとめつつ、レスポンスタイムの可視化という最近の取り組みについて話しました。 最近、レスポンスタイムについては、以下のようなグラフを使っています。 x軸がレスポンス時間、y軸がその時間内に収
キャッシュの構造(基礎編) - どういう単位でキャッシュに入れるのか?
キャッシュって何だろう? 性能の観点でCPUの仕様を見るとき、コア数、クロック周波数の次に来るのがキャッシュの容量というのが一般的であるが、キャッシュとはどういうもので、どう動くのかについてはあまり理解されていないように思われる。そこでこの一連の連載ではキャッシュについて述べようと思う。 プロセサのクロックが16MHz(GHzでは無い!)程度であった1980年代半ばまではDRAMメモリのアクセス時間も5サイクル程度であり、データをDRAMまで取りに行くことは大した問題では無かった。しかし、プロセサのクロックが1GHzを超えると、プロセサのクロック周期は1ns以下であるのに対して、DRAMのアクセスは1CPUの小規模システムでも50〜80ns程度であり、100CPUサイクルのオーダで待ち時間が発生することになった。これではプロセサコアはメモリにデータを取りに行く時間、遊んでいるばかりで、処理
Dbspj preliminary numbers
So some 5 month later... - Dbspj has an ndbapi - Dbspj works enough for simple benchmarks! Reminder, what is Dbspj: - It's a new feature for Ndb - It gives the possibility to push-down linked operations (e.g in SQL terminology: joins) - It currently only supports left-outer-joins, and only some kinds of joins - It is currently *not* in anyway integrated with mysqld (for accelerating SQL access) An
MySQL Clusterが苦手とするJOINを如何にして克服するべきか。
シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。 ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合レコード
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
