タグ

2012年4月11日のブックマーク (6件)

  • PostgreSQL tuning technique

    PostgreSQLチューニングテクニック集 SELECT ... WHERE foo = 100 ORDER BY barをSELECT ... WHERE foo = 100 ORDER BY i, jに書き換える(2004/08/18掲載) SELECT * FROM t1 WHERE i = 100 ORDER BY j; のようなパターンの検索では,iにインデックスを貼ることである程度の高 速化ができますが,その後でソートが発生し,速度低下の要因になります. SELECT * FROM t1 WHERE i = 100 ORDER BY j LIMIT 5; のように,出力結果件数を制限しかつjにインデックスを貼ると,今度はjのイ ンデックスを使うようになります. しかし,よく考えてみると,iで検索し,jでソートするのはiとjのインデック スの両方を使えば一度にできるはずです

    somat
    somat 2012/04/11
    シーラカンス本第4版のサブページ / 1.検索条件とorder by に使うカラムで複合インデックス/ 2.group by 指定で HashAggregate つかわせる
  • 基礎から理解するデータベースのしくみ(9)

    図10●レコード・クラスタリングの仕組み。ハッシュ値にしたがって,empとemp_histの二つのテーブルで同じenoを持つレコードを一つのテーブルに格納している RDBMSが備えるさまざまな高速化手法 RDBMSは,ここまで説明してきた基的なデータの格納のしかたや操作方法に加え,高速化のための手法をいろいろ用意しています。Part2の最後に,これらの手法をざっと紹介しておきましょう。 ●ハッシュ・インデックス キャッシュ・バッファのサイズや使われ方にもよりますが,一般にBツリー・インデックスを使って巨大なデータベースにアクセスする際には,ルート・ノードだけがキャッシュ・バッファにあるのが普通です。そのため,レコードにたどりつくまでにブランチ・ノード,リーフ・ノード,データベース・レコードと何回もディスクにアクセスしなければなりません。これを1回のアクセスでレコードを取得できるようにしよ

    基礎から理解するデータベースのしくみ(9)
    somat
    somat 2012/04/11
    ハッシュインデックス、レコードクラスタリング、ビットマップインデックス
  • 第7回 性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree | gihyo.jp

    SQLアタマアカデミー 第7回性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree はじめに データベースを扱う仕事をしていると、パフォーマンスの問題に悩まされることは日常茶飯事です。とくに最近は、データベースに格納されるデータ量が飛躍的に増え、サーバのCPUやメモリといったハード面の増強だけでは追いつかないことも多くあります。 そのようなケースに対応するため、DBMSは性能改善のための手段を多く用意しています。その中で最もコストパフォーマンスの良い方法が、インデックス(索引)です。アプリケーションにもハード構成にも影響を与えずに実行でき、うまくいかなければすぐに削除できるという手軽さが大きな魅力で、効果はしばしば絶大です。 インデックスにはいろいろな種類があり、またDBMSによってもサポートする種類に差がありますが、稿では最も重要な2つを取り上げます。それ

    第7回 性能改善の鍵、インデックスの特性を知る~B-treeとハッシュ (1)B-tree | gihyo.jp
  • 第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(3) | gihyo.jp

    実行計画を取得する対象のクエリは、次のような予約の存在する店舗を選択するSELECT文です。 SELECT shop_name FROM Shops S INNER JOIN Reservations R ON S.shop_id = R.shop_id; 結合のアルゴリズム 一般的に、DBMSが結合を行うアルゴリズムは3種類あります。最も基的でシンプルなのがNested Loopです。片方のテーブルを読み込み、その1つのレコードに対して、結合条件に合致するレコードをもう一方のテーブルから読み込みます。手続き型言語で書くと二重ループで実装するので、この名前があります。 2つ目は、Sort Merge[9]です。結合キー(今のケースでは店舗ID)でレコードをソートしてから、順次アクセスを行って2つのテーブルを結合します。結合の前処理として必ずソートを行うので、そのための領域を必要とします。

    第4回 クエリ評価エンジンと実行計画―“シェフおまかせ”はいつも美味しいのか(3) | gihyo.jp
    somat
    somat 2012/04/11
    Oracle, MySQL, PostgreSQL での結合
  • 基礎から理解するデータベースのしくみ(4)

    図4●ネスト・ループ結合アルゴリズム。テーブルAの各レコードについてテーブルBのすべてのレコードと比較します データベースの統計情報は定期的に更新する 基的には,ほとんどの場合にコスト・ベース・アプローチに基づくオプティマイザは最適な実行計画を選択してくれると考えてさほど問題はありません。ただ,コスト・ベースの基になるコストの計算は,テーブルのフィールドの値が均等に分布していると仮定して行います。そのため,データの分布に極端な偏りがある場合などは,実際には全件走査のほうが処理は早く終わるのに,インデックス検索を選択してしまうような場合もあり得ます。 コスト・ベース・アプローチを使って効率の良い実行計画を立てるには,定期的に統計情報を更新することが重要なポイントとなります。統計情報は,あくまでもそれを作成したときのデータベースの状態を反映しています。したがって,統計情報を作成した後にデータ

    基礎から理解するデータベースのしくみ(4)
    somat
    somat 2012/04/11
    "SQL文の処理には,大きく分けて,選択,射影,結合の3種類がありますが,最も負荷が大きいのがこの結合処理", "「ネスト・ループ結合」「マージ結合」「ハッシュ結合」の三つ"
  • Managing infrastructures in the cloud, with lessons learned the hard way