これは、この記事でデータベースの選択された内臓を待っているということではなく、データベースの最初からの話に加えて、 Ilya Kosmodemyansky （ @hydrobiont ）が重要であると思われる詳細について少し詳しく説明しています。そして、それがそうであると信じるあらゆる理由があります。

この記事は、良い人生から生まれたものではありません。多くの場合、初心者の開発者だけでなく、非常に高度な開発者も、基本的なことを知らない-大学で長い間勉強し、それ以来忘れてしまったか、正常に機能するため、理論に深く入る必要がないかもしれません。

ただし、 更新するには理論的な知識が役立つ場合があります。これは、特に行います。

講演者について：イリヤ・コスモデミャンスキーCEOおよびData Egretのコンサルタント、データベーススペシャリストPostgreSQL、Oracle、DB2。さらに、彼はPostgresテクノロジーのプロモーションを担当し、カンファレンスで講演し、人々にそれらとの連携方法を伝えています。

以下は、 RIT ++ 2017でのIlyaのレポートに関する資料です。特定のデータベースとは関係ありませんでしたが、多くの主要な側面をカバーしています。

なぜこれを知る必要があるのですか？

ストレージとデータ処理は、コンピューターシステムのミッションクリティカルなタスクです 。

一部のデータベース作成者がそうであるように、すでに30年にわたってテキストファイルに関するインターネット上のブログを持っている場合でも、とにかくこのテキストファイルは実際には非常に単純なデータベースです。

誰もがデータベースを発明しようとしています 。会議の講演者の一人は、「20年前にデータベースを書いたが、それが何であるか知らなかった！」と言った。この傾向は世界で非常に発達している。誰もがそうしようとしています。

データを扱うには、データベースが非常に便利です 。多くのデータベースは非常に古い技術です。これらは過去半世紀にわたって開発されてきました。70年代には、現在と同様の原理で機能するデータベースが既に存在していました。

これらのデータベースは非常によく考えられて作成されているため、プログラミング言語を選択して、共通の便利なデータ処理インターフェイスを使用できます。したがって、データが何らかの方法で処理されることを恐れることなく、標準化された方法でデータを処理することが可能です。

プログラミング言語は変化していることを覚えておくと便利です。昨日はPython 2でしたが、今日はPython 3でした。データを操作する作業をエミュレートするコードを持っているかもしれませんが、理論的にはデータベースでこれを行う必要があり、次に何をすべきかわかりません。

ほとんどのデータベースでは、 インターフェイスは非常に保守的です。 PostgreSQLまたはOracleを使用する場合、タンバリンを使用すれば、新しいプログラミング言語の非常に古いバージョンでも作業できます。これは素晴らしいことです。

しかし、タスクは実際には簡単ではありません。結果を信頼して処理できるように、データを「打ち負かす」ことができない方法の深さ、どれだけ速く、効率的に、そして最も重要なことを掘り始めたら、それは難しいことであることがわかります。

単純な永続ストレージを書き込もうとすると、すべては最初の15分だけになります。その後、ロックなどが始まります。ある時点で、「ああ、どうしてこんなことをするの？」

これについてお話します。

データレベル

したがって、データの操作にはさまざまなレベルがあります。

プログラミング言語から使用するのに便利なデータアクセス層 。
ストレージ層 。これは別のレイヤーです。データを使用する以外の方法でデータを保存するのが通常便利であるためです：メモリから効率的に、整列し、ディスクにフォールドします。これは、スキーマレスに関する質問です。保存が容易で、アクセスが容易ではないスキーマです。
「 Iron 」はデータが配置される層であり、オペレーティングシステムがディスクを管理し、ドライバーを介してのみ通信するため、データは3番目の方法で整理されます。このレベルについてはあまり掘り下げません。

データアクセス層には、作業を便利にするために、会議に関心があるという要件 があり ます。

