De tio bästa anledningarna till att migrera från Oracle till PostgreSQL

Oracle Relational Database Management System (RDBMS) har använts flitigt av stora organisationer och anses vara den överlägset mest avancerade databastekniken som finns på marknaden. Det är vanligtvis det vanligaste jämförda RDBMS med andra databasprodukter som fungerar som standard "de-facto" för vad en produkt ska erbjuda. Den rankas av db-engines.com som den #1 RDBMS som finns på marknaden idag.

PostgreSQL rankas som #4 RDBMS, men det betyder inte att det inte finns några fördelar med att migrera till PostgreSQL. PostgreSQL har funnits sedan 1989 och öppnade 1996. PostgreSQL vann årets DBMS två år i rad från 2017 och 2018. Det indikerar bara att det inte finns några tecken på att stoppa från att locka ett stort antal användare och stora organisationer.

En av anledningarna till att PostgreSQL har väckt stor uppmärksamhet är att människor letar efter ett alternativ till Oracle så att de kan skära av organisationens höga kostnader och slippa leverantörslåsning.

Att flytta från en fungerande och produktiv Oracle-databas kan vara en svår uppgift. Bekymmer som företagets TCO (Total Cost of Ownership) är en av anledningarna till att företag drar ut på beslutet om de ska lämna Oracle eller inte.

I den här bloggen kommer vi att ta en titt på några av de främsta anledningarna till att företag väljer att lämna Oracle och migrera till PostgreSQL.

Anledning ett:Det är ett riktigt öppen källkodsprojekt

PostgreSQL är öppen källkod och släpps under PostgreSQL-licensen, en liberal öppen källkodslicens, liknande BSD- eller MIT-licenserna. Att skaffa produkten och supporten kräver ingen avgift.

Om du vill utnyttja databasprogramvaran betyder det att du kan få alla tillgängliga funktioner i PostgreSQL-databasen gratis. PostgreSQL har varit mer än 30 år gammal av mognad i databasvärlden och har varit beröringsbaserad som öppen källkod sedan 1996. Det har njutit av årtionden av utvecklare som arbetar med att skapa tillägg. Det i sig gör att utvecklare, institutioner och organisationer väljer PostgreSQL för företagsapplikationer; driver ledande affärs- och mobilapplikationer.

Återigen vaknar organisationer upp till insikten att databaslösningar med öppen källkod som Postgres erbjuder större kapacitet, flexibilitet och support som inte är helt beroende av något företag eller utvecklare. Postgres, liksom Linux tidigare, har utvecklats (och fortsätter att vara) av engagerade användare som löser dagliga affärsproblem som väljer att lämna tillbaka sina lösningar till samhället. Till skillnad från en stor utvecklare som Oracle, som kan ha olika motiv för att utveckla produkter som är lönsamma eller stöder en smal men lukrativ marknad, är Postgres-communityt engagerat i att utveckla de bästa möjliga verktygen för vardagliga relationsdatabasanvändare.

PostgreSQL utför ofta dessa uppgifter utan att lägga till för mycket komplexitet. Dess design är strikt fokuserad på att hantera databasen utan att behöva slösa resurser som att hantera ytterligare IT-miljöer genom extra funktioner. Det är en av de saker som konsumenter av denna programvara med öppen källkod gillar när de migrerar från Oracle till PostgreSQL. Att spendera timmar på att studera komplex teknik om hur en Oracle-databas fungerar, eller hur man optimerar och finjusterar, kan sluta med dess dyra support. Detta lockar institutioner eller organisationer att hitta ett alternativ som kan ge mindre huvudvärk på kostnaden och ger vinst och produktivitet. Kolla in vår tidigare blogg om hur kapabel PostgreSQL har att matcha SQL-syntaxnärvaro med Oracles syntax.

Orsak två:Ingen licens och en stor grupp

För användare av Oracle RDBMS-plattformen är det svårt att hitta någon typ av communitysupport som är gratis eller utan en rejäl avgift. Institutioner, organisationer och utvecklare hittar ofta en alternativ information online som kan erbjuda svar eller lösningar på deras problem gratis.

När du använder Oracle är det svårt att bestämma sig för en specifik produkt eller om man ska gå med produktsupport eftersom (vanligtvis) mycket pengar är inblandade. Du kan prova en specifik produkt för att testa den, sluta köpa den, bara för att inse att den inte kan hjälpa dig. Med PostgreSQL är gemenskapen gratis och full av experter som har lång erfarenhet som gärna hjälper dig med dina nuvarande problem.

