Gå til innhold

Postgresql 8.4 er ferdig


Anbefalte innlegg

Videoannonse
Annonse
Pressemeldingen lover blant annet forbedret ytelse når det gjelder gjenoppretting av krasjede databaser fra backup,

 

Kor står det at gjenoppretting av databaser som har kræsja har blitt raskare? Så vidt eg veit så kræsjar ikkje skikkelege databaser.....er bare MySQL som kræsjar.

 

Det som er rett er at importering har blitt raskare nå fordi at pg_restore bruker fleire tilkoplingar når den importerer ny databasedump.

Lenke til kommentar
Kor står det at gjenoppretting av databaser som har kræsja har blitt raskare? Så vidt eg veit så kræsjar ikkje skikkelege databaser.....er bare MySQL som kræsjar.

Fanboyholdninger av den typen er en stor grunn til alvorlige systemfeil og lange nedetider.

Lenke til kommentar
Så vidt eg veit så kræsjar ikkje skikkelege databaser.....

Litt naivt å tro det finnes software som overhodet ikke kan krasje...?

For ikke å nevne hardware og administratorer, hvor sistnevnte er de farligste. Er selv en av de som går rundt med licence to delete på daglig basis. Det er mye rart en kan gjøre som kan lede til feil, og ikke alt er like intuitivt. Særlig i aktive utviklingsmiljøer og komplekse cluster konfigurasjoner. Dessuten har vel software som regel en bug per 5000 LOC eller.no og postgresql er nok mange tusen LOC.

Lenke til kommentar
Så vidt eg veit så kræsjar ikkje skikkelege databaser.....

Litt naivt å tro det finnes software som overhodet ikke kan krasje...?

For ikke å nevne hardware og administratorer, hvor sistnevnte er de farligste. Er selv en av de som går rundt med licence to delete på daglig basis. Det er mye rart en kan gjøre som kan lede til feil, og ikke alt er like intuitivt. Særlig i aktive utviklingsmiljøer og komplekse cluster konfigurasjoner. Dessuten har vel software som regel en bug per 5000 LOC eller.no og postgresql er nok mange tusen LOC.

 

At administrator eller anna hardware lager feil er ikkje databasen sin feil. Eg har liten tro på at du greier å "kræsje" ein PostgreSQL database uansett kor hardt du prøver. Det som også er så kult med PostgreSQL er jo at du kan kjøre transaksjonelle statements i hytt og pine inkl. oppretting av tabeller, dropping av tabeller, indekser osv og framleis trykke på rollback om du gjer feil.

PostgreSQL er rimeleg stabil og syretestet. Den kjører milliarder av transaksjoner kvar dag utan å feile eller at data forsvinner. Finner du ein feil og skriver om det på mailinglista til PostgreSQL så vil Tom Lane og gjengen gå ganske bananas med å få dette fiksa "FORT".

Lenke til kommentar
Så vidt eg veit så kræsjar ikkje skikkelege databaser.....

Litt naivt å tro det finnes software som overhodet ikke kan krasje...?

For databaser, så faktisk ikke, det heter å være ACID compliant. De fleste databaser i flerbrukermiljøer støtter det out-of-the-box, med unntak av MySql.

 

Det går ihvertfall ut på at samme hvor i programvaren programmet kræsjer, så kan du starte det på nytt, uten at du får korrupte data. (inkludert strømbrudd, hardware failure, eller software failure)

Lenke til kommentar

Nei det har du ikkje, leser du dokumentasjonen grundigare så vil du finne fleire smutthol der blant anna fleire ting er skrudd av som standard(sikkert for å ivareta ytelsen?) sånn at du ikkje har 100% ACID. Det er mogleg å få MySQL til å bli 100% ACID, men det krevje ein del å setja seg inn i.

Endret av siDDIs
Lenke til kommentar

Litt komisk at de i artikkelen fra hw.no vektlegger gjenoppretting av databasen og kobler den til kræsjer... Har kjørt en PostgreSQL database i 7-8 år nå og har aldri trengt noe crash-recovery. (Databasen har til tider blitt kjørt uten UPS på et strømnett med 6 strømbrudd i året...)

 

Jeg hadde forstått det hvis det var MySQL det var snakk om, forumet hadde en tid ganske mye nedetid pga crash-recovery... :p

 

Det som er veldig bra med 8.4 er:

- Automatisk endring av Free Space Map (en setting mindre å klusse til)

- Optimalisering av EXISTS (Du trenger ikke sjekke om IN går kjappere)

- Optimalisering av komplekse queries (Flere småpunkter)

- Windowing Functions

- Common Table Expressions and Recursive Queries

- De har endret måten DISTINCT blir kjørt på så den er kjappere og bruker vesentlig mindre minne.

Endret av blackbrrd
Lenke til kommentar
  • 4 måneder senere...

PostgreSQL kan absolutt kræsje, og ingen mekanisme, selv ikke ACID, gir deg 100% sikkerhet. Disker, operativsystem, jordskjelv... you name it, ting KAN gå galt.

 

Det sagt, så er postgreSQL blant de gode løsningene på markedet, og den har hittil ikke gitt oss problemer - tvert imot, den er mye mer stabil og pålitelig enn... vel, alternativet ;) Oh, raskere også by the way.

 

Men husk at det er flere faktorer der ute, maskinvare, OS, eller naturfenomen for den saks skyld. Som de andre her sier, sikre dataene dine utover databasen - den ER sårbar, i likhet med maskinvare og plattform.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
×
×
  • Opprett ny...