汎用性 。これにより、任意のテクノロジーを使用してデータを要求できます。
このクエリの最適性 。アクセス方法は、データベースからデータを取得するのに適したものである必要があります。
同時実行性：すべてがスケーラブルになったため、異なるサーバーが同じデータのデータベースに同時にアクセスします。この方法で同時実行の利点を最大限に活用し、データをより速く処理することを確認する必要があります。

ストレージレイヤーについては 、 元の並列性を維持して、すべてのデータが破損したり、上書きされたり、擦られたりしないようにすることが重要です。

同時に、 安全に保管し、確実に再現する必要があります。つまり、データベースに何かを記録した場合、それを確実に取り戻す必要があります。

FoxProなどの古いデータベースを使用した場合、破損したデータが頻繁に表示されることがわかります。 MongoDB、Cassandraなどの新しいデータベースでは、このような問題も発生します。多くのデータがあり、気づきにくいので、彼らは常に気づいているとは限りません。

ハードウェアにとって 、信頼性は本当に重要です。それでも理論的なことについて話をするので、これは仮定です。私たちのモデルでは、何かがディスクに乗った場合、すべてがそこにあると信じています。 RAIDのディスクを時間通りに交換する方法は、今日の管理者の関心事です。この問題について深く掘り下げることはせず、ストレージが物理的にどの程度効率的に編成されているかについては実質的に触れません。

これらの問題を解決するために、さまざまなデータストアで非常によく似たアプローチがいくつかあります（新しいものと古典的なものの両方）。

まず、 データへの普遍的で最適なアクセスを提供するために、クエリ言語があります。ほとんどの場合、これはSQLです （理由は後述します）が、今はトレンドに注意を払いたいだけです。最初は、かなり長い間SQLがありました-もちろん、以前はありましたが、それにもかかわらず、SQLが長い間支配していました。その後、あらゆる種類のKey-Value-Storageが出現し始めました。これは、SQLがなくても機能し、はるかに優れていると言います。

多くのKey-value-storageは、主にお気に入りのプログラミング言語からデータに簡単にアクセスできるようにするために作成されたもので、SQLはお気に入りのプログラミング言語にうまく適合しません。これは高レベルで宣言型ですが、オブジェクトが必要なので、 SQLは必要ないという考えが浮かびました 。

しかし、これらの技術のほとんどは、実際には何らかのクエリ言語を実際に思いつきます。 Hibernateは独自のクエリ言語を開発しており、誰かがLuaを使用しています。以前にLuaを使用したことがある人でも、SQLの実装を行っています。つまり、現在の傾向は次のとおりです。セットを操作するための人間が読める便利な言語がまだ必要であるため、 SQLが再び戻ってきています。

さらに、テーブルビューは引き続き便利です。ある程度まで、多くのデータベースにはまだ兆候があり、これは偶然ではありません-このようにすると、クエリを最適化するのが簡単になります。 すべての最適化数学はリレーショナル代数に結び付けられており 、SQLとテーブルがある場合、作業がはるかに簡単になります。

シリアル化などの概念は、 ストレージ層に表示されます。並行性と競争力のあるアクセスがある場合、プロセッサ上またはディスク上で、ある程度予測可能な順序で到着するようにする必要があります。これには、ストレージレイヤーに実装されるシリアル化アルゴリズムが必要です。

繰り返しますが、何か問題が発生してデータベースがクラッシュした場合は、すぐにそれを拾う必要があります。

100％信頼性のあるフェールセーフストレージを作成することは可能だと思いますか？おそらく、データベースがクラッシュした場合にすぐにそれを上げるメカニズムがある場合にのみ、データベースが確実に機能することを知っています。

これには復元が必要です。何をするにしても、どこかに弱いリンクと非常に大きな同期オーバーヘッドがあるためです。 100台のサーバーに100個のコピーを作成できます。その結果、電源または何らかのスイッチが燃え尽きてしまい、ひどく痛みを伴います。

実際、 ハードウェアの場合 、データベースがOSとうまく統合され、効率的に動作し、正しいsyscallを呼び出し、データを高速に処理するためにすべてのカーネル機能をサポートすることが重要です。

