mysql:11696
From: zen kishimoto <zen kishimoto <zen@xxxxxxxxxx>>
Date: Wed, 06 Jul 2005 15:39:15 -0700
Subject: [mysql 11696] MySQL: デジタル・ライブラリー構築で学んだレッスン
MySQL: デジタル・ライブラリー構築で学んだレッスン http://csdl2.computer.org/comp/mags/so/2005/03/s3010.pdf 注:長文のため抜粋のみ。機能比較のテーブルは有益(この文 では省略) 出典IEEE Software Mariella Di Giacommo著, Los Alamos 研究所 最近オープンソースのデータベースが機能も充実してきて 商業データベースと肩を並べるようになった。2つの 代表的なオープンソースのデータベースはMySQLとPostgreSQLである。 Los Alamos 研究所ではMySQLを広く使用してきた。最近 デジタル・ライブラリーを構築するにあたり、MySQL を使用してその長所とユニークな機能について述べる。 デジタル・ライブラリーの要求 まづはRDBとしての機能が上げられる。 1.複数ユーザによる同時アクセス 2.複数言語によるアクセス(ODCやJDC) 3.トランザクションもサポート 4.高度な検索 5.オンライン・バックアップ 6.多量データを高性能でサポート 7.リプリケーション その他 * コマーシャル的なサポート * 完全なロギング その他大切なことはライセンスと値段である。値段と サポートからMySQLを選択した。選択理由の詳細は 1.インストレーションと管理が容易。サポートが良い 2.種々のストレッジ・エンジンを搭載し選択可能 3.速い 4.耐障害性、負荷分散、リプリケーション 製品比較 http://csdl2.computer.org/comp/mags/so/2005/03/s3010.pdf のテーブルを参照 Oracle, MSSQL, MySQLとPostgreSQL間に大きな機能の違いはない。 コマーシャル版にあってオープンソース側にない機能は 確かにあるが、このプロジェクトには必要なかった。 PostgreSQLでなくMySQLを選択した理由はスケーラビリティ と組み込まれたリプリケーションのため。 結果 5500万件の記事と6億個のレファレンスをサポートする。 リプリケーション MySQLのリプリケーションは良く機能するが、スクリプトを 提供しないので、サーバーとの通信が途絶えたりした際の 状況をモニターできない。このため独自のスクリプトを 開発した。その後、MySQL::ReplicationやMy::Rep::MySQL Perlなどのモジュールも提供されるようになった。 最適化 システムの根本を知るのが最適化の中心。 インデクシング クエリの高速化を進める上で重要な機能。インデクスをすべて B-treeで格納。関連のある列にインデクスを使用するのが クエリをスピードアップする最良の方法。MySQLでは複数 の列にもインデクスを定義できる。但し、インデクスに 頼りすぎるのも問題。インデクスの追加はディスク領域 を消費しwriteのオペレーションの性能を下げる。テーブル の内容が変るとインデクスもアップデートが必要。 インデクスの数が増えると、性能もおちる。 ディスクの問題 莫大な量のデータを取り扱う際にはディスクへのアクセスは 大事になる。キャッシングは殆ど不可能となり、データへ のアクセスで性能が支配される。テーブルやデータベースを MySQLのディレクトリーから移動することができる。通常は データベースをsymbolic linkで移動する。しかし、データベース が大きくなってくると、テーブルの一部もsymbolic linkを 使用して移動することが必要となる。ここで重要なのは 4.0以前の版ではALTER, REPAIRやOPTIMIZE TABLEは symbolic linkを切って本当のファイルと入れ替えてしまう ことを知っているべきだ。 クエリの処理 クエリが複雑な場合MySQLがどのようにデータを拾ってくるか のルールを理解するのが困難な場合がある。しかし、大きく 分けて2つのルールがある。MySQLはテーブルをスキャンした 方が速いと判断するとインデクスを使用しない。複数個の クエリがあった場合、一番限定的なものを使用して、一番 数の少ない結果を返還する。選択しようとしているコラムが 全てインデクスの一部の場合、インデクスからデータを入手し テーブルには一切触れない。複数個のテーブルをjoinする場合 MySQLは一番返還する行の数が少ないテーブルから処理を始める。 与えたテーブルの順番は必ずしもMySQLが処理する順番では ないので、ORDER BYをつけることが肝要。とはいうものの 時としてMySQLの処理はランダムのように見える。EXPLAIN を使用するとどのように処理しているか分かる。しかしながら、 インデクスの使用、未使用に関しては完全にコントロールできる。 クエリの処理とLIMITクローズ LIMITクローズは返還される行の数を制限できるので、 ウエブでの検索のときに役にたつ。LIMITとSELECTとを 組み合わせるとリクエストされた行の数と場所に応じて クエリを異なった方法で処理する。行の数が少ないと インデクスを使用して、完全なテーブルのスキャンなど は行はない。LIMITを使用した場合(MySQLに限らず)返還 された塊に重複がある場合がある。それを避ける ためにはORDER BYを使用してソートする必要がある。 クエリの問題 コラムインデクスをチェックして、追加することで、遅い SELECT .... WHERE のようなクエリのスピードアップを はかることができる。これはWHEREクローズの内容を 簡単にしてSELECT側に移動することで達成できる。 結論 MySQLの速いという評判は本当で、15億の行をリンクする大量の データを扱う状況で問題なく作動した。リプリケーションの 機能を利用して負荷を分散し、耐障害性を補強し、データを保護し アップデートした。我々の経験はMySQLをプロモートするのに 十分使用できる。 -- Zen Kishimoto www.ipdevices.com IP Devices, Inc. zen@xxxxxxxxxx 2175 De La Cruz Blvd., Suite 10 (408) 567-9391 Santa Clara, CA 95050 (801) 720-8847 (FAX)