Top ti grunde til at migrere fra Oracle til PostgreSQL

Oracle Relational Database Management System (RDBMS) er blevet meget brugt af store organisationer og anses for at være langt den mest avancerede databaseteknologi på markedet. Det er typisk den oftest sammenlignede RDBMS med andre databaseprodukter, der fungerer som standard "de-facto" for, hvad et produkt skal tilbyde. Det er rangeret af db-engines.com som det #1 RDBMS, der er tilgængeligt på markedet i dag.

PostgreSQL er rangeret som #4 RDBMS, men det betyder ikke, at der ikke er nogen fordele ved at migrere til PostgreSQL. PostgreSQL har eksisteret siden 1989, det åbnede i 1996. PostgreSQL vandt årets DBMS to år i træk fra 2017 og 2018. Det indikerer bare, at der ikke er nogen tegn på at stoppe med at tiltrække et stort antal brugere og store organisationer.

En af grundene til, at PostgreSQL har tiltrukket sig en masse opmærksomhed, er, fordi folk leder efter et alternativ til Oracle, så de kan afskære organisationens høje omkostninger og undgå leverandørlåsning.

Det kan være en skræmmende opgave at flytte fra en fungerende og produktiv Oracle-database. Bekymringer som virksomhedens TCO (Total Cost of Ownership) er en af ​​grundene til, at virksomheder trækker deres beslutning om, hvorvidt de vil droppe Oracle eller ej.

I denne blog vil vi tage et kig på nogle af hovedårsagerne til, at virksomheder vælger at forlade Oracle og migrere til PostgreSQL.

Grund 1:Det er et ægte Open Source-projekt

PostgreSQL er open source og udgives under PostgreSQL-licensen, en liberal Open Source-licens, der ligner BSD- eller MIT-licenserne. Anskaffelse af produktet og support kræver intet gebyr.

Hvis du ønsker at udnytte databasesoftwaren, betyder det, at du kan få alle de tilgængelige funktioner i PostgreSQL-databasen gratis. PostgreSQL har været mere end 30 år gammel i databaseverdenen og har været berøringsbaseret som open source siden 1996. Det har nydt årtier af udviklere, der arbejder på at skabe udvidelser. Det får i sig selv udviklere, institutioner og organisationer til at vælge PostgreSQL til virksomhedsapplikationer; driver førende forretnings- og mobilapplikationer.

Igen er organisationer ved at vågne op til erkendelsen af, at open source-databaseløsninger som Postgres tilbyder større kapacitet, fleksibilitet og support, der ikke er helt afhængig af en enkelt virksomhed eller udvikler. Postgres, ligesom Linux før det, er blevet (og bliver ved med at være) udviklet af dedikerede brugere, der løser daglige forretningsproblemer, som vælger at returnere deres løsninger til fællesskabet. I modsætning til en stor udvikler som Oracle, der kan have forskellige motiver til at udvikle produkter, der er rentable eller understøtter et snævert, men lukrativt marked, er Postgres-fællesskabet forpligtet til at udvikle de bedst mulige værktøjer til daglige relationelle databasebrugere.

PostgreSQL udfører ofte disse opgaver uden at tilføje for meget kompleksitet. Dens design er udelukkende fokuseret på at håndtere databasen uden at skulle spilde ressourcer som at administrere yderligere it-miljøer gennem tilføjede funktioner. Det er en af ​​de ting, som forbrugere af denne open source-software kan lide, når de migrerer fra Oracle til PostgreSQL. At bruge timer på at studere kompleks teknologi om, hvordan en Oracle-database fungerer, eller hvordan man optimerer og justerer op, kan muligvis ende med dens dyre support. Dette lokker institutioner eller organisationer til at finde et alternativ, der kan være mindre hovedpine på omkostningerne og bringer overskud og produktivitet. Tjek venligst vores tidligere blog om, hvordan PostgreSQL er i stand til at matche SQL-syntaks tilstedeværelse med Oracles syntaks.

Årsag to:Ingen licens og et stort fællesskab

For brugere af Oracle RDBMS-platformen er det svært at finde nogen form for fællesskabssupport, der er gratis eller uden et stort gebyr. Institutioner, organisationer og udviklere ender ofte med at finde en alternativ information online, der gratis kan tilbyde svar eller løsninger på deres problemer.

Når du bruger Oracle, er det svært at beslutte sig for et specifikt produkt, eller om man skal bruge produktsupport, fordi der (typisk) er mange penge involveret. Du kan prøve et specifikt produkt for at teste det, ende med at købe det, bare for at indse, at det ikke kan hjælpe dig. Med PostgreSQL er fællesskabet gratis og fyldt med eksperter, der har stor erfaring, der gerne hjælper dig med dine nuværende problemer.