ストレージ層

ストレージレイヤーから始めましょう。どのように機能するかを理解することは、上位層で何が起こっているかを理解するのに役立ちます。

ストレージレイヤーは以下を提供します。

✓ 並行性と効率。

言い換えれば、これは競争力のあるアクセスです。つまり、並行性の恩恵を受けようとすると、必然的に競合アクセスの問題が発生します。同時に、誤って記録された可能性のある1つのリソースを探し、記録中にビートを打ち、そして他に何が解決するかを地獄は知っています。

✓ 信頼性：災害復旧。

2番目の問題は突然の失敗です。信頼性が確保されると、これは最も悲惨なソリューションを提供するだけでなく、何かが発生した場合に迅速に回復できることも重要です。

競争力のあるアクセス

整合性、外部キーなどについて話すとき、誰もがどういうわけかうんざりして、コードレベルでこれをすべてチェックすると言います。しかし、あなたが提案したらすぐに：そして、あなたの給料の例を挙げましょう！給与はあなたに移されますが、それは来ませんでした。」何らかの理由で、それはすぐに明らかになります。理由はわかりませんが、すぐに目がキラキラし、外部キー、制約のトピックに興味があります。

以下は、存在しないプログラミング言語のコードです。

account_a { balance = 1000, curr = 'RUR' } send_money(account_a, account_b, 100); send_money(account_a, account_c, 200); account_a->balance = ???

1,000ルーブルの残高がある銀行口座があり、2つの機能があるとします。それらが内部にどのように配置されているかは今のところ重要ではありません。これらの関数は100から200ルーブルを口座aから他の銀行口座に転送します。

注意、問題は、アカウントaの残高に結果としてどのくらいのお金が表示されるかということです。ほとんどの場合、700に答えます。

問題

ここで私の言語が発明されたため、データへの競争的アクセスの問題が始まります。それがどのように実装されるか、これらの機能が同時に実行されるかどうか、そしてそれらがどのように内部に配置されるかは完全に明確ではありません。

send_money（）操作は基本的なアクションではないと考えられます。制御1と2を実行するには、残高と残高の転送先を確認する必要があります。これらは、時間がかかる基本的な操作ではありません。したがって、それらの内部で基本操作を実行する順序は重要です。

「貸借対照表の値を読む」、「別の貸借対照表に記録される」というシーケンスでは、質問が重要です。この貸借対照表をいつ読んだのでしょうか。同時にこれを行うと、競合が発生します。両方の機能はほぼ並行して実行されます。つまり、残高の同じ値を読み取り、送金し、それぞれを書き留めます。

800ルーブル、あるべき700ルーブル、またはバランスシートに何かがぶつかり、バランスシートがヌルであることが判明した結果、一連の競合が発生する可能性があります。残念ながら、これを十分に注意して処理しないと発生します。これに対処する方法、私たちは話します。

理論的には、すべてが単純です-次々と実行でき、すべてがうまくいきます。実際には、これらの操作は多数存在する可能性があり、厳密に連続して実行すると問題が発生する可能性があります。

覚えているなら、数年前、SberbankがOracleをドロップし、カード処理が停止したという話がありました。その後、一般の人々にアドバイスを求め、データベースが書き込むログの数を大まかに示しました。これらは膨大な数と競争上の問題です。

操作が厳密に連続して実行されることは、多くの操作が存在するという単純な理由から得策ではありません。また、同時実行の利点はありません。もちろん、操作を互いに競合しないグループに分割できます。そのようなアプローチも存在しますが、それらは現代のデータベースにとってあまり古典的ではありません。

ドイツの交通規制には興味深い話が1つあります。道路が狭くなると、ルールでは最後まで到達する必要があり、その後は一度に1つずつ再構築し、次の車が通過する必要があります。すべてが次々に厳密に再構築されています-そのような兆候はそれについて語っています。

これは、ルールを尊重する必要があることを大衆に長い間教えてきたときの、可能なシリアライゼーションの生きた例です。モスクワで車を運転する人は皆、この写真がどれほど理想的でないかを理解していると思います。

基本的に、ディスクに書き込むデータに対して同じことを行う必要があります。

状況を改善するには？

●操作は互いに独立している必要があります- 分離。

純粋に理論的に制御された方法で、操作は外部で何が起こっているかを知る必要があります。ある操作が何かを変更するとすぐに、その結果がすぐに別の操作に見えるようになることはできません。いくつかのルールが必要です。

これは、トランザクション分離と呼ばれます。最も単純なケースでは、トランザクションは近隣のトランザクションで何が起こっているのかを知りません。これらは、それ自体がアクションであり、1つの機能の範囲内で、終了するまで外部との対話はありません。

●操作は、「すべてまたは無」の原則- 原子性で行われます。

つまり、操作全体が完了し、その結果が記録されたか、何か問題が発生した場合は、現状を返すことができるはずです。このような操作は回復可能でなければならず、回復可能で分離されている場合はアトミックです。これは基本的な操作であり、結果のように割り切れません。途中で通過することはできませんが、完全に通過するか、完全に通過しません。

●すべてが正しく行われたことを確認するメカニズム、つまり一貫性が必要です。

私たちの例では、貸借対照表からどれくらいのお金が来たのかを尋ねましたが、何らかの理由で700と言いました。私たちは皆、銀行や会計士が何かをしないように監視する犯罪法違法。刑法は、一貫性のプライベートバージョンの1つです。データベースについて話すと、外部キー、制約、その他すべてのものがあります。

ACIDトランザクション

原子性、一貫性、分離、および耐久性のプロパティを持つデータを持つアクションは、ACIDトランザクションの定義です。

D- 耐久性は、私が話していたモデルです。データが既にディスクに書き込まれている場合、それらはそこにあり、安全に記録され、どこにも行かないと信じています。実際、これはそうではありません。たとえば、データをバックアップする必要がありますが、このモデルではこれは重要ではありません。

悲しいことに、これらのプロパティはロックを使用してのみ実現できます。 トランザクションのスケジューリングには、主に3つのアプローチがあります。

悲観的なシェダー;
楽観的なシェダー;
ハイブリッドシェダーと進行中のトランザクションのタイムスタンプベースの順序付け。

シェダラーは 、トランザクションのシリアル化と適切な実行を保証するコンポーネントです 。

タイムスタンプの順序については誰もが知っています。1つのトランザクションの時間、別のトランザクションの時間、最初に起きた人、そのスリッパを調べます。実際、ほとんどの深刻なシステムでは、このアプローチには多くの問題があります。なぜなら、初心者にとっては、サーバーの時間が逆行したり、スキップしたり間違ったりすることがあるためです。

これを改善するにはさまざまな方法がありますが、トランザクションを同期する1つの方法としては機能しません。ベクトル時計、ランポート時計もあります-彼らはそのような用語を聞いたことがあるはずです-しかし、彼らはまた、独自の制限があります。

楽観的なアプローチは、銀行口座で説明したような矛盾がないことを意味します。しかし、楽観的なオプションを使用していくつかの操作を実行するのに役立つ実装がありますが、実際にはそれらはあまりうまく機能しません。

データベースを扱う人々として、私たちは常に悲観的です。プログラマーが悪いコードを書き、サプライヤーが悪いハードウェアを提供し、Mary Ivannaが床を掃除するときに壁のコンセントからサーバーのプラグを抜くことを期待しています。

したがって、 悲観的なトランザクションシェディング、つまりロックの助けが必要です。これは、データベースの整合性を保証する唯一の保証された方法です。証明および実証できる対応する定理があります。

ロックとロック解除に効果的なアルゴリズムが必要です。必要なものをすべてブロックするだけでは、すべての操作を厳密に連続して実行すると、非常に愚かなバージョンになる可能性が高いからです。すでに知っているように、これは同時使用率、最新のCPU、サーバー数などの点で効果的ではありません。