Du kan prenumerera på e-postlistan här på https://lists.postgresql.org/ för att börja nå ut med communityn. Nybörjare eller underbarn av PostgreSQL är baserade här för att kommunicera, visa upp och dela sina lösningar, teknologi, buggar, nya rön eller till och med dela med sig av sin nya mjukvara. Du kan till och med be om hjälp från IRC-chatten genom att använda irc.freenode.net och gå med i #postgresql-kanalen. Du kan också nå ut till communityn genom Slack genom att gå med på https://postgres-slack.herokuapp.com/ eller https://postgresteam.slack.com/. Det finns många alternativ att ta och många organisationer med öppen källkod som kan ställa frågor till dig

För mer information och information om var du ska börja, kolla in här https://www.postgresql.org/community/.

Om du vill gå och kolla in för professionella tjänster i PostgreSQL, finns det massor av alternativ att välja mellan. Även om du kollar deras hemsida på https://www.postgresql.org/support/professional_support/northamerica/ kan du hitta en stor lista över företag där och några av dessa är till ett billigt pris. Även här på Severalnines erbjuder vi även Support för Postgres, som är en del av ClusterControl-licensen eller en DBA-konsultverksamhet.

Orsak tre:  Brett stöd för SQL-överensstämmelse

PostgreSQL har alltid varit mån om att anpassa och överensstämma med SQL som en de facto-standard för sitt språk. Det formella namnet på SQL-standarden är ISO/IEC 9075 "Databasspråk SQL". Eventuella på varandra följande reviderade versioner av standardutgåvorna ersätter den tidigare, så påståenden om överensstämmelse med tidigare versioner har inga officiella meriter.

Till skillnad från Oracle finns fortfarande några nyckelord eller operatorer som inte överensstämmer med ANSI-standarden SQL (Structured Query Language). Exempelvis kan operatorn OUTER JOIN (+) tillskriva förväxlingar med andra DBA:er som inte har berört eller med minsta bekantskap till Oracle. PostgreSQL följer ANSI-SQL-standarden för JOIN-syntax och det ger en fördel att hoppa enkelt och enkelt med andra RDBMS-databaser med öppen källkod som MySQL/Percona/MariaDB-databaser.

En annan syntax som är mycket vanlig med Oracle är att använda hierarkiska frågor. Oracle använder den icke-standardiserade START WITH..CONNECT BY-syntaxen, medan i SQL:1999 implementeras hierarkiska frågor i form av rekursiva vanliga tabelluttryck. Till exempel skiljer frågorna nedan sin syntax i enlighet med hierarkiska frågor:

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 ett mycket liknande tillvägagångssätt som de andra vanliga RDBMS med öppen källkod som MySQL/MariaDB.

I enlighet med PostgreSQL-manualen syftar PostgreSQL-utvecklingen till överensstämmelse med den senaste officiella versionen av standarden där sådan överensstämmelse inte motsäger traditionella funktioner eller sunt förnuft. Många av funktionerna som krävs av SQL-standarden stöds, men ibland med något annorlunda syntax eller funktion. Detta är faktiskt det som är bra med PostgreSQL eftersom det också stöds och samarbetas av de olika organisationerna, oavsett om det är litet eller stort. Skönheten förblir på sin SQL-språköverensstämmelse med vad som har standarden genomdrivit.

PostgreSQL-utveckling syftar till överensstämmelse med den senaste officiella versionen av standarden där sådan överensstämmelse inte strider mot traditionella funktioner eller sunt förnuft. Många av funktionerna som krävs av SQL-standarden stöds, men ibland med något annorlunda syntax eller funktion. Ytterligare steg mot överensstämmelse kan förväntas med tiden.

Orsak fyra:Fråga parallellism

För att vara rättvis är PostgreSQL:s frågeparallellism inte lika rik jämfört med Oracles parallella körning för SQL-satser. Bland funktionerna som Oracles parallellism är statement-kö med tips, förmåga att ställa in graden av parallellism (DOP), sätta en parallell gradspolicy eller adaptiv parallellism.

PostgreSQL har en enkel grad av parallellitet baserat på planerna som stöds, men det definierar inte att Oracle kanter över postgreSQL med öppen källkod.

