26. april 2004 - 01:21Der er
12 kommentarer og 3 løsninger
mysql limits og kan det betale sig
hej
Jeg søger en top vudering af MYSQL serveren.
Høre mange sige MYSQL server er noget lort, men det mener jeg ikke lige selv.
Jeg bruger selv MYSQL meget, men hvornår skal man skifte til en mere avanseret og komplex server ?
Hvad er MYSQL serverens "limits" hvis jeg kan udtrykke det på den måde. ?
Vedhæft kun links til sites hvis der står 100 % forklaring, og man ikke skal bruge 100 timer på at finde det selv. Siger dette fordi der er mange som bare søger på google.dk og smider et svar ind. og mange af gangende er det, det forkerte.
Begrænsningen i MySql hænger sammen med query fortolkeren - den kan p.t. ikke håndtere views, funktioner, procedurer og triggers, kaskaderelationer etc samt sql med subqueries - dvs. standard sql er ikke fuldt understøttet, og de metadata man skal kunne trække jfr standard findes heller ikke (SYSTEM_INFORMATION views).
Det betyder, at blot nogenlunde avancerede databaser og forespørgsler er meget besværlige at opbygge i Mysql - og dermed skal mere arbejde udføres i klientdelen. Det giver dårligere performance.
Der er begrænset understøttelse af transaktioner og mulighed for point-in-time restore er, så vidt jeg ved, ikke-eksisterende. Dermed kan du kun genskabe databasen til sidste backup - ikke til en given transaktion eller tidspunkt.
Så har du data hvoraf din virksomhed afhænger - så smid dem i en Oracle, Sybase eller SQL Server fremfor en MySQL, de har alle ovennævnte funktioner.
Firebird, Interbase og Postgre kender jeg ikke godt nok til at jeg ved om de har alt det ovennævnte - men jeg tror det.
MySQLs eneste fordel er, at den med simple queries leverer data ekstremt hurtigt - og så er den gratis til ikke-kommerciel brug. Som professionel db har den altså seriøse mangler (heck - selv Access har en mere avanceret databasemotor end MySQL når det gælder SQL-fortolkning).
Firebird og Postgre er svjv også gratis til ikke-kommerciel brug - og er væsentlig mere avancerede databaser.
Derudover - hvad der er en god db afhænger ekstremt meget af din brug og dine ønsker.
Jeg kunne så i øvrigt godt finde på at anbefale MySQL til en datamart eller til en lille foreningens medlemsarkiv etc (altså steder med forholdsvis få opdateringer eller hvor hele db'en opbygges udfra en kørsel) og jeg har da også MySQL på mit eget webhotel.
Ret morsomt at læse den. Checker man fx på SQL Server er der flere bare fejl i deres output:
* bl.a. at GROUP BY altid sorteres (nix, den laves via en hash og er derfor ikke garenteret sorteret), * at man ikke kan oprette en tabel via en select (det kan man - syntaks er SELECT x,y,z INTO newtbl FROM oldtbl), * at SOME og ANY (SQL92) ikke er understøttet (de findes i T-SQL, check Books Online), * at man ikke kan ændre en kolonne efter oprettelsen (kan man, syntaks ALTER TABLE ALTER COLUMN), * at der ikke findes midlertidige tabeller (det gør der - man benytter blot ikke temporary keyword men prefixer tabelnavnet med en #), * at triggere ikke er understøttet (det er de, crash-me benytter blot en forkert sql syntaks i oprettelsen), * at ABSOLUTE() ikke findes (den hedder ABS() og findes), * etc etc etc etc etc
Når der er så mange forkerte info på SQL Server vil der sikkert også være mange på andre db platforme - så vær forsigtig med at stole på crash-me's resultater.
MySQL mangler en del i SQL support. UNION kom i 4.0, subqueries kommer i 4.1, views + stored procedures komemer i 5.0.
Hvis man porterer fra en anden database til MySQL kan det være et stort problem.
Hvis man starter på MySQL er det normalt et mindre problem.
Det giver lidt ekstra kode i applikationen at lave workarounds, men normalt vil detgive bedre performance da de manglende SQL features netop er dem som kan give dårlig performance (undtagelsen er stored procedures).
Man kan lave point in time recovery med både MyISAM og InnoDB tabeller (binlog) og begge understøtter også replikering så data sikkerhed er ikke et problem.
MyISAM tabeller understøtter ikke transaktioner. InnoDB tabeller understøtter transaktioner.
MyISAM er hurtigere end alt andet netop fordi de ikke understøtter transaktioner.
Vær opmærksom på at hvis du skifter fra MyISAM til InnoDB for at få transaktioner, så svinder gruppen af folk der kan hjælpe dig ind til 1/100 af hvad den var før, fordi næsten ingen bruger InnoDB.
MySQL har fremragende performance på skrivebords og lowend server maskiner.
Jeg er overbevist om at den ikke kan følge med på midend server (f.eks. 4 CPU Xeon) og highend server (f.eks. 24 CPU SUN).
Restriktioner for databaser og tabeller er i nyere MySQL versioner så store at de ingen praktisk betydning har.
Grundet den måde MySQL er struktureret på, så vil jeg nok fraråde MySQL hvis databasen ikke kan ligge på en enkelt disk (skift så til f.eks. MS SQLServer eller Sybase - og når du ikke længere orker at tælle dine diske så skift til Oracle eller DB2).
arne_v> Godt at blive rettet når man begår fejl. Jeg troede at MySQL ikke havde point-in-time option - det har den altså. Tak for info.
Mht workarounds - generelt tager det længere tid at udføre en operation på klientsiden end det gør når den udføres direkte på serveren. Fx at udføre en kaskade operation via klienten vil kræve ekstra opslag i tabeller, overførsel af data til klienten og nye kommandoer retur til serveren. Tilsvarende ved manglen mht subqueries og views samt triggers.
Mht diske som begræsning; Alle benytter vel som minimum RAID systemer i dag fremfor fysiske diske hvis det er en server de drifter eller har en af de her dejlige storage bokse fra EMC eller Hitachi hvis det er et lidt større sted...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