エルブランのセマンティクス

次に起こることを理解するのに役立つ小さな叙情的な余談。ジャック・エルブランは、20世紀前半のフランスの数学者であり、偶然にも再帰を発明しました。彼は次の方法でトランザクションを示すためにコンピューター以前の時代に思いついた：

ここで、 Sは「スケジュール」という単語の一部です。トランザクションスケジュールには、操作-r （読み取り-読み取り）またはw （書き込み-書き込み）が含まれます。 b （開始）、 c （コミット）なども発生します。

これは便利です-2つのトランザクション（番号1と2）があります。 1つのトランザクションはリソース（ x ）からデータを読み取り、2番目のトランザクションもそれを読み取り、 xのこれら2つの読み取りに基づいて計算を行い、 yに何かを書き込みます。

非常に便利-トランザクションは基本的な読み書きアクション、読み書きアクションで構成されています。 scheduleな数学の助けを借りて、最終的なスケジュールを作成し、競合があるかどうかを確認して、すべてが正常で完全であることを保証できます。

これは何のためですか？

二相ロック

最新のデータベースの基本的なアルゴリズムの1つは、いわゆる2フェーズロックまたは2PL （2フェーズロック）です。

データベースのロックとロック解除を最適化するために、2つのステップでこれを行うのが便利であることに気づいたため、これは2フェーズです。

まず、現在データベースにあるトランザクションの配列に対して読み取りまたは書き込みが必要なすべてのリソースにロックを設定します。
必要なロックがすべて設定されるまで、単一のロックは解除されません。

これにより、トランザクションをより効率的に処理して、待機しないようにすることができます。

図3では、バーはトランザクションとその実行時間を示しています。リソースxの最初のトランザクションでの書き込み操作は、記録に時間がかかるため、ディスクが回転するまで、ページがそこに移動するなどの理由で、ゼロ以外の時間があります。

開始時には、このモデルには他のトランザクションがないため、記録が開始され、書き込まれます。ただし、2番目のトランザクションもxを読み取る必要があります。 xが現在別のトランザクションによって書き込まれているという単純な理由により、このトランザクションはxの読み取りをロックできません。線が破線になります-これは、トランザクションt _1が設定したロックをトランザクションが待機していることを意味します。

トランザクションt ₂がそれを実行するために必要なすべてのロックを取得するとすぐに-彼女はまだyのロックとzのロックを必要としています-それから彼女はそれらを解放し始めることができます。この時点で、次のトランザクションのロックが解除され、最後まで実行されます。

この考え方により、トランザクションの効率が向上し、基本操作がブロックされ、競合する場合にのみ待機するように、同じ操作のみを並列に配置できます。

「Transactional Information Systems」（Gerhard Weikum、Gottfried Vossen）という本をお勧めします。これは、取引理論に関する基本的な教科書です。

二相ブロッキングの何が悪いのですか？

1つの単純な魔法のアルゴリズムですべてのデータベースの問題全体を解決できないのはなぜですか？

✓第一に、このようなロックでは、鶏や卵のように透明でない場合、必然的にデッドロックが発生します。

あるトランザクションはリソースxを必要とし、別のトランザクションはそれをブロックし、次に同じリソースを横方向に必要とし、誰が最初にロックを解除すべきかは明確ではありません。これを行うために、データベースには、デッドロックといわゆるデッドロックシューティングを制御するための特別なシステムがあります。デッドロックを平和的に解決することはできませんが、トランザクションの1つをロールバックするだけです。

通常、デッドロック検出内の数学はデッドロックグラフであり、トランザクションIDが頂点に示され、有向エッジがどのブロックがどのブロックからのブロッキングを待機しているかを示します。このグラフでは、これらの頂点の1つからの小さなサブグラフが強調表示されています。たとえば、1つのトランザクションが非常に多数のトランザクションを待機している場合、このトランザクションが釘付けになります。

しかし、デッドロック検出で検索できる他の美しい数学的アプローチがあります。

