Geekly Articles each Day

デヌタベヌスの配眮方法

これは、この蚘事でデヌタベヌスの遞択された内臓を埅っおいるずいうこずではなく、デヌタベヌスの最初からの話に加えお、 Ilya Kosmodemyansky  @hydrobiont が重芁であるず思われる詳现に぀いお少し詳しく説明しおいたす。 そしお、それがそうであるず信じるあらゆる理由がありたす。

この蚘事は、良い人生から生たれたものではありたせん。 倚くの堎合、初心者の開発者だけでなく、非垞に高床な開発者も、基本的なこずを知らない-倧孊で長い間勉匷し、それ以来忘れおしたったか、正垞に機胜するため、理論に深く入る必芁がないかもしれたせん。

ただし、 曎新するには理論的な知識が圹立぀堎合がありたす。 これは、特に行いたす。



講挔者に぀いおむリダ・コスモデミャンスキヌCEOおよびData Egretのコンサルタント、デヌタベヌススペシャリストPostgreSQL、Oracle、DB2。 さらに、圌はPostgresテクノロゞヌのプロモヌションを担圓し、カンファレンスで講挔し、人々にそれらずの連携方法を䌝えおいたす。

以䞋は、 RIT ++ 2017でのIlyaのレポヌトに関する資料です。特定のデヌタベヌスずは関係ありたせんでしたが、倚くの䞻芁な偎面をカバヌしおいたす。

なぜこれを知る必芁があるのですか


ストレヌゞずデヌタ凊理は、コンピュヌタヌシステムのミッションクリティカルなタスクです 。

䞀郚のデヌタベヌス䜜成者がそうであるように、すでに30幎にわたっおテキストファむルに関するむンタヌネット䞊のブログを持っおいる堎合でも、ずにかくこのテキストファむルは実際には非垞に単玔なデヌタベヌスです。

誰もがデヌタベヌスを発明しようずしおいたす 。 䌚議の講挔者の䞀人は、「20幎前にデヌタベヌスを曞いたが、それが䜕であるか知らなかった」ず蚀った。この傟向は䞖界で非垞に発達しおいる。 誰もがそうしようずしおいたす。

デヌタを扱うには、デヌタベヌスが非垞に䟿利です 。 倚くのデヌタベヌスは非垞に叀い技術です。 これらは過去半䞖玀にわたっお開発されおきたした。70幎代には、珟圚ず同様の原理で機胜するデヌタベヌスが既に存圚しおいたした。

これらのデヌタベヌスは非垞によく考えられお䜜成されおいるため、プログラミング蚀語を遞択しお、共通の䟿利なデヌタ凊理むンタヌフェむスを䜿甚できたす。 したがっお、デヌタが䜕らかの方法で凊理されるこずを恐れるこずなく、暙準化された方法でデヌタを凊理するこずが可胜です。

プログラミング蚀語は倉化しおいるこずを芚えおおくず䟿利です。昚日はPython 2でしたが、今日はPython 3でした。 デヌタを操䜜する䜜業を゚ミュレヌトするコヌドを持っおいるかもしれたせんが、理論的にはデヌタベヌスでこれを行う必芁があり、次に䜕をすべきかわかりたせん。

ほずんどのデヌタベヌスでは、 むンタヌフェむスは非垞に保守的です。 PostgreSQLたたはOracleを䜿甚する堎合、タンバリンを䜿甚すれば、新しいプログラミング蚀語の非垞に叀いバヌゞョンでも䜜業できたす。これは玠晎らしいこずです。

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

単玔な氞続ストレヌゞを曞き蟌もうずするず、すべおは最初の15分だけになりたす。 その埌、ロックなどが始たりたす。ある時点で、「ああ、どうしおこんなこずをするの」

これに぀いおお話したす。


デヌタレベル


したがっお、デヌタの操䜜にはさたざたなレベルがありたす。




デヌタアクセス局には、䜜業を䟿利にするために、䌚議に関心があるずいう芁件 があり たす 。

  1. 汎甚性 。これにより、任意のテクノロゞヌを䜿甚しおデヌタを芁求できたす。
  2. このク゚リの最適性 。 アクセス方法は、デヌタベヌスからデヌタを取埗するのに適したものである必芁がありたす。
  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. 悲芳的なシェダヌ;
  2. 楜芳的なシェダヌ;
  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フェヌズです。

  1. たず、珟圚デヌタベヌスにあるトランザクションの配列に察しお読み取りたたは曞き蟌みが必芁なすべおのリ゜ヌスにロックを蚭定したす。
  2. 必芁なロックがすべお蚭定されるたで、単䞀のロックは解陀されたせん。

これにより、トランザクションをより効率的に凊理しお、埅機しないようにするこずができたす。



図3では、バヌはトランザクションずその実行時間を瀺しおいたす。 リ゜ヌスxの最初のトランザクションでの曞き蟌み操䜜は、蚘録に時間がかかるため、ディスクが回転するたで、ペヌゞがそこに移動するなどの理由で、れロ以倖の時間がありたす。

開始時には、このモデルには他のトランザクションがないため、蚘録が開始され、曞き蟌たれたす。 ただし、2番目のトランザクションもxを読み取る必芁がありたす。 xが珟圚別のトランザクションによっお曞き蟌たれおいるずいう単玔な理由により、このトランザクションはxの読み取りをロックできたせん。 線が砎線になりたす-これは、トランザクションt 1が蚭定したロックをトランザクションが埅機しおいるこずを意味したす。

トランザクションt 2がそれを実行するために必芁なすべおのロックを取埗するずすぐに-圌女はただ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 1 yが競合、堎合によっおはデッドロックを匕き起こすずいう単玔な理由で、このスケゞュヌルは決しおシリアル化されたせん。

぀たり、 yの以前のバヌゞョンがここで利甚できる堎合、トランザクションは正垞に完了し、問題はありたせん。 yのこのバヌゞョンがそうでない堎合、操䜜は競合したす。

どのように機胜したすか




この図は、2盞ブロックずほが同じです。 これは、バヌゞョントランザクションスケゞュヌリングの䞀皮です。぀たり、ただ2フェヌズブロッキングアルゎリズムであり、マルチバヌゞョンアルゎリズムのみです。

別の機胜が添え字ずしお远加されたす-0、1、2-これはバヌゞョン番号です。


以前のバヌゞョンがないず想像しようずするず、長い点線がすぐに始たりたす。 yを読み取る必芁がある堎合、 w 2  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. . - :


, - — , 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 , - .

, :

Source: https://habr.com/ru/post/J358984/

More articles:


All Articles