[mysql] zeer veel inserts, wat te doen?!

left part of the evil twins

Verwijderd schreef op dinsdag 11 oktober 2005 @ 23:46:
Voor een grote database applicatie binnen ons bedrijf maak ik omzetstaten aan. (details zijn niet interessant). Nu is het zo dat de regels voor een omzetstaat (zon 300-500 stuks) in een loop worden toegevoegd aan de database (per loop worden er wat controles voor de betreffende klant en bijbehorend contract uitgevoerd, dus het moet echt wel in een loop plaatsvinden).
Elke keer als dus de nieuwe regel moet worden toegevoegd, wordt dus een insert-query uitgevoerd.
Nu de database en de applicatie zeer snel groeiende zijn, merk ik dat dus aan de performance.

Sorry, maar bedrijfsvitale gegevens als de omzetstaten en daarmee dus de rest van de administratie moet je niet in MySQL stoppen. MySQL is geschikt voor niet-vitale data die alleen continu geselect wordt in redelijk simpele queries.

Als je veel inserts moet doen en complexe queries moet uitbouwen om analytische data te aggregeren ben je je werkgever moedwillig aan het verneuken als je "a sorry excuse for a flat file system with indexes" aka MySQL gebruikt.

Je hebt nu een probleem dat je vast met noodgrepen als die van MrX op kunt lossen, maar tis uitstel van executie tot je het volgende probleem tegenkomt.... of dataloss, of transactionele problemen of wat dan ook waar MySQL je hoe dan ook mee gaan confronteren. SQL Server is nog niet zo duur als je het vergelijkt met de kosten van een verloren database restoren en een stapel orders kwijtraken.

woensdag 12 oktober 2005 01:27

Acties:

woensdag 12 oktober 2005 01:38

Dus het gebeurt maar 1x per dag??? Dan gewoon van te voren alle indexen eraf gooien, dan zoveel mogelijk gegevens controleren en in 1 array douwen, dan de array met zo min mogelijk checks naar mysql toe sturen, als alles geinsert is de indexen weer toevoegen.

Maar btw. Waar komen de gegevens vandaan??? Want volgens mij voer jij per insert minimaal 90% dezelfde checks uit als de vorige insert, dus 90% van de gegevens is bij de vorige insert al gechecked en zou nu goed moeten zijn ( alleen de check op oude gegevens op een zondag laten plaatsvinden ). Of kijk of je niet een boel checks of op voorhand ( tijdens invoer van stuksgegevens ) of naderhand ( als totaalcheck in mysql ) kan laten doen.

Want het checken kost volgens mij veel tijd ( als je tenminste 500 checks hebt ) niet het inserten zelf vermoed ik.
En over het voorbeeld wat je geeft : alle klanten matchen die een afspraak in een contract hebben staan voor de betreffende krant en de berekening van enkele specificaties (bijv: in week 2,3 en 5 wil de klant wel meedoen en in week 4 niet).

Dit noem ik geen check, dit noem ik gewoon een query op de database, dus laat je database dit ook lekker oplossen

code:

select klantid,klantnaam
from klant ,contract,afspraak
where klantid=contractid and
contractid=afspraakid and
afspraakweek=week(nu())

of zoiets zou je de klanten kunnen opleveren die in een contract zitten waarvan de afspraak is dat er deze week iets gedaan moet worden.

Btw wat gebeurt er trouwens met de records die niet uit je checks komen??? Kloppen je php-loops wel dus als check 1 faalt doet hij dan niet check 2/500.

Ik vermoed dat je met indexen stoppen en na inserten weer aanzetten en goed naar je php-code kijken ( moet alles wel in php, kan de app niet gewoon checken wat er als output gegenereerd wordt , kan je mysql niet de resultaten laten geven, kan je niet met incremental updates werken ) , het meeste resultaat zal boeken.

Acties:

woensdag 12 oktober 2005 01:48

curry684 schreef op woensdag 12 oktober 2005 @ 01:12:
[...]

Sorry, maar bedrijfsvitale gegevens als de omzetstaten en daarmee dus de rest van de administratie moet je niet in MySQL stoppen. MySQL is geschikt voor niet-vitale data die alleen continu geselect wordt in redelijk simpele queries.

Als je veel inserts moet doen en complexe queries moet uitbouwen om analytische data te aggregeren ben je je werkgever moedwillig aan het verneuken als je "a sorry excuse for a flat file system with indexes" aka MySQL gebruikt.

Je hebt nu een probleem dat je vast met noodgrepen als die van MrX op kunt lossen, maar tis uitstel van executie tot je het volgende probleem tegenkomt.... of dataloss, of transactionele problemen of wat dan ook waar MySQL je hoe dan ook mee gaan confronteren. SQL Server is nog niet zo duur als je het vergelijkt met de kosten van een verloren database restoren en een stapel orders kwijtraken.

