Die zehn wichtigsten Gründe für die Migration von Oracle zu PostgreSQL

Oracle Relational Database Management System (RDBMS) wird von großen Organisationen weit verbreitet verwendet und gilt bei weitem als die fortschrittlichste Datenbanktechnologie, die auf dem Markt erhältlich ist. Es ist in der Regel das am häufigsten mit anderen Datenbankprodukten verglichene RDBMS, das als „de-facto“-Standard dessen dient, was ein Produkt bieten sollte. Es wird von db-engines.com als das RDBMS Nr. 1 eingestuft, das heute auf dem Markt erhältlich ist.

PostgreSQL wird als RDBMS Nr. 4 eingestuft, aber das bedeutet nicht, dass die Migration zu PostgreSQL keine Vorteile bietet. PostgreSQL gibt es seit 1989 und wurde 1996 als Open Source veröffentlicht. PostgreSQL wurde in zwei aufeinanderfolgenden Jahren, 2017 und 2018, zum DBMS des Jahres gekürt.

Einer der Gründe, warum PostgreSQL viel Aufmerksamkeit auf sich gezogen hat, ist, dass die Leute nach einer Alternative zu Oracle suchen, um die hohen Kosten des Unternehmens zu senken und der Herstellerbindung zu entgehen.

Der Wechsel von einer funktionierenden und produktiven Oracle-Datenbank kann eine entmutigende Aufgabe sein. Bedenken wie die TCO (Total Cost of Ownership) des Unternehmens sind einer der Gründe, warum Unternehmen ihre Entscheidung zögern, ob sie Oracle aufgeben oder nicht.

In diesem Blog werfen wir einen Blick auf einige der Hauptgründe, warum Unternehmen sich dafür entscheiden, Oracle zu verlassen und zu PostgreSQL zu migrieren.

Grund eins:Es ist ein echtes Open-Source-Projekt

PostgreSQL ist Open-Source und wird unter der PostgreSQL-Lizenz veröffentlicht, einer liberalen Open-Source-Lizenz, ähnlich der BSD- oder MIT-Lizenz. Für den Erwerb des Produkts und des Supports fallen keine Gebühren an.

Wenn Sie die Datenbanksoftware nutzen möchten, bedeutet dies, dass Sie alle verfügbaren Funktionen der PostgreSQL-Datenbank kostenlos erhalten. PostgreSQL ist seit mehr als 30 Jahren in der Datenbankwelt ausgereift und seit 1996 berührungsbasiert als Open Source. Entwickler haben jahrzehntelang daran gearbeitet, Erweiterungen zu erstellen. Das allein veranlasst Entwickler, Institutionen und Organisationen, PostgreSQL für Unternehmensanwendungen zu wählen; führende Geschäfts- und Mobilanwendungen vorantreiben.

Erneut erkennen Unternehmen, dass Open-Source-Datenbanklösungen wie Postgres mehr Kapazität, Flexibilität und Support bieten, die nicht vollständig von einem Unternehmen oder Entwickler abhängig sind. Postgres wurde (und wird weiterhin) von engagierten Benutzern entwickelt, die alltägliche Geschäftsprobleme lösen und sich dafür entscheiden, ihre Lösungen an die Community zurückzugeben. Im Gegensatz zu großen Entwicklern wie Oracle, die möglicherweise andere Motive für die Entwicklung von Produkten haben, die profitabel sind oder einen engen, aber lukrativen Markt unterstützen, ist die Postgres-Community bestrebt, die bestmöglichen Tools für alltägliche Benutzer relationaler Datenbanken zu entwickeln.

PostgreSQL führt diese Aufgaben oft aus, ohne zu viel Komplexität hinzuzufügen. Sein Design konzentriert sich ausschließlich auf die Handhabung der Datenbank, ohne Ressourcen wie die Verwaltung zusätzlicher IT-Umgebungen durch zusätzliche Funktionen verschwenden zu müssen. Dies ist eines der Dinge, die Verbraucher dieser Open-Source-Software mögen, wenn sie von Oracle zu PostgreSQL migrieren. Wenn Sie Stunden damit verbringen, sich mit komplexer Technologie darüber zu beschäftigen, wie eine Oracle-Datenbank funktioniert oder wie sie optimiert und optimiert werden kann, kann dies zu einem teuren Support führen. Dies verleitet Institutionen oder Organisationen dazu, eine Alternative zu finden, die weniger Kosten verursacht und Gewinn und Produktivität bringt. Bitte lesen Sie unseren vorherigen Blog darüber, wie PostgreSQL in der Lage ist, das Vorhandensein von SQL-Syntax mit der Syntax von Oracle abzugleichen.