Du kan abonnere på mailinglisten lige her på https://lists.postgresql.org/ for at begynde at nå ud med fællesskabet. Nybegyndere eller vidunderbørn af PostgreSQL er baseret her for at kommunikere, fremvise og dele deres løsninger, teknologi, fejl, nye resultater eller endda dele deres nye software. Du kan endda bede om hjælp fra IRC-chat ved at bruge irc.freenode.net og deltage i #postgresql-kanalen. Du kan også nå ud til fællesskabet gennem Slack ved at deltage med https://postgres-slack.herokuapp.com/ eller https://postgresteam.slack.com/. Der er mange muligheder at tage og masser af Open Source-organisationer, der kan stille dig spørgsmål

For flere detaljer og information om, hvor du skal starte, tjek her https://www.postgresql.org/community/.

Hvis du vil gå og betale for professionelle tjenester i PostgreSQL, er der masser af muligheder at vælge imellem. Selv ved at tjekke deres hjemmeside på https://www.postgresql.org/support/professional_support/northamerica/, kan du finde en stor liste over virksomheder der, og nogle af disse er til en billig pris. Selv her hos Severalnines tilbyder vi også Support til Postgres, som er en del af ClusterControl-licensen eller en DBA-konsulentvirksomhed.

Årsag tre:  Bred understøttelse af SQL-overensstemmelse

PostgreSQL har altid været ivrig efter at tilpasse og tilpasse sig SQL som en de facto-standard for sit sprog. Det formelle navn på SQL-standarden er ISO/IEC 9075 "Database Language SQL". Eventuelle successive reviderede versioner af standardudgivelserne erstatter den tidligere, så påstande om overensstemmelse med tidligere versioner har ingen officiel værdi.

I modsætning til Oracle er nogle nøgleord eller operatorer stadig til stede, som ikke er i overensstemmelse med ANSI-standarden SQL (Structured Query Language). Eksempelvis kan operatøren OUTER JOIN (+) tilskrive forvekslinger med andre DBA'er, som ikke har rørt ved eller med den mindste kendskab til Oracle. PostgreSQL følger ANSI-SQL-standarden for JOIN-syntaks, og det giver en fordel at hoppe let og enkelt med andre open source RDBMS-databaser såsom MySQL/Percona/MariaDB-databaser.

En anden syntaks, der er meget almindelig med Oracle, er at bruge hierarkiske forespørgsler. Oracle bruger den ikke-standardiserede START WITH..CONNECT BY-syntaks, mens i SQL:1999 implementeres hierarkiske forespørgsler ved hjælp af rekursive fælles tabeludtryk. For eksempel adskiller forespørgslerne nedenfor sin syntaks i overensstemmelse med hierarkiske forespørgsler:

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 har en meget lignende tilgang som de andre top open source RDBMS som MySQL/MariaDB.

Ifølge PostgreSQL-manualen sigter PostgreSQL-udviklingen mod overensstemmelse med den seneste officielle version af standarden, hvor en sådan overensstemmelse ikke er i modstrid med traditionelle funktioner eller sund fornuft. Mange af de funktioner, der kræves af SQL-standarden, understøttes, dog nogle gange med lidt forskellig syntaks eller funktion. Det er faktisk det, der er fantastisk med PostgreSQL, da det også understøttes og samarbejdes af de forskellige organisationer, uanset om det er lille eller stor. Skønheden forbliver på dets SQL-sprog i overensstemmelse med det, der har standarden presset igennem.

PostgreSQL-udvikling sigter mod overensstemmelse med den seneste officielle version af standarden, hvor en sådan overensstemmelse ikke er i modstrid med traditionelle funktioner eller sund fornuft. Mange af de funktioner, der kræves af SQL-standarden, understøttes, dog nogle gange med lidt forskellig syntaks eller funktion. Yderligere bevægelser i retning af overensstemmelse kan forventes over tid.

Årsag fire:Forespørgselsparallelisme

For at være retfærdig er PostgreSQL's Query Parallelism ikke så rig sammenlignet med Oracles parallelle udførelse af SQL-sætninger. Blandt de funktioner, som Oracles parallelisme er, er udsagn i kø med hints, evnen til at indstille graden af ​​parallelisme (DOP), sætte en parallel gradspolitik eller adaptiv parallelisme.

PostgreSQL har en simpel grad af parallelitet baseret på de understøttede planer, men det definerer ikke, at Oracle kanter over open source PostgreSQL.

