MySQL FULLTEXT Ngram : LIKE検索より数十倍高速な、お手軽 日本語全文検索 について｜blog｜たたみラボtatamilab.jp
ファイルシステムとパフォーマンス - nothing but trouble
数ヶ月前、うちのオーストラリア人エンジニアが、ファイルシステム毎のMySQLのベンチをInnoDB,MyIsamで取ってみたという話をしてきて、その結果を凄く意外に思ったことがあった。 数十万オーダーのベンチで、ext2が圧倒的に速かったらしい。そのあとは、reiserfs,ext3,xfs,jfsとかそんな感じの順番だったっけ？ext2が早いっていうことが意外すぎてあまり覚えていない。 それだけ、ジャーナル取るコストが高いってことなのかな。 CRUD特性やDB構成にも寄るんだろうけど、うちみたいなIO負荷が高くてmaster-slaveな構成のDBで廻しているWebシステムなんかにはext2で十分じゃないのかという話になって、該当するものに関しては、ext2にした。 そもそも、master-slave構成の時点で、ジャーナリングは殆ど必要ないだろうとおもう。ケアする必要があるのは、一度に
mysql -Xでクエリーの結果をXMLで取得 - 技術メモ帳
mysql -X でクエリーの結果がXMLで取得できるらしい。 興味深いのでやってみた。 なんか適当にテーブルを作成する。 とりあえず、4つのカラムを持つtというテーブル作った。 mysql> create table t(id int not null, name varchar(255), body text, updated_at datetime); mysql> insert into t values(1, 'name', 'body', current_timestamp); mysql> insert into t values(2, 'name2', 'body2', current_timestamp); とりあえず、普通にSELECTで表示してみる。 # mysql -e 'SQL' で任意のSQLを実行可能。ワンライナーに使えます。 $ mysql -e 'sele
テニス朝練, MySQLのクエリーキャッシュが効かない - いしなお!(2007-02-06)
だいぶサービスはいい感じになってきた。けど、相変わらずストロークは飛びすぎる。そろそろガットの寿命が近いはずなんで、明日にでもガットを張り直してこよう。前は堅めのガットを52ポンドくらいで張ったはずなんで、今度は柔らかめのガットを48ポンドくらいで張ってみるつもり。飛びすぎるのをスピンで抑えるイメージで。 _ [MySQL][クエリーキャッシュ][プリペアードステートメント] MySQLのクエリーキャッシュが効かない なんかやけにパフォーマンスが出ないなーと思ったら、MySQLのクエリーキャッシュが全然効いていなかった。なんでだろうと思ったら、 Zend_Db_Adapter_Pdo_Mysqlは必ずプリペアードステートメントとしてMySQLにクエリーを流す プリペアードステートメントに対しては、MySQLのクエリーキャッシュが効かない という合わせ技だった。 そんな罠があったのかよ。My
DBICでMySQLのロック - Hatena::Diary::Neko::kak 500 Internal Server Error
http://d.hatena.ne.jp/tokuhirom/20070126/1169812586 なんとなくDBICのにしてみた。 package DBIx::Class::Lock::MySQL; use strict; use warnings; use base 'DBIx::Class'; use Carp::Clan qw/^DBIx::Class/; sub get_lock { my ($self, $lock_id, $timeout) = @_; $self->{__MYSQL__LOCK__ID} = $lock_id; my $dbh = $self->storage->dbh; my $sth = $dbh->prepare('SELECT GET_LOCK(?,?)'); $sth->execute($self->{__MYSQL__LOCK__ID}, $
InnoDB vs MyISAM (vs Falcon) を読んで興味深いと思った点 - （ひ）メモ
InnoDB vs MyISAM vs Falcon benchmarks - part 1 を読んだ。興味深かった。 だけだとナンなので、思ったことをメモってみる。 がんばれFalcon まだ生まれたてなのでベンチマークの結果は参考程度に。 InnoDB vs MyISAM The second goal of benchmark was a popular myth that MyISAM is faster than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and has an operational overhead. As you will see it is not always true. の通り、どちかというと(Falconより)InnoDBとMyISAMの性能比較の方が興味深い点が
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
DBD::mysqlをMSVC6でコンパイルする - Charsbar::Note
DBD::mysqlの新版が出ていたのでちょろっと試してみたのですが、いくつか落とし穴があるのでメモっておきます。 ＃MySQL ABの公式見解は「ActiveStateのリポジトリに入ってるんだからおとなしくそれ使っとけ」のようなので、以下はなんでも自分でコンパイルしないと気が済まない人向けということで。 1) MySQLの公式サイトからMySQL 4.1のソースを落としてくる 多くの人が使っているであろうバイナリはVC7（以降）でコンパイルされているので不可。ページ最下段にあるWindows用のソースを落とす。 http://www.mysql.org/downloads/mysql/4.1.html カレントの5.0系ないし5.1系を落としたい誘惑にかられるかもしれませんが、少なくとも5.0.27のソースにはVC6で宣言されていない(u)intptr_tを使っている箇所があるのでひと
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
COUNT(*) for Innodb Tables
I guess note number one about MyISAM to Innodb migration is warning what Innodb is very slow in COUNT(*) queries. The part which I often however see omitted is fact it only applies to COUNT(*) queries without WHERE clause. So if you have query like SELECT COUNT(*) FROM USER It will be much faster for MyISAM (MEMORY and some others) tables because they would simply read number of rows in the table
DBIでmysqlのmy.cnfを読み込ませる方法
1つのサーバでmysqlを2台動かしてmy.cnfを分けたときに、DBIから接続する際にそのmy.cnfをdata sourceとして読み込ませる方法を初めて知った。。。(see also DBD::mysql) my $dbh = DBI->connect('dbi:mysql:foo;mysql_read_default_file=/path/to/my.cnf', 'root', '') or die $!; こうやるとできるみたい。もちろんmy.cnfの[client]セクションに接続したいmysqldの起動してあるポートとかを指定する必要があります。まぁ最近はサーバのコストも低くなってきているので、1台で複数のmysqlを動かすなんて機会がないっちゃないんですけどね…。 これは個人サーバでやりたかっただけです。
[ThinkIT] 第6回：データベースの負荷分散とまとめ (1/3)
Webサーバーも順調に増えた、となると次はデータベースが悲鳴を上げる頃です。データベースの増設と行きましょう。 はてなではデータベースにはMySQLを利用しています。MySQLは組み込みでレプリケーションをサポートしているので、これを使わない手はありません。レプリケーションを行い、マスターDBのコピーであるスレーブDBサーバーを作り2台構成にします。 レプリケーションは、データベースを複数台に増やし、且つその複数のデータベースが保持するデータを同期させるための仕組みです。レプリケーションされたデータベースのうち、元々あったデータベースが親、それ以外が子という親子関係になります。 親はマスター、子はスレーブと呼ばれ、マスターへの更新処理と同じ処理をスレーブに伝播させることでデータの同期が行われます。実際にはマスターからスレーブへ処理が伝播するのではなく、スレーブがポーリングを行ってマスターと
「コネクションプーリング都市伝説」はほんとに都市伝説?（その3) - 最速配信研究会(@yamaz)
前回のシリアル/パラレル処理の視点に立ってコネクションプールについて考えてみたい. コネクションプールが遅いとは はてなおやさんが考察しているように 普通にmod_perl でコネクションプールを素直に張るとコネクション数が爆発する. 図にすると図1のような感じで個々のapacheがコネクションを複数持つので,サーバ台数が増えるとコネクション数が飛躍的に増えることがわかると思う. 図1 コネクションが爆発してる様子(正直書くのも大変) コネクション数が増えると単純にコネクションを維持するコストも増えていくので， このあたりが「コネクションプーリング都市伝説」の根拠になっていると思われる. これはこれで全くその通りで間違いない. さて,ここでもうちょっと大きな視点に立って,クライアント<->サーバ間の通信路が 1個の伝送路をパケットによって多重化しているととらえてみたい.そうするとここで シ
最速配信研究会 - 「コネクションプーリング都市伝説」はほんとに都市伝説?（その2
ずいぶんと間が空いてしまったが, 「コネクションプーリング都市伝説」はほんとに都市伝説?（その1)の続きについて書きたい. まず本題に移る前にシリアル処理とパラレル処理の違いについて説明したい. シリアル処理ととパラレル処理 シリアル/パラレル処理というのは複数のタスクがあった場合の処理の方法で シリアル処理 → タスクを一つずつ処理する. パラレル処理 → タスクを並列に処理する という違いがある.一般にタスクの処理時間が一定で共通のボトルネックが 存在する場合,パラレル処理はシリアル処理に比べて遅くなる. 図1と図2は全タスクを処理し終わる時間はどちらも3単位で違いがないように見えるが, 平均処理時間を見てみると図1は2単位が平均処理時間になるのに対して,図2の方は 2+2/3単位が平均処理時間となるので不利になっているのがわかると思う. 実際にはこれに加えてタスクの切り替えのコストが
MySQLをインストールしたらまずチューニングするパラメータ - （ひ）メモ
MySQL Performance Blog » What to tune in MySQL Server after installation とりあえずパラメータを抜き出してみる。詳細はオリジナルのエントリを参照してくださいませm(_ _)m key_buffer_size innodb_buffer_pool_size innodb_additional_pool_size innodb_log_file_size innodb_log_buffer_size innodb_flush_logs_at_trx_commit table_cache thread_cache query_cache
CMSとモバイルとフィードと四畳半社長: みんなMySQLとかPerlとかがが好きだなあ
東京都文京区本郷でとあるCMS開発会社を営む社長のブログ。さっきまで「越後のCMS問屋」だったのですが、会社が新潟に移転したと勘違いされたようなので変えました。 モバイル、ゲーム、フィード、Ajax、Flash、ハイテクグッズあたりのはやりモノが好きです。 最新作「メルルーの秘宝」がドワンゴから提供中 週刊アスキーで「2045年の週刊アスキーをつくる」連載中 原稿を書けと言われて、オープンソースマガジンを二号ほど続けて買ったのですが、オープンソースに明るくない僕にも意外と面白くて、夢中になって読みあさりました。 今日は先月号を重点的に読んだのですが、先月号のテーマは、ズバリ、負荷分散。 ライブドアとGREEの方がそれぞれの負荷分散メソッドをかなり詳細まで語っているのですが、結論から言うと、こういうことです。 1.なるべくキャッシュしろ(memcachedとかtmpfsとか使え(基本
ウノウラボ Unoh Labs: LVM + XFSで高速簡単 MySQLバックアップ
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
naoyaのはてなダイアリー - MySQL の負荷分散に LVS + keepalived を使う
あとで書く、と言った手前なので書くとします。 DSASの中の人がすごい勢いで LVS の話を書いてくれてます。この辺。LVS を使うと Linux と箱でロードバランサが作れちゃいます。普通に買ったら数百万とかしちゃうやつ。 DSAS の中のひとに感謝しつつ、いい機会なのでやってみよう! と思っていろいろ試して昨日あたりからはてなの中でも LVS + keepalived で動かしはじめてます。いまのところ問題なし。 そのロードバランサをどこに使ってるかですが、普通ロードバランサというとインターネットからの入り口のところに置いてウェブサーバーの負荷分散に使うイメージがあります。が、今回ははてなでは MySQL のスレーブの手前に置くという役割でとりあえず使いはじめました。 +-----------+ +-----------+ | mod_perl | | mod_perl | +----
はてなブログ | 無料ブログを作成しよう
はじめまして新潟 隣の県なのになんとなく遠いイメージがあった新潟。休日出勤の振休と夫の休暇（上司から取れと言われたらしい、かわいそ…）が合ったので久々に遠出しよう！となり新潟へ。このあたりで隣の県を選ぶあたり我々の出不精具合が現れていますね。 1日目 行くぜ新潟 まずはへ…
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソフトエイジェンシー、MySQL 5.0対応のクラストソフトウェアを発売：CodeZine