horisontell skalbarhet med Sharding i PostgreSQL-där det går Del 1 av 3

jag hade nyligen möjlighet att delta i några intressanta samtal om framtiden för sharding i PostgreSQL. Det första samtalet levererades av Bruce Momjain i PostgreSQL conf Ottawa (maj 2019) där han presenterade framtiden för Sharding i PostgreSQL och pratade om nuvarande tillstånd och framtid för inbyggd sharding i PostgreSQL. Det andra samtalet presenterades av mig själv i PostgreSQL – konferensen i Peking (Kina-juli 2019) där jag också pratade om det nuvarande läget och framtiden för inbyggd sharding i PG. Jag använde i huvudsak bilderna från Bruces presentation (med hans tillstånd av kursen) och lade till några fler bilder som diskuterade kraven som garanterar skalbarhet och pratade också om andra alternativ för global transaction manager.

under PostgreSQL-konferensen i Ottawa fortsatte jag med traditionen att arrangera ett frukostmöte under konferensveckan för att diskutera sharding-ämnet. Vi har gjort detta varje år under de senaste åren när jag arbetade med EnterpriseDB och fortsatte mötet nu när jag arbetar med HighGo Software Inc. Frukostmötet i år deltog av folk från EDB, NTT, HighGO och Pivotal, antalet deltagare i år var mer än vad vi har fått de senaste åren så vi var tvungna att välja ett större frukostbord. Syftet med detta möte för att få folk från företag som arbetar med den här funktionen i samhället och den här gången också folk från företag som har för avsikt att bidra till denna funktion i samhället. Agendan är att diskutera det aktuella läget för inbyggd sharding, pågående arbete, vad som kommer ner i röret. De andra ämnen som diskuteras i detta möte är att diskutera det övergripande målet för sharding-funktionen, vilka användningsfall vi förväntar oss att dra nytta av dessa funktioner, vilka är de grova tidsskalorna för att få något i PG som vi kan kalla sharding.

om den här bloggen

jag hoppades ursprungligen att täcka detta ämne i en blogg men eftersom den här funktionen är så stor visade sig bloggen också vara mycket längre än vad jag ursprungligen förväntade mig att skriva. Jag har täckt detta i 3 bloggar så att folk inte blir trötta och läser det och förlorar intresset. Slutsatsen ges i slutet av 3: e bloggen i denna serie.

den första bloggen i serien kommer att diskutera skalbarhet, vad är olika typer av skalbarhet och vad som för närvarande finns tillgängliga alternativ för skalbarhet i PostgreSQL. Den andra delen av bloggen fokuserar på deklarativt partitionering som läggs till i PG 10 och hur sharding i PostgreSQL fungerar idag. Den tredje delen av den här bloggen fokuserar på inbyggd sharding arkitektur, pushdown kapacitet redan i PG och slutligen de återstående funktionerna och det tillhörande utmaningar.

en sak som jag inte pratade om i den här bloggen är andra lösningar som har försökt ge sharding, det finns postgres-xc,xl och pg_shards av denna värld. Jag tror att några av dessa försök har varit imponerande men alla har det begränsningar som hindrade dem för att nå bästa sändningstid med PG gemenskap.

Vad är skalbarhet och varför vi behöver det

innan vi går in i sharding är det viktigt att förstå ”vad är skalbarhet” och behovet av skalbarhet och vad som är olika sätt att göra din databas skalbar. Databasskalning är i grunden möjligheten att öka databasens genomströmning/prestanda genom att öka resurser som I/O, minne, CPU eller lägga till ytterligare datorer i klustret. Tillägget av fler beräkningar i sin tur innebär också att öka databasens prestanda genom att använda resurser från flera system för att göra jobbet. Din databas behöver bara skalbarhet om du kör din PostgreSQL-databas på en enda standardserver och den inte kan tillgodose behovet av din arbetsbelastning. De symptom som pekar på orsaken till behöver skalbarhet är databasen inte fungerar bra, datastorleken växer mycket stor och det kan inte passa i serverns Lagring, databasen blir för många samtidiga klienter att det inte kan hantera, det finns komplexa analytiska frågor som tar för lång tid att köra eller inte returnera några data alls i vissa fall och slipning systemet till ett stopp.

när användaren börjar se några av de problem som nämns i föregående stycke måste de tänka på olika alternativför att ta itu med denna fråga innan de slutligen börjar tänka på skalbarhet.De olika alternativen som användaren bör överväga innan man tänker på skalbarhetär följande :