✓2番目のポイントは遅い -誰もロックを待ちたくない。

リソースを長時間使用するトランザクションがあります。たとえば、一部のレポートはリソースを使用したとみなし、他のすべてのユーザーは待機する必要があります。これを防ぐために、彼らはいくつかの改善を思い付きました。それについては少し後で説明します。

✓しかし、この方法でシリアル化が保証されます。

2フェーズブロッキングがない場合、シリアル化は行われません。つまり、待機時間を短縮するために、2フェーズブロッキングを改善する方法を理解する必要があります。

最新のデータベースでは、バージョン付きデータベースについて話している場合でも、2フェーズロックが整合性とシリアル化を保証する主な方法です。

実際、原則として2PLで解決できない競合があり、競合するトランザクションの1つがロールバックされます。通常、メカニズムはデータベースに実装されます。データベースがしばらく待機し、一部のトランザクションがロックを長時間待機していること、および競合を解決する方法がないことを認識すると、データベースはそのようなトランザクションを強制終了します。これはまれな状況であり、次のアルゴリズムを使用すると、これらの競合の一部を解決できます。

MVCC-マルチバージョン同時実行制御

データのバージョン管理は、データを高速化するためだけでなく、発生する可能性のあるいくつかのタイプの競合を解決するためにも必要です。

✓直感的に、すべてが明確です-ロックを待たないために、以前のバージョンを使用します。

一部のリソースがブロックされている場合、古いバージョンを確認して作業を開始できます。たとえば、ブロックされたトランザクションがこのリソースで何も変更しないようなロックであった場合、トランザクションを実行し続けることができます。変更があり、新しい、より新しいバージョンのデータが表示された場合、トランザクションは再度そのデータを再度読み取る必要があります。

いずれにせよ、これは通常、ロックを長時間待つよりも高速です。古いMS SQL ServerとDB2の古いバージョンを覚えているなら、それはひどいことです。そして、多くのロックがあった場合、それらはエスカレートします-すべてがうまくいきませんでした。

✓最新のDBMSはすべてバージョン管理されています

Oracle、PostgreSQL、MySQLはすべて正直に「バージョン管理」されています。 DB2はこのトピックに関してもう少し独創的であり、独自のメカニズムがあります-以前のバージョンを1つだけ保存します。

これは以前に描いたスケジュールですが、やや複雑です。より多くのトランザクション（3個）、より多くのリソース（まだzがあります）、および2つのコミットがあります。つまり、両方のトランザクションがコミットで終了します。

数学者がそのような場合に言うように、「気づきやすい...」-私はこれが大好きです。特に式が半分のボードであるとき。実際、ここで1つのことに気付くのは簡単です。宿題として、なぜこれに気付きやすいのかを理解してください。

教えます yの前のバージョンが使用できない場合、操作r ₁ （y）が競合、場合によってはデッドロックを引き起こすという単純な理由で、このスケジュールは決してシリアル化されません。

つまり、 yの以前のバージョンがここで利用できる場合、トランザクションは正常に完了し、問題はありません。 yのこのバージョンがそうでない場合、操作は競合します。

どのように機能しますか？

この図は、2相ブロックとほぼ同じです。これは、バージョントランザクションスケジューリングの一種です。つまり、まだ2フェーズブロッキングアルゴリズムであり、マルチバージョンアルゴリズムのみです。

別の機能が添え字として追加されます-0、1、2-これはバージョン番号です。

トランザクションt ₁を実行しようとすると、読み取り値x _0があります。非常にオリジナルのバージョン。
さらにt _2では、バージョンが変更されたため、異なるバージョンのyの書き込みを開始します。
yの書き込みを開始する前に開始したトランザクションt ₁では、 t ₂がまだ完了していないため、 y _0の以前のバージョンが表示されたままであり、安全に作業を開始できます。
トランザクションt ₁はw ₂ （ y ₂ ）よりも早く終了するため、 yの再読み取りが発生し、トランザクションt ₂で通常の操作が実行され、他のトランザクションは正常に終了します。

