Förra veckan på CHAR(10) konferensen hade vi en workshop om "molndatabaser". För att uttrycka det enkelt:vad ska man göra när användningsfallskraven överstiger de resurser som finns tillgängliga i databasservern.
Detta var ett huvudämne på hela konferensen och flera lösningar har illustrerats under dagen. Ett gemensamt tema har varit att ingen lösning passar alla användningsfall, och att varje lösning kommer med sin kostnad; därför måste du välja den lösning som ditt användningsfall har råd med.
En annan vanlig (om än underförstådd) poäng har varit fokus på "högnivålösningar", det vill säga att koppla ihop flera databasservrar på en högre nivå för att emulera en enda server med större resurser.
En uppenbar fördel är att du inte behöver ändra den väl granskade PostgreSQL-koden; en nackdel är att när du använder flera databasservrar med deras oberoende tidslinjer förlorar du några användbara egenskaper. Två exempel:den partiella förlusten av transaktionssemantik genererar konflikter; Att förtolka varje fråga utanför databasen introducerar begränsningar för de accepterade frågorna.
Diskussionen var ganska intressant, och när Dimitri Fontaine nämnde avlägsna tabellutrymmen började jag undra kring en relaterad men distinkt idé, nämligen:om ett tillvägagångssätt på lägre nivå till problemet med resurspoolning vore verkligen opraktiskt. Innan jag kunde utveckla detaljerna avslutades workshopen och jag kunde bara skissa idén till några av människorna som fanns runt tavlan (bland annat Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) tillsammans med de grundläggande frågor "ser det genomförbart ut?" och "liknar det något du redan vet?".
En kort skiss:en applikationsstack kan representeras på detta sätt
(application) --> (connection) --> (db server) --> (resources)
där resurserna som används av databasen inkluderar lagring, RAM och processorer. Syftet är att tillåta applikationen att behärska mer resurser för att öka kapaciteten och hastigheten. "Smarta" applikationer som hanterar flera databaser kan representeras som
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
medan "connection pooling"-lösningar kan representeras som
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
med lösningar på lägre nivå menar jag något liknande
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
som kan likna något bekant, men det är inte vad jag föreslår här. För att förklara skillnaden kan jag öka detaljerna och skriva
(resources) = (virtual resources) --> (physical resources)
att representera det faktum att man på den lägsta nivån kan ha en icke-trivial mappning mellan fysiska objekt och virtuella. Till exempel kan SAN-lagring eller RAID-stripning ge större virtuella diskar genom att sammanfoga mindre fysiska diskar. Sådana fall kan avbildas som
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Mitt förslag är att samla resurser på databasservern nivå, så att vi kan få en mer effektiv "virtualisering" genom att använda kunskapen om de specifika användningsfallen för varje resurs (CPU, RAM, disk), och samtidigt kan vi undvika eventuella svårigheter med transaktionsparadigmet. Bilden skulle vara:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Fördelen är att vi inte behöver hantera alla möjliga användningsfall för varje virtuell resurs; vi måste bara hantera (och optimera för) de användningsfall som faktiskt behövs av PostgreSQL. Till exempel:WAL ska fortfarande skrivas i lokal "ovirtualiserad" lagring, bgwriter kommer åt lokala och fjärrresurser (RAM och disk), etc.
Några sista ord om tillförlitlighet. För att fungera korrekt behöver hela systemet varje delsystem; partiella fel hanteras inte, eftersom den här arkitekturen inte är redundant. Det är ett distribuerat system, men inte delat. Om denna arkitektur kunde ge billig och enkel skalbarhet via en virtuell databasserver som funktionellt motsvarar en fysisk server med större resurser, så skulle hög tillgänglighet kunna erhållas på standard sätt genom att sätta upp två identiska virtuella servrar i en Hot Standby-konfiguration.
Nätverkskvalitet har en stor inverkan på den övergripande prestandan; den här designen kan vara användbar bara om du har en rad maskiner i samma LAN, inte bara av hastighetsskäl utan också för att ett nätverksfel faktiskt skulle vara ett systemfel. Även med dessa begränsningar är min uppfattning att det skulle vara ganska användbart att ha det här alternativet.
Detta är fortfarande en skiss som ska användas som referens för vidare diskussion. Nästa möjliga steg:
- för att göra en detaljerad lista över resursanvändningsfallen
- för att bestämma vilken teknik som kan hjälpa bäst i varje användningsfall
- för att uppskatta de faktiska prestanda-/utvecklingskostnaderna