Grund zwei:Keine Lizenz und eine große Community

Für Benutzer der Oracle RDBMS-Plattform ist es schwierig, irgendeine Art von Community-Support zu finden, der kostenlos oder ohne hohe Gebühren ist. Institutionen, Organisationen und Entwickler finden oft online alternative Informationen, die kostenlos Antworten oder Lösungen für ihre Probleme bieten können.

Wenn Sie Oracle verwenden, ist es schwierig, sich für ein bestimmtes Produkt oder den Produktsupport zu entscheiden, da es (normalerweise) um viel Geld geht. Sie könnten ein bestimmtes Produkt ausprobieren, um es zu testen, und es am Ende kaufen, nur um festzustellen, dass es Ihnen nicht helfen kann. Mit PostgreSQL ist die Community kostenlos und voller Experten, die über umfangreiche Erfahrung verfügen und Ihnen gerne bei Ihren aktuellen Problemen helfen.

Sie können die Mailingliste direkt hier unter https://lists.postgresql.org/ abonnieren, um mit der Community in Kontakt zu treten. Neulinge oder Wunderkinder von PostgreSQL kommen hierher, um ihre Lösungen, Technologien, Fehler, neuen Erkenntnisse oder sogar ihre neu entstehende Software zu kommunizieren, zu präsentieren und zu teilen. Sie können sogar im IRC-Chat um Hilfe bitten, indem Sie irc.freenode.net verwenden und dem #postgresql-Kanal beitreten. Sie können die Community auch über Slack erreichen, indem Sie sich über https://postgres-slack.herokuapp.com/ oder https://postgresteam.slack.com/ anmelden. Es gibt viele Optionen und viele Open-Source-Organisationen, die Ihnen Fragen stellen können

Weitere Details und Informationen darüber, wo Sie anfangen können, finden Sie hier https://www.postgresql.org/community/.

Wenn Sie sich für Professional Services in PostgreSQL anmelden möchten, stehen unzählige Optionen zur Auswahl. Selbst wenn Sie ihre Website unter https://www.postgresql.org/support/professional_support/northamerica/ besuchen, finden Sie dort eine große Liste von Unternehmen, von denen einige zu einem günstigen Preis erhältlich sind. Auch hier bei Multiplenines bieten wir auch Support für Postgres an, der Teil der ClusterControl-Lizenz oder einer DBA-Beratung ist.

Grund drei:  Breite Unterstützung für SQL-Konformität

PostgreSQL war schon immer bestrebt, SQL als De-facto-Standard für seine Sprache anzupassen und sich an SQL anzupassen. Der formale Name des SQL-Standards lautet ISO/IEC 9075 „Database Language SQL“. Alle nachfolgenden überarbeiteten Versionen der Standardversionen ersetzen die vorherige, sodass Ansprüche auf Konformität mit früheren Versionen keinen offiziellen Wert haben.

Im Gegensatz zu Oracle sind einige Schlüsselwörter oder Operatoren immer noch vorhanden, die nicht dem ANSI-Standard SQL (Structured Query Language) entsprechen. Beispielsweise kann der OUTER JOIN (+)-Operator Verwechslungen mit anderen DBAs zuschreiben, die Oracle noch nicht berührt haben oder mit Oracle am wenigsten vertraut sind. PostgreSQL folgt dem ANSI-SQL-Standard für die JOIN-Syntax, was den Vorteil bietet, einfach und unkompliziert mit anderen Open-Source-RDBMS-Datenbanken wie MySQL/Percona/MariaDB-Datenbanken zu springen.

