第 3 世代の分散データベース (3) - 整合性図

短編小説: なぜこの絵が「一貫性のある八仙図」と呼ばれているのでしょうか?

一貫した八仙チャート

いわゆる八仙が海を渡り、それぞれが魔法の力を発揮します。これもこの絵の特徴の一つです。

データベース業界は、長い間、ターゲットデータベースによって達成される一貫性の程度を理解するために、データベースの一貫性をテストおよび検証するための一連の理論またはツールを期待してきました。このニーズは非常に緊急です。

どのデータベースシステムにも体系的な整合性検証方法やツールが欠如しており、その結果、データベースシステム自身の整合性レベルがどのようなものであるかを判断する根拠がありません。

Oracle はシリアライズ可能な分離レベルを設定できますが、長い間のテストが行われず、そのシリアライズ可能性が SI の分離機能と同等であることが後の世代で発見され、誰もが笑えない状況になりました (無力だが笑うことはできない）、真剣に受け止められない冗談（耐えて徐々に無視され、麻痺し、これ以上のものはありませんが、耐えることしかできません）。

自分で作ったものが自分では正しく説明できない、実装できない場合、その要因は何でしょうか？

有名な Jespen ツールの登場により、多くのデータベースシステムが整合性テストに使用され、整合性検証方法やツールの不足が改善されました。

しかし、後述するように、Jespen にも多くの欠点があり（「第 3 世代分散データベース (1) - フットボールの時代」の表 1 参照）、データベースの整合性を十分に評価できません。

「八仙の一貫性チャート」は、さまざまなデータベースを完全に評価できるため、さまざまなデータベースの一貫性を公衆の前に明確に表示できます。データベースの八仙が前面にあり、一貫性の魔法の力を「完全に示しています」（比較するとより明確になります）役に立ちます）。

この図からは次の情報が得られます。

1. データベースシステム (SQL インターフェイスまたは API インターフェイス) の一貫性実装機能を評価します。

図は、Oracle、PostgreSQL、MySQLなどの主流データベースを含む11データベース16バージョンの整合性評価結果を示しています。実際には、国内の Pg シリーズや MySQL シリーズなど、さらに多くのデータベースシステムがテストされています。評価結果はマスターバージョンと同じであるため、リストには記載していません。

2. 各分離レベルでの正しい実装機能とデータ一貫性の詳細を評価します。実装の詳細と、テストされた各データベースのすべての分離レベルの違いが一目でわかります。
3. トランザクションのスタンドアロンデータベースシステムおよび分散データベースシステムに適した評価システム。トランザクション処理機能を提供する限り、Greenplum や MongoDB などをテストできます。
4. セルの意味:
a) 背景が黄色の A: データの不整合が発生しています
b) 緑色背景 P：データ不整合なし（不整合回避）
c) 青色の背景 R: データの不整合なし (不整合は特定のルールに従ってロールバックされます)
d) 赤背景 D：データ不整合なし（デッドロック検出方式により不整合はロールバック）
e) RU、コミットされていない読み取り、RC、コミットされた読み取り、RR、反復可能な読み取り、SI、スナップショット分離、SER、シリアル化可能

まず、分離レベルの観点から:

