派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)
派手なイノベーションは必要ない…ただ地味な少しだけのリードがあることが重要(Oracleの読み取り一貫性に関して思う事)
職場内向けの資料なのでここには上げられないが、今日は少し思うところがあって、創設20年を迎えているオラクルマスター試験の変遷や、データベース・ソフトウェアとしての Oracle Database について、自分なりに考えた。
まぁ、現在においては、世界で最も利用されているDBMSは、OSSのMySQLであるという事実はある。(それもOracle社が持ってしまっているが)
しかし、ことにエンタープライズ分野の、特に大規模システムでは、Oracle Real Application Clusters(Oracle RAC) 等で可用性に優れているオラクルDBが、あいかわらず強い。
「同時実行制御」のほんのわずかな違い(リード:先行分野)が明暗を分けた
1992年(平成4年)に公開された「Oracle 7」において、「分散トランザクション」「パラレルクエリー」「データベーストリガー」といった、大規模OLTPシステムには欠かせない基本機能を、Oracle は持っていた。
そして「同時実行制御」の考え方において、IBMのDB2のような「ロック」による解決を行わなかった。
「読み取り一貫性」を当初から導入していたのである。
これがオラクルの生命線だった。
あるトランザクションが終わるまで、そのトランザクションが更新しているレコードは、他のトランザクションからは「一貫して」"更新前"として見える事を保証する。
これが、「読み取り一貫性」である。
オラクルを普段から使用している人にとっては、「何を当たり前な事を」と思うだろう。そう。オラクルでは、これが「当たり前」なのであった。
更新する前にUNDO表領域(昔風に言うとロールバックセグメント)にレコードデータを退避して、それを他のトランザクションには見せる。
このことから、単なる読み込みであれば、ロックという概念すら必要はない。
これが、例えば同じように大規模システム向けのIBM DB2 だと、話は違ってくる。
更新するレコードは「ロック」することで書き込みも読み込みも矛盾を起こさないようにする。
非常に単純な仕様で、明解ではある。
単純で明解ではあったが、「同時実行性」の面で、オラクルに少しだけ先行(リード)を許した。
だが、それが致命的な差になってしまうのである。
「読み取り一貫性」はいまで言う「イノベーション」だったのか
「読み取り一貫性」はいまで言う「イノベーション」だったのかというと、そこまで大げさな機能ではなかったはずである。
「同時実行性」を、少しだけ向上させるための、ひとつの「工夫」にすぎなかったのだろう。
同じ「工夫」を、2017年である現在やったとしても、誰も見向きもしない事だろう。
1980年代~1990年代初頭という、RDBの黎明期にやったからこそ、ものすごい大きな「差」となっている。
技術とは、得てしてこういうものなのだなぁ…。