PostgreSQL:s parallellitet har ständigt förbättrats och kontinuerligt förbättrats av communityn. När PostgreSQL 10 släpptes, lade den till mer tilltalande för allmänheten, särskilt förbättringarna av parallellitetsstöd för sammanfogning, bitmappshögavsökning, indexskanning och endast index-skanning, samla sammanfogning, etc. Förbättringar lägger också till statistik till pg_stat_activity.

I PostgreSQL-versioner <10 är parallellism inaktiverad som standard, vilket du behöver för att ställa in variabeln 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

Frågeplanen avslöjar att det är den faktiska tiden kan gå runt 522,5 ms, sedan går den verkliga exekveringstiden för frågan runt 596,95 ms. Medan det möjliggör parallellism,

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

Frågeplanen bestämmer att frågan måste använda parallellism och sedan använder den en insamlingsnod. Det är faktiska tidsuppskattningar till 339 ms med 2 arbeten och uppskattningar till 264 ms innan det har aggregerats av frågeplanen. Nu tog den verkliga exekveringstiden för frågan 346ms, vilket är mycket nära den beräknade faktiska tiden från frågeplanen.

Detta illustrerar bara hur snabbt och fördelaktigt det är med PostgreSQL. Även om PostgreSQL har sina egna gränser när parallellism kan uppstå eller när frågeplanen avgör att det är snabbare än att använda parallellism, gör det inte dess funktion till en stor skillnad än Oracle. PostgreSQL:s parallellitet är flexibel och kan aktiveras eller användas korrekt så länge som din fråga matchar sekvensen som krävs för frågeparallellism.

Orsak fem:Avancerat JSON-stöd och förbättras alltid

JSON-stöd i PostgreSQL är alltid i nivå med andra RDBMS med öppen källkod. Ta en titt på den här externa bloggen från LiveJournal där PostgreSQL:s JSON-stöd visar sig alltid vara mer avancerat jämfört med andra RDBMS. PostgreSQL har ett stort antal JSON-funktioner och funktioner.

JSON-datatypen introducerades i PostgreSQL-9.2. Sedan dess har den fått en hel del betydande förbättringar och bland de stora tilläggen kom upp i PostgreSQL-9.4 med tillägget av JSONB-datatyp. PostgreSQL erbjuder två datatyper för lagring av JSON-data:json och jsonb. Med jsonb är det en avancerad version av JSON-datatypen som lagrar JSON-data i binärt format. Detta är den stora förbättringen som gjorde stor skillnad för hur JSON-data söktes och bearbetades i PostgreSQL.

Oracle har också omfattande stöd för JSON. Däremot har PostgreSQL omfattande stöd såväl som funktioner som kan användas för datahämtning, dataformatering eller villkorliga operationer som påverkar utmatningen av data eller till och med data som lagras i databasen. Data som lagras med jsonb-datatypen har en större fördel med möjligheten att använda GIN (Generalized Inverted Index) som kan användas för att effektivt söka efter nycklar eller nyckel/värdepar som förekommer inom ett stort antal jsonb-dokument.

PostgreSQL har ytterligare tillägg som är användbara för att implementera TRANSFORM FOR TYPE för jsonb-typen till dess procedurspråk som stöds. Dessa tillägg är jsonb_plperl och jsonb_plperlu för PL/Perl. Medan för PL/Python är dessa jsonb_plpythonu, jsonb_plpython2u och jsonb_plpython3u. Om du till exempel använder jsonb-värden för att mappa Perl-arrayer kan du använda tilläggen jsonb_plperl eller jsonb_plperlu.

ArangoDB hade lagt ut ett riktmärke som jämförde PostgreSQL:s JSON-prestanda tillsammans med andra JSON-stödda databaser. Även om det är en gammal blogg, visar den fortfarande hur PostgreSQL:s JSON presterar jämfört med andra databaser där JSON är dess kärnfunktion i deras databaskärna. Detta gör bara att PostgreSQL har sin egen fördel även med sin sidofunktion.

Orsak sex:DBaaS-stöd av stora molnleverantörer

PostgreSQL har fått brett stöd som DBaaS. Dessa tjänster kommer från Amazon, Microsofts med sin Azure Database for PostgreSQL, och Googles Cloud SQL för PostgreSQL.

