Oracle scheint den Ruf zu haben, skalierbarer zu sein als andere RDBMS. Nachdem ich ein wenig damit gearbeitet habe, kann ich sagen, dass es komplexer ist als andere RDBMS, aber ich habe noch nie etwas gesehen, das es mehr als andere RDBMSes skalierbar macht. Aber andererseits habe ich nicht wirklich viel daran gearbeitet.Was macht Oracle skalierbarer?
Welche Funktionen bietet Oracle, die besser skalierbar sind?
Die RAC-Architektur von Oracle macht sie skalierbar, wenn sie Lasten über Knoten verteilen kann, und parallele Abfragen können aufgeteilt und zur Verarbeitung an andere Knoten weitergeleitet werden.
Einige Tricks, wie das Laden von Blöcken aus dem Puffer-Cache eines anderen Knotens, anstatt auf einen Datenträger zu gehen, machen die Leistung viel besser skalierbar.
Auch die Wartbarkeit von RAC mit rollenden Upgrades helfen, den Betrieb eines großen Systems vernünftiger zu machen.
Es gibt auch einen anderen Aspekt der Skalierbarkeit - Storage-Skalierbarkeit. ASM macht die Speicherkapazität sehr einfach. Eine gut konzipierte ASM-basierte Lösung sollte die 100-Terabyte-Größe überschreiten, ohne etwas Besonderes tun zu müssen.
Ob diese Oracle skalierbar als andere RDBMS machen, weiß ich nicht. Aber ich denke, ich wäre weniger glücklich darüber, eine Nicht-Oracle-Datenbank zu erweitern.
Cursor Sharing ist (oder war) ein großer Vorteil gegenüber der Konkurrenz. Im Grunde wird derselbe Abfrageplan für übereinstimmende Abfragen verwendet. Eine Anwendung wird einen Standardsatz von Abfragen haben (z. B. die Bestellungen für diese Kundennummer erhalten). Der einfache Weg besteht darin, jede Abfrage einzeln zu behandeln. Wenn Sie also 'SELECT * FROM ORDERS WHERE KUNDE_ID =: b1' sehen, sehen Sie, ob die Tabelle ORDERS einen Index für KUNDEN_ID usw. hat Meta-Daten, um einen Abfrageplan zu erhalten, da die Daten tatsächlich abgerufen werden. Mit einfachen Schlüsselsuchen ist ein Abfrageplan einfach. Komplexe Abfragen mit mehreren Tabellen, die in schrägen Spalten verknüpft sind, sind schwieriger.
Oracle verfügt über einen Cache mit Abfrageplänen und ältere/weniger verwendete Pläne werden ausgemustert, da neue benötigt werden.
Wenn Sie Abfragepläne nicht zwischenspeichern, gibt es eine Grenze dafür, wie schlau Sie Ihren Optimierer als den intelligenteren Code definieren können, je größer die Auswirkungen auf die einzelnen Abfragen sind. Wenn Sie Caching-Abfragen durchführen, wird der Overhead erst bei der ersten Abfrage angezeigt.
Die "Nachteil" ist, dass für die Cursor-Sharing Sie Bind-Variablen verwenden müssen. Einige Programmierer erkennen das nicht und schreiben Code, der nicht geteilt wird, und beklagen dann, dass Oracle nicht so schnell ist wie mySQL.
Ein weiterer Vorteil von Oracle ist das UNDO-Protokoll. Wenn eine Änderung vorgenommen wird, wird die "alte Version" der Daten in ein Rückgängig-Protokoll geschrieben. Andere Datenbanken behalten alte Versionen des Datensatzes an derselben Stelle wie der Datensatz. Dies erfordert VACUUM-Bereinigungsvorgänge oder Sie stoßen auf Platz- und Organisationsprobleme. Dies ist besonders relevant in Datenbanken mit hoher Aktualisierungs- oder Löschaktivität.
Auch Oracle hat keine zentrale Lock-Registrierung. Ein Sperrbit ist auf jedem einzelnen Datensatz gespeichert. SELECT nimmt keine Sperre vor. In Datenbanken, in denen SELECT-Sperren aktiviert sind, können mehrere Benutzer Daten lesen und sich gegenseitig sperren oder Aktualisierungen verhindern, wodurch Skalierbarkeitsgrenzen eingeführt werden. Andere Datenbanken würden einen Datensatz sperren, wenn ein SELECT ausgeführt wurde, um sicherzustellen, dass niemand anderes dieses Datenelement ändern kann (es wäre also konsistent, wenn dieselbe Abfrage oder Transaktion die Tabelle erneut überprüft).Oracle verwendet UNDO für sein Lesekonsistenzmodell (dh Nachschlagen der Daten zu einem bestimmten Zeitpunkt).
Tom Kytes "Expert Oracle Database Architecture" von Apress beschreibt die Architektur von Oracle mit einigen Vergleichen mit anderen rDBMS sehr gut. Lesenswert.