Valt best mee, hangt er totaal vanaf wat je omzetstaten noemt. Ik heb zelf ook een systeem wat ook allerlei staatjes produceert/in web omgeving op aanvraag toont in php/mysql gebouwd. Alleen de complete mysql gaat wel elke nacht 99% compleet leeg ( behalve rechten en gebruikers tabellen voor dit systeem ) en wordt opnieuw gevuld vanuit erp systeem ( incremental update vanuit erp is langzamer dan totale dump

), bedrijfsvitaal is het wel. Want onze verkoopafdeling maakt hierop de beslissingen voor kortingen / cadeaus etc, onze inkoopafdeling gaat aan de hand hiervan bellen over welke orders nog openstaan etc.
Maar de echte maand/jaarcijfers moeten nog steeds bij onze boekhouder vandaan komen. Plus dat er bij iedereen in de webinterface een stop-knop zit, activeert iemand die ( om wat voor reden dan ook ) dan kan niemand meer in de web-interface totdat hij handmatig gedeactiveerd is ( vals alarm ) of tot de volgende dag ( want dan is of weer nieuwe data uit het erp-systeem gekomen of er is iets grondigs aan de hand en dan kan er niks vanuit het erp-systeem geimporteerd worden ).

Als er echt bedrijfskritisch op ingevoerd moet worden ben ik het volkomen met je eens. Maar voor overzichten / staatjes en weet ik wat niet voldoet mysql perfect zolang je de gegevens maar ergens anders vandaan krijgt en het alleen als rapportage-tool gebruikt.

Acties:

iH8

curry684 schreef op woensdag 12 oktober 2005 @ 01:12:
[...]
MySQL is geschikt voor niet-vitale data die alleen continu geselect wordt in redelijk simpele queries.

niet echt tijd om hier op in te gaan maar ik vind de stelling erg kort door de bocht. het is maar net hoe je met je data omspringt, ook in een MySQL omgeving.

Aunt bunny is coming to get me!

woensdag 12 oktober 2005 01:57

Acties:

NMe

Quia Ego Sic Dico.

iH8 schreef op woensdag 12 oktober 2005 @ 01:48:
niet echt tijd om hier op in te gaan maar ik vind de stelling erg kort door de bocht. het is maar net hoe je met je data omspringt, ook in een MySQL omgeving.

Minder kort door de bocht dan je zou denken hoor.

Curry gaat er hier niet zo heel diep op in, maar MySQL is het gewoon op een aantal punten net niet. Als je weet wat de tekortkomingen zijn, dan kun je eromheen "hacken", maar dat is niet iets wat je wil doen met gegevens die echt belangrijk zijn voor het bedrijf.

'E's fighting in there!' he stuttered, grabbing the captain's arm.
'All by himself?' said the captain.
'No, with everyone!' shouted Nobby, hopping from one foot to the other.

woensdag 12 oktober 2005 07:23

Acties:

woensdag 12 oktober 2005 08:05

Software Architect

Werkt hier

Verwijderd schreef op dinsdag 11 oktober 2005 @ 23:58:
Dit stukje roept redelijk veel vragen op (wat gaat er langzaam, waarom worden er zoveel records ineens ge-insert, etc), maar ik bedacht mij in ieder geval wel 1 ding: na een insert moeten ook de indexen op de tabel opnieuw gemaakt worden. Daarom is het in sommige situaties zinvol om voor batch inserts de indexen weg te gooien en opnieuw op te bouwen na alle inserts.

Deze tip geldt niet op die manier voor MySQL. Die slaat de indexen en tabel in een opslag op, waardoor de hele tabel opnieuw weggeschreven moet worden als je een index wijzigt/verwijdert/aanmaakt.

Wel is er vanaf 4.0.x een disable key's setting om indexen pas achteraf bij te werken (oid).

Andere dingen die ik me afvraag:
Gebruik je innodb? Zoja, heb je alle queries samen in één transactie, of laat je MySQL (via de standaard auto commit) na elke query committen?
Als de gegevens uit de database komen, is het dan niet handiger om het ook binnen de database te verwerken, bijvoorbeeld met insert into tabel ... select ... from een_tabel en/of het gebruik maken van temporary tables.

iH8 schreef op woensdag 12 oktober 2005 @ 01:48:
niet echt tijd om hier op in te gaan maar ik vind de stelling erg kort door de bocht. het is maar net hoe je met je data omspringt, ook in een MySQL omgeving.

Hoe complexer de applicatie/queries, hoe minder goed MySQL mij erbij beviel. Zo erg dat de laatste app die ik ontwikkelde in PostgreSQL heb gezet en daarbij aardige performance winsten haalde (en dat is nog wel insert daily, select a lot).

Acties:

joopst

