kilogram Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 Det populære databasesystemet får støtte for rekursive spørringer og forbedret ytelse. Les mer Lenke til kommentar
siDDis Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 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
Dunsay Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 Så vidt eg veit så kræsjar ikkje skikkelege databaser..... Litt naivt å tro det finnes software som overhodet ikke kan krasje...? Lenke til kommentar
TEE Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 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
Anders Jensen Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 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
siDDis Skrevet 2. juli 2009 Del Skrevet 2. juli 2009 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
blackbrrd Skrevet 3. juli 2009 Del Skrevet 3. juli 2009 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
shaker Skrevet 3. juli 2009 Del Skrevet 3. juli 2009 Er vel bare å bruke InnoDB så har man ACID-compliant transaction support i MySQL også. Lenke til kommentar
siDDis Skrevet 3. juli 2009 Del Skrevet 3. juli 2009 (endret) 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 3. juli 2009 av siDDIs Lenke til kommentar
blackbrrd Skrevet 3. juli 2009 Del Skrevet 3. juli 2009 (endret) 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... 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 3. juli 2009 av blackbrrd Lenke til kommentar
argon264 Skrevet 18. november 2009 Del Skrevet 18. november 2009 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå