2010年 1月 1日 「実践編-15 『INDEX-only』 と 『null-key』」 を読む >> 目次にもどる

 

 本編では、B-tree 構造には、以下の 2つの弱点があることを指摘しています。

  (1) たぐる

  (2) ゆらぐ

 セット・アット・ア・タイム 法に上積みされた indexing (B-tree) 構造は、「上積み」 と謂ったように、そもそも、コッド 関係 モデル とは関係がない。言い換えれば、プロダクト としての RDB は、その内部構造において index を識別できない。試しに、以下の テスト を実施してみればいい。

  (1) { a, b, c } という 3つの column を用意する。

  (2) それらの columns に対して以下の index-key を作る。

     CREATE INDEX (a, b, c) [ by ascending ]. (昇順)

  (3) 次に、それらの columns に対して以下の index-key を作る。

     CREATE INDEX (a, b, c) [ by dscending ]. (降順)

 そして、たとえば、ORACLE あるいは DB2 において、(3) の index-key を使って、(a, b, c) を 「降順」 で表示してみてください──昇順でしか表示されないでしょう。

 すなわち、同じ column(s) に対して create index を定義すれば──たとえ、by ascending と by dscending として条件を変えたとしても──、optimizer は、ふたつの index を見分けることができない。もし、indexing が RDB の internals として構成されていれば、それらの indexes を べつべつのものとして扱うはずです。indexing は、RDB (正確に言えば、テーブル 構造を基底にした セット・アット・ア・タイム 法) と無関係です。

 そこで、上積みされた indexing を使って view を構成するのが 「INDEX-only」 です。つまり、CREATE VIEW (a, b, c) の代わりに CREATE INDEX (a, b, c) を定義して、SELECT (および JOIN) を実行する、ということ。そうすれば、セット・アット・ア・タイム 法の弱点である traversal table を生成しないで、高 レスポンス を実現できます。ただし、「INDEX-only」 では、前述した 「同じ column(s) に対する by ascending と by dscending のちがい」 を optimizer は認識しないので、しかるべき対応を講じます (その対応法は、本 エッセー では割愛します)。

 B-tree を たぐらないようにするためには、null-key を使って、「木」 上において、対象外となっている道を除去します──ただし、null-key は B-tree から除去されるということが前提です [ たいがいの RDB は、そうしていますが、そうしない RDB もあるようです ]。null-key の使いかたは、RDB の マニュアル を読んでください。

 B-tree が揺らぐ原因は、たいがい、付値 (データ の値) にあると思っていいでしょう。例えば、以下を考えてみます。

 (1) 「取引先」 テーブル の基数 (データ 件数) は 100 である。

 (2) 「受注」 テーブル の基数は 1,000 である。

 (3) 取引先 a は、受注の 30% を占めている。

 (4) 取引先 a に対して、取引先番号の値を 0001 としていて、取引先 データ のなかで下組にいる。

 さて、「取引先」 と 「受注」 の割合は、「100 対 1,000」 で、平均すれば、ひとつの取引先には、10 の受注があることになりますが、取引先 a は受注の 30% を占めているので、「偏り (skewness)」 が生じています。しかも、取引先 a の番号には 001 が付値されていて、「取引先」 のなかで下組に属しているので、index-key として、(取引先番号, 受注番号) を作れば、取引先 a は indexing の B-tree (leaf) のなかで前方に格納されます。今後も、取引が、この 「偏り」 で実施されれば、取引先 a の受注があるたびに、(取引先番号, 受注番号) の low-level index は split します──したがって、high-level index が再編成される頻度も増えるでしょう。こういう事態に対しては、しかるべき対応を講じなければならない (その対応法は、本 エッセーでは割愛します)。

 「INDEX-only」 は高 レスポンス を実現しますが、万能ではない。「INDEX-only」 の使用上の注意点を本編で示しておきました。データ が すべて メモリー 内に格納されるのであれば、「INDEX-only」 などという テクニック は無用です。

 
(参考)

ひとつの集合 (セット) A を、たとえば、ふたつの組 A1 A2 に分けることを 「切断」 といい、( A1, A2 ) で表わします。A1 に属する メンバー の値は A2 に属する どの メンバー の値よりも小さい。A2 を 「上組 (上級)」 と云い、A1 を 「下組 (下級)」 と云います。

 



  << もどる HOME すすむ >>
  目次にもどる