Je kan insert delayed doen, dan krijg je van de database meteen je cursor terug zodat je niet hoeft te wachten totdat je insert werkelijk is uitevoerd

http://dev.mysql.com/doc/mysql/en/insert-delayed.html

woensdag 12 oktober 2005 08:30

Acties:

P_de_B

Ik vraag me af of MySQL wel de vertragende factor is:

Maar als ik die met php in een for-loop zet, dan kost het wel degelijk aardig wat tijd. Zeker als ook al die controles nog uitgevoerd moeten worden.

Als er in een PHP loopje steeds een INSERT commando wordt gegeven is denk ik niet de insert performance van MySQL de grootste bottleneck. Die moet dat toch makkelijk bij kunnen houden? Het in een loopje inserten van grote hoeveelheden data is natuurlijk sowieso niet echt lekker.

Dan de checks, doe je die ook door in het loopje de gegevens te SELECTen en daar mee te vergelijken? Je zou dan kunnen overwegen alle gegevens in een tijdelijke tabel te gooien en dan in de database de gegevens op basis van de checks (die je dan veel eenvoudiger met bijv. een join kunt doen) s naar de definitieve tabel te gooien.

Laat eens het PHP script zien dat de controles en insert doet.

Oops! Google Chrome could not find www.rijks%20museum.nl

woensdag 12 oktober 2005 09:06

Acties:

Janoz

Moderator Devschuur®

!litemod

Gomez12 schreef op woensdag 12 oktober 2005 @ 01:38:
[...]

Valt best mee, hangt er totaal vanaf wat je omzetstaten noemt. Ik heb zelf ook een systeem wat ook allerlei staatjes produceert/in web omgeving op aanvraag toont in php/mysql gebouwd. Alleen de complete mysql gaat wel elke nacht 99% compleet leeg ( behalve rechten en gebruikers tabellen voor dit systeem ) en wordt opnieuw gevuld vanuit erp systeem ( incremental update vanuit erp is langzamer dan totale dump ), bedrijfsvitaal is het wel. Want onze verkoopafdeling maakt hierop de beslissingen voor kortingen / cadeaus etc, onze inkoopafdeling gaat aan de hand hiervan bellen over welke orders nog openstaan etc.

Mwah, bedrijfs vitaal is dit imho niet. Natuurlijk moet het blijven draaien, maar wanneer het weg is kun je zo een nieuwe dump halen.

Ken Thompson's famous line from V6 UNIX is equaly applicable to this post:
'You are not expected to understand this'

woensdag 12 oktober 2005 12:18

Acties:

Verwijderd

Verwijderd schreef op dinsdag 11 oktober 2005 @ 23:58:
Daarom is het in sommige situaties zinvol om voor batch inserts de indexen weg te gooien en opnieuw op te bouwen na alle inserts.

