タグ

ブックマーク / kazuhooku.hatenadiary.org (5)

  • MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場

    読み込み>書き込みなデータベースだと、実体化ビュー (materialized view) を使って読み込み速度を上げるってのは有効な手法 ちなみに MySQL や PostgreSQL だと実体化ビューはトリガーを使って書く *1 では、トリガーベースの実体化ビューを後から追加した場合に、どうやって既存データを新しいビューに反映させるのか。 UPDATE トリガを、ビューの側に対応するデータがない場合は INSERT トリガと同様の動作をするように実装すればいい (典型的には REPLACE INTO 文を使う)。ビューの初期データ充填は UPDATE src_table SET id=id; MySQL だと CREATE INDEX CONCURRENTLY がないから副インデックス作成はスレーブでやったりする*2けど、上の UPDATE を LIMIT つきで回すことで、ビューをイ

    MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場
    bull2
    bull2 2010/03/17
    マテビュー
  • はてなのサーバ運用は教科書的なスケールアウト手法? - kazuhoのメモ置き場

    はてなにおける SSD の実績 - mura日記 (halfrack) の感想。木を見て森を語るような話ですが、この iostat を見ていて興味深かったのが、 ボトルネックは SSD この状態だと iostat -x の ioutil は 100% にかなり近い値40%-50% 前後だと思う*1 CPU がスカスカ メモリもそんなに積んでない*2 それでも SSD を複数台つながない、ってことは、ストレージの上限にあわせて CPU とメモリをスケールダウンする方針なんだろう。絵に描いたようなスケールアウトダウンアプローチ。 高可用性はレプリケーションで確保する、と割り切るなら、サーバ毎に RAID を組んでシステムを複雑化させる必要はないし*3、方針がはっきりしてて素晴らしいな、と思った。 酔っぱらってるようなエントリだけどまだ飲んでない 追記: うちのパストラックの新サーバの X25-

    はてなのサーバ運用は教科書的なスケールアウト手法? - kazuhoのメモ置き場
    bull2
    bull2 2010/01/26
  • perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場

    syscall って組込関数でシステムコールはできますけど、libc やその他ライブラリの関数を呼びたい、ってこともありますよね。i386 かつ dlopen な環境なら、こんな風に書けます。 use DynaLoader; use ops; sub ccall { my $r = '1111'; my $s = "\x68" . pack("L", $_[5]) . "\x68" . pack("L", $_[4]) . "\x68" . pack("L", $_[3]) . "\x68" . pack("L", $_[2]) . "\x68" . pack("L", $_[1]) . "\xb8" . pack("L", ("Dyna"."Loader")->can("dl_find_symbol")->(("Dyna"."Loader")->can("dl_load_file")->

    perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場
  • MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場

    集約演算を行うケースでは、行のサイズを小さく保つことはとても重要。アクセス頻度が低いコラムは別テーブルに追い出すとかしたほうがいいくらい。 一方、集約演算を行わないケース (単一行の insert, update 等を含む) の場合は、(クライアントとの通信のための) システムコールがオーバーヘッドになるので、小さなテーブルにたくさんアクセスをするよりも、長い行を持つテーブルに1回アクセスするほうが良い。 たとえば手元の環境での insert on duplicate key update の速度は、 行のサイズ 必要時間 0KB 1 3KB 4 6KB 7 9KB 13 12KB 13 とかそんな感じ (環境やクエリによる変わるので自分で測定してね。9KB の速度低下はページサイズの1/2を超えたからかな)。つまり、行のサイズが1KB程度だと、通信のオーバーヘッドが大きいからあまり問題に

    MySQL (InnoDB) における行のサイズと速度の関係について - kazuhoのメモ置き場
  • InnoDB におけるカラムの格納 - kazuhoのメモ置き場

    カラムサイズが768バイトを超えると16KB単位になるってのは重要。 Question: How much space InnoDB allocates for each blob outside of the page? HT: For each column that InnoDB needs to store ‘externally’, it allocates whole 16 kB pages. That will cause a lot of waste of space if the fields are less that 16 kB. The ‘zip’ source code tree by Marko has removed most of the 768 byte local storage in the record. In that source code tr

    InnoDB におけるカラムの格納 - kazuhoのメモ置き場
    bull2
    bull2 2008/02/12
    768バイトを超えると16kBになるらしい
  • 1