次の要件でMySQLのデータをバックアップする方法を考える。 MySQLのテーブルはInnoDBテーブルオンラインバックアップで、MySQLサーバーを止めずにバックアップするmysqldプロセスの冗長化にはLifeKeeperなどの共有ストレージ型のクラスタリングを採用する この要件に従ってバックアップ方法の検証の手間、管理のし易さなどを検討すると、表の通りとなる。 表 . バックアップ構成検討時の予想検証工数と管理のし易さ
あくまで憶測で仮説でしかないんですが。 MySQL のストレージエンジンのうち代表的な二つ、MyISAM と InnoDB はよく MyISAM: Read は速いけどテーブルロックのため並行性が低い。運用が簡単。 InnoDB: MyISAM より Read は遅いけど並行性が高い 。行レベルロックなので。あとトランザクションや外部キー制約。運用が MyISAM よりちょっとめんどくさい。 という区別がされます。ここから転じて、 MyISAM は参照系クエリが大部分を占める場合に適用すると良い。例えば blog アプリケーションとか。 InnoDB は更新系クエリが多い場合に適用すると良い。 と言わたりします。実践ハイパフォーマンスMySQL でも第2章 ストレージエンジン(テーブル型) P.30 に アプリケーションでトランザクションを使用する必要がなく、主に SELECT または I
基本はInnoDBです。 MyISAMを選択できるようなケースを考えてみます。 ・完全に検索Onlyの場合(基幹系とかから一定間隔で検索用テーブルを再構築する。それ以外の時間は検索のみのようなケース。) ・ログ系のテーブルを出力のみする場合(insertは3~15倍程度MyISAMが高速) 正直、これくらいなのかなと思います。 パフォーマンスについては(5.0.37以上を選択すれば)InnoDBはMyISAMと比べてほとんど同じです。 以下は計測結果です。 InnoDB vs MyISAM パフォーマンス比較 PrimaryKEY、UniqueIndex、非UniqueIndex InnoDB vs MyISAM パフォーマンス比較 取得件数が多い場合 InnoDB vs MyISAM パフォーマンス比較 SELECT ・・・ LIMIT N InnoDB vs MyISAM
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く