待ち時間をなくす工夫
表ロックと行ロック
排他制御のように、データが正しいことを保証するため、更新しようとするデータを保護しておく仕組みを、データベースでは「ロック」と呼びます。Aさんが何らかのデータを更新しようとしたとき、このデータをロックしてしまえば、Aさんがロックを解除するまでBさんはアクセスできません。つまり、Aさんの一連の処理（トランザクション）が終わるまでBさんは待つことになります。
しかし、Aさんの作業内容によっては、Bさんは長時間待たされる可能性があります。そこで、可能な限りロック時間を短くすることを考えます。このとき、「表ロック」と「行ロック」という考え方があります。表ロックでは該当のテーブルを利用している全員がAさんのロック解除を待たなければなりません。これでは非常に効率が悪いでしょう。一方、行ロックは行単位でロックするため、Aさんが更新した行以外はほかの人もアクセスできます。
処理を待ち続ける「デッドロック」
ただし、このように行ロックにしても、待たされる状況は発生します。例えば、デッドロックと呼ばれる現象です。例として、複数の口座の間で2人がそれぞれに送金する場面を考えてみます（図4）。
Aさんは自分の口座から出金し、Bさんの口座に入金しようとしています。一方で、Bさんも、自分の口座からAさんの口座に入金しようとしています。このときAさんとBさんが同時に出金しても、別の口座なのでロックはかかりません。しかし、相手の口座に入金しようとすると、それぞれの持ち主が利用中なのでロックされています。すなわち、同時に入金しようとすると、いずれも相手の処理を待っている状況が永遠に続きます。いずれの処理も途中で中断すると整合性が確保できないためロックが解除できず、この状態をデッドロックと呼びます。
対策の一つのとして、トランザクションを頻繁にコミットして、デッドロックの可能性を下げるという手があります。また、デッドロックを検出して処理前の状態に戻す対応が行われています。
データは使うことに価値がある
エンジニアが考えるべきこと
企業などで使われるデータベースの場合、一度保存したデータは長く使われることが多いでしょう。画面や処理などのプログラムは変更されても、格納されたデータはずっと変更されないこともよくあります。つまり、最初の段階でどういったデータベースを使うのか、どういった形式で格納するのかを考えておかなければなりません。適切に設計されたデータベースは拡張性も高く、安心して長く使い続けられます。
また、企業などで使われるデータベースを担当していると、消失や改ざんなどの被害が発生すると大きな損害になります。結果として、安全性や運用に関する技術を第一に考えてしまいがちです。しかし、データベースに関する仕事をしているエンジニアは、技術に関する知識があればよいわけではありません。
つまり、データを確実に保存することの保証だけでなく、データの活用を求められる場面が増えています。データは持っているだけでは価値がありません。ところが、データベースの存在は利用者には見えにくいものです。具体的にどのような処理ができるのか、利用者には分かりません。格納されている内容は利用者がイメージできていても、どのようなデータ構造になっているのか、どのような処理が実現可能なのかを理解しているのはエンジニアです。
具体的な活用法をエンジニアが考え、提示する必要があるのです。次回は統計的な処理を中心に、データの活用方法について紹介します。
単行本化のお知らせ
2016年12月17日に、この連載をベースにした新刊『エンジニアが生き残るためのテクノロジーの授業』が発売されました！
ITとビジネスの関係、コンピュータ、ネットワーク、プログラミング、データベース、セキュリティ、人工知能など、本連載で解説した内容も含め、エンジニアなら誰もが知っておくべきテーマを一冊で学ぶことができます。
IT業界でずっと活躍するために、本物の力を身につけよう。