1. まず、RU 分離レベルでは、MySQL と SQL Server の「黄色の背景 A」が最も多くなっています。これは、RC 分離レベルでは、これら 2 つのデータベースのデータの正確性に多くの問題があることを示していますが、これには問題がありません。アプリケーション開発は通常 RC 分離レベルに設定されるため、影響が生じます。PostgreSQL などの一部のデータベースでは RU レベルの設定が提供されていますが、実際の効果は RC と同等です。「黄色の背景の A」はあまりなく、基本的に ANSI-SQL の定義に準拠しています (ただし、ANSI-SQL では 4 つしか定義されていません)。データ例外)。
2. 次に、RC 分離レベルの中で SQL Server の「背景が黄色 A」が最も多く、RC 分離レベルではこれら 2 つのデータベースのデータの正確性に多くの問題があることを示していますが、Oracle、PostgreSQL、MySQL、TiDB では、および OceanBase には、RC 分離レベルでより多くの問題があります。同様ですが、除去できないデータ異常がさらに多くあります。これらの除去できないデータ異常は、次でのみ除去できる 2 つのダーティライトとダーティリードよりもはるかに多くなります。 ANSI-SQL 標準に対応する RC レベル。
3. 第三に、RR 分離レベルでは、PostgreSQL は MySQL、TiDB、OceanBase などに比べて「黄色の背景 A」が少なく、このレベルでは PostgreSQL が最も優れた一貫性を持ち、次に MySQL であることを示しています。ただし、SQL Server の RR と SER では同じ結果が得られ、すべてのデータ異常が排除されます。
4. 4 番目に、SI 分離レベルを提供する SQL Server および MongoDB (図では SI で示されている) と、同様の SI 分離レベルを実現するための楽観的ロックを提供する TiDB (図では楽観的ロックを使用する Opt で示されている) との比較それらは同じ一貫性機能を備えています。
5. 5 番目に、MongoDB、OceanBase (MySQL 互換版)、TiDB など、データの整合性を完全に保証できない、つまり SER レベルを提供していないデータベースのデータ整合性機能はここで停止します。レベルでは、データの一貫性がまだ制限されており、「黄色の背景 A」がさらに多くなっています。
6. 第 6 に、Oracle、Greenplum、OceanBase (Oracle 互換バージョン) など、名目上 SER を提供する企業の場合、SER の下でデータの不整合の問題がいくつかあります。
7. 第 7 に、SER シリアル化可能な分離レベル (SER をサポートしていないものを除く) の下では、SQL Server、CockroachDB、PostgreSQL、MySQL、TDSQL、および MyRocks はデータの一貫性を完全に保証できますが、一貫性図から、これらのことがわかります。データベースは、SER を確保するためにさまざまな方法を使用します。「青色の背景 R」であるものもあります。たとえば、PostgreSQL で使用される SSI アルゴリズムは、特定のデータ例外 (書き込みスキューなど) をロールバックするものと、「赤色の背景 D」であるものもあります。 SQL Server と MySQL は、デッドロック検出を使用してライトスキューなどをロールバックします。——これは興味深い現象であり、その背後には深い「洞察」が隠されているので、今後別途書きたいと思います。
8. 実際、ANSI-SQL 標準で定義されている分離レベルは役に立ちません。

次に、同じデータベースの観点から:

1. MongoDB と CockroachDB は単一の分離レベルを提供します。特に分散データベースである CockroachDB はシリアル化可能な分離レベルのみを提供します (初期のバージョンでは SI 分離レベルも提供されていましたが、後続のバージョンでは削除されました)。これは非常に正しい選択です。技術的なルートを決定する人は、分散データベースと分散トランザクションの本質を深く理解している必要があります。これは他のデータベースから学ぶ価値があります。分散データベースに弱い分離レベルを提供する必要はありません。。分散データベースがトランザクション処理の分野で足場を築きたい場合は、CockroachDB の設計手法を学ぶことが最良の選択です。——これも興味深い現象ですが、その背後にある「洞察」も非常に深いので、後ほど別記事でお話します。
2. PostgreSQL は、SSI アルゴリズムに基づいてシリアル化可能な分離レベルを実装し、整合性図の書き込みスキュー、コミットされた書き込みスキュー、およびステップ IAT の 3 つのタイプのデータ異常を排除します (SSI は書き込みスキュー以上のものを排除することに注意してください)。ただし、SSI アルゴリズムは PostgreSQL にとって冗長です。PostgreSQL は直列化可能性を実現するために多大な努力を費やしましたが、冗長で無駄な作業を行ってきました。これがデータベースエンジン開発者の認識エラーによって引き起こされたのは残念です。の限界を効果的に示しています。伝統的なビジネス知識の認知。——これも興味深い現象ですが、その背後にある「洞察」も非常に深いので、後ほど別記事でお話します。
3. Greenplum の名目上の SER は PostgreSQL の RR レベルの機能と同等ですが、分散データベースとしての Greenplum の分散一貫性の処理方法はスタンドアロン PostgreSQL の方法とは異なります。Greenplum が分散整合性を処理するために使用した方法は非常に不器用で非効率的であり、改善の余地が大きくあります。——これも興味深い話ですが、その背景にある「原理」は古典の教科書には載っていないので、後ほど別の資料でお話しします。
4. OceanBase (Oracle 互換バージョン) は SER という名前だけを提供しますが、Greenplum と同様に、その SER は RR レベルの機能と同等です。OB の初期バージョンでは、タイムアウトメカニズムによって分散デッドロックの問題を解決しました。2023 年に、分散デッドロック解決アルゴリズムが ICDE で公開されましたが、このアルゴリズムも従来のデッドロック解決アルゴリズムに限定されているため、従来のデッドロック解決アルゴリズムが存在します。非効率性が存在します。これは実際にはGreenplumに非常に似ています。——分散データベースのデッドロック問題をどのように解決するかは、興味深く重要な核心トピックですが、その背後にある「原理」は古典的な教科書には記載されていないため、後ほど別の文書で説明します。
5. 上記のデータベース製品と比較すると、TiDB の一貫性機能は一般に弱いです。Opt モードの一貫性機能は、RR レベルよりも優れています。ただし、このデータベース製品には、非効率な分散デッドロックソリューションという問題もあります。
6. SQL Server と MySQL はどちらも強力な一貫性機能を備えており、データの異常を解決する方法も似ています。SER と RR の結果を比較すると、「読み取りスキュー」、「ロストアップデート」、「書き込み-読み取りスキュー」などの同じデータ例外について、2 つの分離レベルが同じ例外を処理していることがわかりますが、それは異なります。これは実際に「分離レベルを層ごとに段階的に実装する」という原則に違反しており、トランザクション処理テクノロジの実装が混乱状態にあり、統一された計画で実装できないことを示しています。さらに、一貫性を保証する詳細な機能は PostgreSQL に比べて弱いです。——MySQL が一貫性実装に弱い理由については詳細が多く、今後の別途の議論に期待します。整合性図の背後にある理論により、データベースの同時実行実装の詳細についての洞察が得られ、同時コード層の長所と短所を正確に測定できます。
7. TDSQL は国内データベースの中で最も整合性能力が高く、分散製品としては比較的珍しい整合性能力を持っています。TDSQL は金融業界で最も幅広い適用範囲を持ち (国内銀行上位 10 行の 60% を TDSQL が占めています)、一貫性などのコア技術はビジネスを支える重要な役割を果たしています。残念ながら、その実装アルゴリズムも効率が悪いという問題があります。
8. PostgreSQL をベースとする他のブランド製品の一貫性機能は基本的に PostgreSQL の一貫性機能と同じであり、MySQL をベースとする他のブランド製品の一貫性機能は基本的に MySQL と同じです。