Eine weitere Syntax, die bei Oracle sehr verbreitet ist, ist die Verwendung hierarchischer Abfragen. Oracle verwendet die nicht standardmäßige START WITH..CONNECT BY-Syntax, während in SQL:1999 hierarchische Abfragen über rekursive allgemeine Tabellenausdrücke implementiert werden. Beispielsweise unterscheiden sich die folgenden Abfragen in ihrer Syntax in Übereinstimmung mit hierarchischen Abfragen:

Oracle

SELECT

    restaurant_name, 

    city_name 

FROM

    restaurants rs 

START WITH rs.city_name = 'TOKYO'

CONNECT BY PRIOR rs.restaurant_name = rs.city_name;

PostgreSQL

WITH RECURSIVE tmp AS (SELECT restaurant_name, city_name

                                 FROM restaurants

                                WHERE city_name = 'TOKYO'

                                UNION

                               SELECT m.restaurant_name, m.city_name

                                 FROM restaurants m

                                 JOIN tmp ON tmp.restaurant_name = m.city_name)

                  SELECT restaurant_name, city_name FROM tmp;

PostgreSQL hat einen sehr ähnlichen Ansatz wie die anderen Top-Open-Source-RDBMS wie MySQL/MariaDB.

Gemäß dem PostgreSQL-Handbuch zielt die PostgreSQL-Entwicklung auf Konformität mit der neuesten offiziellen Version des Standards ab, sofern eine solche Konformität nicht im Widerspruch zu traditionellen Merkmalen oder gesundem Menschenverstand steht. Viele der vom SQL-Standard geforderten Features werden unterstützt, wenn auch manchmal mit leicht abweichender Syntax oder Funktion. Das ist in der Tat das Tolle an PostgreSQL, da es auch von den verschiedenen Organisationen, ob klein oder groß, unterstützt und mit ihnen zusammengearbeitet wird. Das Schöne bleibt bei seiner SQL-Sprachkonformität, was den Standard durchsetzt.

Die PostgreSQL-Entwicklung zielt auf die Konformität mit der neuesten offiziellen Version des Standards ab, sofern eine solche Konformität nicht im Widerspruch zu traditionellen Merkmalen oder gesundem Menschenverstand steht. Viele der vom SQL-Standard geforderten Features werden unterstützt, wenn auch manchmal mit leicht abweichender Syntax oder Funktion. Weitere Schritte in Richtung Konformität sind im Laufe der Zeit zu erwarten.

Grund vier:Abfrageparallelität

Um fair zu sein, die Abfrageparallelität von PostgreSQL ist nicht so umfangreich wie die parallele Ausführung von Oracle für SQL-Anweisungen. Zu den Merkmalen der Parallelität von Oracle gehören Anweisungswarteschlangen mit Hinweisen, die Möglichkeit, den Grad der Parallelität (DOP) festzulegen, eine Parallelgradrichtlinie festzulegen oder adaptive Parallelität.

PostgreSQL hat ein einfaches Maß an Parallelität, basierend auf den unterstützten Plänen, aber das bedeutet nicht, dass Oracle das Open-Source-PostgreSQL übertrifft.

Die Parallelität von PostgreSQL wurde ständig verbessert und von der Community kontinuierlich erweitert. Als PostgreSQL 10 veröffentlicht wurde, wurde es für die Öffentlichkeit attraktiver, insbesondere die Verbesserungen bei der Parallelitätsunterstützung für Merge Join, Bitmap Heap Scan, Index Scan und Index-Only Scan, Gather Merge usw. Verbesserungen fügen pg_stat_activity auch Statistiken hinzu.

In PostgreSQL-Versionen <10 ist die Parallelität standardmäßig deaktiviert, was Sie tun müssen, um die Variable max_parallel_workers_per_gather zu setzen.

postgres=# \timing

Timing is on.

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                   QUERY PLAN                                                   

----------------------------------------------------------------------------------------------------------------

 Seq Scan on movies  (cost=0.00..215677.28 rows=41630 width=68) (actual time=0.013..522.520 rows=84473 loops=1)

   Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

   Rows Removed by Filter: 8241546

 Planning time: 0.039 ms

 Execution time: 525.195 ms

(5 rows)



Time: 525.582 ms

postgres=# \o /dev/null 

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 596.947 ms

