Sollte die Datenbank Fremdschlüsselbeschränkungen unter hoher Parallelität verwendet werden?

Kompromisse bei Datenbank fremde Schlüsselbeschränkungen in hohen Parallelitätsszenarien

In Projekten, die eine hohe Parallelitätsleistung verfolgen, wird häufig eine kontroverse Frage gestellt: Ist es erforderlich, ausländische Schlüsselbeschränkungen in der Datenbank zu verwenden? Einige Leute sagen, dass ausländische Schlüssel zur Verbesserung der Effizienz verboten werden müssen. Was ist los?

In einigen hohen Parallelitätsszenarien ist es in der Tat notwendig, die von der Datenbank bereitgestellten physischen Fremdschlüsseleinschränkungen nicht zu verwenden. Dies bedeutet nicht, dass das Konzept der Fremdschlüssel vollständig aufgegeben wurde, sondern dass es vermeidet, dass sich die von der Datenbank selbst bereitgestellten ausländischen Schlüsselmerkmale zur Gewährleistung der Datenkonsistenz stützen. Der Grund dafür ist, dass ausländische Schlüsselbeschränkungen auf Datenbankebene die Schreibbetriebsleistung der Datenbank beeinflussen, insbesondere in hohen Parallelitätsumgebungen. Fremdkey -Inspektion wird zu einem Leistungsengpass.

Wie kann die Konsistenz von Daten garantiert werden, wenn physische Fremdschlüssel nicht verwendet werden? Die Antwort lautet: Sie wird über die Geschäftsschicht implementiert. Wenn beispielsweise die primären Tabellendaten gelöscht werden, müssen auch die entsprechenden Datensätze in der Assoziationstabelle gelöscht werden. Die Verwendung physischer Fremdschlüssel kann durch die Kaskadierung von Löschungen einfach implementiert werden. Wenn jedoch physische Fremdschlüssel deaktiviert sind, müssen Sie explizit Code in die Geschäftslogikschicht schreiben, um die Haupttabelle bzw. die zugehörige Tabelle zu löschen. In ähnlicher Weise muss auch der Aktualisierungsbetrieb ausländischer Schlüsselbeschränkungen in der Geschäftsschicht bearbeitet werden.

Auf diese Weise wird die Atomizität von Datenbankoperationen von der Datenbankschicht in die Anwendungsschicht übertragen. Die Anwendungsschicht muss die Atomizität von Operationen sicherstellen und benötigt normalerweise einen Transaktionsmechanismus, um die Integrität von Daten zu gewährleisten.

Es ist erwähnenswert, dass in vielen hohen Parallelitätsszenarien die endgültige Konsistenz ausreicht. Dies bedeutet, dass die Datenkonsistenz nicht gleichzeitig abgeschlossen sein muss, um ein kurzes Zeitfenster zu ermöglichen, und die Daten können möglicherweise in einem inkonsistenten Zustand liegen, aber letztendlich die Konsistenz erreichen. Dies unterscheidet sich von einer starken Konsistenz (Daten müssen jederzeit konsistent sein). Die endgültige Konsistenz kann sich besser an eine hohe Genauigkeitsumgebungen anpassen und den Systemdurchsatz verbessern. Daher ist die Aufgabe der physischen Fremdschlüssel der Datenbank und der Verantwortung für die Datenkonsistenz eine praktikable Lösung in vielen hohen Parallelitätsszenarien.

Das obige ist der detaillierte Inhalt vonSollte die Datenbank Fremdschlüsselbeschränkungen unter hoher Parallelität verwendet werden?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!