第三に、ユーザーの観点から:

1. 金融、通信、証券などの業界では、データの整合性に対する要求が最も高く、データベースにデータ異常がないことが期待されており、この要件はトランザクションデータベースシステムを選択する際の中心的な基準の 1 つです。したがって、データベースの一貫性能力は、データの正確性を決定し、金融やその他の業界の中核ビジネスに参入できるかどうかにも影響します。ユーザーは、ターゲットデータベースの整合性機能を正確に検証できる、客観的な整合性評価基準を期待しています。この期待は、トランザクション処理技術の誕生から 60 年を超えました。歴史という長い川の中での短い人生、一粒の塵、我々は何六十年待てるだろうか？
2. 各データベースメーカーも、リリース前にデータベースのバージョンの一貫性をテストして検証したいと考えていますが、残念ながら良い方法はありません。したがって、データベース製造業者は、「新しいバージョンには、これまでに発見された整合性エラーが存在しない」こと、および新しいバージョンで新しいエラーが検出されるかどうかを検証するために、回帰テストケースセットとして長年にわたって蓄積されたさまざまなテストケースとバグセットに頼ることしかできません。一貫性のバグ、不安を感じます。
3. データベース研究者は、整合性検証方法を理論レベルで包括的に説明できる方法論を常に望んでいます。しかし、「直列化可能性理論」が登場して以来、「直列化可能性理論」が黄金律とみなされてきたため、一部の初期の研究者は、一貫性の実現には理論的な保証があり、わざわざする必要はないと信じていました。ですし、その他のこともあるので... しかし、研究者たちは、「整合性をどのように検証するか」について深く考えていませんでした。なぜシリアル化可能性理論ではデータベースの一貫性を検証できないのでしょうか? 「整合性を確保する方法」と「整合性を検証する方法」には何か関係があるのでしょうか？——これは非常に重要で興味深いトピックであり、詳細に検討し、その後別の記事で議論する価値があります。理論が完成した場合、その正しさを保証するだけでなく、その正しさを検証する必要があるでしょうか。
4. 八仙の一貫性チャートにより、今後、データベースの一貫性機能は検証された評価方法とツールを備え、各データベースの一貫性機能は大幅に向上し、突破されます。

