タグ

mysqlに関するaprlのブックマーク (126)

  • InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ

    http://www.mysql-ucj2007.jp/details/j25.html 木下 靖文 氏 NTTコムウェア株式会社 プロジェクト管理統括部技術SE部門 DB技術グループ (「InnoDB」は「いんのでーびー」と言うらしい...今まで「いのでーびー」と言ってました) InnoDBをなぜ使うか トランザクション コミット、ロールバック、セーブポイント 外部キー 行レベルロック オンラインバックアップ クラッシュリカバリ クラッシュリカバリ MyISAMはデータ量の増大とともに時間がかかる InnoDBはデータ量の増大との相関がない InnoDBチューニングの王道的アプローチ クエリを改善して全体的に処理効率を上げる データサイズをできるだけ小さく メモリをできるだけ多く積む コミット性能(同期書き込み) innodb_flush_log_at_trx_commit=1,0,2

    InnoDB のパフォーマンスチューニング - MySQLカンファレンス2007 - akiyan.com 管理人メモ
    aprl
    aprl 2007/12/23
    MySQL5.1では、インデックス領域だけの再作成ができるようになり、インデックスの追加/削除が高速になる
  • InnoDBのflush_methodによる違い - フツーな日常

    パラメータで言うとinnodb_flush_method っていう奴。 ようはトランザクションログなどをディスクに反映するときにfsync(2)を使うか、そもそもファイルをopen(2)するときにカーネルのバッファをバイパスするようなオプションを使うかの違い。デフォルトだとfsyncdataになるため前者になるが、Linuxの場合O_DIRECTを指定することで後者の動作となる。 InnoDBはI/Oのバッファリングを独自に行うことが出来るので、OSが提供するキャッシュを切ってしまった方がメモリの無駄が少ない。 例によって使ったベンチマークはsysbench-0.4.8、MySQLは5.0.37 Threads fdatasync O_DIRECT 1 19.8 20.31 2 20.88 21.04 3 21.06 20.64 4 20.89 20.78 5 21.15 21.03 6

    InnoDBのflush_methodによる違い - フツーな日常
    aprl
    aprl 2007/12/23
    InnoDBはI/Oのバッファリングを独自に行うことが出来るので、OSが提供するキャッシュを切ってしまった方がメモリの無駄が少ない。使ったベンチマークはsysbench-0.4.8、MySQLは5.0.37
  • Pluggable Storage Engineのオーバーヘッドとエンジン別性能比較 - mir the developer

    Pluggable Storage Engineはdynamic linkなのでオーバーヘッドがどれくらいなのか気になって調べることにしました。 先に結論を述べておくと、Pluggable化そのものはあまり気にしなくて良さそうです。 測定にはこんな感じでmysqlslapを使いました。同時に100個のスレッドが1000回ずつ処理を行います。 ./mysqlslap --iterations=1000 --concurrency=100 --auto-generate-sql --engine=myisam,tritonnここで使用しているtritonnエンジンはmyisamをpluggable化しただけのエンジンです。まだSenna呼出機能とか持っていません。 まずmyisam(built-in myisam)ですが、こんな結果になりました。 Benchmark Running for e

    Pluggable Storage Engineのオーバーヘッドとエンジン別性能比較 - mir the developer
    aprl
    aprl 2007/12/23
    測定にはmysqlslapを使いました。同時に100個のスレッドが1000回ずつ処理を行います。myisam(built-in myisam)とtritonn(pluggable myisam)ですが、ほとんど差がありません。
  • MySQL ABのディレクターが明かす「MySQL 5.1」の魅力

    企業システムにおけるオープンソースソフトウェア(以下、OSS)の活用が叫ばれて久しい。一部では大規模な基幹システムへの採用事例もあるが、全般的に導入は進んでいない。特に、企業システムのエンジンとなるRDBMSとなると商用製品がほとんどである。 しかし、ミクシィや楽天をはじめとするWeb系企業の多くでは、RDBMSを含めOSSを中心にシステムが構築されている。せっかくの公共財である。一般企業においても利用できる場面がないか、いま一度目を向けてみてはどうだろう。そこで注目したいのが、Web系企業ではRDBMSの業界標準となってきたMySQLである。 処理性能こそ高いが、商用製品に比べると機能的に劣るとされてきたMySQLだが、ここにきて急速にキャッチアップしようとしている。2008年に登場予定の最新バージョン「MySQL 5.1」ではその機能差が改善される見込みで、データウェアハウス(以下、D

    MySQL ABのディレクターが明かす「MySQL 5.1」の魅力
    aprl
    aprl 2007/12/23
    MySQL 5.1のパーティショニング機能は、アプリケーションに手を入れることなく1つのDB内でテーブルを分割できるため、スケールアップで対処。MySQL 5.1からは、ディスク内のデータをベースにしたクラスタ構成が可能
  • MySQL/PostgreSQL+Sennaで行うラクラク全文検索……Tritonn&Ludia導入のポイント | gihyo.jp

    Tritonn、Ludia、そしてSennaとは…… 昨今のWeb 2.0と呼ばれるようなWebシステムでは、一般的に大量のコンテンツデータを内部に保有しているのではないでしょうか。大量のコンテンツから目的のコンテンツをユーザが選び取る手段の一つとして全文検索が挙げられます。全文検索とは、検索対象コンテンツの中身すべてに対して検索を行うことを指します。たとえば、タグやタイトルを対象にした検索だけでは、目的のコンテンツを発見できないような場合に有効な検索です。 データベースに保持された大量のデータを簡単に全文検索したい、という場合も多いことでしょう。稿では、それを実現にする全文検索システムとして、次の2つを取り上げて紹介します。 Tritonn Ludia これらはそれぞれ、Tritonnは「MySQL⁠」⁠、Ludiaは「PostgreSQL」という、Webシステムを開発する上で人気の高

    MySQL/PostgreSQL+Sennaで行うラクラク全文検索……Tritonn&Ludia導入のポイント | gihyo.jp
    aprl
    aprl 2007/12/23
    Tritonnは「MySQL」,Ludiaは「PostgreSQL」という,Webシステムを開発する上で人気の高いDBMSで簡単に全文検索を行えるように改良したシステムです。
  • koyachiの日記 - Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳

    del.icio.us見てたら面白いファイルがあったので訳しながらはてな記法ワープロでメモったものを公開します。2005/10/18-25に行われたZend/PHP Conference & ExpoにてFlickrのJohn Allspaw氏が発表されたプレゼンの内容のようです。英語読めるヒトは物のほうをご覧ください。そもそもプレゼンなので長文はほとんどないし、図も入ってるので。天丼に親近感を覚えました。 あと はてな記法ワープロいいですね。ついでにはてな記法なプレゼンツールも是非作ってください!!! 普通にSQL書いてMySQL使うのは出来るけど負荷とかほとんど考えたことないなーと思って「実践ハイパフォーマンスMySQL」読んでたところでhttp://del.icio.us/tag/flickr+mysqlあたりで見つけました。「実践ハイパフォーマンスMySQL」だと6章から9章辺り

    koyachiの日記 - Flickrの中のヒトのLAMP構成プレゼン(Hardware Layouts for LAMP Installations)訳
    aprl
    aprl 2005/11/27
    「実践ハイパフォーマンスMySQL」読んでたところでhttp://del.icio.us/tag/flickr+mysqlあたりで見つけました。ロードバランシング以降の話(port exhaustion,10k vs 15k drive, SQUID辺りの具体的な数値とか)は知らなかったので勉強になりました