Getver. Dit kan misschien handig zijn als je een single user systeem hebt of alle andere users uit het systeem kan schoppen (bv 's nachts) maar echt aan te bevelen is dit natuurlijk niet. Terwijl de TS zijn statistieken zit te berekenen kan iemand anders nieuwe orders aan het invoeren zijn. Dan zijn indexen toch wel erg handig.

Daarnaast begrijp ik eigenlijk niet zo goed waarom er bij het opvragen van statistieken honderden nieuwe records gegenereerd moeten worden. Je zou zeggen dat alle relevante informatie al in de database zou moeten staan.

woensdag 12 oktober 2005 13:39

Acties:

Verwijderd

Topicstarter

het zijn geen statistieken / overzichten, maar er worden adhv complexe contracten (veel randvoorwaarden) werkbestanden gegenereerd.

woensdag 12 oktober 2005 14:46

Acties:

jochemd

Ik zou eerst maar eens gedetailleerd gaan benchmarken voordat je op basis van de aanname dat de inserts langzaam zijn gaat micro-optimaliseren.

woensdag 12 oktober 2005 15:13

Acties:

igmar

ISO20022

curry684 schreef op woensdag 12 oktober 2005 @ 01:12:
Sorry, maar bedrijfsvitale gegevens als de omzetstaten en daarmee dus de rest van de administratie moet je niet in MySQL stoppen. MySQL is geschikt voor niet-vitale data die alleen continu geselect wordt in redelijk simpele queries.

Beetje extreem kort door de bocht, maar goed.

Als je veel inserts moet doen en complexe queries moet uitbouwen om analytische data te aggregeren ben je je werkgever moedwillig aan het verneuken als je "a sorry excuse for a flat file system with indexes" aka MySQL gebruikt.

Nog korter door de bocht. MySQL-MaxDB wil ik zo absoluut niet noemen, en 4.1 en 5.x versies ook al niet. MySQL is, mits juist opgezet, snel zat.

SQL Server is nog niet zo duur als je het vergelijkt met de kosten van een verloren database restoren en een stapel orders kwijtraken.

MySQL afzeiken : Prima, maar dan wel onderbouwd. Met alle respect Curry, maar je verkoopt nu gewoonweg crap. Of MySQL de juiste DB is valt inderdaad over te discuseren, maar SQL server is ook op een aantal gebieden niet al te fijntjes. Zoals elke DB zo z'n nadelen heeft.

Maar goed, zonder verder info ed van de TS is het gokwerk, maar ik zou iig aanraden om 500 inserts te doen in 1 transactie, en mocht je nog een 3.x ov 4.0 versie van MySQL draaien : Meteen upgraden naar 4.1 met InnoDB.

En als dat niet hebt een alternatief zoeken, PostgreSQL is wat dat betreft een aanrader.

[ Voor 4% gewijzigd door igmar op 12-10-2005 15:15 ]

woensdag 12 oktober 2005 15:17

Acties:

P_de_B

igmar schreef op woensdag 12 oktober 2005 @ 15:13:

MySQL afzeiken : Prima, maar dan wel onderbouwd. Met alle respect Curry, maar je verkoopt nu gewoonweg crap. Of MySQL de juiste DB is valt inderdaad over te discuseren, maar SQL server is ook op een aantal gebieden niet al te fijntjes. Zoals elke DB zo z'n nadelen heeft.
r.

Maar bijvoorbeeld het ontbreken van referentiele integriteit is wel iets meer dan een nadeel :x, of wat dacht je van maximaal 1 index per tabel gebruiken?

Oops! Google Chrome could not find www.rijks%20museum.nl

woensdag 12 oktober 2005 15:29

Acties:

left part of the evil twins

igmar schreef op woensdag 12 oktober 2005 @ 15:13:
[...]

Beetje extreem kort door de bocht, maar goed.

Kort door de bocht, maar terecht. Zolang MySQL met geen enkele tabletype perfect ACID-compliant is is het niet serieus te nemen voor serieuze data.

Nog korter door de bocht. MySQL-MaxDB wil ik zo absoluut niet noemen, en 4.1 en 5.x versies ook al niet. MySQL is, mits juist opgezet, snel zat.

Waarom haal je een compleet ander produkt erbij

Het gaat hier over MySQL, niet over MaxDB.

En wat MySQL zelf betreft: da's het hele punt ja, tis snel. Omdat het nul data verificatie doet. Omdat het geen enkele integriteitscontrole heeft. Omdat het liever ingevoerde data wegkiepert dan een een fout geven omdat het niet past. Omdat het geen queries kan optimizen zodra ze moeilijker zijn dan een simpele SELECT. En daarom gebruik je MySQL niet voor serieuze systemen.

MySQL afzeiken : Prima, maar dan wel onderbouwd. Met alle respect Curry, maar je verkoopt nu gewoonweg crap.

Ik zal de volgende keer speciaal voor jou 2 kantjes voltypen ipv 1 en deze pagina meelinken

Bij m'n werkgever (AEX-multinational) werd me een paar maanden terug gevraagd waarom ze die dure SQL Server bakken onderhielden voor business critical applicaties terwijl MySQL wat we voor het intranet gebruiken gratis is. Nadat ik in een datetime field de waardes "31-02-2005" en "aap" had opgeslagen en bij een select na de 2e er braafjes "00-00-0000" uit kwam was men er alweer over uit. Ik had nog niet eens toegevoegd dat MySQL voor commercieel gebruik 495 euro per jaar per server kost.

[ Voor 18% gewijzigd door curry684 op 12-10-2005 15:35 ]

woensdag 12 oktober 2005 15:31

Acties:

Ricvdp

Misschien wat offtopic, maar moet je niet eens wat meer richting normalisatie denken?

woensdag 12 oktober 2005 16:55

Acties:

Verwijderd

Topicstarter

Nou het werkt weer en ik heb aardig wat verbeteringen aangebracht: onnodige arrays etc.
MySQL inserts zullen idd niet de hoofdbottleneck zijn. Het aanmaken van een omzetstaat bestaat uit 3 grote onderdelen, dus wellicht ook handig om dit op te delen in 3 aparte pagina's. Na onderdeel 1 wordt onderdeel 2 geladen. .... nouja we denken verder. De normalisatie is ok trouwens, veel meer valt er niet te normaliseren.

woensdag 12 oktober 2005 19:50

Acties:

woensdag 12 oktober 2005 20:08

Verwijderd schreef op woensdag 12 oktober 2005 @ 16:55:
Nou het werkt weer en ik heb aardig wat verbeteringen aangebracht: onnodige arrays etc.
MySQL inserts zullen idd niet de hoofdbottleneck zijn. Het aanmaken van een omzetstaat bestaat uit 3 grote onderdelen, dus wellicht ook handig om dit op te delen in 3 aparte pagina's. Na onderdeel 1 wordt onderdeel 2 geladen. .... nouja we denken verder. De normalisatie is ok trouwens, veel meer valt er niet te normaliseren.

En je bent wel bekend met het feit dat je soms/meestal weer moet gaan denormaliseren voor de performance??? Dacht dat het zelfs stap 4 of stap 5 van een goed normalisatie traject was.

Normalisatie is een hulpmiddel, geen einddoel.

Acties:

Soultaker

Sowieso moet je dit soort dingen altijd in een transactie doen; doordat de database tussendoor niet hoeft te committen gaat het vaak een stuk vlotter.

Verwijderd schreef op dinsdag 11 oktober 2005 @ 23:58:
Dit stukje roept redelijk veel vragen op (wat gaat er langzaam, waarom worden er zoveel records ineens ge-insert, etc), maar ik bedacht mij in ieder geval wel 1 ding: na een insert moeten ook de indexen op de tabel opnieuw gemaakt worden. Daarom is het in sommige situaties zinvol om voor batch inserts de indexen weg te gooien en opnieuw op te bouwen na alle inserts

Misschien geldt dit voor andere databases, maar voor MySQL met InnoDB is dat niet het geval. Een index opnieuw aanmaken duurt langer en levert een grotere database op; gewoon lekker laten staan dus.

woensdag 12 oktober 2005 22:59

Acties:

Verwijderd

Verwijderd schreef op woensdag 12 oktober 2005 @ 16:55:
Nou het werkt weer en ik heb aardig wat verbeteringen aangebracht: onnodige arrays etc.
MySQL inserts zullen idd niet de hoofdbottleneck zijn.

Ergens vind ik het wel heel slordig om een topic te openen met een vraagstelling die gebaseerd is op een onjuiste aanname en dus te weinig vooronderzoek.

donderdag 13 oktober 2005 00:33

Acties:

Verwijderd

Verwijderd schreef op woensdag 12 oktober 2005 @ 22:59:
[...]

Ergens vind ik het wel heel slordig om een topic te openen met een vraagstelling die gebaseerd is op een onjuiste aanname en dus te weinig vooronderzoek.

Als iemand weet dat die een onjuiste aanname heeft zal die de aanname veranderen. Als die denkt dat zijn aanname goed is, is daar geen reden voor. Vroeger heeft men heel lang gelooft dat de aarde plat was of dat de zon om de aarde draaide. Op basis van die aannamen zijn een hoop ideeen ontwikkeld. Wil jij beweren dan onze voorouders eerst deze aannames hadden moeten testen?

Een van de gevolgen van een post hier kan zijn dat de basisaannames onder de loop genomen worden en men het probleem op een andere wijze oplost. Zo hoop ik dat de TS ook maar weer eens heeft nagedacht over het gebruik van MySQL. De aanname dat die database ergens voor geschikt is staat in ieder geval bij mij continue ter discussie.

donderdag 13 oktober 2005 09:23

Acties:

Verwijderd

Topicstarter

Hoi, toch een interessante discussie geworden.
Helaas kan ik niet de inserts in een batch gooien, omdat na iedere insert de id van de klant in een array wordt geplaatst (dit voor latere controles, een klant mag bijvoorbeeld in onderdeel 1 slechts 1x voorkomen). Als de insert mislukt is, dan moet de id dus niet in die array opgenomen worden. Met een batch gaat dit volgens mij niet ... toch?!

Maar idd: destijds was het programma voor 10 gebruikers op 1 vestiging met relatief weinig gegevens. Echter is het bedrijf en het programma in zeer korte tijd explosief in omvang toegenomen. Dus we hebben hier nu idd de discussie of een internet bedrijfje wel de aangewezen partij is voor het (verder) ontwikkelen en beheer van een dusdanig belangrijk programma (ook al is het een webapplicatie). En dan nog valt ook na te denken of het wel bij een webapplicatie moet blijven en niet een client-server programma op Windows (de gebruikers op de verschillende vestigingen hebben allemaal Windows).

En over dat normaliseren: ja zeker, ik weet dat je op een gegeven moment ook weer moet gaan de-normaliseren en dat is dan ook idd toegepast

Toevoeging:

Nu is het ook een class (terwijl het aanmaken van een omzetstaat), maar op 1 locatie gebeurt. Dus ik vraag me ook nog af of een class wel beter is dan losse functies. Met een class kan ik $this->variabele makkelijk gebruiken als globale variabele, maar met functies moet je dan weer met global gaan werken (of meesturen met de functie). Allemaal overwegingen.

[ Voor 15% gewijzigd door Verwijderd op 13-10-2005 09:26 ]

donderdag 13 oktober 2005 09:43

Acties:

Verwijderd

Nadat ik in een datetime field de waardes "31-02-2005" en "aap" had opgeslagen en bij een select na de 2e er braafjes "00-00-0000" uit kwam was men er alweer over uit.

Dus het feit dat jíj bagger de database ingooit is de schuld van MySQL?

Ik had nog niet eens toegevoegd dat MySQL voor commercieel gebruik 495 euro per jaar per server kost.

Kolder. MySQL is voor commercieel gebruik helemaal gratis. Je hoeft pas te betalen als je MySQL wil integreren maar niet aan de GPL voorwaarden wil voldoen.

[ Voor 4% gewijzigd door Verwijderd op 13-10-2005 09:44 ]

donderdag 13 oktober 2005 09:56

Acties:

BasieP

igmar schreef op woensdag 12 oktober 2005 @ 15:13:
...en mocht je nog een 3.x ov 4.0 versie van MySQL draaien : Meteen upgraden naar 4.1 met InnoDB.

daar wil ik even op ingaan.
Ik heb een ongeveer gelijke situatie als de topicstarter, en hoorde toen ook van iedereen 'neem innoDB' die heeft rollback functionaliteit, en kan FK's aanmaken..

ik had daarvoor myISAM, en ben braaf overgestapt.. maar dezelfde migratie (nog geen mil records) duurde toen opeens 17 minuten, waar hij eerst 2 minuten duurde..

kortom, ik ben me rotgeschrokken, en dacht dat ik wat fout gedaan moest hebben. Ik heb een boel settings (buffer sizes enzo) veranderd, maar het mocht allemaal niks uitmaken. zodoende ben ik snel teruggeswitched naar myISAM..
ben dus niet zo happy over innoDB.. functies zijn leuk, maar het is baggertraag als je het mij vraagt

This message was sent on 100% recyclable electrons.

donderdag 13 oktober 2005 10:10

Acties:

jelmervos

Simple user

Verwijderd schreef op donderdag 13 oktober 2005 @ 09:43:
[...]

Dus het feit dat jíj bagger de database ingooit is de schuld van MySQL?

Deze hoort er toch voor te zorgen dat de integriteit van de gegevens te allen tijde behouden blijft?

"The shell stopped unexpectedly and Explorer.exe was restarted."

donderdag 13 oktober 2005 11:04

Acties:

left part of the evil twins

Verwijderd schreef op donderdag 13 oktober 2005 @ 09:43:
[...]

Dus het feit dat jíj bagger de database ingooit is de schuld van MySQL?

Ja? Zoek eens op wat ACID betekent. Tip: de C staat voor "Consistency", oftewel a transaction should transform a system from one consistent state to another consistent state. Een database die je toestaat om waarde A erin te stoppen waarna je vervolgens waarde B eruit krijgt is op z'n zachtst gezegd niet consistent, en daarmee minder dan geen cent waard in een bedrijfskritische omgeving. Weet je wat SQL Server met deze code doet:

SQL:

create table #test (field datetime);
insert #test values ('01-10-2005');
insert #test values ('31-02-2005');
insert #test values ('00-00-0000');
insert #test values ('aap');
drop table #test;

Dat levert op:

code:

(1 row(s) affected)

Server: Msg 242, Level 16, State 3, Line 3
The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.
The statement has been terminated.
Server: Msg 242, Level 16, State 3, Line 4
The conversion of a char data type to a datetime data type resulted in an out-of-range datetime value.
The statement has been terminated.
Server: Msg 241, Level 16, State 1, Line 5
Syntax error converting datetime from character string.

Dat heet data-validatie en beschermt je ertegen dat er door bugs, corrupte input of wat dan ook troep in je DB komt. Dat is het werk van een database.

Even de test herhaald in MySQL op innoDB table:

SQL:

insert temp values ('01-10-2005');
insert temp values ('31-02-2005');
insert temp values ('00-00-0000');
insert temp values ('aap');
select * from temp;

Levert op:

code:

      Edit        Delete    0000-00-00 00:00:00
    Edit    Delete  0000-00-00 00:00:00
    Edit    Delete  0000-00-00 00:00:00
    Edit    Delete  0000-00-00 00:00:00

Dat neem je toch niet serieus

[...]

Kolder. MySQL is voor commercieel gebruik helemaal gratis. Je hoeft pas te betalen als je MySQL wil integreren maar niet aan de GPL voorwaarden wil voldoen.

Of feitelijke support wil. Denk je dat de onderhevige multinational die iets met gloeilampjes doet serieus bedrijfsvitale data (we hebben het hier over miljarden) in een softwarepakket stopt waar ze geen support op hebben? Ze zouden prolly zelfs voor het duurste supportcontract van 4000 euro/jr gaan, wat tegenover een one-off investering van 5000 euro voor SQL Server stervensduur is.

[ Voor 11% gewijzigd door curry684 op 13-10-2005 11:14 ]

donderdag 13 oktober 2005 11:10

Acties:

left part of the evil twins

BasieP schreef op donderdag 13 oktober 2005 @ 09:56:
[...]

zodoende ben ik snel teruggeswitched naar myISAM..
ben dus niet zo happy over innoDB.. functies zijn leuk, maar het is baggertraag als je het mij vraagt

Nee wederom: myISAM is fscking snel omdat het van ACID niet aan de A van Atomicity, niet aan de C van Consistency, niet aan de I van Isolation en niet aan de D van Durability voldoet. Het is een baggersysteem dat de naam database eigenlijk niet mag dragen maar eerder een ultra-thin wrapper om een comma-separated file met indexing is. Als je je data veilig wil opslaan kost dat kruim ja, dat heb je wel eens.

Een middenklasser auto tegenwoordig is anderhalf keer zo zwaar dan 10 jaar geleden, en die extra 400kg zijn allemaal staalbalken in deuren en kooi die ervoor zorgen dat jij het overleeft als er een dronken automobilist binnen komt rijden. Is de auto van 10 jaar oud beter omdat ie sneller kan rijden op minder motorpower?

donderdag 13 oktober 2005 11:47

Acties:

donderdag 13 oktober 2005 14:49

Software Architect

Werkt hier

curry684 schreef op donderdag 13 oktober 2005 @ 11:10:
Het is een baggersysteem dat de naam database eigenlijk niet mag dragen maar eerder een ultra-thin wrapper om een comma-separated file met indexing is.

Geef eens een definitie van de term database?

En dan dus niet de wensenlijst die jij gelijk bij de term database erbij bedenkt, maar wat puur de term betekent.

Ik ben helemaal met je eens dat MySQL niet zo lekker met ACID overweg kan als je kiest voor MyISAM, maar dat is dan ook de afweging die de gebruiker moet maken: wat sneller en minder data-veilig of wat langzamer en meer data-veilig.

Overigens is MySQL nog altijd niet snel met complexe queries, subqueries en dergelijke zijn bedroevend langzaam en sommige joins heb ik in PostgreSQL in 0.5 seconde zien uitvoeren op dezelfde hardware en data waar ik het bij MySQL na 30 minuten maar een kill-signaal gaf; inclusief de data-dump en data-import was het nog steeds veel sneller om het in PostgreSQL uit te voeren.
Dat was overigens een query die ik verder weinig gebruik, maar niet eens zo complex was en daardoor was het toch wel een erge teleurstelling. Het is ook wel jammer dat er voor zover ik kan vinden geen structurele wijzigingen in de query-executie/planning zijn doorgevoerd sinds de 3.23-reeks.

Gelukkig is MySQL met versie 5 eindelijk begonnen met ACID beter te ondersteunen, zelfs voor MyISAM. Die datum-inserts zouden daar ook geweigerd moeten worden bijvoorbeeld. Met 5.1 wordt geloof ik de query-engine onder handen genomen, dus dan wordt het eindelijk een beetje interessant. Jammer alleen voor ze dat Postgres tegen die tijd versie 8.2 in late ontwikkeling of zelfs uitgebracht heeft en ze daardoor niet zo gauw voor zullen lopen op die concurrent (op dat gebied iig).

Acties:

Soultaker

Ik werd eerder al volslagen genegeerd; nog een poging dus maar:

BasieP schreef op donderdag 13 oktober 2005 @ 09:56:
ik had daarvoor myISAM, en ben braaf overgestapt.. maar dezelfde migratie (nog geen mil records) duurde toen opeens 17 minuten, waar hij eerst 2 minuten duurde..

kortom, ik ben me rotgeschrokken, en dacht dat ik wat fout gedaan moest hebben. Ik heb een boel settings (buffer sizes enzo) veranderd, maar het mocht allemaal niks uitmaken. zodoende ben ik snel teruggeswitched naar myISAM..
ben dus niet zo happy over innoDB.. functies zijn leuk, maar het is baggertraag als je het mij vraagt

Heb je toen een transactie gebruikt of niet? Als je InnoDB na elke insertion laat comitten wordt het ook retetraag ja, dat geldt voor alle databases die ook nog een beetje consistentie enzo garanderen.

donderdag 13 oktober 2005 16:21

Acties:

Hydra

ACM schreef op donderdag 13 oktober 2005 @ 11:47:
Ik ben helemaal met je eens dat MySQL niet zo lekker met ACID overweg kan als je kiest voor MyISAM, maar dat is dan ook de afweging die de gebruiker moet maken: wat sneller en minder data-veilig of wat langzamer en meer data-veilig.

"Met ACID overweg kan"? Sorry hoor, maar ACID is geen dubieuze extensie op de SQL syntax ofzo, het is een basisprinciepe waar een goeie DBMS op gebaseerd is. Ik heb heel fijn gewerkt met MySQL, maar het is gewoon geen serieuze speler in de DB markt.

https://niels.nu

donderdag 13 oktober 2005 22:08

Acties:

BasieP

Soultaker schreef op donderdag 13 oktober 2005 @ 14:49:
Ik werd eerder al volslagen genegeerd; nog een poging dus maar:

[...]

Heb je toen een transactie gebruikt of niet? Als je InnoDB na elke insertion laat comitten wordt het ook retetraag ja, dat geldt voor alle databases die ook nog een beetje consistentie enzo garanderen.

yu, maar dan nog is het langzamer dan myisam..

This message was sent on 100% recyclable electrons.

donderdag 13 oktober 2005 22:45

Acties:

Soultaker

BasieP schreef op donderdag 13 oktober 2005 @ 22:08:
yu, maar dan nog is het langzamer dan myisam..

In mijn ervaring is InnoDB niet langzamer dan MyISAM. Misschien moeten we eens benchmarken?

donderdag 13 oktober 2005 23:11

Acties:

donderdag 13 oktober 2005 23:12

Software Architect

Werkt hier

Hydra schreef op donderdag 13 oktober 2005 @ 16:21:
"Met ACID overweg kan"? Sorry hoor, maar ACID is geen dubieuze extensie op de SQL syntax ofzo, het is een basisprinciepe waar een goeie DBMS op gebaseerd is. Ik heb heel fijn gewerkt met MySQL, maar het is gewoon geen serieuze speler in de DB markt.

ACID is een acroniem voor vier termen die in deze context gebruikt worden om aan te geven dat de data gegarandeert in een bepaalde status is, dat je de data terugkrijgt die je er in gestopt hebt en niet iets anders of een halve versie, etc.

Als je InnoDB gebruikt heb je een transactionele database met transaction isolation en een log-based schrijfsysteem en dus in principe gewoon de A, I en D van ACID. Waar MySQL nog grote steken laat vallen is bij de C, omdat het stilletjes data kan veranderen die je invoert. Met 5 is dat minder erg of zelfs helemaal weg (ik heb het niet zó goed gevolgd). Dus het kan atomicity, isolation en durability goeddeels garanderen en binnenkort doet het ook moeite voor consistency. Daarvoor gebruikte ik de uitdrukking 'overweg kunnen met ACID'

Gebruik je MyISAM dan ben je niet eerlijk aan het vergelijken, en heb je imho bewust gekozen geen A, I en D te verwachten van je DBMS.

Ik ben zelf van mening dat MySQL niet enorm geschikt is voor complexe zaken, maar zie toch keer op keer opmerkingen verschijnen die suggereren dat MySQL helemaal nergens geschikt voor zou zijn (op triviale applicaties na). En dat is dan wellicht ook een foute aanname, vaak genoeg is men bereid met de tekortkomingen te leven en wordt om een deel van de vervelendste fouten heen geprogrammeerd in de client-omgeving. Als je daardoor aanzienlijk minder vaste kosten en eventueel ook nog betere performance in de rest van je use cases krijgt... dan is het best interessant om te doen.

Vaak is het van data (heel) vervelend als het weg is, niet cruciaal voor je bedrijfsvoering. Imho wordt er te vaak gedaan alsof alle data cruciaal is en dus dat alle data zo veel mag kosten als nodig is om te garanderen dat het nooit verdwijnt of onterecht verandert... dat is in mijn beleving niet het geval. Natuurlijk zijn er zat situaties waar dat wel zo is, maar ook erg veel waar het minder van belang is.

In die grote markt van 'niet-absolute, maar grote zekerheid van je data' speelt MySQL een grote rol en is het onzin om te claimen dat het geen serieuze speler in de markt is.

Wil je meer, by all means, neem meer. Maar geef op relevante punten af op MySQL en sluit het niet bij voorbaat al uit van de discussie

Acties:

donderdag 13 oktober 2005 23:14

BasieP schreef op donderdag 13 oktober 2005 @ 22:08:
[...]

yu, maar dan nog is het langzamer dan myisam..

Yup klopt, maar wat wil je nou. Myisam is imho gewoon een dump van de gegevens op disk. Of de gegevens op disk hetzelfde zijn als de aangeleverde gegevens, dat is niet myisams zorg. Dus dit is razendsnel. Innodb probeert nog iets van de aangeleverde gegevens te checken, dus dit is langzamer want er zitten verschillende checks tussen.

Wil je je gegevens enigszins betrouwbaar opgeslagen hebben ( dus met checks van database ) dan kies je voor innodb. Wil je je gegevens snel opgeslagen dan kies je voor myisam. Wil je je gegevens snel terugkunnen halen met ingewikkelde queries dan kies je voor een andere db. Easy as pie.

Acties: