Warum ist das Skalieren von Schreibvorgängen in eine relationale Datenbank so gut wie unmöglich?

Die Langsamkeit von physischen Platten-Subsystemen ist normalerweise die größte Herausforderung, die es zu bewältigen gilt, wenn man versucht, eine Datenbank so zu skalieren, dass eine sehr große Anzahl gleichzeitiger Autoren bedient werden kann. Aber es ist nicht "praktisch unmöglich", Schreibvorgänge in einer relationalen Datenbank zu optimieren. Es kann getan werden. Es gibt jedoch einen Kompromiss: Wenn Sie Schreibvorgänge optimieren, sind die Auswahlvorgänge für große Teilmengen logisch zusammenhängender Daten normalerweise langsamer.

Das Schreiben der Primärdaten auf die Festplatte und das Neuausgleichen von Indexbäumen kann sehr aufwendig sein. Die Wartung von Clustered-Indizes, bei denen logisch zusammengehörende Zeilen physisch zusammenhängend auf der Festplatte gespeichert werden, ist ebenfalls diskettenintensiv. Solche Indizes machen selects (reads) schneller, während Schreibvorgänge verlangsamt werden. Eine stark indizierte Tabelle skaliert daher nicht gut und je niedriger die Kardinalität des Index ist, desto weniger skaliert sie.

Eine Optimierung, die darauf abzielt, die Geschwindigkeit konkurrierender Schreiber zu verbessern, besteht darin, Sparse-Tabellen mit Hash-Primärschlüsseln und minimaler Indizierung zu verwenden. Dieser Ansatz beseitigt die Notwendigkeit eines Indexes für den Primärschlüsselwert und ermöglicht eine sofortige Suche nach dem Plattenspeicherort, an dem eine Zeile lebt, 'unmittelbar' in dem Sinne, dass die Vermittlung eines Indexlesens nicht erforderlich ist. Der Hashed-Primärschlüsselalgorithmus gibt die physische Adresse der Zeile unter Verwendung des Primärschlüsselwerts selbst zurück - eine einfache Berechnung, die keinen Festplattenzugriff erfordert.

Die Sparse-Tabelle ist genau das Gegenteil davon, logisch zusammenhängende Daten zu speichern, so dass sie physisch zusammenhängend sind. In einem kargen Tisch treten die Autoren nicht sozusagen auf die Zehenspitzen. Schreiben sind wie Regentropfen, die auf ein großes Feld fallen, nicht wie eine Menschenmenge auf einer U-Bahn-Plattform, die versucht, durch ein paar offene Türen in den Zug zu steigen. Die Sparse-Tabelle hilft Schreibengpässe zu beseitigen.

Da logisch zusammenhängende Daten jedoch nicht zusammenhängend sondern verstreut sind, ist der Vorgang des Sammelns aller Zeilen in einer bestimmten Postleitzahl teuer. Diese Hash-PK-Optimierung mit Sparse-Tabelle ist daher nur dann optimal, wenn die vorherrschende Aktivität das Einfügen von Datensätzen, das Aktualisieren einzelner Datensätze und das Nachschlagen von Daten in Bezug auf eine einzelne Entität zu einer Zeit und nicht auf eine große Menge von Entitäten ist. wie etwa in einem Order-Entry-System. Ein Unternehmen, das Waren im Fernsehen verkaufte und Zehntausende gleichzeitig anrufender Anrufer bedienen musste, würde von einem System gut bedient, das spärliche Tabellen mit Hash-Primärschlüsseln verwendete. Eine nationale Sicherheitsdatenbank, die sich auf verknüpfte Listen stützte, wäre auch mit diesem Ansatz gut bedient. Viele Social-Networking-Anwendungen könnten dies auch nutzen.

Eine sharded-Datenbank unterscheidet sich tatsächlich von einer normalen SQL-Datenbank. In vielerlei Hinsicht ähnelt es eher einem benutzerdefinierten NoSQL-System, das zufällig eine Datenbank für den Speicher verwendet. Wenn Ihr Dataset nicht aus einer Menge vollständig getrennter Teilmengen besteht, funktionieren die meisten Abfragen, die komplexer sind als die Get-by-ID, nicht genauso wie bei einer einzelnen Knotendatenbank.

Der andere Grund ist, dass SQL-Schreibvorgänge aufgrund der Notwendigkeit sofortiger Konsistenz ziemlich teuer sind - die Indizes, die für eine gute Leseleistung in einer großen Datenbank erforderlich sind, werden im Rahmen der Schreiboperation aktualisiert, und verschiedene Einschränkungen werden überprüft . In Systemen, die für horizontale Skalierbarkeit ausgelegt sind, werden diese zusätzlichen Operationen entweder vollständig übersprungen oder getrennt vom Schreiben ausgeführt.

Offensichtlich ist dies ihre Meinung, mit StackOverflow hier als ein einfacher Beweis, dass Sie relationales Schreiben zu beschäftigten Seiten effektiv skalieren können.

NoSQL-Provider wie Cassandra machen es viel einfacher auf mehrere Server zu skalieren, aber dies ist bei herkömmlichen Datenbanken nicht unmöglich, und eine Skalierung auf mehrere db-Server ist selten erforderlich.

Es ist nicht. Die Folie ist falsch (oder zumindest sollte die Aussage sorgfältiger qualifiziert werden, wenn man solch eine offensichtlich kühne Behauptung macht).

Es bedeutet, dass einige SQL-basierte Produkte für einige dieser Szenarien mit hoher Skalierbarkeit nicht geeignet sind. Zu vermuten, dass einige oder alle "relationalen Datenbanken" die gleichen Probleme haben, wäre eine grobe Überallgenerierung. Leider ist es genau die Art von Über-Generalisierung, für die die No-SQL-Marketing-Crowd berüchtigt ist.