以前のバージョンがないと想像しようとすると、長い点線がすぐに始まります。 yを読み取る必要がある場合、 w ₂ （ y ）はt _1が完了するまで待機するため、実線は開始されず、点線が開始されます。したがって、スケジュールの幅が腐食し、すべてが遅くなります。

これは大きなプラスMVCCです。マルチバージョンは実際にはブロッキングよりも高速であり、単なるマーケティング機能ではありません。

しかし、トランザクションの期間が明らかにゼロではない場合、たとえば、ハードドライブがデータベースの下でバラバラになったり、ワイヤがサーバーから引き出されたりすると、障害が発生します。

実際、トランザクションはこのように実行されるため、これに対応できます。抽象データベースを考えます：

クライアント接続が処理されるさまざまなプロセスまたはスレッド間でソーシャル化される一定量のメモリがあります。スレッドには、SQLクエリが到着する独自のメモリ量があります。このメモリ量で、SQLクエリ（または別の言語のクエリ）が何らかの方法でプリコンパイル、解釈、再構築されます。

次に、彼は読み取り、変更する必要があるデータを探します。ディスク上のこのデータは特別な方法です。ストレージをさらに深く見ると、PostgreSQLの固定部分（ページ）は8Kbであり、Oracleではさまざまなサイズを使用できます。さまざまな方法でさまざまなデータベースに。

このページには、さまざまなデータが多数含まれているという点で非常に便利です（実際には、タプル（タプル）が含まれています。つまり、プレートがあり、その中に行があり、これらの行は大きなページに詰め込まれます。

リクエストがページの1つからのデータを必要とする場合、このページをメモリに移動するだけで、すべてのワーカー、スレッド、およびデータベースプロセスがアクセスできます。あなたがたくさん必要な場合、彼はいくつかを発生させます。それらはキャッシュされます-これは便利で生産的です-メモリはすべてのディスクよりも高速です。

少なくとも1つのページで少なくとも1つのエントリを変更する必要がある場合、ページ全体がいわゆる「ダーティ」としてマークされます。これはより便利だからです。図にxおよびyリソースを描画しました-これらはここのページです。

実際、データベースは、単一のレコードを含むより詳細なレベルでブロックできます。しかし今、私たちはより深い理論のことについて話しているのであって、深い認識の複雑さについては話していません。

したがって、ページは「ダーティ」としてマークされ、問題があります。これは、メモリ上の印象がディスク上の印象と異なるということです。今落ちた場合、メモリは永続的ではなく、「ダーティ」ページに関する情報を失います。

: - , , , , , , , .

, , Write Ahead Log. , — WAL , , data- .

— . - , Write Ahead Log , «». .

, , , , , , .

ARIES . 1992 .

— Write Ahead Log Write Ahead Log. . - :

MySQL InnoDB,
PostgreSQL , 10 WAL PGX-Log;
Oracle Redo Log;
DB2 — WAL.

, - — , WAL.

, , WAL. , .

Checkpoint

Checkpoint — «» . , Checkpoint. , , , .

— , , . Word , .

. . , , .

, , , - - . , . — , .

, A B . , . , engine , , .

, SQL, . sequential scan A B — , — .

, , JOIN, - , .

? : - Python , , JOIN 90% . — , , . , . , JOIN, , .. , , full sequential scan, , , , .

.

結論

SQL - , . SQL , . , SQL .

. : , , -. , , . , , . , , .

. . — .

, , . , , .

!

, , . , — SQL, , , , .

— , , , , , . .

, , - - : « — , , !»

. , . noSQL - , , , . , , , , ..

, , , .

Percona server, MariaDB, MySQL 8, , .

, , ?

… ++ , , Highload++ Siberia , - .

, :

, Oracle 7- 18- , .

(Altinity) (Ivinco) MySQL ClickHouse .

() LZ4 .

データベースの配置方法

なぜこれを知る必要があるのですか？

データレベル