ダウンロード Wikipedia:データベースダウンロード ウィキペディア日本語版: jawiki-latest-pages-meta-current.xml.bz2 xml2sqlでmysqldump形式に変換 wikipediaのコンテンツは、600MB以上ある。それなりに時間が掛かるので、落としている間にデータベースへのインポートの準備。データの提供形態はxmlなので、データベースに入れるにはそれなりの工夫が必要である。幸いwikipedia自体が２種類の方法を提供してくれている。MediaWikiに付属しているimportDump.phpを使うか、xml2sqlというツールをインストールするかが選べる。 他でも使えそうなので、xml2sqlを使うことにした。 xml2sql $wget ftp://ftp.tietew.jp/pub/wikipedia/xml2sql-0.5.ta
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
自分が開発したLAMPのシステムに異変発生。 普通にアクセスできるものの、データの登録や更新ができない。つまり、selectはOKだけとinsertやupdateがNG。 この時点でだいたい原因は想像できた。サーバーにログインして「df -h」をしてみると、やっぱり、/varディレクトリが100%になっている。つまりMySQLが更新ログ(バイナリログ)をディスクに書き込めず、処理ができなかったというわけだ。 よく見てみると、「/var/lib/mysql/DB名.log」というファイルが肥大しまくっている。実は、開発時にデバッグ用にmy.cnfでlogオプションを有効にしており、本番運用開始後もずっとそのままだったのが原因。 さっそくログファイルを削除し、my.cnfのlogオプションをコメントアウトしてmysqlを再起動。問題は無事、解消されました。 ひとまず一件落着なんですが、同じディ
Wild Growth 日本語
2/18にSkySQLが日本で第２回目となるMariaDB/MySQLのコミュニティイベントを開催します。 http://atnd.org/event/E0023540 海外からの講演者は、前回来日されたColin Charles氏、Michael Carney氏のほか、今回はMySQL ABの創業者のMicael“Monty”Widenius氏(MySQLの生みの親としても有名)とDavid Axmark氏も加わる豪華な顔ぶれです。 また、前回より時間枠が拡大し、株式会社ディー・エヌ・エー様、株式会社アシスト様、MySQLユーザー会堤井氏の講演が予定されており、私も本イベントで登壇させて頂くことになりました。 DeNA 樋口氏からは「Handlersocket 2.0」 DeNA 中谷氏からは「MySQLite: SQLiteデータベースを読み書きするMySQLストレージエンジン」 の講
最近 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
MySQL4.1以降で空間情報を扱う機能が使えるけど、指定した緯度経度から半径nメートル以内の検索が出来ないのが難点です。 かなり大雑把なやり方で半径nメートル検索のやり方を考えてみました。 まず最初に緯度経度の情報を持ったテーブルを作成。 CREATE TABLE `geotable` ( `id` INT(10) NOT NULL AUTO_INCREMENT PRIMARY KEY , `name` VARCHAR(255) NOT NULL, `geom` POINT NOT NULL, SPATIAL INDEX(geom) ) ENGINE = MYISAM ; 続いてデータを挿入。 INSERT INTO `geotable` (`name`, `geom`) VALUES ('上野駅', GeomFromText('POINT(139.777254 35.713768)')
[追記 2012/09/29] 最近でもこの記事を参照してくださる方がいるので追記します。下記エントリを書いた時点では非常に局所的なケースで重い現象に悩まされていたことを前提に調査しており、その延長線上で「一律InnoDBというのは言い過ぎな印象を受けるパフォーマンス差に感じる」ということを書いてしまっていますが、その後色々と勉強した結果、特定箇所のニッチなベンチマークではなく一般的な運用上の負荷を焦点にした場合はInnoDBは適切に設定しておれば十分にパフォーマンスがある（もしくはInnoDBの方が有利）というのが現在の意見です。 「MyISAM InnoDB」で検索するとあちらこちらであるように、今時は理由がなければInnoDB、ということでMyISAMのテーブルをいくつかInnoDBに変更したところ、かなりパフォーマンスが落ちるケースがあった。 InnoDBにしたら軒並み遅くなったと
The world.sql file contains sample data for a world database that you can play with. The file is available for download from http://dev.mysql.com/doc/. The sample data used in the world database is Copyright Statistics Finland, http://www.stat.fi/worldinfigures. To load the contents of the world.sql file into MySQL, use the following procedure: Change directory to where the world.sql file is locat
データベースの運用で避けられないのが、ロック競合によって起こるシステムトラブルへの対応です。「2時までに終わるはずのバッチ処理が朝になっても終わっていない」とか「負荷が高いわけでもないのにシステムが無応答になっている」といったトラブルが発生したとき、DBエンジニアはそれがロック競合によるものなのかどうかを切り分けて、適切に対処しなければなりません。 これまでInnoDBはロック競合に対してほとんど打つ手がなかったのですが、最近ようやく対処方法がでてきました。今日はその手順を確認していきたいと思います。 前提 今回ご紹介する手順は、MySQLの以下のバージョンを対象にしています。 MySQL 5.1＋InnoDB Plugin 1.0 MySQL 5.4 いきなりハードルを上げてしまって申し訳ありませんが、バージョン5.0以下や素の5.1では使えませんのでご注意ください。以降の実行例はすべて
Baron got a great amount of response from his 50 things to know before migrating Oracle to MySQL. I’m glad I invited him as a fellow MySQL colleague to my presentation to the Federal Government on Best Practices for Migrating to MySQL from Oracle and SQL Server for his inspiration. Oracle will always be a more featured product then MySQL. There are however features that MySQL has that Oracle does
前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。 実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqld のプロセスが利用できるメモリの上限が、32bit OS の場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。 2 つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bit OS でないとリソースの有効活用ができないか。それとも、先に書いたとおり、OS レベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む
MySQLでいちいちshow tables;とか打つのがだるい。\tみたいなalias設定できないのかなぁ http://twitter.com/weboo/status/1658300902 おぉ、readlineのマクロを使えばいいのかー http://twitter.com/weboo/status/1658314333 なるほ！ってことでちょっと設定してみました。 # ~/.inputrc $if mysql "\C-xd": "show databases;" "\C-xt": "show tables;" "\C-xu": "select user,host,password from mysql.user order by user,host;" "\C-xb": "select user,host,db from mysql.db order by user,host;"
先週一週間、MySQL Conference & Expo 2009 に参加してきました。ほとんどのキーノートのビデオや一部のセッションの資料は公開されているようなので、それ以外、全体からうけたイメージなどについて、つらつらと。 サービスをスケールアウトする話は、意外と聞かなかったように思います。今回が初参加だったので間違っているのかもしれませんが、単純な「スケールアウトできるよね」という話ではなく、むしろ、アプリケーションデベロッパに負担をかけずにスケールアウト (もしくはスケールアップ) するデータベースを、どのように作るか、というところが盛り上がっていたように思います。一方で、クラウドコンピューティングに関しては、サービスをスケールさせる道具というよりは、（リソースの確保が）柔軟で安定したインフラストラクチャとして期待されている側面が大きいように感じました。今後は、両者をどう組み合わ
MySQL Proxy => proxydb + replication
A couple of weeks ago I wrote a lua script to use with the MySQL Proxy that transforms the Proxy into a key=>value lookup dictionary. But I couldn't just stop there. So I decided to add replication to it :). The basic idea is that you have one proxy that acts like a master, it can handle all write/read operations. Once it receives a write query, it will send that query to the slave proxy instances
"The Documents contained within this site may include statements about Oracle's product development plans. Many factors can materially affect Oracle's product development plans and the nature and timing of future product releases. Accordingly, this Information is provided to you solely for information only, is not a commitment to deliver any material, code, or functionality, and should not be reli
Good Bye MySQL 6.0
MySQL 6.0.11-alphaがリリースされた。が、アナウンスレターには気になる記述がひとこと。「これはMySQL 6.0の最後のリリースです」と。寝耳に水かも知れないがこの話は本当だ。実はこれが最後のMySQL 6.0のリリースになる。つまり、MySQL 6.0の開発はこれでストップするのだ。 などと心配しないで頂きたい。MySQLの開発はちゃんと継続される。開発の方針が変更されることになったからMySQL 6.0のリリースが見送られただけである。（ちなみに、次期バージョンはMySQL 5.4で、MySQL 6.0はその次のバージョンになる予定だったものである。といっても、MySQL 5.4は後から間に挿入された形なのだが。）理由は、ここのところMySQLの新バージョンのリリーススケジュールが遅れがちだったり色々と問題があったからだ。（何かが変更されるときは大抵その背景には問題があ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InnoDB performance TODO list