[{"@context":"http:\/\/schema.org\/","@type":"BlogPosting","@id":"https:\/\/wiki.edu.vn\/wiki17\/2021\/01\/27\/parallelitatskontrolle-wikipedia\/#BlogPosting","mainEntityOfPage":"https:\/\/wiki.edu.vn\/wiki17\/2021\/01\/27\/parallelitatskontrolle-wikipedia\/","headline":"Parallelit\u00e4tskontrolle – Wikipedia","name":"Parallelit\u00e4tskontrolle – Wikipedia","description":"before-content-x4 In der Informationstechnologie und Informatik, insbesondere in den Bereichen Computerprogrammierung, Betriebssysteme, Multiprozessoren und Datenbanken, Parallelit\u00e4tskontrolle stellt sicher, dass korrekte","datePublished":"2021-01-27","dateModified":"2021-01-27","author":{"@type":"Person","@id":"https:\/\/wiki.edu.vn\/wiki17\/author\/lordneo\/#Person","name":"lordneo","url":"https:\/\/wiki.edu.vn\/wiki17\/author\/lordneo\/","image":{"@type":"ImageObject","@id":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/44a4cee54c4c053e967fe3e7d054edd4?s=96&d=mm&r=g","height":96,"width":96}},"publisher":{"@type":"Organization","name":"Enzyklop\u00e4die","logo":{"@type":"ImageObject","@id":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","url":"https:\/\/wiki.edu.vn\/wiki4\/wp-content\/uploads\/2023\/08\/download.jpg","width":600,"height":60}},"image":{"@type":"ImageObject","@id":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/1\/1c\/Wiki_letter_w_cropped.svg\/20px-Wiki_letter_w_cropped.svg.png","url":"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/1\/1c\/Wiki_letter_w_cropped.svg\/20px-Wiki_letter_w_cropped.svg.png","height":"14","width":"20"},"url":"https:\/\/wiki.edu.vn\/wiki17\/2021\/01\/27\/parallelitatskontrolle-wikipedia\/","wordCount":5280,"articleBody":"     (adsbygoogle = window.adsbygoogle || []).push({});before-content-x4In der Informationstechnologie und Informatik, insbesondere in den Bereichen Computerprogrammierung, Betriebssysteme, Multiprozessoren und Datenbanken, Parallelit\u00e4tskontrolle stellt sicher, dass korrekte Ergebnisse f\u00fcr gleichzeitige Vorg\u00e4nge generiert werden, w\u00e4hrend diese Ergebnisse so schnell wie m\u00f6glich abgerufen werden.       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Computersysteme, sowohl Software als auch Hardware, bestehen aus Modulen oder Komponenten.  Jede Komponente ist so konzipiert, dass sie ordnungsgem\u00e4\u00df funktioniert, dh bestimmte Konsistenzregeln befolgt oder erf\u00fcllt.  Wenn Komponenten, die gleichzeitig arbeiten, durch Messaging oder durch gemeinsame Nutzung von Daten, auf die zugegriffen wird (im Speicher oder im Speicher), interagieren, kann die Konsistenz einer bestimmten Komponente von einer anderen Komponente verletzt werden.  Der allgemeine Bereich der Parallelit\u00e4tskontrolle bietet Regeln, Methoden, Entwurfsmethoden und Theorien, um die Konsistenz von Komponenten zu gew\u00e4hrleisten, die w\u00e4hrend der Interaktion gleichzeitig arbeiten, und damit die Konsistenz und Korrektheit des gesamten Systems.  Das Einf\u00fchren der Parallelit\u00e4tskontrolle in ein System bedeutet das Anwenden von Betriebsbeschr\u00e4nkungen, die normalerweise zu einer gewissen Leistungsminderung f\u00fchren.  Die Konsistenz und Korrektheit des Betriebs sollte mit m\u00f6glichst guter Effizienz erreicht werden, ohne die Leistung unter ein angemessenes Ma\u00df zu reduzieren.  Die Parallelit\u00e4tssteuerung kann in einem gleichzeitigen Algorithmus im Vergleich zum einfacheren sequentiellen Algorithmus eine erhebliche zus\u00e4tzliche Komplexit\u00e4t und zus\u00e4tzlichen Aufwand erfordern.Beispielsweise kann ein Fehler bei der Parallelit\u00e4tssteuerung zu einer Datenbesch\u00e4digung durch zerrissene Lese- oder Schreibvorg\u00e4nge f\u00fchren.Table of Contents       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Parallelit\u00e4tskontrolle in Datenbanken[edit]Datenbanktransaktion und die ACID-Regeln[edit]Warum ist eine Parallelit\u00e4tskontrolle erforderlich?[edit]Parallelit\u00e4tskontrollmechanismen[edit]Kategorien[edit]Methoden[edit]Hauptziele von Parallelit\u00e4tskontrollmechanismen[edit]Richtigkeit[edit]Serialisierbarkeit[edit]Wiederherstellbarkeit[edit]Verteilung[edit]Verteilte Serialisierbarkeit und Commitment-Bestellung[edit]Verteilte Wiederherstellbarkeit[edit]Andere wichtige Themen der Aufmerksamkeit[edit]Wiederherstellung[edit]Reproduzieren[edit]Siehe auch[edit]Verweise[edit]Zitate[edit]Parallelit\u00e4tskontrolle in Betriebssystemen[edit]Siehe auch[edit]Verweise[edit]Parallelit\u00e4tskontrolle in Datenbanken[edit]Bemerkungen:Dieser Abschnitt gilt f\u00fcr alle Transaktionssysteme, dh f\u00fcr alle Systeme, die diese verwenden Datenbanktransaktionen ((atomare Transaktionen;;  B. Transaktionsobjekte in der Systemverwaltung und in Netzwerken von Smartphones, die typischerweise private, dedizierte Datenbanksysteme implementieren, nicht nur Allzweck-Datenbankverwaltungssysteme (DBMS).DBMS m\u00fcssen sich auch mit Problemen der Parallelit\u00e4tskontrolle befassen, die nicht nur f\u00fcr Datenbanktransaktionen, sondern allgemein f\u00fcr Betriebssysteme typisch sind.  Diese Probleme (z. B. siehe Parallelit\u00e4tskontrolle in Betriebssystemen unten) fallen nicht in den Geltungsbereich dieses Abschnitts.Die Parallelit\u00e4tskontrolle in Datenbankverwaltungssystemen (DBMS; z. B. Bernstein et al. 1987, Weikum und Vossen 2001), anderen Transaktionsobjekten und verwandten verteilten Anwendungen (z. B. Grid Computing und Cloud Computing) stellt dies sicher Datenbanktransaktionen werden gleichzeitig ausgef\u00fchrt, ohne die Datenintegrit\u00e4t der jeweiligen Datenbanken zu verletzen.  Daher ist die Parallelit\u00e4tskontrolle ein wesentliches Element f\u00fcr die Korrektheit in jedem System, in dem zwei oder mehr Datenbanktransaktionen, die mit zeitlicher \u00dcberlappung ausgef\u00fchrt werden, auf dieselben Daten zugreifen k\u00f6nnen, z. B. praktisch in jedem Allzweck-Datenbanksystem.  Infolgedessen hat sich seit dem Aufkommen von Datenbanksystemen in den fr\u00fchen 1970er Jahren eine Vielzahl verwandter Forschungsergebnisse angesammelt.  Eine gut etablierte Theorie der Parallelit\u00e4tskontrolle f\u00fcr Datenbanksysteme ist in den oben genannten Referenzen beschrieben: Serialisierbarkeitstheorie, mit der Methoden und Mechanismen der Parallelit\u00e4tskontrolle effektiv entworfen und analysiert werden k\u00f6nnen.  Eine alternative Theorie zur Parallelit\u00e4tskontrolle atomarer Transaktionen \u00fcber abstrakte Datentypen wird in (Lynch et al. 1993) vorgestellt und im Folgenden nicht verwendet.  Diese Theorie ist verfeinert, komplexer, hat einen breiteren Anwendungsbereich und wurde in der Datenbankliteratur weniger verwendet als die obige klassische Theorie.  Jede Theorie hat ihre Vor- und Nachteile, Schwerpunkte und Einsichten.  Bis zu einem gewissen Grad erg\u00e4nzen sie sich, und ihre Verschmelzung kann n\u00fctzlich sein.Um die Richtigkeit zu gew\u00e4hrleisten, garantiert ein DBMS normalerweise nur dies serialisierbar Transaktionspl\u00e4ne werden generiert, sofern nicht Serialisierbarkeit wird absichtlich gelockert, um die Leistung zu steigern, jedoch nur in F\u00e4llen, in denen die Richtigkeit der Anwendung nicht beeintr\u00e4chtigt wird.  Um die Korrektheit bei fehlgeschlagenen (abgebrochenen) Transaktionen zu gew\u00e4hrleisten (was aus vielen Gr\u00fcnden immer vorkommen kann), m\u00fcssen die Zeitpl\u00e4ne ebenfalls \u00fcber Folgendes verf\u00fcgen: Wiederherstellbarkeit (vom Abbruch) Eigentum.  Ein DBMS garantiert auch, dass keine Wirkung von engagiert sein Transaktionen gehen verloren und keine Auswirkung von abgebrochen (Rollback-) Transaktionen verbleiben in der zugeh\u00f6rigen Datenbank.  Die allgemeine Transaktionscharakterisierung wird normalerweise durch die folgenden ACID-Regeln zusammengefasst.  Da Datenbanken verteilt wurden oder f\u00fcr die Zusammenarbeit in verteilten Umgebungen erforderlich sind (z. B. Federated-Datenbanken Anfang 1990 und Cloud Computing derzeit), hat die effektive Verteilung von Mechanismen zur Kontrolle der Parallelit\u00e4t besondere Aufmerksamkeit erhalten.Datenbanktransaktion und die ACID-Regeln[edit]Das Konzept eines Datenbanktransaktion (oder Atomtransaktion) wurde entwickelt, um sowohl ein gut verstandenes Verhalten des Datenbanksystems in einer fehlerhaften Umgebung zu erm\u00f6glichen, in der jederzeit Abst\u00fcrze auftreten k\u00f6nnen, als auch Wiederherstellung von einem Absturz zu einem gut verstandenen Datenbankstatus.  Eine Datenbanktransaktion ist eine Arbeitseinheit, die normalerweise eine Reihe von Vorg\u00e4ngen \u00fcber eine Datenbank (z. B. Lesen eines Datenbankobjekts, Schreiben, Erfassen einer Sperre usw.), eine in der Datenbank und auch in anderen Systemen unterst\u00fctzte Abstraktion umfasst.  Jede Transaktion hat genau definierte Grenzen, in Bezug darauf, welche Programm- \/ Codeausf\u00fchrungen in dieser Transaktion enthalten sind (vom Programmierer der Transaktion \u00fcber spezielle Transaktionsbefehle festgelegt).  Jede Datenbanktransaktion befolgt die folgenden Regeln (durch Unterst\u00fctzung im Datenbanksystem, dh ein Datenbanksystem soll sie f\u00fcr die von ihr ausgef\u00fchrten Transaktionen garantieren):       (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4Atomizit\u00e4t – Entweder bleiben die Auswirkungen aller oder keiner seiner Operationen erhalten (Semantik “alles oder nichts”), wenn eine Transaktion abgeschlossen ist (engagiert sein oder abgebrochen beziehungsweise).  Mit anderen Worten, f\u00fcr die Au\u00dfenwelt scheint eine festgeschriebene Transaktion (aufgrund ihrer Auswirkungen auf die Datenbank) unteilbar (atomar) zu sein, und eine abgebrochene Transaktion wirkt sich \u00fcberhaupt nicht auf die Datenbank aus.  Entweder sind alle Operationen ausgef\u00fchrt oder keine.Konsistenz – Jede Transaktion muss die Datenbank in einem konsistenten (korrekten) Zustand belassen, dh die vorgegebenen Integrit\u00e4tsregeln der Datenbank (Einschr\u00e4nkungen f\u00fcr und zwischen den Objekten der Datenbank) beibehalten.  Eine Transaktion muss eine Datenbank von einem konsistenten Status in einen anderen konsistenten Status umwandeln (es liegt jedoch in der Verantwortung des Programmierers der Transaktion, sicherzustellen, dass die Transaktion selbst korrekt ist, dh korrekt ausgef\u00fchrt wird, was beabsichtigt ist (aus Sicht der Anwendung) view), w\u00e4hrend die vordefinierten Integrit\u00e4tsregeln vom DBMS erzwungen werden).  Da eine Datenbank normalerweise nur durch Transaktionen ge\u00e4ndert werden kann, sind alle Status der Datenbank konsistent.Isolation – Transaktionen k\u00f6nnen sich nicht gegenseitig st\u00f6ren (als Endergebnis ihrer Ausf\u00fchrung).  Dar\u00fcber hinaus sind die Auswirkungen einer unvollst\u00e4ndigen Transaktion normalerweise (abh\u00e4ngig von der Parallelit\u00e4tskontrollmethode) f\u00fcr eine andere Transaktion nicht einmal sichtbar.  Die Bereitstellung von Isolation ist das Hauptziel der Parallelit\u00e4tskontrolle.Haltbarkeit – Die Auswirkungen erfolgreicher (festgeschriebener) Transaktionen m\u00fcssen durch Abst\u00fcrze bestehen bleiben (normalerweise durch Aufzeichnen der Auswirkungen der Transaktion und ihres Festschreibungsereignisses in einem nichtfl\u00fcchtigen Speicher).Das Konzept der atomaren Transaktion wurde im Laufe der Jahre auf Gesch\u00e4ftstransaktionen erweitert, die tats\u00e4chlich Arten von Workflows implementieren und nicht atomar sind.  Bei solchen erweiterten Transaktionen werden jedoch typischerweise atomare Transaktionen als Komponenten verwendet.Warum ist eine Parallelit\u00e4tskontrolle erforderlich?[edit]Wenn Transaktionen ausgef\u00fchrt werden seriellDas hei\u00dft, sequentiell ohne zeitliche \u00dcberlappung existiert keine Transaktionsgleichzeitigkeit.  Wenn jedoch gleichzeitige Transaktionen mit Verschachtelungsvorg\u00e4ngen auf unkontrollierte Weise zul\u00e4ssig sind, k\u00f6nnen einige unerwartete, unerw\u00fcnschte Ergebnisse auftreten, wie z.Das Problem der verlorenen Aktualisierung: Eine zweite Transaktion schreibt einen zweiten Wert eines Datenelements (Datum) \u00fcber einen ersten Wert, der von einer ersten gleichzeitigen Transaktion geschrieben wurde, und der erste Wert geht f\u00fcr andere Transaktionen verloren, die gleichzeitig ausgef\u00fchrt werden und aufgrund ihrer Priorit\u00e4t erforderlich sind , um den ersten Wert zu lesen.  Die Transaktionen, die den falschen Wert gelesen haben, enden mit falschen Ergebnissen.Das Dirty-Read-Problem: Transaktionen lesen einen Wert, der von einer Transaktion geschrieben wurde, die sp\u00e4ter abgebrochen wurde.  Dieser Wert verschwindet beim Abbruch aus der Datenbank und sollte von keiner Transaktion gelesen worden sein (“Dirty Read”).  Die Lesetransaktionen enden mit falschen Ergebnissen.Das falsche Zusammenfassungsproblem: W\u00e4hrend eine Transaktion eine Zusammenfassung \u00fcber die Werte aller Instanzen eines wiederholten Datenelements erstellt, aktualisiert eine zweite Transaktion einige Instanzen dieses Datenelements.  Die resultierende Zusammenfassung spiegelt kein korrektes Ergebnis f\u00fcr eine (normalerweise zur Richtigkeit erforderliche) Rangfolge zwischen den beiden Transaktionen wider (wenn eine vor der anderen ausgef\u00fchrt wird), sondern ein zuf\u00e4lliges Ergebnis, abh\u00e4ngig vom Zeitpunkt der Aktualisierungen und ob dies sicher ist Aktualisierungsergebnisse wurden in die Zusammenfassung aufgenommen oder nicht.Die meisten Hochleistungs-Transaktionssysteme m\u00fcssen Transaktionen gleichzeitig ausf\u00fchren, um ihre Leistungsanforderungen zu erf\u00fcllen.  Ohne Parallelit\u00e4tskontrolle k\u00f6nnen solche Systeme daher weder korrekte Ergebnisse liefern noch ihre Datenbanken konsistent pflegen.Parallelit\u00e4tskontrollmechanismen[edit]Kategorien[edit]Die Hauptkategorien von Parallelit\u00e4tskontrollmechanismen sind:Optimistisch – Verz\u00f6gern Sie die \u00dcberpr\u00fcfung, ob eine Transaktion die Isolations- und andere Integrit\u00e4tsregeln (z. B. Serialisierbarkeit und Wiederherstellbarkeit) erf\u00fcllt, bis zu ihrem Ende, ohne einen ihrer (Lese-, Schreib-) Vorg\u00e4nge zu blockieren (“… und seien Sie optimistisch, welche Regeln eingehalten werden) … “) und brechen Sie dann eine Transaktion ab, um den Versto\u00df zu verhindern, wenn die gew\u00fcnschten Regeln bei ihrem Festschreiben verletzt werden sollen.  Eine abgebrochene Transaktion wird sofort neu gestartet und erneut ausgef\u00fchrt, was einen offensichtlichen Overhead verursacht (anstatt sie nur einmal bis zum Ende auszuf\u00fchren).  Wenn nicht zu viele Transaktionen abgebrochen werden, ist es normalerweise eine gute Strategie, optimistisch zu sein.Pessimistisch – Blockieren Sie einen Vorgang einer Transaktion, wenn dies zu einem Versto\u00df gegen die Regeln f\u00fchren kann, bis die M\u00f6glichkeit eines Versto\u00dfes verschwindet.  Blockierungsvorg\u00e4nge sind normalerweise mit einer Leistungsreduzierung verbunden.Halboptimistisch – Blockieren Sie Vorg\u00e4nge in bestimmten Situationen, wenn sie zu Verst\u00f6\u00dfen gegen bestimmte Regeln f\u00fchren k\u00f6nnen, und blockieren Sie sie in anderen Situationen nicht, w\u00e4hrend Sie die \u00dcberpr\u00fcfung der Regeln (falls erforderlich) bis zum Ende der Transaktion verz\u00f6gern, wie dies mit Optimismus geschehen ist.Unterschiedliche Kategorien bieten unterschiedliche Leistung, dh unterschiedliche durchschnittliche Transaktionsabschlussraten (Durchsatz), abh\u00e4ngig von der Mischung der Transaktionstypen, dem Rechengrad der Parallelit\u00e4t und anderen Faktoren.  Wenn Auswahl und Wissen \u00fcber Kompromisse verf\u00fcgbar sind, sollten Kategorie und Methode ausgew\u00e4hlt werden, um die h\u00f6chste Leistung zu erzielen.Das gegenseitige Blockieren zwischen zwei Transaktionen (wobei jede die andere blockiert) oder mehr f\u00fchrt zu einem Deadlock, bei dem die beteiligten Transaktionen blockiert sind und nicht abgeschlossen werden k\u00f6nnen.  Die meisten nicht optimistischen Mechanismen (mit Blockierung) sind anf\u00e4llig f\u00fcr Deadlocks, die durch einen absichtlichen Abbruch einer blockierten Transaktion (die die anderen Transaktionen in diesem Deadlock freigibt) und deren sofortigen Neustart und erneute Ausf\u00fchrung behoben werden.  Die Wahrscheinlichkeit eines Deadlocks ist normalerweise gering.Blockieren, Deadlocks und Abbr\u00fcche f\u00fchren zu einer Leistungsminderung und damit zu Kompromissen zwischen den Kategorien.Methoden[edit]Es gibt viele Methoden zur Parallelit\u00e4tskontrolle.  Die meisten von ihnen k\u00f6nnen in beiden oben genannten Hauptkategorien implementiert werden.  Die wichtigsten Methoden,[1]  die jeweils viele Varianten haben und in einigen F\u00e4llen \u00fcberlappen oder kombiniert werden k\u00f6nnen, sind:Sperren (z. Zweiphasenverriegelung – 2PL) – Steuern des Zugriffs auf Daten durch Sperren, die den Daten zugewiesen sind.  Der Zugriff einer Transaktion auf ein Datenelement (Datenbankobjekt), das von einer anderen Transaktion gesperrt wurde, kann (abh\u00e4ngig vom Sperrtyp und vom Zugriffsoperationstyp) bis zur Freigabe der Sperre blockiert werden.\u00dcberpr\u00fcfung des Serialisierungsdiagramms (auch als Serialisierbarkeits-, Konflikt- oder Priorit\u00e4tsdiagrammpr\u00fcfung bezeichnet) – \u00dcberpr\u00fcfen Sie das Diagramm des Zeitplans auf Zyklen und unterbrechen Sie diese durch Abbr\u00fcche.Zeitstempelbestellung (TO) – Zuweisen von Zeitstempeln zu Transaktionen und Steuern oder \u00dcberpr\u00fcfen des Zugriffs auf Daten nach Zeitstempelreihenfolge.Verpflichtungsbestellung (oder Commit-Reihenfolge; CO) – Steuern oder \u00dcberpr\u00fcfen der chronologischen Reihenfolge von Commit-Ereignissen von Transaktionen, um mit ihrer jeweiligen Priorit\u00e4tsreihenfolge kompatibel zu sein.Andere wichtige Arten der Parallelit\u00e4tskontrolle, die in Verbindung mit den oben genannten Methoden verwendet werden, sind:Multiversion-Parallelit\u00e4tskontrolle (MVCC) – Erh\u00f6hen der Parallelit\u00e4t und Leistung durch Generieren einer neuen Version eines Datenbankobjekts bei jedem Schreiben des Objekts und Erm\u00f6glichen der Lesevorg\u00e4nge von Transaktionen mit mehreren letzten relevanten Versionen (jedes Objekts) in Abh\u00e4ngigkeit von der Planungsmethode.Kontrolle der Index-Parallelit\u00e4t – Synchronisieren von Zugriffsvorg\u00e4ngen mit Indizes und nicht mit Benutzerdaten.  Spezialisierte Methoden sorgen f\u00fcr erhebliche Leistungssteigerungen.Privates Arbeitsbereichsmodell ((Zur\u00fcckgestelltes Update) – Jede Transaktion unterh\u00e4lt einen privaten Arbeitsbereich f\u00fcr ihre Daten, auf die zugegriffen wird, und ihre ge\u00e4nderten Daten werden au\u00dferhalb der Transaktion erst nach ihrem Festschreiben sichtbar (z. B. Weikum und Vossen 2001).  Dieses Modell bietet in vielen F\u00e4llen ein anderes Verhalten bei der Parallelit\u00e4tskontrolle mit Vorteilen.Der h\u00e4ufigste Mechanismus-Typ in Datenbanksystemen seit ihren Anf\u00e4ngen in den 1970er Jahren war Starke strenge Zweiphasenverriegelung (SS2PL; auch genannt Strenge Planung oder Rigorose 2PL) Dies ist ein Sonderfall (Variante) sowohl der Zweiphasenverriegelung (2PL) als auch der Verpflichtungsbestellung (CO).  Es ist pessimistisch.  Trotz seines langen Namens (aus historischen Gr\u00fcnden) ist die Idee des SS2PL Der Mechanismus ist einfach: “Alle von einer Transaktion angewendeten Sperren werden erst nach Beendigung der Transaktion freigegeben.”  SS2PL (oder Rigorosit\u00e4t) ist auch der Name des Satzes aller Zeitpl\u00e4ne, die durch diesen Mechanismus generiert werden k\u00f6nnen, dh, dies sind SS2PL-Zeitpl\u00e4ne (oder Rigoros) mit der Eigenschaft SS2PL (oder Rigorosit\u00e4t).Hauptziele von Parallelit\u00e4tskontrollmechanismen[edit]Parallelit\u00e4tskontrollmechanismen m\u00fcssen zun\u00e4chst korrekt funktionieren, dh um die Integrit\u00e4tsregeln jeder Transaktion (in Bezug auf die Parallelit\u00e4t; anwendungsspezifische Integrit\u00e4tsregeln fallen hier nicht in den Geltungsbereich) beizubehalten, w\u00e4hrend Transaktionen gleichzeitig ausgef\u00fchrt werden, und damit die Integrit\u00e4t des gesamten Transaktionssystems .  Korrektheit muss mit m\u00f6glichst guter Leistung erreicht werden.  Dar\u00fcber hinaus besteht zunehmend ein Bedarf an einem effektiven Betrieb, w\u00e4hrend Transaktionen \u00fcber Prozesse, Computer und Computernetzwerke verteilt werden.  Andere Themen, die die Parallelit\u00e4tskontrolle beeinflussen k\u00f6nnen, sind Wiederherstellung und Replikation.Richtigkeit[edit]Serialisierbarkeit[edit]Aus Gr\u00fcnden der Korrektheit besteht ein gemeinsames Hauptziel der meisten Mechanismen zur Kontrolle der Parallelit\u00e4t darin, Zeitpl\u00e4ne mit dem zu generieren Serialisierbarkeit Eigentum.  Ohne Serialisierbarkeit k\u00f6nnen unerw\u00fcnschte Ph\u00e4nomene auftreten, z. B. kann Geld von Konten verschwinden oder aus dem Nichts generiert werden. Serialisierbarkeit eines Zeitplans bedeutet \u00c4quivalenz (in den resultierenden Datenbankwerten) zu einigen seriell Zeitplan mit denselben Transaktionen (dh, bei denen Transaktionen ohne zeitliche \u00dcberlappung sequentiell und somit vollst\u00e4ndig voneinander isoliert sind: Es ist kein gleichzeitiger Zugriff von zwei Transaktionen auf dieselben Daten m\u00f6glich).  Die Serialisierbarkeit wird als die h\u00f6chste Isolationsstufe unter Datenbanktransaktionen und als das wichtigste Korrektheitskriterium f\u00fcr gleichzeitige Transaktionen angesehen.  In einigen F\u00e4llen sind kompromittierte, entspannte Formen der Serialisierbarkeit f\u00fcr eine bessere Leistung zul\u00e4ssig (z. B. die beliebte Snapshot-Isolation Mechanismus) oder um die Verf\u00fcgbarkeitsanforderungen in stark verteilten Systemen zu erf\u00fcllen (siehe Eventuelle Konsistenz), aber nur, wenn die Korrektheit der Anwendung durch die Entspannung nicht verletzt wird (z. B. ist bei Geldtransaktionen keine Entspannung zul\u00e4ssig, da durch Entspannung Geld verschwinden oder aus dem Nichts erscheinen kann).Fast alle implementierten Parallelit\u00e4tskontrollmechanismen erreichen Serialisierbarkeit durch Bereitstellung Konfliktserialisierbarkeit, ein breiter Spezialfall der Serialisierbarkeit (dh er deckt die meisten serialisierbaren Zeitpl\u00e4ne ab, erm\u00f6glicht keine wesentlichen zus\u00e4tzlichen verz\u00f6gerungsbedingten Einschr\u00e4nkungen), der effizient implementiert werden kann.Wiederherstellbarkeit[edit]Sehen Wiederherstellbarkeit im SerialisierbarkeitKommentar: W\u00e4hrend sich der Begriff “Wiederherstellbarkeit” im allgemeinen Bereich von Systemen auf die F\u00e4higkeit eines Systems beziehen kann, sich von einem Fehler oder einem falschen \/ verbotenen Zustand zu erholen, hat dieser Begriff innerhalb der Parallelit\u00e4tskontrolle von Datenbanksystemen eine bestimmte Bedeutung erhalten.Die Parallelit\u00e4tskontrolle stellt in der Regel auch die Wiederherstellbarkeit Eigenschaft von Zeitpl\u00e4nen zur Aufrechterhaltung der Korrektheit bei abgebrochenen Transaktionen (was aus vielen Gr\u00fcnden immer vorkommen kann). Wiederherstellbarkeit (vom Abbruch) bedeutet, dass keine festgeschriebene Transaktion in einem Zeitplan Daten gelesen hat, die von einer abgebrochenen Transaktion geschrieben wurden.  Solche Daten verschwinden aus der Datenbank (beim Abbruch) und sind Teile eines falschen Datenbankstatus.  Das Lesen solcher Daten verst\u00f6\u00dft gegen die Konsistenzregel von ACID.  Im Gegensatz zur Serialisierbarkeit kann die Wiederherstellbarkeit in keinem Fall beeintr\u00e4chtigt oder gelockert werden, da jede Lockerung bei Abbr\u00fcchen zu einer schnellen Verletzung der Datenbankintegrit\u00e4t f\u00fchrt.  Die oben aufgef\u00fchrten Hauptmethoden bieten Serialisierbarkeitsmechanismen.  Keiner von ihnen in seiner allgemeinen Form bietet automatisch Wiederherstellbarkeit, und spezielle \u00dcberlegungen und Mechanismenverbesserungen sind erforderlich, um die Wiederherstellbarkeit zu unterst\u00fctzen.  Ein h\u00e4ufig verwendeter Sonderfall der Wiederherstellbarkeit ist StrengeDies erm\u00f6glicht eine effiziente Datenbankwiederherstellung nach einem Ausfall (schlie\u00dft jedoch optimistische Implementierungen aus; z. B. kann Strict CO (SCO) keine optimistische Implementierung haben, sondern halboptimistische).Kommentar: Notiere dass der Wiederherstellbarkeit Die Eigenschaft wird auch dann ben\u00f6tigt, wenn kein Datenbankfehler auftritt und keine Datenbank vorhanden ist Wiederherstellung von Ausfall wird ben\u00f6tigt.  Es ist vielmehr erforderlich, Transaktionsabbr\u00fcche automatisch automatisch zu behandeln, was m\u00f6glicherweise nicht mit einem Datenbankfehler und einer Wiederherstellung danach zusammenh\u00e4ngt.Verteilung[edit]Mit der schnellen technologischen Entwicklung des Rechnens verschwimmt der Unterschied zwischen lokalem und verteiltem Rechnen \u00fcber Netzwerke oder Busse mit geringer Latenz.  Daher ist die recht effektive Verwendung lokaler Techniken in solchen verteilten Umgebungen \u00fcblich, z. B. in Computerclustern und Mehrkernprozessoren.  Die lokalen Techniken haben jedoch ihre Grenzen und verwenden Multi-Prozesse (oder Threads), die von Multi-Prozessoren (oder Multi-Cores) unterst\u00fctzt werden, um zu skalieren.  Dadurch werden Transaktionen h\u00e4ufig in verteilte Transaktionen umgewandelt, wenn sie selbst mehrere Prozesse umfassen m\u00fcssen.  In diesen F\u00e4llen lassen sich die meisten lokalen Techniken zur Steuerung der Parallelit\u00e4t nicht gut skalieren.Verteilte Serialisierbarkeit und Commitment-Bestellung[edit]Sehen Verteilte Serialisierbarkeit im SerialisierbarkeitMit der Verteilung von Datenbanksystemen oder der Zusammenarbeit in verteilten Umgebungen (z. B. Verbunddatenbanken in den fr\u00fchen neunziger Jahren und heutzutage Grid Computing, Cloud Computing und Netzwerke mit Smartphones) wurden einige Transaktionen verteilt.  Eine verteilte Transaktion bedeutet, dass die Transaktion Prozesse umfasst und sich \u00fcber Computer und geografische Standorte erstrecken kann.  Dies erfordert effektive Mechanismen zur verteilten Parallelit\u00e4tskontrolle.  Erreichen der Serialisierbarkeitseigenschaft des Zeitplans eines verteilten Systems (siehe Verteilte Serialisierbarkeit und Globale Serialisierbarkeit ((Modulare Serialisierbarkeit)) stellt effektiv besondere Herausforderungen dar, die von den meisten regul\u00e4ren Serialisierbarkeitsmechanismen, die urspr\u00fcnglich f\u00fcr den lokalen Betrieb entwickelt wurden, normalerweise nicht bew\u00e4ltigt werden.  Dies ist insbesondere auf die Notwendigkeit einer kostspieligen Verteilung von Informationen zur Parallelit\u00e4tskontrolle bei Kommunikation und Computerlatenz zur\u00fcckzuf\u00fchren.  Die einzige bekannte allgemein wirksame Technik f\u00fcr den Vertrieb ist die Commitment Ordering, die 1991 (nach ihrer Patentierung) \u00f6ffentlich bekannt gegeben wurde. Verpflichtungsbestellung (Commit Ordering, CO; Raz 1992) bedeutet, dass die chronologische Reihenfolge der Commit-Ereignisse von Transaktionen mit ihrer jeweiligen Priorit\u00e4tsreihenfolge kompatibel bleibt.  CO erfordert keine Verteilung von Informationen zur Parallelit\u00e4tskontrolle und bietet eine allgemeine effektive L\u00f6sung (zuverl\u00e4ssig, leistungsstark und skalierbar) f\u00fcr verteilte und globale Serialisierbarkeit, auch in einer heterogenen Umgebung mit Datenbanksystemen (oder anderen Transaktionsobjekten) mit unterschiedlichen ( beliebige) Mechanismen zur Kontrolle der Parallelit\u00e4t.[1]  CO ist gleichg\u00fcltig, welcher Mechanismus verwendet wird, da es keine Transaktionsoperationsplanung st\u00f6rt (die von den meisten Mechanismen gesteuert wird) und nur die Reihenfolge der Festschreibungsereignisse bestimmt.  Somit erm\u00f6glicht CO die effiziente Verteilung aller anderen Mechanismen und auch die Verteilung einer Mischung verschiedener (beliebiger) lokaler Mechanismen, um eine verteilte und globale Serialisierbarkeit zu erreichen.  Die Existenz einer solchen L\u00f6sung wurde bis 1991 und von vielen Experten auch sp\u00e4ter aufgrund von Missverst\u00e4ndnissen der CO-L\u00f6sung als “unwahrscheinlich” angesehen (siehe Zitate in Globale Serialisierbarkeit).  Ein wichtiger Nebeneffekt von CO ist die automatische verteilte Deadlock-Aufl\u00f6sung.  Im Gegensatz zu CO neigen praktisch alle anderen Techniken (wenn sie nicht mit CO kombiniert werden) zu verteilten Deadlocks (auch als globale Deadlocks bezeichnet), die einer besonderen Behandlung bed\u00fcrfen.  CO ist auch der Name der resultierenden Zeitplaneigenschaft: Ein Zeitplan hat die CO-Eigenschaft, wenn die chronologische Reihenfolge der Festschreibungsereignisse seiner Transaktionen mit der Vorrangreihenfolge der jeweiligen Transaktionen (Teilreihenfolge) kompatibel ist.Das oben erw\u00e4hnte SS2PL ist eine Variante (Sonderfall) von CO und somit auch wirksam, um eine verteilte und globale Serialisierbarkeit zu erreichen.  Es bietet auch eine automatische verteilte Deadlock-Aufl\u00f6sung (eine Tatsache, die in der Forschungsliteratur auch nach der Ver\u00f6ffentlichung von CO \u00fcbersehen wird) sowie Strenge und damit Wiederherstellbarkeit.  Der Besitz dieser gew\u00fcnschten Eigenschaften zusammen mit bekannten effizienten Implementierungen auf der Basis von Sperren erkl\u00e4rt die Beliebtheit von SS2PL.  SS2PL wird seit 1980 verwendet, um eine verteilte und globale Serialisierbarkeit effizient zu erreichen, und ist zum De-facto-Standard daf\u00fcr geworden.  SS2PL blockiert und beschr\u00e4nkt jedoch (pessimistisch), und mit der zunehmenden Verbreitung und Nutzung von Systemen, die sich von herk\u00f6mmlichen Datenbanksystemen unterscheiden (z. B. wie beim Cloud Computing), sind m\u00f6glicherweise weniger einschr\u00e4nkende CO-Typen (z. B. optimistisches CO) erforderlich bessere Leistung.Bemerkungen:Das Verteilte Serialisierbarkeit von Konflikten Eigentum in seiner allgemeinen Form ist schwer effizient zu erreichen, aber es wird effizient \u00fcber seinen Sonderfall erreicht Verteiltes CO: Jede lokale Komponente (z. B. ein lokales DBMS) muss sowohl eine Form von CO bereitstellen als auch eine spezielle erzwingen Abstimmungsstrategie f\u00fcr die Zweiphasiges Festschreibungsprotokoll (2PC: Wird zum Festschreiben verteilter Transaktionen verwendet).  Abweichend vom allgemeinen verteilten CO, Verteilte SS2PL existiert automatisch, wenn alle lokalen Komponenten SS2PL-basiert sind (in jeder Komponente existiert CO, impliziert, und die Strategie f\u00fcr die Reihenfolge der Stimmen wird jetzt automatisch erf\u00fcllt).  Diese Tatsache ist seit den 1980er Jahren bekannt und wird genutzt (dh SS2PL existiert global, ohne \u00fcber CO Bescheid zu wissen), um verteiltes SS2PL effizient zu nutzen, was verteilte Serialisierbarkeit und Strenge impliziert (siehe z. B. Raz 1992, Seite 293; dies ist auch in Bernstein impliziert) et al. 1987, Seite 78).  Eine weniger eingeschr\u00e4nkte verteilte Serialisierbarkeit und Strenge kann effizient durch verteiltes striktes CO (SCO) oder durch eine Mischung aus SS2PL-basierten und SCO-basierten lokalen Komponenten erreicht werden.\u00dcber die Referenzen und die Reihenfolge der Zusagen: (Bernstein et al. 1987) wurde vor der Entdeckung von CO im Jahr 1990 ver\u00f6ffentlicht. Die Eigenschaft CO-Zeitplan wird aufgerufen Dynamische Atomizit\u00e4t in (Lynch et al. 1993, Seite 201).  CO wird in (Weikum und Vossen 2001, Seiten 102, 700) beschrieben, aber die Beschreibung ist teilweise und verfehlt das Wesen von CO.  (Raz 1992) war der erste referierte und zur Ver\u00f6ffentlichung angenommene Artikel \u00fcber CO-Algorithmen (Ver\u00f6ffentlichungen \u00fcber eine \u00e4quivalente dynamische Atomizit\u00e4tseigenschaft k\u00f6nnen jedoch bis 1988 zur\u00fcckverfolgt werden).  Weitere CO-Artikel folgten.  (Bernstein und Newcomer 2009)[1]  Beachten Sie CO als eine der vier wichtigsten Methoden zur Kontrolle der Parallelit\u00e4t und die F\u00e4higkeit von CO, Interoperabilit\u00e4t zwischen anderen Methoden bereitzustellen.Verteilte Wiederherstellbarkeit[edit]Im Gegensatz zur Serialisierbarkeit Verteilte Wiederherstellbarkeit und Verteilte Strenge kann auf einfache Weise effizient erreicht werden, \u00e4hnlich wie verteiltes CO: In jedem Datenbanksystem m\u00fcssen sie lokal angewendet werden und eine Abstimmungsstrategie f\u00fcr das Zwei-Phasen-Festschreibungsprotokoll anwenden (2PC; Raz 1992, Seite 307) ).Wie oben erw\u00e4hnt, verwendet Distributed SS2PL, einschlie\u00dflich Distributed Strictness (Wiederherstellbarkeit) und Distributed Commitment Ordering (Serialisierbarkeit), automatisch die erforderliche Abstimmungsreihenfolge-Strategie und wird (global) erreicht, wenn sie lokal in jedem (lokalen) Datenbanksystem eingesetzt wird (wie bisher) ist seit vielen Jahren bekannt und wird genutzt. Tats\u00e4chlich wird die Lokalit\u00e4t durch die Grenze eines 2PC-Teilnehmers definiert (Raz 1992).Andere wichtige Themen der Aufmerksamkeit[edit]Das Design von Parallelit\u00e4tskontrollmechanismen wird h\u00e4ufig von folgenden Themen beeinflusst:Wiederherstellung[edit]Alle Systeme sind fehleranf\u00e4llig und handhabbar Wiederherstellung vom Scheitern ist ein Muss.  Die Eigenschaften der generierten Zeitpl\u00e4ne, die vom Parallelit\u00e4tskontrollmechanismus vorgegeben werden, k\u00f6nnen die Effektivit\u00e4t und Effizienz der Wiederherstellung beeinflussen.  Beispielsweise ist die Strictness-Eigenschaft (oben im Abschnitt Wiederherstellbarkeit erw\u00e4hnt) h\u00e4ufig f\u00fcr eine effiziente Wiederherstellung w\u00fcnschenswert.Reproduzieren[edit]F\u00fcr Hochverf\u00fcgbarkeit sind Datenbankobjekte h\u00e4ufig repliziert.  Aktualisierungen von Replikaten desselben Datenbankobjekts m\u00fcssen synchronisiert bleiben.  Dies kann die Art und Weise beeinflussen, wie die Parallelit\u00e4tskontrolle durchgef\u00fchrt wird (z. B. Gray et al. 1996)[2]).Siehe auch[edit]Verweise[edit]Philip A. Bernstein, Nathan Goodman (1987), Vassos Hadzilacos: Parallelit\u00e4tskontrolle und Wiederherstellung in Datenbanksystemen  (kostenloser PDF-Download), Addison Wesley Publishing Company, 1987, ISBN 0-201-10715-5 Gerhard Weikum, Gottfried Vossen (2001): Transaktionsinformationssysteme, Elsevier, ISBN 1-55860-508-8 Nancy Lynch, Michael Merritt, Alan Fekete (1993), William Weihl: Atomtransaktionen in gleichzeitigen und verteilten Systemen Morgan Kaufmann (Elsevier), August 1993, ISBN 978-1-55860-104-8, ISBN 1-55860-104-X Yoav Raz (1992): “Das Prinzip der Auftragsbestellung oder Gew\u00e4hrleistung der Serialisierbarkeit in einer heterogenen Umgebung mehrerer autonomer Ressourcenmanager unter Verwendung von Atomic Commitment.”  ((PDF), Tagungsband der 18. Internationalen Konferenz \u00fcber sehr gro\u00dfe Datenbanken (VLDB), S. 292-312, Vancouver, Kanada, August 1992. (auch DEC-TR 841, Digital Equipment Corporation, November 1990) Zitate[edit]Parallelit\u00e4tskontrolle in Betriebssystemen[edit]Diese Abteilung braucht Erweiterung. Sie k\u00f6nnen helfen, indem Sie es hinzuf\u00fcgen.  ((Dezember 2010)Multitasking-Betriebssysteme, insbesondere Echtzeit-Betriebssysteme, m\u00fcssen die Illusion aufrechterhalten, dass alle darauf ausgef\u00fchrten Aufgaben gleichzeitig ausgef\u00fchrt werden, obwohl aufgrund der. Zu einem bestimmten Zeitpunkt nur eine oder wenige Aufgaben tats\u00e4chlich ausgef\u00fchrt werden Einschr\u00e4nkungen der Hardware, auf der das Betriebssystem ausgef\u00fchrt wird.  Ein solches Multitasking ist ziemlich einfach, wenn alle Aufgaben unabh\u00e4ngig voneinander sind.  Wenn jedoch mehrere Aufgaben versuchen, dieselbe Ressource zu verwenden, oder wenn Aufgaben versuchen, Informationen auszutauschen, kann dies zu Verwirrung und Inkonsistenz f\u00fchren.  Die Aufgabe des Concurrent Computing besteht darin, dieses Problem zu l\u00f6sen.  Einige L\u00f6sungen beinhalten “Sperren”, die den in Datenbanken verwendeten Sperren \u00e4hneln, aber sie k\u00f6nnen eigene Probleme wie Deadlocks verursachen.  Andere L\u00f6sungen sind nicht blockierende Algorithmen und Read-Copy-Update.Siehe auch[edit]Verweise[edit]     (adsbygoogle = window.adsbygoogle || []).push({});after-content-x4"},{"@context":"http:\/\/schema.org\/","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki17\/#breadcrumbitem","name":"Enzyklop\u00e4die"}},{"@type":"ListItem","position":2,"item":{"@id":"https:\/\/wiki.edu.vn\/wiki17\/2021\/01\/27\/parallelitatskontrolle-wikipedia\/#breadcrumbitem","name":"Parallelit\u00e4tskontrolle – Wikipedia"}}]}]