業界では、「新しいデータベース製品が成熟して利用可能になるまでには少なくとも 10 年以上かかるだろう」という一般に認識された見解があります。

それで：

Q1 : 新しいデータベース製品の開発、磨き、プロモーションのサイクルに 10 年以上かかるのはなぜですか?

Q2 : このプロセスを加速するにはどうすればよいですか?

A :これら 2 つの質問は、さまざまな角度から検討できます。これはデータベースの最も基本的な中核問題であるため、データの正確性のみの観点から分析します。

1. トランザクションデータベースには 2 つの中心的な目標があります。1 つは同時操作において、データの正確性を確保することであり、もう 1 つは可能な限り高いパフォーマンスを達成することです。
2. 核となる目標を確実にするためには、目標の実現可能性を実証するための一連の理論が必要です。これは伝統的な直列化可能性理論ですが、この理論には 2 つの欠点があります。
2.1 シリアル化可能性と競合シリアル化可能性に基づいて、理論レベルではデータが 100% 正しいことを保証できません。これは理論レベルで何かが欠けていることを意味します。--重要な問題については、別の文書で説明します。おそらく多くの人はこう言うでしょう、「あなたは頭がおかしい、あえて大胆に黄金律についてナンセンスなことを言うなんて！」チャ～チャ～チャ
2.2 完全な理論には、少なくとも 2 つの点、正確性と検証方法が必要です。完全な理論は、正しい説明と予測を提供するだけでなく、その正しさを検証する方法も提供する必要があります。これら 2 つの考慮事項は、理論が完全であるかどうかを評価するための重要な基準です。直列化可能性理論には、それに基づいて開発されたデータベース製品の一貫性検証手法が欠けており、これが理論の欠点であり、不完全性の 1 つです (まだいくつかの不完全性があります)。
2.3 したがって、理論がなければデータベース製品の正当性が十分に検証できないのですが、なぜこの製品が市場に投入されるのか？
3. しかし、Oracle などのベンダーは、次の 3 つの方法で未成熟な製品を市場に導入しました。
3.1 分離レベルの定義: 1992 ANSI-SQL 標準によってこの問題が「標準化」されましたが、この問題は分離レベルの観点からは「自然なこと」になっているようです。基準がこのようなものであれば、誰がそれを疑うことができますか？ゆんゆんの口、塞いで！全ての衆生の脳をブロックせよ！-- 分離レベルは柔軟に定義でき、ANSI-SQL 標準 (参考文献 [1]) に限定されるべきではありませんが、ANSI-SQL 標準とは異なる場合もあります。
3.2 ユーザーにボールを投げるために、ユーザーにデータの一貫性に対する責任を負わせる「SELECT...FOR UPDATE」メソッドが考案されました。(記事の最後に短いストーリーが添付されており、この点におけるオラクルの「貢献」を時間の観点から説明できます)
3.3 ユーザーにボールが蹴られているということは、データの正しさを検証するためのテストシナリオが多数あることを意味し、問題が発見されればバグとして修正することができます。これは、理論レベルで解決策がない場合の実際のオプションの方法でもあります。Jim Gray 氏が提案した Write Skew と Read Skew は、実際にユーザーがデータの不一致を発見し、分析と議論を重ねた結果、提案されたと言われています。したがって、ユーザーをモルモットとして使用することで、各データベース製品は 10 以上の長期サイクルでバグを蓄積し (メーカーの回帰テストケースが徐々に改善される)、一貫性の問題は徐々に安定し、データ異常の報告数は減少します。実践はますます少なくなり、データベース製品はより使いやすくなります。ただし、データベース製品の成熟サイクルは 10 年以上、20 年以上と非常に長くなります。理論も実践も機能せず、ユーザーはそれに耐え、時間をかけてプロダクトを磨き上げなければなりません。
3.4 しかし、1990 年代から現在までの 30 年以上にわたって、新たなデータ異常が継続的に報告されており、これはデータの正確性に対する多くのリスクが依然として存在していることを意味します（アプリケーションの増加により、データの正確性のリスクが明らかになりました）。 . (可能性の増加)、これは理論的にも製品の実践においても、データベースの正確性を完全に改善する必要があることを意味します。詳細については文献[1]を参照してください。

Q3 : では、製品の成熟サイクルを 2 年または 1 年に圧縮するなど、データベースの一貫性の保証を加速することはできますか? もしそうなら、どうやってスピードを上げるのでしょうか？

