データベースの整合性とは？仕組みや強整合性・弱整合性の違いを解説

データベースの整合性とは？

データベースの整合性とは、データベースシステム内のすべてのデータポイントが、正しく読み取られ受け入れられるために準拠すべき一連の基準値として定義されます。事前に定められた値を満たさないデータがデータベースに流入すると、データセットに整合性エラーが発生します。データベースの整合性は、ルールを確立することによって実現されます。データベースに書き込まれるすべてのデータトランザクションは、開発者が設定した制約、トリガー、変数、カスケードなどで定義された対象のデータのみを変更しなければなりません。

例を挙げましょう。あなたが全米交通安全協会（NTSI）で働いており、カリフォルニア州の新しい運転免許証のデータベース作成を任されたとします。ここ10年でカリフォルニア州の人口が爆発的に増加したため、初めて運転免許証を取得する人向けに、新しい英数字フォーマットが必要になりました。チームは、データベースにおけるカリフォルニア州運転免許証の新しい基準値を「アルファベット1文字＋数字7桁」と決定しました。以後、すべてのエントリはこのルールに従わなければなりません。たとえば「C08846024」という入力はエラーとなります。なぜなら、入力された値がアルファベット1文字＋数字8桁であり、これは不整合データの一種だからです。

さらに、整合性とは、あるテーブル内の特定のオブジェクトに対するデータ変更が、そのオブジェクトが存在する他のすべてのテーブルにも反映される必要があることを意味します。運転免許証の例で言えば、新しいドライバーの自宅住所が変更された場合、その更新は旧住所が登録されていたすべてのテーブルに反映されなければなりません。1つのテーブルだけ古い住所のままで、他のテーブルは新しい住所になっている状態は、データ不整合の典型例です。

注意：データベースの整合性は、トランザクションで投入されるデータの中身が正しいことを保証するものではありません。保証されるのは、システム内で書き込み・読み取りされるデータが、データベースへの登録資格を満たす前提条件をすべて満たしているということだけです。簡単に言えば、上記の例で「アルファベット1文字＋数字7桁」のルールを満たすデータを入力することはできますが、それが実際に存在する運転免許証に対応するとは限りません。データベースの整合性が扱うのはデータの形式のみであり、データが何を表しているかまでは関知しません。

データベースの整合性が重要な理由

一貫性のあるデータこそが、データベースをよく整備された機械のように機能させる鍵です。プライマリデータベースやレプリカから不整合データを締め出す確立されたルールや基準値によって、次のようなスムーズな運用が実現します。

• データの精度向上
• データベース容量の効率的な活用
• より高速かつ効率的なデータ取得

データベースの整合性は、流入するすべてのデータを管理します。新しいデータを受け入れる際にデータベースは変化しますが、少なくともその変化は一貫しており、当初に確立された検証ルールに従うものとなります。今日の世界では、データベースの認識上の整合性に基づいて、世界中で日々数十億ドル規模の意思決定が行われています。リアルタイム情報が現代のデジタルビジネスの新常態となる中、誤った情報をデータセットから排除し、レイテンシの増大を防ぐ検証ルールを導入することが極めて重要です。そうしなければ、リアルタイム体験はもはやリアルタイムではなくなってしまうのです。

データベースの整合性の具体例

現実世界におけるデータベース整合性の運用例にはどのようなものがあるでしょうか。前述のNTSIのシナリオで1つの例を見ましたので、今度は銀行業界の例に目を向けてみましょう。

ある口座から別の口座へ送金するとします。残高300ドルの口座に1,200ドルを送金しました。画面を更新すれば、残高が1,500ドルになっているはずだと確信しています。ところが、この最新の操作は残高に反映されていません。それどころか、新しい残高は0ドルと表示されています。この技術的な不具合は弱い整合性の典型例であり、銀行の担当者とともに問題を切り分ける時間を費やすことになりかねません。こうした問題はブランドの評判を損ない、多大なコストをもたらします。データベースシステムにおける強い整合性は、開発者にとってもユーザーにとっても、ますます譲れない要件になりつつあります。

強整合性と弱整合性の違い

強整合性とは、プライマリ、レプリカ、および対応するすべてのノード内のデータが検証ルールに適合し、任意の時点で常に同一であることを意味します。強力なデータベース整合性のもとでは、どのクライアントがどこからデータにアクセスしても、データベースに設定されたルールに従った最新の更新済みデータが必ず表示されます。

