Database Lecture 6/10

宿題の答
Mini-SQL
絵の入ったメールの出し方

Mini-SQLの使い方(つづき)

min, max, avg, sum, count などの表全体を対象とする演算
レコードの存在を調べる exists
レコードのグループを作る group-by
projectionやjoinなどを使って仮想的なrelationを作る view
SQL のネスト
自分自身とのjoinができる、名前付きの表

商用のRDBは、数十万から数百万。もにによってはそれ以上の値段がするのが普通だ。しかし、今では、Personal Oracle のような製品が一時代前のメインフレームRDBをうわまる能力を持っている。

そういうものを使う時には、マニュアルを読めば良い。だが、RDBのイメージを持っていなければ、きっと歯が立たない。ここでの授業ではセコイSQLしか使えないけど、そういうRDBやSQLのイメージをちゃんと持っていれば、どんなRDBでも使いこなせるはずだ。そう思ってがまんして使って下さい。

機能の低いMini-SQLだが、一つ、それを補う方法がある。それは、他のプログラミング言語からMini-SQLを呼び出すことである。

Mini-SQLのAPI

msql は、結局、簡易なインタフェースに過ぎない。これを使ってできることは限られている。実際には、WWWに結果を表示したり、きれいなレポートを提出したり、QBEのfront endを付けたり、あるいは「すごい」GUIを付けて高く売ったりしたい。そのためにAPI が必要となる。

APIは通常は、OSごとの互換性はまったくない。なにも互換性のことを考えずに、OSや、良く使われる言語を対象に設計されている。それはあるい意味ではアセンブラレベルで定義されている。

では、互換性はまったくないならAPIを使う意味はないのだろうか? いや、実際には、APIの背後には、Mini-SQLの実装モデルがあり、それは、どの機械でも同一だということができる。実際、C言語に対する APIが定義されていれば、それはさまざまなOS上で実質的な互換性を持つことができる。

例えば、Mini-SQL をCから使う手順は以下のようになる。

if ((sock = msqlConnect(host)) < 0)
{
        fprintf(stderr,"ERROR : %s\n",msqlErrMsg);
        exit(1);
}
if (msqlSelectDB(sock, database) < 0)
{
        printf("ERROR : %s\n",msqlErrMsg);
        exit(1);
}

このserverに対して、SQLのqueryを出すには、q という変数にSQL文を含む文字列を代入して以下のように呼び出す。

if (msqlQuery(sock,q) < 0)
{
        printf("\n\nERROR : %s\n\n",msqlErrMsg);
        return;
}
printf("\nQuery OK.\n\n");

m_result *result;
result = msqlStoreResult();
if (!result)
{
        printf("\n\n"); 
        return;
}
printf("%d rows matched.\n\n",msqlNumRows(result));

準備がすんだら、答を一レコードごとに呼び出す。その前に、フィールド名を取ってこなくてはならない。

m_field *curField;
while((curField = msqlFetchField(result))) {
   ...
}

typedef struct field_s {
        char    *name,
                *table;
        int     type,
                length,
                flags;
} m_field;

while ((cur = msqlFetchRow(result))) {
   for(off=0;off < msqlNumFields(result);off++) {
     printf("%s\n",cur[off]);
   }
}

このようにして、すべてのフィールドを読み終ったら、

msqlFreeResult(result);
msqlClose(sock);

このCのAPIを利用して、他のAPIも作ることができる。例えば、Perl のAPIを使えば、WWWからMini-SQLをアクセスするようなことができるはずである。

Mini-SQLの実装

% ls /usr/open/Minerva/msqldb/test
test.dat*              アカウント.key*        データベース工学.dat*
test.def*              アカウント.stk*        データベース工学.def*
test.key*              アンケート.dat*        データベース工学.key*
test.stk*              アンケート.def*        データベース工学.stk*
test2.dat*             アンケート.key*        学生.dat*
test2.def*             アンケート.stk*        学生.def*
test2.key*             ソフトウェア工学.dat*  学生.key*
test2.stk*             ソフトウェア工学.def*  学生.stk*
アカウント.dat*        ソフトウェア工学.key*
アカウント.def*        ソフトウェア工学.stk*

ソフトウェア工学.dat
ソフトウェア工学.def
ソフトウェア工学.key
ソフトウェア工学.stk