I jämförelse är Oracle endast tillgängligt på Amazon RDS för Oracle. Tjänsterna som erbjuds av de stora aktörerna börjar till ett överkomligt pris och är mycket flexibla att ställa in efter dina behov. Detta hjälper institutioner och organisationer att ställa in i enlighet med detta och befrias från de stora kostnaderna för Oracle-plattformen.

Orsak sju:  Bättre hantering av enorma mängder data

PostgreSQL RDBMS är inte utformade för att hantera analytiska arbetsbelastningar och datalager. PostgreSQL är en radorienterad databas, men den har förmågan att lagra stora mängder data. PostgreSQL har följande gränser för att hantera datalagring:

Om du vill använda kärnfunktionerna i PostgreSQL kan du lagra stora mängder data med jsonb. Till exempel, en stor mängd dokument (PDF, Word, kalkylblad) och lagra detta med jsonb datatyp. För geolokaliseringsapplikationer och -system kan du använda PostGIS.

Orsak åttonde:Skalbarhet, hög tillgänglighet, redundans/geo-redundans och feltoleranta lösningar till billigare

Oracle erbjuder liknande, men kraftfulla, lösningar som Oracle Grid, Oracle Real Application Clusters (RAC), Oracle Clusterware och Oracle Data Guard för att nämna några. Dessa tekniker kan öka dina ökade kostnader och är oförutsägbart dyra att implementera och göra stabila. Det är svårt att avstå från dessa lösningar. Utbildning och färdigheter måste förbättras och utveckla de personer som är involverade i implementerings- och implementeringsprocessen.

PostgreSQL har enormt stöd och det har många alternativ att välja mellan. PostgreSQL inkluderar streaming och logisk replikering inbyggd i kärnpaketet för programvaran. Du kanske också kan ställa in en synkron replikering för PostgreSQL för att ha fler högtillgänglighetskluster, samtidigt som en stand-by-nod bearbetar dina läsfrågor. För hög tillgänglighet föreslår vi att du läser vår blogg Top PG Clustering High Availability (HA) Solutions for PostgreSQL och som täcker många fantastiska verktyg och teknik att välja mellan.

Det finns även företagsfunktioner som erbjuder lösningar med hög tillgänglighet, övervakning och säkerhetskopiering. ClusterControl är en av dessa teknologier och erbjuder till ett överkomligt pris jämfört med Oracle Solutions.

Orsak nio:  Stöd för flera procedurspråk:PL/pgSQL, PL/Tcl, PL/Perl och PL/Python.

Sedan version 9.4 har PostgreSQL en fantastisk funktion där du kan definiera ett nytt procedurspråk i enlighet med ditt val. Även om inte alla olika programmeringsspråk stöds, men det har ett antal språk som stöds. För närvarande, med basdistribution, inkluderar den PL/pgSQL, PL/Tcl, PL/Perl och PL/Python. De externa språken är:

Det fantastiska med detta är att, till skillnad från Oracle, kan utvecklare som nyligen hoppat av till PostgreSQL snabbt tillhandahålla affärslogik till sina applikationssystem utan att ta längre tid att lära sig om PL/SQL. PostgreSQL gör miljön för utvecklare enklare och effektiv. Denna karaktär av PostgreSQL bidrar till anledningen till att utvecklare älskar PostgreSQL och börjar gå över till företagsplattformslösningar till öppen källkodsmiljö.

Orsak tio:  Flexibla index för stora data och textdata (GIN, GiST, SP-GiST och BRIN)

PostgreSQL har en enorm fördel när det kommer till stöd för index som är fördelaktiga för att hantera stora data. Oracle har många indextyper som är fördelaktiga för att hantera stora datamängder också, speciellt för fulltextindexering. Men för PostgreSQL är dessa typer av index gjorda för att vara flexibla efter ditt syfte. Till exempel är dessa typer av index tillämpliga för stora data:

GIN - (Generalized Inverted Indexes) 

Denna typ av index är tillämplig för datatypskolumner jsonb, hstore, range och arrays. Det är användbart när du har datatyper som innehåller flera värden i en enda kolumn. Enligt PostgreSQL-dokumenten är GIN designat för att hantera fall där objekten som ska indexeras är sammansatta värden, och frågorna som ska hanteras av indexet måste söka efter elementvärden som visas i de sammansatta objekten. Till exempel kan objekten vara dokument, och frågorna kan vara sökningar efter dokument som innehåller specifika ord.”