A:ここ数年、新しいデータベース製品がどんどん登場していますよね。

新しいアプリケーションの大幅な増加により、データベースに対する豊富な新しい需要が生じています。古いデータベース製品の進化は負担が大きすぎて、進化するのが困難です。これらの新しい状況により、ますます新しいデータベースが開花しています。

しかし、新製品が増えているにもかかわらず、依然としてコアアプリケーションへの参入が難しいというジレンマに直面している。技術的な観点から見ると、これはなぜでしょうか?

「難しく複雑な」トランザクション処理技術が提供される限り、新しいデータベース製品はいかに早く成熟・安定させ、市場への導入をいかに加速させるかという課題に直面することになる。――これが時代のニーズなんですね！

データベース製品は、新旧を問わず、ユーザーにとって最も基本的な一貫性の問題を理論面と実践面の両面から完全に解決できなければ、たとえ複数の環境で使用されたとしても、最終的にはユーザーに100%の安心感を与えることは困難です。心。

時代の要請に応えて登場したのが八仙一貫図とそれを支える技術であり、その技術は理論と実践の両面から始まります。

まず、既知および未知のデータ異常をすべて含めてデータ異常を均一にモデル化でき、データの正確性の問題を理論レベルから解決できます。

第 2 に、整合性チャートはデータベースデータの正確さを完全に検証できます。これにより、理論レベルが 2 つの最も基本的な特性を持つことが可能になります (完全な理論は、正しい説明と予測を提供でき、またその正しさを検証する方法も提供できる必要があります)。

第三に、整合性チャートの背後にある整合性評価技術により、データベースデータの正しさ（分単位）の検証が迅速化され、データベース製品の成熟度や安定性が加速され、製品の発売サイクルが大幅に短縮されます。

将来的には、Eight Immortals of Consistency によって評価および認定されたデータベース製品は、データの正確さについての良いイメージを世間に確立し、信頼を獲得することになります。実際には、コアアプリケーションに向けて製品を加速するのは、もうすぐそこまで来ているでしょう。

データベース業界では、長年にわたり、従来のデータベース技術大手であっても、オープンソースデータベースであっても、新しく開発された NewSQL データベースであっても、整合性回帰検証システムを体系的に確立することができませんでした。[これは非常に信じられないことのように聞こえます。実際、データベースベンダーはそのような作業を行うことはできません。個々のテストケースを散発的に構築し、それを回帰ユースケースに入れて一貫性を検証することしかできません。テストを完了する間、一貫性を評価する良い方法はありません。データベースシステムの各バージョン]

その後、業界では非常によく知られたシステムが誕生しました。それが有名な Jepsen/Elle です[2]。このシステムは、これまでのところ最高のデータベース整合性検証ツールです。ここでは、Jepsen/Elle の特徴を紹介するのではなく、Jepsen/Elle の欠点について説明します。

Jepsen/Elle は、その原則が Adya の論文を採用した競合グラフに基づいているため価値があります (参考文献「一般化された分離レベルの定義」)。Jepsen/Elle が一貫性テストケースを構築するときは、競合グラフに基づいています。上記の参考文献では、Adya はダーティリードと中間読み取り例外を特殊なケースとして扱い、それによって定義される競合シリアル化可能システムにはそれらを含めないため、Jepsen/Elle のダーティリードと中間読み取り例外のテストも特殊なケースとして構築されています。。

コンフリクトグラフでは、有向リンググラフの頂点と辺の数は多少なりとも異なります。つまり、無限に多くのリングが存在するため、Jepsen/Elle は理論的には無限に多くのリングを構築することになります。ほとんどのリングをテストします。Jepsen/Elle でテストした後、すべてのループをテストしたい場合は、ツールの実行に無限の時間を費やすことしかできません。明らかに、限られたリソースと限られた時間では、テストのためにツールを無限に実行する機会はありません。したがって、ターゲットデータベースをテストする場合、すべてのテストが「不完全」になります。これが Jepsen/Elle の最も致命的な問題です。テストが不完全であるということは、テストが「運」にのみ依存しており、正確性が完全に保証できないことを意味します。