実際のMini-SQLでは、表のほとんどはメモリ上にキャッシュされる。現在のデータベースの実装は、教科書に乗っているB-Treeなどよりも、ハッシュインデックス、データを入れたファイル、そして、メモリ上のキャシュという構成であることが多い。Disk上の構成をいくら工夫してもメモリ上のキャッシュにはかなわないからである。

このような構成は特にClinet / Server形式で有効である。これとは、別にディスク上の実体をただ一つとして、その上に複数のデータベースマネージャーを置く方法もあるが、少し時代遅れだろう。その場合はディスクを経由して、複数のマネージャーの同期をとらなければならない。例えば、Unixのメールは、そのような方法を取っている。しかし、popper を使えば、Clinet / Server 形式でメールを読み書きすることもできる。

さらに応答性能を上げたい場合には、メモリ上のキャッシュを共有した Multi-Thread (メモリを共有した平行プロセス) を複数走らせる方法がある。現在のデータベースはこれが主流だと考えられる。一つは、これだと安く実装できるからである。しかし、このようなメモリあるいはディスクを共有する方法では以下のような平行制御の問題に注意して実装をおこなう必要がある。

一方、キャッシュには常に「消えてしまう」という欠点がある。もし、データベースの信頼性が重要ならば、ディスク上のデータとデータベースは常に一致してほしい。しかし、その要求と高速なアクセスとを両立させるのは難しい。一つの方法は、ディスクを複数並べて、その上にプロセッサを対応させる方法である。ディスクが別にある場合はRAID (Rapid Array of Inexpensive Disks)と呼ばれ、ディスクとプロセッサの組がネットワークでつながれているような場合は、Shared Nothing などと呼ばれる。

データベースはものすごい速度で進歩しており、コンピュータアーキテクチャの進歩に応じて変化している。これらの変化に敏感でいよう。

平行制御

[操作A] 
select count from test
 where name='kono'

[操作B] 
ここでcountを1増やす。例えば、256

[操作C] 
insert into test ( name, count)
        values ( 'kono', 256)

count は 256
[操作A]  by User A
[操作A]  by User B
[操作B]  by User A
[操作B]  by User B
[操作C]  by User A
[操作C]  by User B
count は ?

直列可能性が成立していれば、データベースはトランザクションの変更の積み重ねとなる。これは、トランザクションの持っているデータの関連からデータベース全体の関連ができていることを意味する。これをデータベースの無矛盾性(Consistency)という。ある条件のもとでConsistencyとSerializabilityは同値であることが証明されている。

これは、a1a2,b1b2 の二つのトランザクションが、s1→ s2の順序に依存する b1b2→ a1a2 という順序と、s2→ s3 によって生じる a1a2→ b1b2 という順序が矛盾していることから生じている。

前の人の値を上書きしているという単純なことだが、このように依存関係の矢印を書くことによって、より矛盾が明快になる。また、機械的に矛盾を見つける手順を提供することもできる。あたり前のことを明確にすることがコンピュータサイエンスでは重要なことが多い。

これを防ぐためにはいくつか方法がある。

a1a2などのトランザクションを初めから順番付けしてしまう
a1 を始める時に、lock をかけて他の人がアクセスできないようにする

後者の方法は良く使われるが、二つの問題がある。

何に対してlockをかけるのか?
Dead Lock, Live Lock

lockの単位としては以下のようなものが考えられる。

データベース単位 (大きすぎる)
リレーション単位
レコード単位
読み書きでさらに分ける
読み書きの可能性でさらに分ける

Dead lockを避けるには、一つはリソースかトランザクションに順序を付け、順序にそってlock をかけていく方法がある。そうすれば、最初にもっとも順序の大きいリソースを確保したものが必ず処理を行うとすれば良い。この時には、相手のlockを解除しなければならない場合もある。

また、単にlockをかけただけでは直列可能性は保証されない。このために良く使われるのは、2相lockというものである。これは、まず、必要なリソースに順番にlockをかけ、操作が終わったら順にlock をはずすというものである。lockをかけたりはずしたりすると、途中で割り込まれたりするので気まずいのだ。

もう一つlive lockというのがある。一つのリソースのlockが取れなかった時に普通は、しばらくあけて、もう一度lockをかけにいく。この時に、二つのトランザクションが両方で同じことをしていることがありえる。これは例えば、二人で相手の家に同時に電話をかけることによって実現することができる。

live lockは避けられないものであるが、実装の工夫によってある程度緩和できる。その意味で深刻度は低い。しかしdead lockは必ず起きるものなので、なんらかの方策を用意しなければならない。

Prev Next Kono's home page