タイトルのまんまのプチトリビアを紹介しようと思う。mysqlの--one-databaseオプションを使えば「mysqldumpで--all-databasesとか--databasesオプションを使って作成したダンプファイルに含まれる複数のデータベースから、一つのデータベースだけを選択してリストアする」という操作ができるけど、毎回ダンプファイル全体を読み込むのは無駄じゃないか？と思われることもあるだろう。だったら事前にダンプファイルを分けちゃいたい！と考えるのが人情というもの。そんなときはawkコマンドを使うといい。 #!/usr/bin/awk -f

BEGIN { dump_current_db = 0; num_db = split(databases, db_arr, ",") for (i = 1; i <= num_db; i++) { db_arr[

　昨日開催された shibuya.pm #12 - NoSQL特集で使用したスライドを slideshare にアップロードしました。

高度に進化した分散データストアについてView more documents from kazuho.

　開発しているシャーディングミドルウェアである Incline と Pacific については YAPC::Asia 2009 を始めいろいろな所で話をする機会をいただいてきたので、今回は、なぜ RDBMS …

Spiderストレージエンジンのバージョン 2.9(beta)をリリースしました。
Spiderストレージエンジンは、database sharding用のストレージエンジンです。
http://spiderformysql.com/

今回の主な変更は以下です。
・UDF「spider_ping_table」を追加しました。
・テーブルパラメータに「monitoring_kind」「monitoring_limit」「monitoring_server_id」を追加しました。
・サーバパラメータに「spider_udf_table_mon_mutex_count」を追加しました。
　このリリースでは、Spiderのリンク障害状況確認機能が追加されています。

それ以外の変更については、ダウンロードドキュメント中の「99_change_logs.txt」をご確認下さい。
…

MySQLのクエリキャッシュ機能ですが、SELECT文の内容によってはquery_cache_XXX変数の値に依らず無条件に結果がキャッシュされませんよね。

ではどんなキーワードを含んでいるとキャッシュされないのでしょうか。sql_yacc.yyとlex.hで確認してみました。

• SQL_NO_CAHCE
• FOR UPDATE
• LOCK IN SHARE MODE
• CURRENT_DATE
• CURDATE
• CURRENT_TIME
• CURRENT_TIMESTAMP
• CURTIME
• CURRENT_USER
• DATABASE
• DATABASES
…

レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン でも掲げたゴールである、「マスタが落ちてもぐーすか寝ていられるようにしたい」がほぼできたので、ほとんどサービスが停止することなく、フェイルオーバする様をスクリーンキャストに収めました。

埋め込みプレイヤーだと、小さくてわからないと思うので、リンク直接でみてください。
http://www.irori.org/pub/mysql-mm.mov

登場するホスト

登場するホストは2台、db901とdb902です。
最初は、db901が更新系クエリを受けるプライマリでdb900の浮動 …

色々試してみてたら，
共起語の各共起回数が少ない場合に相互情報量を使うのは
一つの手段としてアリなのかもとか思った．

例1:相互情報量のが意味がありそうな結果

例2：どっちもまぁまぁ

例3:共起語のが良い結果

テスト結果をつらつら書いてると長くなりそうなので記事を分けた．

情報量にidf値を用いてやってみた．
単語Aが出たら単語Bも出るっていう確率は分子で行っているので，
分母はidfってゆー，対極的重み付けのスコアを使ってみる．

相互情報量 = log(

  (全文書に出現した単語の総数 * 単語Aと単語Bの共起頻度)

   / 

  (単語Aのidf値 * 単語Bのidf値)

)

発行したSQLは以下の通り．

select
  t1.id,
  t1.name,
  t2.id,
  t2.name,
  log(
    -- T1
    (
      -- 語の総数
      (select count(id) from terms as t_cnt)
      *
      -- AとBの共起回数
      (
        select …

推薦の勉強の一環のメモです。

相互情報量とは、単語Aが出たら単語Bも文書Xに出るという
情報量の計算に使えそうな理論。
これをクラスタリングする際の指標に使えないかと模索中です。

数式は下記の通り。

数Aとか数Bが超苦手だったので、
解釈があっているのかアレなのですが、
この式をこんな風に解釈できるんじゃないかと考えてみました。
(正しい数式じゃないのでご注意ください)

 …

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" where iid = 2;

これ↓は、where句で使っているのが、インデックスがはられていないカラムなので、後発のクエリはすぐ返らず(先発のがcommit or rollback or タイムアウトするまで)待たされます。これも期待通り。 …

シェアードナッシング型の負荷分散機能を持ち、なおかつ同期レプリケーションによるHA機能まで備えたMySQL Cluster最大の弱点といえば、JOINの遅さであろう。MySQL ClusterのJOINは偽りなく遅い。JOINを多用するアプリケーションでMySQL Clusterを利用するのはある意味マゾヒスティックな行為であると言えよう。何故MySQL ClusterはJOINが遅いのか？それはMySQL Clusterが分散データベースだからである。

ご存じの通り、MySQLにおけるJOINのアルゴリズムにはNested Loopしかない。他のストレージエンジンを利用していればそれでも十分実用に耐えうるぐらい高速なのだが、MySQL Clusterの場合はそうはいかない。JOINでは自ずとストレージエンジンからデータをフェッチする回数が増えるが、MySQL Clusterの場合