Sidste uge på CHAR(10) konference havde vi en workshop om "Cloud Databases". For at sige det enkelt:hvad skal man gøre, når use case-kravene overstiger de tilgængelige ressourcer i databaseserveren.
Dette var et hovedemne på hele konferencen, og flere løsninger er blevet illustreret i løbet af dagen. Et fælles tema har været, at ingen løsning passer til alle use cases, og at hver løsning kommer med sine omkostninger; derfor skal du vælge den løsning, som din use case har råd til.
En anden fælles (omend implicit) pointe har været fokus på "højt niveau" løsninger, det vil sige:at forbinde flere databaseservere på et højere niveau for at efterligne en enkelt server med større ressourcer.
En åbenlys fordel. er, at du ikke behøver at ændre den grundigt undersøgte PostgreSQL-kode; en ulempe er, at ved at bruge flere databaseservere med deres uafhængige tidslinjer, mister du nogle nyttige egenskaber. To eksempler:det delvise tab af transaktionel semantik genererer konflikter; Preparsing af hver forespørgsel uden for databasen introducerer begrænsninger for de accepterede forespørgsler.
Diskussionen var ret interessant, og da Dimitri Fontaine nævnte remote tablespaces, begyndte jeg at spekulere på en relateret, men distinkt idé, nemlig:om en tilgang på lavere niveau til problemet med ressourcepulje ville virkelig være upraktisk. Inden jeg kunne uddybe detaljerne, sluttede workshoppen, og jeg kunne kun skitsere ideen til nogle af de mennesker, der var omkring tavlen (herunder Gabriele Bartolini, Nic Ferrier, Marko Kreen, Hannu Krosing, Greg Smith) sammen med det grundlæggende spørgsmål "ser det muligt ud?" og "ligner det noget, du allerede kender?".
En kort skitse:en ansøgningsstabel kan repræsenteres på denne måde
(application) --> (connection) --> (db server) --> (resources)
hvor de ressourcer, der bruges af databasen, omfatter lager, RAM og CPU'er. Formålet er at give applikationen mulighed for at kommandere flere ressourcer for at øge kapaciteten og hastigheden. "Smarte" applikationer, der administrerer flere databaser, kan repræsenteres som
(application) --> (connection) --> (db server) --> (resources) | +---------> (connection) --> (db server) --> (resources)
mens "connection pooling"-løsninger kan repræsenteres som
(application) --> (connection) --> (db server) --> (resources) | +---------> (db server) --> (resources)
med "lavere niveau"-løsninger mener jeg noget som
(application) --> (connection) --> (db server) --> (resources) | +---------> (resources)
som måske ligner noget bekendt, men det er ikke det, jeg foreslår her. For at forklare forskellen kan jeg øge detaljerne og skrive
(resources) = (virtual resources) --> (physical resources)
at repræsentere det faktum, at man på det laveste niveau kan have en ikke-triviel kortlægning mellem fysiske objekter og virtuelle. For eksempel kan SAN-lagring eller RAID-striping give større virtuelle diske ved at forbinde mindre fysiske diske. Sådanne tilfælde kunne afbildes som
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (ph.res.)
Mit forslag er at samle ressourcer på databaseserveren niveau, så vi kan få en mere effektiv "virtualisering" ved at bruge kendskabet til de specifikke use cases for hver ressource (CPU, RAM, disk), og samtidig kan vi undgå måske af vanskelighederne ved det transaktionelle paradigme. Billedet ville være:
(application) --> (connection) --> (db server) --> (virt.res.) --> (ph.res.) | +--------> (virt.res.) --> (ph.res.)
Fordelen er, at vi ikke behøver at administrere alle mulige use cases for hver virtuel ressource; vi skal bare administrere (og optimere til) de use cases, der faktisk er behov for af PostgreSQL. For eksempel:WAL skal stadig skrives i lokalt "uvirtualiseret" lager, bgwriteren vil få adgang til lokale og eksterne ressourcer (RAM og disk) osv.
Nogle sidste ord om pålidelighed. For at fungere korrekt har hele systemet brug for hvert delsystem; delvise fejl håndteres ikke, fordi denne arkitektur ikke er overflødig. Det er et distribueret system, men ikke delt. Hvis denne arkitektur kunne give billig og enkel skalerbarhed via en virtuel databaseserver, som funktionelt svarer til en fysisk server med større ressourcer, så kunne høj tilgængelighed opnås på standardmåden ved at opsætte to identiske virtuelle servere i en Hot Standby-konfiguration.
Netværkskvalitet har stor indflydelse på den samlede ydeevne; dette design kan kun være nyttigt, hvis du har en række maskiner i det samme LAN, ikke kun af hastighedsmæssige årsager, men også fordi en netværksfejl faktisk ville være en systemfejl. Selv med disse begrænsninger er min mening, at det ville være ret nyttigt at have denne mulighed.
Dette er stadig en skitse, der skal bruges som reference til yderligere diskussion. Næste mulige trin:
- for at lave en detaljeret liste over ressourceanvendelsestilfælde
- for at beslutte, hvilke teknologier der kan hjælpe bedst i hver brugssituation
- for at estimere de faktiske ydeevne/udviklingsomkostninger