IT (情報技術) 学習記録-もしくは中高年(就職氷河期世代)の生き方-

IT系,または,電気通信系資格の学習記録を中心に。もしくは中高年(就職氷河期世代)の生き方,働き方,世の中。中高年の転職の現実。

派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)


派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)


職場内向けの資料なのでここには上げられないが、今日は少し思うところがあって、創設20年を迎えているオラクルマスター試験の変遷や、データベース・ソフトウェアとしての Oracle Database について、自分なりに考えた。


まぁ、現在においては、世界で最も利用されているDBMSは、OSSMySQLであるという事実はある。(それもOracle社が持ってしまっているが)

しかし、ことにエンタープライズ分野の、特に大規模システムでは、Oracle Real Application Clusters(Oracle RAC) 等で可用性に優れているオラクルDBが、あいかわらず強い。


「同時実行制御」のほんのわずかな違い(リード:先行分野)が明暗を分けた


1992年(平成4年)に公開された「Oracle 7」において、「分散トランザクション」「パラレルクエリー」「データベーストリガー」といった、大規模OLTPシステムには欠かせない基本機能を、Oracle は持っていた。

そして「同時実行制御」の考え方において、IBMDB2のような「ロック」による解決を行わなかった。

「読み取り一貫性」を当初から導入していたのである。

これがオラクルの生命線だった。


あるトランザクションが終わるまで、そのトランザクションが更新しているレコードは、他のトランザクションからは「一貫して」"更新前"として見える事を保証する。


これが、「読み取り一貫性」である。

オラクルを普段から使用している人にとっては、「何を当たり前な事を」と思うだろう。そう。オラクルでは、これが「当たり前」なのであった。

更新する前にUNDO表領域(昔風に言うとロールバックセグメント)にレコードデータを退避して、それを他のトランザクションには見せる。

このことから、単なる読み込みであれば、ロックという概念すら必要はない。

これが、例えば同じように大規模システム向けのIBM DB2 だと、話は違ってくる。

更新するレコードは「ロック」することで書き込みも読み込みも矛盾を起こさないようにする。

非常に単純な仕様で、明解ではある。

単純で明解ではあったが、「同時実行性」の面で、オラクルに少しだけ先行(リード)を許した。

だが、それが致命的な差になってしまうのである。


「読み取り一貫性」はいまで言う「イノベーション」だったのか


「読み取り一貫性」はいまで言う「イノベーション」だったのかというと、そこまで大げさな機能ではなかったはずである。

「同時実行性」を、少しだけ向上させるための、ひとつの「工夫」にすぎなかったのだろう。

同じ「工夫」を、2017年である現在やったとしても、誰も見向きもしない事だろう。

1980年代~1990年代初頭という、RDBの黎明期にやったからこそ、ものすごい大きな「差」となっている。

技術とは、得てしてこういうものなのだなぁ…。


プライバシーポリシー/お問い合わせ