Der Abfrageplan zeigt, dass die tatsächliche Zeit etwa 522,5 ms betragen kann, während die tatsächliche Ausführungszeit der Abfrage etwa 596,95 ms beträgt. Während Parallelität aktiviert wird,

postgres=# set max_parallel_workers_per_gather=2;

Time: 0.247 ms

postgres=# explain analyze select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

                                                          QUERY PLAN                                                           

-------------------------------------------------------------------------------------------------------------------------------

 Gather  (cost=1000.00..147987.62 rows=41630 width=68) (actual time=0.172..339.258 rows=84473 loops=1)

   Workers Planned: 2

   Workers Launched: 2

   ->  Parallel Seq Scan on movies  (cost=0.00..142824.62 rows=17346 width=68) (actual time=0.029..264.980 rows=28158 loops=3)

         Filter: ((birthyear >= 1980) AND (birthyear <= 2005))

         Rows Removed by Filter: 2747182

 Planning time: 0.096 ms

 Execution time: 342.735 ms

(8 rows)



Time: 343.142 ms

postgres=# \o /dev/null

postgres=#  select * from imdb.movies where birthyear >= 1980 and birthyear <=2005;

Time: 346.020 ms

Der Abfrageplan legt fest, dass die Abfrage Parallelität verwenden muss, und verwendet dann einen Gather-Knoten. Die tatsächliche Zeit wird auf 339 ms mit 2 Arbeiten und auf 264 ms geschätzt, bevor sie vom Abfrageplan aggregiert wurde. Jetzt dauerte die tatsächliche Ausführungszeit der Abfrage 346 ms, was sehr nahe an der geschätzten tatsächlichen Zeit aus dem Abfrageplan liegt.

Dies zeigt nur, wie schnell und vorteilhaft es mit PostgreSQL ist. Obwohl PostgreSQL seine eigenen Grenzen hat, wenn Parallelismus auftreten kann oder wenn der Abfrageplan feststellt, dass es schneller ist als die Verwendung von Parallelismus, macht seine Funktion keinen großen Unterschied zu Oracle. Die Parallelität von PostgreSQL ist flexibel und kann korrekt aktiviert oder verwendet werden, solange Ihre Abfrage mit der für die Abfrageparallelität erforderlichen Reihenfolge übereinstimmt.

Grund fünf:Erweiterte JSON-Unterstützung und wird ständig verbessert

JSON-Unterstützung in PostgreSQL ist im Vergleich zu anderen Open-Source-RDBMS immer auf Augenhöhe. Werfen Sie einen Blick auf diesen externen Blog von LiveJournal, in dem die JSON-Unterstützung von PostgreSQL im Vergleich zu anderen RDBMS immer fortschrittlicher ist. PostgreSQL verfügt über eine große Anzahl von JSON-Funktionen und -Features.

Der JSON-Datentyp wurde in PostgreSQL-9.2 eingeführt. Seitdem hat es viele bedeutende Verbesserungen erfahren, und unter den wichtigsten Neuerungen kam in PostgreSQL-9.4 die Hinzufügung des JSONB-Datentyps hinzu. PostgreSQL bietet zwei Datentypen zum Speichern von JSON-Daten:json und jsonb. Bei jsonb handelt es sich um eine erweiterte Version des JSON-Datentyps, der die JSON-Daten im Binärformat speichert. Dies ist die wichtigste Verbesserung, die einen großen Unterschied in der Art und Weise gemacht hat, wie JSON-Daten in PostgreSQL gesucht und verarbeitet wurden.

Oracle bietet auch umfangreiche Unterstützung für JSON. Im Gegensatz dazu bietet PostgreSQL umfangreiche Unterstützung sowie Funktionen, die für den Datenabruf, die Datenformatierung oder bedingte Operationen verwendet werden können, die sich auf die Ausgabe der Daten oder sogar der in der Datenbank gespeicherten Daten auswirken. Daten, die mit dem Datentyp jsonb gespeichert sind, haben einen größeren Vorteil durch die Möglichkeit, GIN (Generalized Inverted Index) zu verwenden, der verwendet werden kann, um effizient nach Schlüsseln oder Schlüssel/Wert-Paaren zu suchen, die in einer großen Anzahl von jsonb-Dokumenten vorkommen.