PostgreSQL's parallelitet er konstant blevet forbedret og løbende forbedret af fællesskabet. Da PostgreSQL 10 blev frigivet, tilføjede det mere appel til offentligheden, især forbedringerne af parallelitetsunderstøttelse for flettesammenføjning, bitmap-heap-scanning, indeksscanning og kun indeksscanning, indsamle fletning osv. Forbedringer tilføjer også statistik til pg_stat_activity.

I PostgreSQL-versioner <10 er parallelisme deaktiveret som standard, hvilket du skal bruge for at indstille variablen max_parallel_workers_per_gather.

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

Forespørgselsplanen afslører, at det er den faktiske tid kan gå omkring 522,5 ms, så går den rigtige forespørgsels eksekveringstid omkring 596,95 ms. Mens det muliggør parallelisme,

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

Forespørgselsplanen bestemmer, at forespørgslen skal bruge parallelitet, og så bruger den en Gather-node. Det er faktiske tidsestimater til 339 ms med 2 værker og estimater til 264 ms, før det er blevet aggregeret af forespørgselsplanen. Nu tog den reelle udførelsestid af forespørgslen 346 ms, hvilket er meget tæt på den estimerede faktiske tid fra forespørgselsplanen.

Dette illustrerer bare, hvor hurtigt og gavnligt det er med PostgreSQL. Selvom PostgreSQL har sine egne grænser, når parallelisme kan forekomme, eller når forespørgselsplanen bestemmer, at det er hurtigere end at bruge parallelisme, gør det ikke dens funktion til en stor forskel end Oracle. PostgreSQL's parallelitet er fleksibel og kan aktiveres eller bruges korrekt, så længe din forespørgsel matcher den sekvens, der kræves for forespørgselsparallelisme.

Årsag fem:Avanceret JSON-understøttelse og er altid i forbedring

JSON-understøttelse i PostgreSQL er altid på niveau sammenlignet med de andre open source RDBMS. Tag et kig på denne eksterne blog fra LiveJournal, hvor PostgreSQL's JSON-understøttelse viser, at den altid er mere avanceret sammenlignet med de andre RDBMS. PostgreSQL har et stort antal JSON-funktioner og funktioner.

JSON-datatypen blev introduceret i PostgreSQL-9.2. Siden da har det fået en masse væsentlige forbedringer, og blandt de største tilføjelser kom op i PostgreSQL-9.4 med tilføjelsen af ​​JSONB data-type. PostgreSQL tilbyder to datatyper til lagring af JSON-data:json og jsonb. Med jsonb er det en avanceret version af JSON-datatypen, som gemmer JSON-dataene i binært format. Dette er den store forbedring, som gjorde en stor forskel for den måde, JSON-data blev søgt og behandlet på i PostgreSQL.

Oracle har også omfattende understøttelse af JSON. I modsætning hertil har PostgreSQL omfattende support såvel som funktioner, der kan bruges til datahentning, dataformatering eller betingede operationer, der påvirker outputtet af dataene eller endda de data, der er gemt i databasen. Data gemt med jsonb-datatypen har en større fordel med muligheden for at bruge GIN (Generalized Inverted Index), som kan bruges til effektivt at søge efter nøgler eller nøgle/værdi-par, der forekommer i et stort antal jsonb-dokumenter.

PostgreSQL har yderligere udvidelser, der er nyttige til at implementere TRANSFORM FOR TYPE for jsonb-typen til dens understøttede proceduresprog. Disse udvidelser er jsonb_plperl og jsonb_plperlu for PL/Perl. Hvorimod for PL/Python er disse jsonb_plpythonu, jsonb_plpython2u og jsonb_plpython3u. Hvis du f.eks. bruger jsonb-værdier til at kortlægge Perl-arrays, kan du bruge jsonb_plperl- eller jsonb_plperlu-udvidelser.

ArangoDB havde postet et benchmark, der sammenlignede PostgreSQL's JSON-ydeevne sammen med andre JSON-understøttede databaser. Selvom det er en gammel blog, viser den stadig, hvordan PostgreSQL's JSON klarer sig sammenlignet med andre databaser, hvor JSON er dens kernefunktion i deres databasekerne. Dette gør bare, at PostgreSQL har sin egen fordel, selv med dens sidefunktion.

Årsag seks:DBaaS-understøttelse af store cloud-leverandører

PostgreSQL er blevet bredt understøttet som en DBaaS. Disse tjenester kommer fra Amazon, Microsofts med sin Azure Database for PostgreSQL og Googles Cloud SQL for PostgreSQL.

