Felles database for mange kunder/bedrifter..

[cruzader]

servern trenger ikke nødvendigvis gå ned for at en service skal få et problem eller en error, oracle starter vel på en 150-200$ pr bruker med minimum på 5brukere.

[kaffenils]

om du har forslag til like "universalt støttet" og gratis system så kan du vel opplyse folket om noen evnt leser tråden i ettertid på jakt etter det

At du personlig vil ta denne risikoen for din egen webshop (eller hva det nå måtte være) får være din sak, men skal du levere systemer til eksterne kunder så bør du seriøst vurdere hvilke problemer MySQL kan forårsake. For kunder er heller ikke gratis-lisens noe argument.

 

Hvis dere ikke skjønte det, grunnen til at jeg rakker ned på MySQL er at alt for mange tror at MySQL er et driftssikert system. HAdde kundene visst hvilken "fare" de ble utsatt for så hadde de gladelig betalt for et skikkelig DBMS.

[cruzader]

personlig bruker jeg ikke mysql på noe kritisk data, bare mer eller mindre statiske databaser hvor jeg har backup av alt innholdet.

 

om mysql blir sett på som driftssikkert system av enkelte er nok godt mulig, men jeg lever i troen av at det er heller få i denne gruppen som selger produktene sine eller lager stort mer enn små forums/clansider.

 

men oracle express er gratis for "Independent Software Vendors" vet ikke helt om nilsh kvalifiserer der.

[nilsh]

Det blir i tilfellet Standard Edition One. Er dette enkelt å komme i gang med..?

[kaffenils]

Det blir i tilfellet Standard Edition One. Er dette enkelt å komme i gang med..?

Du vet at det finnes en databasemotor til MySQL som heter MaxDB, utviklet av SAP. Jeg vil tro at denne gir deg den ACID kompabiliteten du trenger. Grunnen til at jeg _tror_ det er at jeg tviler åp at SAP vil sette sine kunder i fare ved å risikere tap av krisitske ERP data.

 

Les mer her:

http://www.sdn.sap.com/irj/sdn/maxdb;jsess...451158491294End

De har også en community edition lisens. Kanskje du kan benytte deg av den. http://maxdb.sap.com/license/

[quantum]

Jo, for Oracle og SQL Server har full ACID støtte by default, ikke "wannabe" ACID støtte slik som InnoDB. Jeg er nemlig agnske overbevist om at veldig mange som bruker MySQL tror at når de har COMMITet så er data trygt skrevet til disk.

Det er nok veldig mange brukere av Oracle og SQL Server som heller ikke veit hva de driver med. Se f.eks. annen tråd om SQL Server og Clarion ... (no offense til deg som postet denne tråden, man må kunne forutsette at ting virker også etter oppgraderinger.)

 

Tap av data er for de aller fleste formål a'la webshop håndterbart med MySQL. Hvis du vil sponse din favorittwebshops Oracle-lisens i form av høyere pris på varene du kjøper så gjerne for meg. Men - vurderingen de fleste webshop-eiere foretar er nok at 99,9% av kundene vil velge annerledes, og da går de for MySQL. Jeg anser det primært som et problem for de som skal utvikle og drifte løsningen, ikke for businessen.

 

Akkurat hvilke andre konkrete problemer med MySQL ser du for deg nå som vi har fastslått at synkronisering av binærloggen til disk konfigureres lett på null komma niks?

Endret 1. desember 2009 av quantum

[quantum]

ser ikke helt sammenhengen mellom miste/ødelegge bestillinger og bruke mysql?

jeg har ihvertfal ikke fått med meg det kravet i mysql at du ikke kan ha noe datasikkerhet for og bruke deres system....

At nesten ingen har fått det med seg betyr ikke at problemet ikke finnes. Det står svart på hvitt i dokumentasjonen:

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost.

La oss se på hva dette betyr i webshop eksempelet ditt:

Jeg lager en bestilling, klikker bekreft bestilling og får en bekreftelse på at bestillingen en godkjent/bekreftet/lagret. Gode greier tenker jeg og lukker siden. Det jeg ikke vet er at 1 sekund etter at jeg ble videresendt til websiden med bekreftelse så krasjet mysql-servicen hos leverandøren og min COMMIT var ikke skrevet til transaksjonsloggen og heller ikke var endringene skrevet til tabellene. Min bestillingsbekreftelse er derfor sporløst forsvunnet. Jeg får ikke vite om det, og sannsynligvis får heller aldri leverandøren vite om det.

Det finnes mange ting som kan gå galt i dette scenarioet. Så lenge MySQL ikke logger hver eneste skriveoperasjon i det de skjer, så står du i fare for å miste data ved eventuell krasj.

Scenariet ditt er ikke realistisk, en webshop vil dersom alt går bra sende en ordrebekreftelse inneholdende ordren slik den er lagret, når ingen slik bekreftelse kommer, vil kunden måtte sjekke ordren sin, og i dette tilfelle plassere den på nytt. Slik gjør man det fordi det fins uendelig mange flere feilkilder enn det lille og uvesentlige faktum at mysql er satt opp med lazy binlogg pr. default.

[quantum]

bra du synest den er morsom da, så slapp du kjede deg i hele dag!

jeg tenkte mer i forhold til jalla butikker som var nevnt over enn hva jeg ville valgt, at det ikke er optimalt skjønner vel alle.

mysql er gratis og ganske universalt støttet av hosts, de scripts jeg har testet av mysql for webbutikker dumper ordrene i 1-2backup databaser i tilfelle problemer med første så kontrolleres det daglig om der er noen ordre ikke i hoveddatabasen så importerer om mangler.

 

om du har forslag til like "universalt støttet" og gratis system så kan du vel opplyse folket om noen evnt leser tråden i ettertid på jakt etter det

I hosting-sammenheng bør man sjekke ut nøye hvordan MySQL er satt opp, backuprutiner osv osv. Det vil jo f.eks. ikke overraske meg om binærloggskrivingen er satt opp asynkront, slik at man faktisk kan få de problemene kaffenils påpeker. Fikk f.eks. selv et lite «granatsjokk» da jeg fant ut at tabellene på mitt webhotell ble myisam, selv om jeg explisitt anga innodb i create-scriptene. MySQL var satt opp uten støtte for innodb siden det var for vanskelig å konfigurere backup, og MySQL syns visst ikke det er noe vits i å advare brukeren i utrengsmål ...

 

Det er i det heletatt mye «rart» med MySQL, bare å lese en annen tråd her i forumet om Wilzenius noe odde policy når det gjelder prioritering av bukfix'er ... så mitt råd er også - styr unna MySQL om mulig, men jeg hevder likevel det er realistisk å få det til å funke brukbart til en god del formål.

 

For ikke å snakke om de sinnsyke konstellasjonene rundt eierskapet til mysql-koden ... Wilzenius har starta sitt eget db-engine-prosjekt, Oracle eier innodb, Sun holder i resten ... men er nå oppkjøpt av Oracle ... altså ... alt dette er etter min mening nok til å ligge unna, og da har vi ikke engang vurdert tekniske egenskaper.

[MikkelRev]

MikkelRev, hvorfor mener du jeg gjør med en bjørnetjeneste ved å klaske alle bedriftene sammen..?

Om millioner av kunder skal aksessere den samme fysiske databasen samtidig, så vil systemet bli tregere og kanskje mer ustabilt også. Og hva om en av bedriftene har spesielle behov som krever at du oppgraderer databasen din med nye felt og tabeller? Og kanskje har flere andre bedrifter også sine spesialbehov så du må kjøre på med enda flere felter og tabeller. For de andre primitive bedriftene uten ekstra behov, så har databasen dems en haug med null-felt og ubrukte tabeller.

 

Jeg har ingen erfaring med det, så kan ikke si med sikkerhet at løsningen er dum.

[nilsh]

Ser for meg at systemet vil ha typisk, kanskje maks, noen få hundre brukere innom hver dag..

 

Hvorfor er InnoDB wannabe?

Leser flere steder om InnoBD og ACID..

 

Leste om synkronisering av binærloggen i manualen til mysql. Ser ut til at det kan "fikses" med "sync_binlog=1"..?

[quantum]

MikkelRev, hvorfor mener du jeg gjør med en bjørnetjeneste ved å klaske alle bedriftene sammen..?

Om millioner av kunder skal aksessere den samme fysiske databasen samtidig, så vil systemet bli tregere og kanskje mer ustabilt også. Og hva om en av bedriftene har spesielle behov som krever at du oppgraderer databasen din med nye felt og tabeller? Og kanskje har flere andre bedrifter også sine spesialbehov så du må kjøre på med enda flere felter og tabeller. For de andre primitive bedriftene uten ekstra behov, så har databasen dems en haug med null-felt og ubrukte tabeller.

 

Jeg har ingen erfaring med det, så kan ikke si med sikkerhet at løsningen er dum.

Hallo, jorden kaller ...

 

Millioner av samtidige brukere? Da vil jeg vel nesten hevde at 2012-problematikken er mer reell ...

 

Og så er det vel snakk om å lage én applikasjon her, skal hver bedrift ha sitt eget skreddersydde databaseskjema og følgelig skreddersydd applikasjon oppå så kan man vel anta man har nok å gjøre till hell freezes over and then some ... mayakalender eller ikke.

[MikkelRev]

MikkelRev, hvorfor mener du jeg gjør med en bjørnetjeneste ved å klaske alle bedriftene sammen..?

Om millioner av kunder skal aksessere den samme fysiske databasen samtidig, så vil systemet bli tregere og kanskje mer ustabilt også. Og hva om en av bedriftene har spesielle behov som krever at du oppgraderer databasen din med nye felt og tabeller? Og kanskje har flere andre bedrifter også sine spesialbehov så du må kjøre på med enda flere felter og tabeller. For de andre primitive bedriftene uten ekstra behov, så har databasen dems en haug med null-felt og ubrukte tabeller.

 

Jeg har ingen erfaring med det, så kan ikke si med sikkerhet at løsningen er dum.

Hallo, jorden kaller ...

 

Millioner av samtidige brukere? Da vil jeg vel nesten hevde at 2012-problematikken er mer reell ...

 

Og så er det vel snakk om å lage én applikasjon her, skal hver bedrift ha sitt eget skreddersydde databaseskjema og følgelig skreddersydd applikasjon oppå så kan man vel anta man har nok å gjøre till hell freezes over and then some ... mayakalender eller ikke.

Ok.

[blackbrrd]

Med servere med 99,95 % oppetid.. er dette i realiten et problem..?

 

Men uansett, Noen som vet hva det vil koste meg å opprette og drifte dette i f.eks. oracle..?

 

Det er 365*24 = 8760 timer i året, 0,05% av dette er 4,38 timer i året. La oss si at nedetiden på den fysiske serveren er fordelt på tre ganger 1,5 timer. En ACID compliant database er oppe så snart den fysiske serveren er oppe. En ikke ACID compliant database vet du ikke tilstanden i, uten å "sjekke den"... Hvor lang tid det tar vil jeg ikke vite.

 

Tre ganger i året risikerer du korrupte data hvis du ikke har en fullt ut ACID compliant database. Det kan være du ikke mister noen viktige data, eller kanskje du får hilse på Hr Murphys lov.

 

Det er kanskje verdt å nevne at PostgreSQL er gratis, ACID compliant og brukes ofte som en Oracle erstatning fordi de ligner såpass mye på hverandre (syntax og ytelse). Har god erfaring med PostgreSQL til og med når vi fikk en "hyggelig opplevelse" med en RAID kontroller som ikke taklet at en disk i et RAID 1 array døde.

 

Har forresten en database som trådstarter snakker om i utgangspunktet her med firmakunder og disse firmaene sine kunder... Tipper vi har ca 1 million kunder i systemet... Ytelsesmessig ikke noe stort problem. Hvis det skulle vise seg å bli et problem kunne vi ha brukt partisjonering* på firmakunde-nivå. Vi bruker Postgres** 8.3

 

* http://www.postgresql.org/docs/8.4/interac...rtitioning.html

** http://www.postgresql.org/

Endret 2. desember 2009 av blackbrrd

[drbuggs]

Når du vurderer hva slags database løsning bør du også vurdere hva det betyr for kunden å miste databasen. Ligger kontrakter/kjøp lagret ? Bestillingsinformasjon ? Var selv borti en database som var havarert ( Greide å redde den heldigvis) som en tannlege hadde. Han hadde all betalingsinformasjon, legejournaler etc liggende der inkludert et kvartal med refusjonsgrunnlag fra trygde-etaten. Hadde databasen gått tapt hadde han gått konkurs og 5 mennesker mistet jobben sin. Da leker vi ikke database lenger.

[quantum]