一方、弱い整合性は、いわば「西部開拓時代の荒野」のようなものです。プライマリ、レプリカ、ノード内のデータが任意の時点で同一であるという保証はありません。たとえばインドのあるクライアントがデータにアクセスしたとき、検証ルールを通過する情報を目にしても、それが最新の更新データであるとは限らず、整合性エラーが発生します。クライアントは、かつては有効だったかもしれないが、もはや関連性のない情報に基づいて判断を下してしまう可能性もあるのです。

整合性レベル

整合性レベルとは、新しく許容されたデータが有効なトランザクションとして承認される前に、いくつのレプリカまたはノードからの応答が必要かを決める、もう一つの事前定義済みの基準値セットです。この設定はトランザクションごとに変更できます。たとえば、プログラマーは「新しく入力されたデータを2つのノードが読み取れば、データ整合性を承認する」というように指定できます。その基準を超えれば、以後そのデータは整合性のあるデータとみなされます。

分離レベル（アイソレーションレベル）

分離レベルは、データベースのACID（原子性・整合性・分離性・耐久性）特性の一部です。ACIDはSQLデータベースにおける整合性の基礎概念であり、多くのデータベースが整合性を最適化するために採用しています。分離性はACIDの特性の一つで、特定のデータをデータベースネットワーク内の他の情報から切り離し、他のユーザートランザクションによる変更を防ぎます。分離性は、同時実行されるトランザクションで生じる無関係なデータの読み書きを抑制するために活用されます。

分離レベルには次の4種類があります。

• Read Uncommitted（未コミット読み取り）：最も低いレベル。以前のトランザクションがその行に対して未コミットの更新を行っている場合に行の更新をブロックします。
• Read Committed（コミット済み読み取り）：「ダーティリード」を許可しません。トランザクションがすでに更新済みだが未コミットの場合、読み書きをブロックします。
• Repeatable Read（反復可能読み取り）：読み取り中のデータ行へのアクセスと、それに伴う潜在的な更新を防止します。
• Serializable（直列化）：最高の分離レベル。通常、特定のデータ行ではなくテーブル全体をロックします。

データベースの整合性に関するFAQ

データが整合性を持つとはどういう意味ですか？

ユーザーや地理的なアクセス場所にかかわらず、同じ時点ですべての対応するノードでデータが同じように表示される状態を指します。

データ整合性とデータベース整合性は同じものですか？

いいえ。データベース整合性は、ネットワークに入るデータがテーブル内の他のすべてのデータと形式的に一致するための検証ルールを必要とします。一方、データ整合性とは、ネットワーク全体およびそのデータを利用する複数のアプリケーション間で、データをできる限り均一に保つプロセスのことです。

結果的整合性（イベントualコンシステンシー）とは何ですか？

結果的整合性では、更新されたデータが最終的にそのデータが保存されているすべてのノードに反映されます。最終的には、どのクライアントがネットワーク経由でアクセスしても、すべてのノードが同じデータを返すようになります。

リレーショナルデータベースの単一テーブルは何で構成されていますか？

リレーショナルデータベースのすべてのデータはテーブルに格納されており、テーブルは行と列で構成されます。データポイントは行と列に整理され、「レコード」と呼ばれる行が個々のデータインスタンスを表し、「フィールド」と呼ばれる列がデータの属性（項目）を表します。テーブルはデータベース内に配置され、主題ごとの設計によってデータの重複を防ぐ役割も担います。

リレーショナルデータベースは何のコレクションで構成されていますか？

テーブルです。

ACIDモデルとBASEモデルはどう違いますか？

ACIDとBASE（Basically Available、Soft State、Eventually Consistent）モデルの主な違いは、ACIDがデータベース整合性の最適化を目指すのに対し、BASEは高い可用性を重視する点です。ACIDはトランザクションの一貫性を維持するため、BASEモデルを採用する場合は、整合性が引き続き最優先事項となり、十分に対策されるように設計する必要があります。

Redisデータベースは整合性を保てますか？

Redisがキャッシュとして使われる場合、問題になるのはRedisインスタンス間（プライマリ／レプリカ）、およびRedisキャッシュとプライマリデータベースとしてのRedis間の整合性です。両者のデータが一致しない場合、データが不整合になる可能性があります。この課題については、記事「キャッシュ整合性を維持する3つの方法」で解決策を紹介しています。

オープンソース版Redisの場合は弱い整合性となりますが、Redis Enterpriseのアクティブ・アクティブ地理分散（Active-Active Geo-Distribution）を利用すれば、強い結果的整合性を実現できます。

エンタープライズアプリケーション向けのクラウドキャッシング技術に関心がありますか？ぜひLee Atchison著『Caching at Scale with Redis』をご覧ください。