Til sammenligning er Oracle kun tilgængelig på Amazon RDS til Oracle. De tjenester, der tilbydes af de store aktører, starter til en overkommelig pris og er meget fleksible at konfigurere i overensstemmelse med dine behov. Dette hjælper institutioner og organisationer med at opsætte i overensstemmelse hermed og aflaste fra de store omkostninger, der er bundet op på Oracle-platformen.

Årsag syv:  Bedre håndtering af enorme mængder data

PostgreSQL RDBMS er ikke designet til at håndtere analytiske arbejdsbyrder og data warehousing. PostgreSQL er en rækkeorienteret database, men den har evnen til at gemme store mængder data. PostgreSQL har følgende grænser for håndtering af datalager:

Hvis du vil bruge kernefunktionerne i PostgreSQL, kan du gemme store mængder data ved hjælp af jsonb. For eksempel en stor mængde dokumenter (PDF, Word, Regneark) og gem dette ved hjælp af jsonb datatype. Til geolokationsapplikationer og -systemer kan du bruge PostGIS.

Årsag otte:Skalerbarhed, høj tilgængelighed, redundans/geo-redundans og fejltolerante løsninger til billige penge

Oracle tilbyder lignende, men kraftfulde, løsninger såsom Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware og Oracle Data Guard for at nævne nogle få. Disse teknologier kan øge dine stigende omkostninger og er uforudsigeligt dyre at implementere og gøre stabile. Det er svært at droppe disse løsninger. Uddannelse og færdigheder skal forbedres og udvikle de personer, der er involveret i implementerings- og implementeringsprocessen.

PostgreSQL har massiv support, og det har mange muligheder at vælge imellem. PostgreSQL inkluderer streaming og logisk replikering indbygget i softwarens kernepakke. Du er muligvis også i stand til at konfigurere en synkron replikering til PostgreSQL for at have mere høj tilgængelighedsklynge, mens du får en stand by node til at behandle dine læseforespørgsler. For høj tilgængelighed foreslår vi, at du læser vores blog Top PG Clustering High Availability (HA) løsninger til PostgreSQL, og det dækker en masse gode værktøjer og teknologi at vælge imellem.

Der er også virksomhedsfunktioner, der tilbyder løsninger med høj tilgængelighed, overvågning og backup. ClusterControl er en af ​​disse teknologier og tilbyder til en overkommelig pris sammenlignet med Oracle Solutions.

Årsag ni:  Understøttelse af flere proceduresprog:PL/pgSQL, PL/Tcl, PL/Perl og PL/Python.

Siden version 9.4 har PostgreSQL en fantastisk funktion, hvor du kan definere et nyt proceduresprog i overensstemmelse med dit valg. Selvom ikke alle forskellige programmeringssprog understøttes, men det har en række sprog, der understøttes. I øjeblikket inkluderer den med basisdistribution PL/pgSQL, PL/Tcl, PL/Perl og PL/Python. De eksterne sprog er:

Det fantastiske ved dette er, at i modsætning til Oracle, kan udviklere, der for nylig er hoppet af til PostgreSQL, hurtigt levere forretningslogik til deres applikationssystemer uden at bruge længere tid på at lære om PL/SQL. PostgreSQL gør miljøet for udviklere nemmere og effektivt. Denne karakter af PostgreSQL bidrager til grunden til, at udviklere elsker PostgreSQL og begynder at skifte væk på virksomhedsplatformløsninger til open source-miljøet.

Årsag ti:  Fleksible indekser for store data og tekstdata (GIN, GiST, SP-GiST og BRIN)

PostgreSQL har en kæmpe fordel, når det kommer til understøttelse af indekser, som er gavnlige til at håndtere store data. Oracle har en masse indekstyper, der også er gavnlige til håndtering af store datasæt, især til fuldtekstindeksering. Men for PostgreSQL er disse typer indekser lavet til at være fleksible i henhold til dit formål. For eksempel kan disse typer indekser anvendes til store data:

GIN - (Generalized Inverted Indexes) 

Denne type indeks er anvendelig for datatypekolonnerne jsonb, hstore, range og arrays. Det er nyttigt, når du har datatyper, der indeholder flere værdier i en enkelt kolonne. Ifølge PostgreSQL-dokumenterne er "GIN designet til at håndtere tilfælde, hvor de elementer, der skal indekseres, er sammensatte værdier, og de forespørgsler, der skal håndteres af indekset, skal søge efter elementværdier, der vises i de sammensatte elementer. For eksempel kunne emnerne være dokumenter, og forespørgslerne kunne være søgninger efter dokumenter, der indeholder specifikke ord."