PostgreSQL hat zusätzliche Erweiterungen, die hilfreich sind, um TRANSFORM FOR TYPE für den jsonb-Typ in seine unterstützten Prozedursprachen zu implementieren. Diese Erweiterungen sind jsonb_plperl und jsonb_plperlu für PL/Perl. Während für PL/Python dies jsonb_plpythonu, jsonb_plpython2u und jsonb_plpython3u sind. Wenn Sie beispielsweise jsonb-Werte verwenden, um Perl-Arrays zuzuordnen, können Sie die Erweiterungen jsonb_plperl oder jsonb_plperlu verwenden.

ArangoDB hat einen Benchmark veröffentlicht, der die JSON-Leistung von PostgreSQL mit anderen JSON-unterstützenden Datenbanken vergleicht. Obwohl es sich um einen alten Blog handelt, zeigt er dennoch, wie sich JSON von PostgreSQL im Vergleich zu anderen Datenbanken verhält, in denen JSON die Kernfunktion in ihrem Datenbankkern ist. Dadurch hat PostgreSQL sogar mit seinem Nebenfeature seinen eigenen Vorteil.

Grund sechs:DBaaS-Unterstützung durch große Cloud-Anbieter

PostgreSQL wurde weithin als DBaaS unterstützt. Diese Dienste kommen von Amazon, Microsoft mit seiner Azure-Datenbank für PostgreSQL und Googles Cloud SQL für PostgreSQL.

Im Vergleich dazu ist Oracle nur auf Amazon RDS für Oracle verfügbar. Die von den großen Anbietern angebotenen Dienste beginnen zu einem erschwinglichen Preis und können sehr flexibel gemäß Ihren Anforderungen eingerichtet werden. Dies hilft Institutionen und Organisationen, sich entsprechend einzurichten und sich von den hohen Kosten zu befreien, die an die Oracle-Plattform gebunden sind.

Grund sieben:  Besserer Umgang mit riesigen Datenmengen

PostgreSQL-RDBMS sind nicht darauf ausgelegt, Analyse- und Data-Warehousing-Workloads zu bewältigen. PostgreSQL ist eine zeilenorientierte Datenbank, kann jedoch große Datenmengen speichern. PostgreSQL hat die folgenden Beschränkungen für den Umgang mit Datenspeichern:

Wenn Sie die Kernfunktionen von PostgreSQL verwenden möchten, können Sie große Datenmengen mit jsonb speichern. Zum Beispiel eine große Menge an Dokumenten (PDF, Word, Spreadsheets) und diese mit dem Datentyp jsonb speichern. Für Anwendungen und Systeme zur Geolokalisierung können Sie PostGIS verwenden.

Achter Grund:Skalierbarkeit, Hochverfügbarkeit, Redundanz/Georedundanz und fehlertolerante Lösungen zum günstigen Preis

Oracle bietet ähnliche, aber leistungsstarke Lösungen wie Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware und Oracle Data Guard, um nur einige zu nennen. Diese Technologien können zu Ihren steigenden Kosten beitragen und sind unvorhersehbar teuer in der Bereitstellung und Stabilisierung. Es ist schwer, diese Lösungen aufzugeben. Schulungen und Fähigkeiten müssen verbessert und die am Bereitstellungs- und Implementierungsprozess beteiligten Personen weiterentwickelt werden.

PostgreSQL hat massive Unterstützung und das hat viele Optionen zur Auswahl. PostgreSQL umfasst Streaming und logische Replikation, die in das Kernpaket der Software integriert sind. Sie können möglicherweise auch eine synchrone Replikation für PostgreSQL einrichten, um mehr Cluster mit hoher Verfügbarkeit zu haben, während Sie einen Standby-Knoten dazu bringen, Ihre Leseabfragen zu verarbeiten. Für Hochverfügbarkeit empfehlen wir Ihnen, unseren Blog Top PG Clustering High Availability (HA) Solutions for PostgreSQL zu lesen, der viele großartige Tools und Technologien zur Auswahl enthält.