Tre ganger i året risikerer du korrupte data hvis du ikke har en fullt ut ACID compliant database. Det kan være du ikke mister noen viktige data, eller kanskje du får hilse på Hr Murphys lov.

 

Det er kanskje verdt å nevne at PostgreSQL er gratis, ACID compliant og brukes ofte som en Oracle erstatning fordi de ligner såpass mye på hverandre (syntax og ytelse).

 

MySQL er også en gratis, ACID-compliant database. Desverre ligner den ikke på så mye annet - og har sine quirks - men det er altså ACID-compliance som stadig er din innvending, og da lurer jeg på hva du sikter til? Dokumentasjonen hevder ACID-compliance, og jeg tviler sterkt på at MySQL (også) kunne eksistert som kommersiellt produkt dersom dette ikke stemmer (villedende markedsføring). (Og bare så det er sagt, jeg spør av ren nyskjerrighet og ikke for å «ha rett»)

 

Når det gjelder hva som støttes out-of-the-box, så er det fint om databasen er satt opp mest mulig fornuftig med default-verdier, men jeg hevder likevel det ikke er så relevant, dersom kravene til dataintegritet og tap av data er strenge kan man aldri nøye seg med default-installasjon uansett, og dessuten kommer både postgresql og mysql i ymse forpakninger hvor oppsettet varierer, så out-of-the-box blir veldig avhengig av box'en, for å si det sånn ...

 

Når det gjelder postgresql vs. mysql så er postgresql min preferanse også, men desverre kommer man oftere borti mysql, og da syns jeg det er greit å vite akkurat hvor høla er og hvor store de er.

[blackbrrd]

...

Dokumentasjonen hevder ACID-compliance, og jeg tviler sterkt på at MySQL (også) kunne eksistert som kommersiellt produkt dersom dette ikke stemmer (villedende markedsføring). (Og bare så det er sagt, jeg spør av ren nyskjerrighet og ikke for å «ha rett»)

...

http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

 

By default, the binary log is not synchronized to disk at each write. So if the operating system or machine (not only the MySQL server) crashes, there is a chance that the last statements of the binary log are lost. To prevent this, you can make the binary log be synchronized to disk after every N writes to the binary log, with the sync_binlog system variable. See Section 5.1.3, “Server System Variables”. 1 is the safest value for sync_binlog, but also the slowest.

 

Dette vil si at hvis du har satt sync_binlog til noe annet enn 1 så vil du kunne miste data fra N-1 transaksjoner. F.eks står den til 10 vil du kunne miste data fra de 9 siste transaksjonene dine.

 

Poenget her er altså at i tillegg til å sjekke at OS-et og hardwaren din gjør ting som den skal, så må du med MySQL finne riktig innstilling der også for å få den til å være ACID compliant. Mao, et sted til det kan gå gærnt.

 

Hvis man f.eks bruker hosted MySQL så tviler jeg på at du får lov til å røre på denne verdien og kan tro at du sitter på en ACID compliant database.

Endret 4. desember 2009 av blackbrrd

[quantum]

Dette vil si at hvis du har satt sync_binlog til noe annet enn 1 så vil du kunne miste data fra N-1 transaksjoner. F.eks står den til 10 vil du kunne miste data fra de 9 siste transaksjonene dine.

 

Ja? Det har jo vært pointet ditt hele veien, ingenting forandrer seg om du gjentar det mange ganger.

 

Poenget her er altså at i tillegg til å sjekke at OS-et og hardwaren din gjør ting som den skal, så må du med MySQL finne riktig innstilling der også for å få den til å være ACID compliant. Mao, et sted til det kan gå gærnt.

 

Hvis man f.eks bruker hosted MySQL så tviler jeg på at du får lov til å røre på denne verdien og kan tro at du sitter på en ACID compliant database.

 

Ja, det er ett punkt det er enkelt å ha kontroll på i en veldig lang liste av punkter. Sånn er det med andre databaser også, du må gå gjennom «sjekklista» for å vite hva du driver med.

 

Hvis du bruker en hosted database hvor du ikke har kontroll på konfigurasjonen til å lagre noe viktig, så kan jeg vel egentlig bare ønske deg lykke til videre, selv med postgresql.

 

Innodb kommer med sync-binlog=0, og den kan settes til l for acid-compliance, like it or not. Ser ikke pointet med å svare på ytterligere repetisjoner av dette, så for meg er diskusjonen nå avsluttet.