GiST - (Generaliserat sökträd)

Ett höjdbalanserat sökträd som består av nodsidor. Noderna består av indexrader. Varje rad i en lövnod (lövrad) innehåller i allmänhet något predikat (booleskt uttryck) och en referens till en tabellrad (TID). GiST-index är bäst om du använder detta för geometriska datatyper som, du vill se om två polygoner innehöll någon punkt. I ett fall kan en specifik punkt finnas i rutan, medan en annan punkt bara finns inom en polygon. De vanligaste datatyperna där du vill utnyttja GiST-index är geometrityper och text när du hanterar fulltextsökning

När du väljer vilken indextyp du ska använda, GiST eller GIN, överväg dessa prestandaskillnader:

• GIN-indexsökningar är ungefär tre gånger snabbare än GiST
• GIN-index tar ungefär tre gånger längre tid att bygga än GiST
• GIN-index är måttligt långsammare att uppdatera än GiST-index, men cirka 10 gånger långsammare om stödet för snabb uppdatering var inaktiverat
• GIN-index är två till tre gånger större än GiST-index

Som en tumregel är GIN-index bäst för statisk data eftersom uppslagningar är snabbare. För dynamisk data är GiST-index snabbare att uppdatera.

SP-GiST - (Space Partitioned GiST) 

För större datamängder med naturlig men ojämn klustring. Denna typ av index utnyttjar utrymmespartitioneringsträd. SP-GiST-index är mest användbara när din data har ett naturligt klustringselement och inte heller är ett lika balanserat träd. Ett bra exempel på detta är telefonnummer, till exempel i USA använder de följande format:

• 3 siffror för riktnummer
• 3 siffror för prefix (historiskt relaterat till en telefonoperatörs switch)
• 4 siffror för radnummer

Detta betyder att du har en viss naturlig klustring runt den första uppsättningen av 3 siffror, runt den andra uppsättningen av 3 siffror, sedan kan siffror fläkta ut i en jämnare fördelning. Men med telefonnummer har vissa riktnummer en mycket högre mättnad än andra. Resultatet kan bli att trädet är mycket obalanserat. På grund av den naturliga klustringen i förväg och den ojämna fördelningen av data – kan data som telefonnummer vara ett bra fall för SP-GiST.

BRIN - (Block Range Index) 

För riktigt stora datamängder som radas upp sekventiellt. Ett blockintervall är en grupp av sidor som gränsar till varandra, där sammanfattande information om alla dessa sidor lagras i Index. Blockomfångsindex kan fokusera på några liknande användningsfall som SP-GiST eftersom de är bäst när det finns en naturlig ordning på data och data tenderar att vara mycket stora. Har du en miljard rekordtabell, särskilt om det är tidsseriedata? BRIN kanske kan hjälpa till. Om du frågar efter en stor uppsättning data som naturligt grupperas tillsammans, såsom data för flera postnummer (som sedan rullas upp till någon stad) hjälper BRIN till att säkerställa att liknande postnummer finns nära varandra på disken.

När du har mycket stora datamängder som är beställda, såsom datum eller postnummer, låter BRIN-indexen dig hoppa över eller exkludera mycket av onödiga data mycket snabbt. BRIN bibehålls dessutom som mindre index i förhållande till den totala datastorleken, vilket gör dem till en stor vinst när du har en stor datamängd.

Slutsats

PostgreSQL har några stora fördelar när man konkurrerar mot Oracles företagsplattform och affärslösningar. Det är definitivt lätt att hylla PostgreSQL som ditt bästa val av RDBMS med öppen källkod eftersom det är nästan kraftfullt som Oracle.

Oracle är svårt att slå (och det är en svår sanning att acceptera) och det är inte heller lätt att avstå från teknikjättens företagsplattform. När system ger dig kraft och produktiva resultat kan det vara ett dilemma.

Ibland finns det situationer där ett beslut måste fattas eftersom fortsatta överinvesteringar i din plattform kan uppväga kostnaden för dina andra affärslager och prioriteringar, vilket kan påverka framstegen.

PostgreSQL och dess underliggande plattformslösningar kan vara ett val för att hjälpa dig att minska kostnaderna, lindra dina budgetproblem; alla med måttliga till små förändringar.