Es gibt auch Unternehmensfunktionen, die Hochverfügbarkeits-, Überwachungs- und Sicherungslösungen bieten. ClusterControl ist eine dieser Technologien und bietet im Vergleich zu Oracle-Lösungen einen erschwinglichen Preis.

Grund neun:  Unterstützung für mehrere prozedurale Sprachen:PL/pgSQL, PL/Tcl, PL/Perl und PL/Python.

Seit Version 9.4 hat PostgreSQL eine großartige Funktion, mit der Sie eine neue prozedurale Sprache nach Ihrer Wahl definieren können. Obwohl nicht alle Programmiersprachen unterstützt werden, gibt es eine Reihe von Sprachen, die unterstützt werden. Derzeit umfasst die Basisdistribution PL/pgSQL, PL/Tcl, PL/Perl und PL/Python. Die externen Sprachen sind:

Das Tolle daran ist, dass Entwickler, die neu auf PostgreSQL umgestiegen sind, im Gegensatz zu Oracle schnell Geschäftslogik für ihre Anwendungssysteme bereitstellen können, ohne sich weiter mit PL/SQL vertraut machen zu müssen. PostgreSQL macht die Umgebung für Entwickler einfacher und effizienter. Diese Art von PostgreSQL trägt zu dem Grund bei, warum Entwickler PostgreSQL lieben und beginnen, von Unternehmensplattformlösungen auf die Open-Source-Umgebung umzusteigen.

Grund zehn:  Flexible Indizes für große und Textdaten (GIN, GiST, SP-GiST und BRIN)

PostgreSQL hat einen großen Vorteil, wenn es um die Unterstützung von Indizes geht, die für den Umgang mit großen Daten von Vorteil sind. Oracle hat viele Indextypen, die auch für die Handhabung großer Datenmengen von Vorteil sind, insbesondere für die Volltextindizierung. Aber für PostgreSQL sind diese Arten von Indizes so gestaltet, dass sie je nach Zweck flexibel sind. Beispielsweise sind diese Arten von Indizes für große Daten anwendbar:

GIN – (Verallgemeinerte invertierte Indizes) 

Dieser Indextyp gilt für Spalten vom Datentyp jsonb, hstore, range und arrays. Dies ist nützlich, wenn Sie Datentypen haben, die mehrere Werte in einer einzelnen Spalte enthalten. Gemäß den PostgreSQL-Dokumenten „ist GIN für die Behandlung von Fällen konzipiert, in denen die zu indizierenden Elemente zusammengesetzte Werte sind und die vom Index zu verarbeitenden Abfragen nach Elementwerten suchen müssen, die in den zusammengesetzten Elementen erscheinen. Beispielsweise könnten die Elemente Dokumente sein, und die Abfragen könnten Suchen nach Dokumenten sein, die bestimmte Wörter enthalten.“

GiST - (Generalized Search Tree)

Ein höhenausgeglichener Suchbaum, der aus Knotenseiten besteht. Die Knoten bestehen aus Indexzeilen. Jede Zeile eines Blattknotens (Blattzeile) enthält im Allgemeinen ein Prädikat (boolescher Ausdruck) und eine Referenz auf eine Tabellenzeile (TID). GiST-Indizes eignen sich am besten, wenn Sie dies für geometrische Datentypen verwenden, z. B. wenn Sie sehen möchten, ob zwei Polygone einen Punkt enthalten. In einem Fall kann ein bestimmter Punkt in einer Box enthalten sein, während ein anderer Punkt nur innerhalb eines Polygons existiert. Die häufigsten Datentypen, bei denen Sie GiST-Indizes nutzen möchten, sind Geometrietypen und Text bei der Volltextsuche

Berücksichtigen Sie bei der Auswahl des zu verwendenden Indextyps, GiST oder GIN, diese Leistungsunterschiede:

• GIN-Indexsuchen sind etwa dreimal schneller als GiST
• Die Erstellung von GIN-Indizes dauert etwa dreimal länger als die von GiST
• GIN-Indizes werden etwas langsamer aktualisiert als GiST-Indizes, aber etwa zehnmal langsamer, wenn die Unterstützung für schnelle Updates deaktiviert wurde
• GIN-Indizes sind zwei- bis dreimal größer als GiST-Indizes

