先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
先週金曜日、BPStudy#25で、「パフォーマンスとスケーラビリティのためのデータベースアーキテクチャ」という題目で話をさせていただきました。その際に使用した発表資料は以下のとおりです。 1. Happy Optimization 最初に、最適化の考え方として、上限値を予測し、それを元にリソース配分を考える、という手法を説明しました。
It is a well-known fact that the bottlenecks of MySQL does not exist in its storage engines, but rather in the core, for example, its parser and execution planner. Last weekend I started to wonder how fast MySQL could be if those bottlenecks were skipped. Not being able to stop my curiousity, I started adding memcached proctol support to MySQL as a UDF. And that is Mycached. From what I unders
I am sure many programmers writing network applications have their own abstracting layers hiding the differences between various I/O multiplex APIs, like select(2), poll(2), epoll(2), ... And of course, I am one among them. While writing mycached (see Mycached: memcached protocol support for MySQL for more information), I was at first considering of using libev for multiplexing socket I/Os. Libe
ORM やウェブアプリケーション関連のライブラリなどのテストケースを書くにあたっては、 RDBMS へのアクセスが必要になります。しかし、SQLite のようなスタンドアローンのデータベースと比較すると、サーバ型データベースである MySQL に接続してテストを書くのは、既存の MySQL の権限設定やデータベース名を気にする必要があったりと、いろいろ不便です。そこで、MySQL のインスタンスをテンポラリディレクトリに自動生成し、テストが終わったら削除してくれる Perl モジュール Test::mysqld を書きました。こんな感じで使います。 use DBI; use Test::mysqld; use Test::More; my $mysqld = Test::mysqld->new( my_cnf => { 'skip-networking' => '' }, # TCP接続を
先日書いた「MySQL のボトルネックを統計的に監視・解析する方法」について、PostgreSQL でも pg_stat_activity テーブルを使って実行中のクエリ一覧を取得できると higepon さんに教えてもらったので、やってみました。 % ppdump > ppdump.txt のようにクエリをサンプリング (デフォルトで100秒間程度) して、 % ppfilter < ppdump.txt | ppreport のようにすると、平均負荷の高いクエリから順にソートされて表示されます。詳しい使い方や考え方については、mprofile のエントリをご参照ください。 pprofile のソースコードは、/platform/postgresql/pprofile – CodeRepos::Share – Tracに置いてあります。負荷が高い PostgreSQL 環境が手元にないの
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
RubyKaigi2009の最終日に同じ場所で開催された別のイベント「RejectKaigi2009」にて 「はじめてのRuby1.9プログラミング」と題して、記号Polyglotプログラミングの話をしてきました。 3分という限られた時間でありましたが、貴重な発表の機会を与えてくださりありがとうございます。 取り急ぎプレゼンで披露した記号Polyglotのプログラムを公開しておきます。 ■ hello.pl (という名前ですが、Perlの他にRubyやJavaScriptでも実行できるプログラムです) "#{",$/*"}";%#=();$^_^=’?“;">)~${`&&@`{;:+`[[‘,$^_^=’/?")-=^{(=!".=.!,!)&&>’,$^_^=’`-+|{!?“*.((-+({:^(_^’,$^_=”^’+@$@&’^’^.@%@’.’$^_^"";’.$^_^"",’
最近 RDBMS のトリガーを色々書いているのですが、知らない人にトリガーが何かいちいち説明するのに簡単な例はないかな、というのと、MySQL の処理速度はトリガーによってどの程度変化するか、ということを確認するために、以下のような実験を行ってみました。 InnoDB はしばしば、「SELECT COUNT(*) が遅い!」と批判されます。では、トリガーを使って行数を別のテーブルにキャッシュすればいいのではないでしょうか? 以下のように、極めて小さなテーブル t1 を作り、その行数を t1_cnt にキャッシュしてみることにします。 mysql> create table t1 ( -> id int unsigned not null primary key auto_increment, -> v int unsigned not null -> ) engine=innodb
既に mattn さんが、「Big Sky :: ヘッダファイルだけでC++から使えるJSONパーサ「picojson」が凄い!」で紹介してくださっています (mattn さん、アドバイス&バグ情報ありがとうございます!) が、いまさら C++ で JSON パーサを作りました。それは、以下の3点を満たすものがなかったから。 ヘッダファイル only boost 等、他の重たいライブラリに依存しない array や object が STL にマッピングされる コードは、coderepos に置いてありますので、よろしければお使いください (picojson.h)。 なお、現時点での制限事項として、 \n や \r, \uXXXX といったエスケープの処理が未実装rev. 34232 で対応しました (含サロゲートペア) 空白文字の判断基準が RFC と異なるrev. 34277 で空白と
先週、概要を紹介させていただいた Pacific について。まだ API をフリーズしていないつもりなのですが、だいぶ整ってきた気がするので、ざっくりまとめておきたいと思います。 インストール手順 Thrift をインストール注1 Pacific の svn レポジトリからチェックアウト Perl ドライバを make (cd driver-perl && perl Makefile.PL && make all test install) リゾルバを make (cd resolver && make) テーブルのセットアップ手順 テーブルのセットアップは、pschema コマンドを使って行います。 # リゾルバの裏側の MySQL は 127.0.0.1:33060 で動作 # # プライマリテーブル「user」を作成 # ・ 分散キーの名前は「username」 # (
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
コメントつきソーシャルRSSリーダーfav.or.itの創業者Nick Halsteadさんが、自分がtwitterのスケーラビリティを直すならこうする、というエントリを書いている。 twitterは今日も「データベースがロストした」とかで落ちていて、不安定さに対する不満の声をそれこそ毎日のように見かけるようになっている。 技術的な興味から、訳しながら読んでみたのだけれど、ほんとうにこれですべてた解決するのか、については僕はわかっていない。わからないものを出すのもどうかと思い数日放置してたんだけど、もっと手の長い人に読んでもらうのも意味はあるかなと思い直し、以下に公開する。 「fav.or.itはこれよりもっと複雑だ」と言ってるけれどfav.or.itはtwitterほどユーザいないし(笑)。 前段では有名ブロガーのRobert Scobleさんが、技術的な理解無しにtwitterをMS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く