MySQL InnoDB Pluginのデータ圧縮機能 - SH2の日記
InnoDB Pluginの面白い機能の一つに、データ圧縮機能があります。今回はその仕組みと効果について見ていきたいと思います。まずはグラフをご覧ください。 これはWikipedia日本語版のデータベースをダウンロードし、記事本文の格納されているtextテーブルをMySQL 5.1＋InnoDB Plugin 1.0の環境にロードしたものです。 元テキスト：今回利用したデータは2009/06/21版のものです(jawiki-20090621-pages-articles.xml.bz2)。元テキストはここからXml2sqlを用いてタブ区切りテキストを取り出したものを用いています。このファイルには1,167,411件の記事が格納されており、容量は3,436MBとなっています。 元テキスト gzip：元テキストをgzipコマンドで圧縮したものです。 MyISAM：記事をMyISAMのテーブルに
ZabbixのDBをMySQLの圧縮機能(Barracuda)で小さくしてみた。
@qryuu たんに教わったやり方にて実際試してみました。 ■my.cnfの書き換え テーブル圧縮を今後デフォルトにする場合は、以下の2行をmy.cnfに追記する。 innodb_file_format = Barracuda innodb_file_per_table = 1 ちなみに圧縮前の状況はこちら。総計 388MB 使っている。 [root@FLAMINGO]/var/lib/mysql/zabbix# ls -l | sort -k5 合計 396432 -rw-rw----. 1 mysql mysql 65 4月 3 14:21 2013 db.opt -rw-rw----. 1 mysql mysql 8602 4月 3 14:21 2013 valuemaps.frm -rw-rw----. 1 mysql mysql 8622 4月 3 14:22 2013 glob
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 つきで回すことで、ビューをイ
Monty が MySQL ユーザに支援要請 - sakaikの日々雑感～(T)編
オラクルのサン買収に関し、MySQLのオリジナル開発者の Monty こと Michael Widenius 氏が、MySQLユーザに向け、支援を要請するメッセージを出しました。 http://monty-says.blogspot.com/2009/12/help-saving-mysql.html （１）これまでに起こったこと(要約) （２）オラクルが約束「しなかったもの」は何か （３）これまでのオラクルの、オープンソースへのふるまい （４）この情報を広めて欲しい （５）EUへの email のサンプル が書かれています。 オラクルによるサン買収が発表された後、これまでにも何度となくメッセージを発信してきた Monty ですが、今回のメッセージはこれまでになく強いメッセージであるという印象を受けました。 以下簡単ですがまとめてみます。あくまで参考程度にしていただくことにして、正確なこと
レプリケーションしてるMySQLで、マスタやスレーブが障害停止した場合のリカバリプラン - （ひ）メモ
MySQLで、レプリケーションベースのHAな構成について考えたメモです。 3台(というか2台＋1台)がいいかなぁと思っていて、前半はその理由を、後半では{マスタ,スレーブ}が{再起不能になった,ちょっとダウンしてすぐ復帰した}場合のリカバリプランについて書きます。 今のところはこれがベストかなと思っているのですが、「こうしたほうがいいと思う！」「ここがおかしい！」などなどのご意見はコメント、TBなどでいただけるとうれしいです。 ゴール マスタが落ちてもぐーすか寝ていられるようにしたい リカバリの作業はできるだけ単純に、かつ、短時間で完了するようにしたい めんどくさいのはいや 基本構成、方針 2台＋1台 サービスで使うのは2台 (db1, db2) もう1台は管理用 (db3) スレーブを多数並べる構成にはしない 台数増えると管理コストが上がる マスタダウン時のフェイルオーバとそのフェイルバ
MySQL Cluster進化の歴史
MySQL Cluster開発者の一人であるFrazer Clement氏がその歴史についてとても興味深いエントリを自身のブログで綴っているのだが、いかんせん英語の長文で日本人には辛いかも知れないので今日はその日本語訳を皆さんにも紹介しようと思う。進化の歴史とその結果生じた構造を知ることにより、MySQL Clusterの仕組みに興味を持って頂けると幸いである。（わかり辛いところにはところどころ訳者による注釈を入れてある。ただし翻訳は結構大ざっぱなので、英語が達者であれば細かいニュアンスなどはオリジナルのエントリを参照して頂きたい。なお、日本語訳をすることに関してはFrazer氏の了解を得ているのであしからず。） NDB（MySQL Clusterの略称。元々はNetwork DBという名称であった。）の開発の正確な歴史について、きっと他の誰かのほうが上手く解説できると思うのだが、限られて
Excelファイルからデータベースにインポートする·dbTube MOONGIFT
Excelで作ったデータをデータベースに取り込む、なんて要件はよくある。面倒だがExcelデータをCSVに変換して、1番目のカラムが名称、2番目のカラムが価格…なんて定義したりした経験はないだろうか。 ビジュアル的にデータのインポートを定義する それがさらに関連しているテーブルに渡って処理しないといけないなんてなったらパニックだ。そこで使ってみたいのがdbTubeだ。 今回紹介するフリーウェアはdbTube、ビジュアル的にモデル定義ができるインポートプログラムだ。ソースコードは公開されているがライセンスは明記されていなかったのでご注意いただきたい。 dbTubeの良さは何と言ってもビジュアル的にデータの定義ができることだ。Open-jACOB Draw2Dを使って元になるExcelデータとテーブルのマッピングがドラッグアンドドロップでできる。さらにExcelデータは何行目から読み出すかと言
Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件
大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名：アプリケーションレベルパーティショニング／レベル２分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加（とそれにともなう負荷の再分散）が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:
MySQL Connector/Jにおける大量INSERTのチューニング - SH2の日記
ピンポイントチューニング講座です。まずは結果から。 このグラフは、以下のテーブルに50,000レコードINSERTしたときの処理時間を示したものです。性能に70倍以上もの差が出ているのはなぜか、見ていきたいと思います。 CREATE TABLE `loadtest` ( `id` int(11) NOT NULL, `data` varchar(100) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 方法1 ベースライン conn = DriverManager.getConnection(JDBC_URL, JDBC_USER, JDBC_PASS); pstmt = conn.prepareStatement("insert into loadtest (id, data) values (?
LINEAR HASHパーティショニングってなんだ？
MySQL 5.1から利用出来るパーティショニングの種類には、次の4つがある。 RANGEパーティショニング LISTパーティショニング [LINEAR] HASHパーティショニング [LINEAR] KEYパーティショニング RANGEパーティショニングは値の範囲を指定する。次のように日付を用いて範囲を指定するのが代表的な使い方だ。詳細はこちらの記事（パーティショニングの使用例 - http session情報）を見て欲しい。 mysql> CREATE TABLE http_session ( -> session_id VARCHAR(32) NOT NULL, -> last_access TIMESTAMP NOT NULL, -> created TIMESTAMP NOT NULL, -> t_session_data VARCHAR(1024) -> ...(中略)...
MySQLがフォークか、オープンアライアンスが誕生 － ＠IT
2009/05/14 オラクルによるサン・マイクロシステムズ買収で注目が集まるOSSプロダクトの1つ「MySQL」に異変が起きている。MySQLのオリジナル開発者で創業者でもあるマイケル・ウィデニウス（Michael Widenius）氏は5月13日、オープンソースコミュニティベースでMySQL関連の開発やサポートを行うためのハブとなる「The Open Database Alliance」（ODA）の設立を発表した。 PostgreSQLと並んでオープンソース界でデータベース製品のデファクトスタンダードとなっているMySQLは、サン・マイクロシステムズに2008年1月に買収されたことで同社の一部門に。その後、2009年4月にオラクルがサン・マイクロシステムズを買収すると発表したことから、開発体制やライセンスモデルなどを巡って憂慮の声や憶測が流れていた。オラクルのデータベース製品との整合性
hansode.org - このウェブサイトは販売用です！ - hansode リソースおよび情報
このウェブサイトは販売用です！ hansode.org は、あなたがお探しの情報の全ての最新かつ最適なソースです。一般トピックからここから検索できる内容は、hansode.orgが全てとなります。あなたがお探しの内容が見つかることを願っています！
MySQLのパフォーマンスチューニング - モノノフ日記
とある勉強会でSunのエンジニアの人のプレゼンを直接聞く機会があったのでメモったことを公開します。基本的な事が多いんだろうけど、非常に参考になりました。 パフォーマンスとは スループット レスポンスタイム/レイテンシ スケーラビリティ 上記のコンビネーション アーキテクチャとは Connection Thread Pool Query Cache Parser SQLクエリをパース Optimizer Storage Engines アプリによって最適なエンジンを選択すべき サーバのコネクション&スレッド my.cnf max_connection (100) 多すぎるとメモリを消費しきる可能性あり thread_cache_size (8) スレッドをコネクションの切断後にもキャッシュしておく数 一般的には max_connections / 3 sort_buffer_size(2M)
やってはいけない!!MySQLに悲鳴をあげさせる10の方法
いつも「MySQLを使うときはこうするべき」という観点から記事を書いているが、今日は逆に犯してはいけない過ちをリストアップしようと思う。 1. 全てのカラムにインデックスをつけるデータベース初心者がもっともやってしまいがちな間違いはコレではないだろうか。インデックスはいい。検索がとても速くなるから。しかし、それと引き替えにインデックスは更新するときにコストがかかるし、その分多くのディスクスペースを消費する。特に更新にかかるコストは時に甚大で、該当するインデックスのページがキャッシュ上にない場合はディスクからいったんそのページを読み込まなければいけない。ディスクアクセスは動作にとても時間がかかるので、インデックスが多数、例えば全てのカラムに付いていたりすると「あれ？固まったか？」というような状態になってしまうことがあるだろう。インデックスは必要なカラムにだけつけるようにテーブルを設計しよう。
MySQLレプリケーションを安全に利用するための10のテクニック
MySQLのレプリケーションは非常に簡単に使える割には応用の幅が広いので非常に人気のある機能の一つである。レプリケーションの応用分野は例えば、 バックアップ 参照系の負荷分散 HA（高可用性） ディザスタリカバリ（サイト間レプリケーション） BI（レポーティングetc） という風にとても多くのバリエーションがある。このブログを読んで頂いている皆さんの中にもレプリケーションを使っている方は多いのではないだろうか。ご覧の通りMySQLのレプリケーション機能はミッションクリティカル分野でも利用されているが、レプリケーションの使い方が適切でないとシステムの安定稼働に支障を来してしまってDBAやシステム管理者の肉体的、精神的負担が増大してしまう。逆にレプリケーションを堅牢に運用することが出来ればマクラを高くして眠れるというものだ。レプリケーションはMySQLの代表的な機能であるので、レプリケーション
さらにMySQLを高速化する7つの方法
MySQLを高速化する10の方法という記事がとても好評だったようである。記事を読んで頂いた皆さん、ありがとう。 この記事に対する便乗（？）でWeb屋のネタ帳: PostgreSQLを高速化する16のポイントという記事を書いて頂いたようだが、そちらの方もかなり人気だったようである。他人が作ったソフトウェアに改良を加えるというフリーソフトウェアやオープンソースソフトウェアの精神も基本は便乗であるので、便乗については大いに賛成したいというかむしろ取り上げてくれてありがとう！！と思うわけであるが、ここでさらに俺はこう考える。 と。 Web屋のネタ帳さんの記事では16のポイントが紹介されているが、漢（オトコ）のコンピュータ道の記事は10の方法だったのであと6つ足りない。オトコは数で勝負！！というわけで今日はネタを振り絞ってさらに7つのMySQL高速化テクニックを紹介しよう。 1. インテルコンパイラ
漢(オトコ)のコンピュータ道: MySQLを高速化する10の方法
ちょっとキャッチ−なタイトルをつけてしまったが、今日は独断と偏見でMySQLを高速化する方法を10個紹介しよう。MySQLサーバをチューニングするときや初期導入する場合などに参考にしてもらいたい。 1. バッファを増やす、または減らす チューニングの基本中の基本であるが、適切なバッファサイズを設定することはパフォーマンスチューニングの要である。主なバッファは次の通り。 innodb_buffer_pool_size・・・InnoDBだけを利用する場合は空きメモリの7〜8割程度を割り当てる最も重要なバッファである。余談だが、実際にはここで割り当てた値の5〜10%ぐらいを多めにメモリを使うので注意が必要だ。 key_buffer_size・・・MyISAMだけを利用する場合は、空きメモリの3割程度を割り当てるといい。残りはファイルシステムのキャッシュ用に残しておこう。 sort_buffer_
Ruby on Rails + MySQL で全文検索 - ドワンゴ 研究開発ブログ
このエントリでは Ruby on Rails と MySQL を使って日本語の全文検索を行う方法を記述する。Ruby on Rails のバージョンは 2.0.2、MySQL のバージョンは 5.0.67、Tritonn のバージョンは 1.0.12、Hyper Estraier のバージョンは 1.4.10 を使用した。サンプルの文章データとして、あらゆる日本人にとって極めて身近な著作権切れ文章である『ドグラ・マグラ』と『黒死館殺人事件』を利用した。処理のために整形したデータは本エントリに添付しておく。またデータベースへアクセスするコードではマイグレーションを除きできるだけベンチマークを取るようにし、その結果は本エントリの最後に記載する。 ページネーション Rails でページネーションを実現する will_paginate という plugin は ActiveRecord に標準でつ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MyNA Web Site
DRBD:What is DRBD