Als Faustregel gelten GIN-Indizes am besten für statische Daten, da die Suche schneller ist. Bei dynamischen Daten sind GiST-Indizes schneller zu aktualisieren.

SP-GiST – (Space Partitioned GiST) 

Für größere Datensätze mit natürlicher, aber ungleichmäßiger Clusterbildung. Diese Art von Index nutzt Space-Partitioning-Bäume. SP-GiST-Indizes sind am nützlichsten, wenn Ihre Daten ein natürliches Clustering-Element enthalten und auch kein gleichmäßig ausgewogener Baum sind. Ein tolles Beispiel dafür sind Telefonnummern, zum Beispiel in den USA, sie verwenden das folgende Format:

• 3 Ziffern für Vorwahl
• 3 Ziffern für das Präfix (historisch verwandt mit dem Wechsel eines Telefonanbieters)
• 4 Ziffern für Zeilennummer

Das bedeutet, dass Sie eine natürliche Gruppierung um den ersten Satz von 3 Ziffern haben, um den zweiten Satz von 3 Ziffern herum, dann können die Zahlen in einer gleichmäßigeren Verteilung aufgefächert werden. Bei Telefonnummern haben einige Vorwahlen jedoch eine viel höhere Sättigung als andere. Das Ergebnis kann sein, dass der Baum sehr unausgeglichen ist. Aufgrund dieser natürlichen Clusterbildung im Vorfeld und der ungleichen Verteilung von Daten könnten Daten wie Telefonnummern ein gutes Argument für SP-GiST sein.

BRIN – (Blockbereichsindex) 

Für wirklich große Datensätze, die sequentiell aneinandergereiht werden. Ein Blockbereich ist eine Gruppe von Seiten, die nebeneinander liegen, wobei zusammenfassende Informationen über all diese Seiten im Index gespeichert werden. Blockbereichsindizes können sich auf einige ähnliche Anwendungsfälle wie SP-GiST konzentrieren, da sie am besten sind, wenn die Daten eine natürliche Ordnung aufweisen und die Daten tendenziell sehr groß sind. Haben Sie eine Milliarden-Datensatztabelle, insbesondere wenn es sich um Zeitreihendaten handelt? BRIN kann möglicherweise helfen. Wenn Sie eine große Menge von Daten abfragen, die natürlich gruppiert sind, z. B. Daten für mehrere Postleitzahlen (die dann zu einer Stadt zusammengefasst werden), hilft BRIN sicherzustellen, dass sich ähnliche Postleitzahlen auf der Festplatte nahe beieinander befinden.

Wenn Sie sehr große Datensätze haben, die geordnet sind, wie z. B. Daten oder Postleitzahlen, können Sie mit BRIN-Indizes viele unnötige Daten sehr schnell überspringen oder ausschließen. BRIN werden außerdem als kleinere Indizes im Verhältnis zur Gesamtdatengröße verwaltet, was sie zu einem großen Gewinn macht, wenn Sie über einen großen Datensatz verfügen.

Fazit

PostgreSQL hat einige große Vorteile im Wettbewerb mit der Unternehmensplattform und den Geschäftslösungen von Oracle. Es ist definitiv einfach, PostgreSQL als Open-Source-RDBMS Ihrer Wahl zu begrüßen, da es fast so leistungsfähig wie Oracle ist.

Oracle ist schwer zu schlagen (und das ist eine schwer zu akzeptierende Wahrheit) und es ist auch nicht einfach, die Unternehmensplattform des Technologiegiganten aufzugeben. Wenn Systeme Ihnen Leistung und produktive Ergebnisse liefern, könnte das ein Dilemma sein.

Manchmal gibt es jedoch Situationen, in denen eine Entscheidung getroffen werden muss, da die Kosten einer fortgesetzten Überinvestition in Ihre Plattform die Kosten Ihrer anderen Geschäftsebenen und -prioritäten übersteigen können, was den Fortschritt beeinträchtigen kann.

PostgreSQL und die zugrunde liegenden Plattformlösungen können die erste Wahl sein, um Ihnen zu helfen, die Kosten zu senken und Ihre Budgetprobleme zu lindern; alle mit moderaten bis kleinen Änderungen.