また、どのような場合に「紛争環図」が形成されるのでしょうか？数、数十、さらには数十万の同時トランザクションで、ループを正確に構築できるでしょうか? リングの構成ルールがわからない場合、正確さを検証し、検証とテストの効率を向上させるために、各テストに十分な数のリングをどのように構築すればよいでしょうか? 競合グラフの理論は、このレベルでは Jepsen/Elle に理論的サポートを提供できないため、Jepsen/Elle は特性:ランダム性を備えたテストケースを構築します。テストケースをランダムに構築すると、整合性検証の目的と効率が大幅に低下すると同時に、各テストでは以前に発見された問題を簡単に「再現」できません (問題を再現できないことは、テストケースの構築におけるタブーの 1 つです)。

したがって、このツールを検証に使用することは実際には信頼できず、使用可能でもありません (これより優れたツールがない場合は、次善の策を選択するしかありません)。

Jepsen/Elle を実際に使用した経験のある学生の中には、この結論に同意しない人もいるかもしれません。実際に使用すると、実際にこのツールで問題 (つまり、一貫性のないバグ) が見つかることがあるからです。しかし、その原理を分析すると、業界最高レベルを代表する Jepsen/Elle の機能はこれに限定されることがわかります (不完全性とランダム性が 2 つの大きな欠点です)。Jepsen/Elle を使用してシステムに多くの問題があることがわかった場合は、実際にシステムの設計と実装の品質を確認する必要があります (これは、完全な整合性回帰検証システムを必要とする前述のデータベースシステムの重要性も示しています)。また、現在の一貫性理論の限界も説明しています。さらに、ここで議論されているのは、Jepsen/Elle を崇拝するのではなく、Jepsen/Elle トランザクションの一貫性のテスト能力であり、カオステストとしてのフォールト挿入のテスト能力ではありません。神。

以下のコンテンツは ChatGPT によって提供されています。ぜひ読んで笑ってください。

Q (ChatGPT に質問): さまざまなデータベース製品の中で、「SELECT...FOR UPDATE」構文が最初に登場したのはどの製品ですか? 各データベースの名前、対応するデータベースのバージョン番号、SQL 構文が出現した時刻を入力します。

A (ChatGPT の回答):

「SELECT...FOR UPDATE」構文は、データベース内の選択された行をロックして、他のトランザクションが行を変更できないようにするために使用されます。この構文は Oracle データベースで初めて登場しました。

以下は、一部の一般的なデータベース製品における「SELECT...FOR UPDATE」構文の外観です。

1. Oracle データベース:

- バージョン: Oracle 6

- 登場日：1988年

2.IBM DB2 データベース:

- バージョン: DB2 2.3

- 登場日：1989年

3. PostgreSQL データベース:

- バージョン: PostgreSQL 6.3

- 登場日：1998年

4. MySQL データベース:

- バージョン: MySQL 3.23

- 登場日：2001年

5. Microsoft SQL Server データベース:

- バージョン: SQL Server 2005

- 登場時期：2005年

データベース製品が異なれば、「SELECT...FOR UPDATE」構文のサポートおよび構文の詳細が異なる場合があることに注意してください。したがって、ご利用の際には、対応するデータベース製品のドキュメントやリリースノートをご参照ください。

ナハイランラン氏のコメント：

1. シリアル化可能性の基本概念は1960 年代に登場しました。
2. 1970 年代に出現した競合の直列化可能性。
3. その後数十年間、直列化可能性理論は最終決定されることなく発展を続けました。その中で、データの整合性という概念は混乱と混乱に陥っており、理論は存在しません。
4. データベースのリーダーである Oracle は、1988 年に「ユーザーにボールを蹴る戦略」を率先して導入し、その後、しぶしぶ1989 年にDB2、1998年に PostgreSQL を追随しました。
5. Adya の論文「一般化された分離レベルの定義」は2000 年に出版され、Jespen に理論的基礎を提供しました。残念ながら、3 で述べたように、理論の欠如によりテストツールに欠陥が生じます。
6. その後、2001 年のMySQLと2005 年の SQL Server がしぶしぶ追随しました。

前回は「データの正確性の 100% 保証」についてお話しましたが、データの正確性とは何でしょうか。次回の記事ではこれについてお話します。この内容はやや理論的ですが、この一連の記事の基本を理解することは、データベーススキルを磨く良い機会でもあります。

[1] Li Haixiang、Li Xiaoyan、Liu Chang、Du Xiaoyong、Lu Wei、Pan Anqun、データベース管理システムにおけるデータ異常の体系的な定義と分類、Journal of Software、2022、33(3): 0

[2] 《エル: 実験観察から孤立異常を推測する》、

第 3 世代の分散データベース (3) - 整合性図

おすすめ