1. Schemaoptimering-måste se till att schemat är helt optimerad för att hantera arbetsbördan och vilken typ av frågor som skickas till databasservern. Viktig aspekt är att kontrollera om användartabellerna är tillräckligt stora för att delas upp så att frågorna kan dirigeras till mindre storlekstabeller. Måste också tänka på om tabellerna är korrekt normaliserade.
2. Application logic tweaking-ett annat viktigt område som vi behöver tänka på när vi stöter på problem är application logic tweaking. Användaren kan tänka på om applikationen kan justeras för att få bästa prestanda från databasen. Det kan handla om att skriva om några av databasfrågorna eller i vissa fall göra refactoring på applikationsnivå för att påskynda prestanda.
3. Inställning av Databaskonfigurationsparametrar – detta är förmodligen det viktigaste förslaget från alternativen, databaskonfigurationsparametrarna måste vridas beroende på arbetsbelastningen och typen av trafik som genereras för databasen. Värdena för viktiga parametrar som delat minne, work mem, checkpoint etc måste konfigureras korrekt och enligt worklaod. Det här är en bra källa som diskuterar några av de viktiga konfigurationsparametrarna för PG-databasinställning.

https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server

Skalbarhetsalternativ

efter att ha provat alla ovanstående alternativ eller mer och problemen kvarstår är det bäst att börja tänka på skalbarhetsalternativ. Databasen kan skalas på två sätt :

de två alternativen för skalbarhet är ganska enkla att förstå, vertikal skalbarhet handlar om skalning uppåt och horisontell skalbarhet handlar om skalning av sidor. Vertikal skalbarhet uppnås genom att förbättra den enda servern, lägga till mer resurs till servern för att uppnå skalbarhet. Horisontell skalbarhet handlar om att kasta fler datorer på problemet, lägga till fler noder i klustret för att använda resurser från flera maskiner för att få databas skalbarhet.

vertikal skalbarhet är vägen att gå om den uppfyller användarkraven och det är också kostnadseffektivt för användaren. Anledningen vertikal är det föredragna alternativet beror på enkel konfiguration och minimalt underhåll och chef overhead. Du kan helt enkelt nötkött upp servern med mer snabbare lagring, mer minne och lägga till mer och snabbare CPU för att öka prestandan i din databas. Det finns främst två skäl där vertikal skalbarhet inte längre är alternativet för din arbetsbelastning. Först och främst anledningen är att förbättra servern kan vara mycket kostsamt och någon gång kan det bli kostnads in-effektiv för användaren. Den andra anledningen är att arbetsbelastningskraven, dvs Lagring, antal samtidiga klienter och inkommande trafik blir så mycket att den enskilda servern inte kunde skala för att tillgodose arbetsbelastningen. Det finns diskussioner om att PostgreSQL bara kan skala till 64 kärnor och efter det blir linjen linjär. Men de publiceras benchmark resultat som visar PostgreSQL skalning på mer än 64 kärna, jag tror att kärnan baserad skalning är i förhållande till antalet samtidiga klienter och databas trafik.

horisontell skalbarhet handlar om att lägga till mer än en dator i databasklustret för att använda resurserna för ytterligare datorer för att få horisontell skalbarhet. Horisontell skalbarhet är inte det första valet eftersom det innebär overhead av konfiguration och underhåll av kluster av maskiner så att användaren måste tänka på driftstopp, failover, backup etc av alla maskiner i klustret. Horisontell skalbarhet blir det självklara valet om arbetsbelastningskraven inte kan uppfyllas med en enda server av de skäl som anges i föregående stycke. Det finns sätt att få horisontell skalbarhet även utan sharding, den mest populära lösningen av icke-sharding horisontell skalbarhet är läs skalbarhet med Pgpool II. Pgpool II är middleware produkt som sitter mellan klienten och PostgreSQL kluster och ger funktionalitet som anslutning pooling, lastbalansering, failover etc. Pgpool II ger horisontell skalbarhet genom lastbalansering, skicka skriver till primär nod och lastbalansering läsa uttalanden över stand-by noder. Pgpool II ger anslutningsnivå och uttalande nivå lastbalansering, med anslutningsnivå lastbalansering Pgpool II processen gör en anslutning med en stand-by nod, alla läser för anslutningen skickas till stand-by noden och skriver skickas till den primära noden. Med uttalande nivå anslutning (kommer i Pgpool II 4.1), är varje uttalande lastbalanserad över stand-by noder. Det finns en bra artikel om detta ämne https://highgo.ca/2019/07/19/pgpool-ii-4-1-taking-the-bull-by-its-horn/