GiST - (Generaliseret søgetræ)

Et højdebalanceret søgetræ, der består af nodesider. Noderne består af indeksrækker. Hver række i en bladknude (bladrække) indeholder generelt et prædikat (boolesk udtryk) og en reference til en tabelrække (TID). GiST-indekser er bedst, hvis du bruger dette til geometriske datatyper som, du vil se, om to polygoner indeholdt et punkt. I et tilfælde kan et specifikt punkt være indeholdt i boksen, mens et andet punkt kun findes inden for en polygon. De mest almindelige datatyper, hvor du ønsker at udnytte GiST-indekser, er geometrityper og tekst, når du beskæftiger dig med fuldtekstsøgning

Når du skal vælge, hvilken indekstype du vil bruge, GiST eller GIN, skal du overveje disse præstationsforskelle:

• GIN-indeksopslag er omkring tre gange hurtigere end GiST
• GIN-indekser tager omkring tre gange længere tid at bygge end GiST
• GIN-indekser er moderat langsommere at opdatere end GiST-indekser, men omkring 10 gange langsommere, hvis hurtig opdateringsunderstøttelse var deaktiveret
• GIN-indekser er to til tre gange større end GiST-indekser

Som en tommelfingerregel er GIN-indekser bedst til statiske data, fordi opslag er hurtigere. For dynamiske data er GiST-indekser hurtigere at opdatere.

SP-GiST - (Space Partitioned GiST) 

Til større datasæt med naturlig, men ujævn klyngning. Denne type indeks udnytter pladsopdelingstræer. SP-GiST-indekser er mest nyttige, når dine data har et naturligt klyngeelement i sig og heller ikke er et lige afbalanceret træ. Et godt eksempel på dette er telefonnumre, for eksempel i USA bruger de følgende format:

• 3 cifre for områdenummer
• 3 cifre for præfiks (historisk relateret til en telefonudbyders switch)
• 4 cifre for linjenummer

Dette betyder, at du har en naturlig klyngning omkring det første sæt af 3 cifre, omkring det andet sæt af 3 cifre, så kan tallene vifte ud i en mere jævn fordeling. Men med telefonnumre har nogle områdekoder en meget højere mætning end andre. Resultatet kan være, at træet er meget ubalanceret. På grund af den naturlige klyngedannelse i forvejen og den ulige fordeling af data – kunne data som telefonnumre være en god sag for SP-GiST.

BRIN - (Blokområdeindeks) 

Til virkelig store datasæt, der er på linje sekventielt. Et blokområde er en gruppe sider, der støder op til hinanden, hvor oversigtsoplysninger om alle disse sider er gemt i Index. Blokområdeindekser kan fokusere på nogle lignende anvendelsestilfælde til SP-GiST, idet de er bedst, når der er en naturlig rækkefølge på dataene, og dataene har tendens til at være meget store. Har du en milliard rekordtabel, især hvis det er tidsseriedata? BRIN kan muligvis hjælpe. Hvis du forespørger på et stort sæt data, der naturligt er grupperet sammen, såsom data for flere postnumre (som derefter ruller op til en by), hjælper BRIN med at sikre, at lignende postnumre er placeret i nærheden af ​​hinanden på disken.

Når du har meget store datasæt, der er bestilt, såsom datoer eller postnumre, giver BRIN-indekser dig mulighed for at springe over eller udelukke en masse af de unødvendige data meget hurtigt. BRIN opretholdes desuden som mindre indekser i forhold til den samlede datastørrelse, hvilket gør dem til en stor gevinst, når du har et stort datasæt.

Konklusion

PostgreSQL har nogle store fordele, når de konkurrerer mod Oracles virksomhedsplatform og forretningsløsninger. Det er bestemt nemt at hylde PostgreSQL som dit foretrukne valg af open source RDBMS, da det er næsten kraftfuldt som Oracle.

Oracle er svært at slå (og det er en svær sandhed at acceptere), og det er heller ikke let at droppe teknologigigantens virksomhedsplatform. Når systemer giver dig kraft og produktive resultater, kan det være et dilemma.

Nogle gange er der dog situationer, hvor der skal træffes en beslutning, da fortsat overinvestering i din platform kan opveje omkostningerne ved dine andre forretningslag og prioriteter, hvilket kan påvirke fremskridt.

PostgreSQL og dets underliggende platformløsninger kan være et valg for at hjælpe dig med at skære ned på omkostningerne, afhjælpe dine budgetproblemer; alle med moderate til små ændringer.