Gepubliceerd: Vrijdag 30 juli 2010
SQL is de de-facto standaard als het gaat om applicatie-databases. Maar er wordt meer en meer getwijfeld aan het nut van relationele databases, ten gunste van het zogenaamde 'NoSQL'.
Toon volledig artikel
(l)mongo
het best te gebruiken is renationele database (b.v mssql) en dynamic velden in mongo te stoppen..
b.v product heeft een naam die zet ik mssql maar b.v kenteken/barcode/gewicht/aantal zet ik mongo
dynamic velden gewoon een een document opslaan in mongo. het mooi aan het document gebeuren is dat je op iedere veld kunt zoeken. het kan zijn dat een product kenteken heeft en andere een barcode.. geen onnodige velden in een document...
gegevens beheer.. iedere beetje programmeur houd daar rekening mee
m.a.w. je moet het gereedschap gebruiken wat het best geschikt is voor de werkzaamheden die je gaat doen, dit was al bij de timmerman zo die een hamer gebruikt ipv een nijptang om de spijkers er in te tikken, beide kunnen het, maar met de een gaat het efficienter als met de andere. Ik verbaas me dan ook dagelijks over bepaalde technologien die ergens gebruikt worden maar gewoon niet bedoeld zijn voor een bepaalde oplossing. Het lijkt wel of de programeurs erg lui zijn geworden met de laatste generatie talen en nog alleen maar de gereedshcappen kennen die er zijn, maar niet meer instaat zijn om zelf een nieuwe 'tool' te maken. Wel lekker goedkoop maar zeker niet altijd efficient.
Waar te beginnen. Een open deur dan maar: storage is een vak apart.
We praten natuurlijk over veeleisende omstandigheden. Performance en schaalbaarheid spelen nooit zomaar een rol, die komen pas om de hoek kijken als de omstandigheden ernaar zijn. Hebben we het dan over relationele databases dan valt er over keuze, opzet en gebruik wel het een en ander te zeggen. Er zijn verschillen tussen de diverse relationele dbs en je kan er goed en minder goed gebruik van maken. Een aanpak die prima werkt bij Postgresql kan beroerd uitpakken bij Oracle. Het is maar net hoe je je data inricht.
Als je dan toch kritisch bent ten aanzien van de keuze voor een database dan kan het heel wel zo zijn dat een NOSQL storage meer voor de hand ligt. Voordat je daar iets over kunt zeggen zul je een gedegen analyse van de data en de verdere wensen en eisen moeten hebben alsmede een goed inzicht in wat de diverse storage soorten te bieden hebben. NOSQL is ook maar een containerbegrip wat de meest diverse databases omvat. Het is maar net hoe je je data inricht.
Maar de laatste jaren staat dit voordeel onder druk, omdat de hardware anders is gaan schalen. “Servers werken nu met meerdere processors, en elke processor heeft meerdere kernen”, legt Bouman uit.
Tja, ik zou factoren als RAM geheugen en IO snelheid ook bekijken. Het is maar net hoe je je data inricht.
“De rekenkracht is enorm toegenomen, terwijl de kloksnelheid nagenoeg gelijk is gebleven. Een MySQL-database schaalt gebrekkig in die richting, hoewel daar wel verbetering in is te bemerken.”
Daar zijn wel lapmiddelen voor, zegt Bouman, zoals caching en sharding. Maar die 'oplossingen achteraf' brengen weer hun eigen problemen mee.
Is dat zo? Hoeveel ervaring heeft die man met Oracle databases en caching, om maar een voorbeeld te noemen? Die lapmiddelen zitten in de db ingebouwd, we hebben het hier toch niet over het caching van bijvoorbeeld de webserver.
Dan is er de SQL-taal zelf. “Het is redelijk ouderwets. Een beetje zoals COBOL ook ouderwets is, maar nog steeds de kern vormt van heel veel applicaties.
Nou ja, COBOL is aardig met haar tijd meegegaan en zelfs harder geupdate dan SQL (het is danook ouder). COBOL legacy zul je veelal vinden bovenop databases die nog voor SQL uitgingen, zoals de netwerk databases. De spreker maakt echter de vergissing om de manipulatietaal de schuld te geven van problemen bij de toepassing. Tenminste, ik ben genoeg snelle database abstracties tegengekomen om SQL niet rechtstreeks in de code te hoeven op te nemen of met code te hoeven maken. Het probleem is de data(opslag), niet de taal om de data te benaderen. Niemand beweert dat SQL perfect is of dat er betere alternatieven denkbaar zijn maar hier is het een met-de-haren-erbij-gesleept argument.
...
SQL is daar eigenlijk enorm onhandig voor”
Inderdaad
Op mijn werk is niet de CPU of RAM het probleem op de DB-server, maar we lopen tegen de I/O grenzen aan....
We hebben niet genoeg gegevens om er zinnig op in te gaan maar de reactie van Blieb is niet zo merkwaardig. Je zult heel nauwkeurig moeten gaan speuren naar waar in jullie geval de bottlenecks zitten en misschien ook wat benchmarking moeten doen op alternatieve configuraties maar in elk geval het geheel in ogenschouw moeten nemen.
Om een heel simpel voorbeeld te geven: als je vermoed dat de IO het probleem is dan kan je gaan werken met snellere schijven en netwerkverbindingen maar misschien valt er een grotere winst te boeken door meer kleinere of juist minder grotere transacties te doen. Stel dat je optimaliseert voor wat betreft de caching dan kan sneller RAM ook een performance winst betekenen.
Het is geen simpel iets. Als je denkt dat de IO de bottleneck vormt dan lijkt het voor de hand te liggen om zo min mogelijk IO proberen te doen maar wellicht is het een kwestie van data groottes beter afstemmen op de IO of vice versa, zoals kijken naar de database server setup vwb. filesystem bijvoorbeeld.
We gaan de database in een RAM-disk gooien. Dus de hele database in het RAM
Dat zal een groot deel van de I/O problemen verhelpen.
Dit kost alleen heel veel ram
De querys optimaliseren hebben we allang gedaan. Dit heeft even geholpen, maar als je spelers-aantal blijft groeien is dit maar tijdelijk
Jaah! Een database in RAM! Dan ben je tenminste alles kwijt als de boel uitvalt!
En verwacht niet dat RAM gaat helpen als I/O het probleem is. Zeker niet als je nu al RAM genoeg hebt om die database in RAM te kunnen draaien. Want vanwege caching had je de gegevens dan al in RAM beschikbaar voor lees-acties. En aangezien je de schrijf-acties (zullen er een stuk minder zijn verwacht ik) uiteindelijk ook wel op een harde schijf wil zetten, zal de Disk-I/O er ook wel blijven.
Overigens zou ik het geen probleem vinden als ik ongelijk blijk te hebben hoor... :-P
*schopt WW. fix die brakke code eens *
Voor stroomuitval heb je iets genaamd een ups en dan laten synchen bij shutdown
Op mijn werk zijn het online spellen, dus behoorlijk veel writes (statussen onthouden ed). Dat is ook het probleem. Bij een site die vooral doet lezen krijg je dit probleem niet snel.
Of MySQL in ons geval een goede keuze is is vers 2. Daar ga ik helaas niet over.
In batches synchen is een stuk sneller dan random access wat een normale DB doet. Dat zal dus de performance flink ten goede komen
Wat is jouw ervaring met UPSen? Die dingen helpen tegen korte dipjes, maar ik heb ook al een keer overgekookte accu's gehad (in een echte APC zelfs!) en dan ga je subiet down zonder waarschuwing...
Hou rekening met eens per 2 of 3 jaar dat je alsnog een keer onverwacht down gaat. Heb je dan bin-logs op een schijf zodat je alles behalve de laatste paar tellen kunt recoveren vanaf een eerdere dump?
Je idee met een tweede server en loadbalancer gaat niet werken als schrijf-acties het probleem zijn (die moeten dan immers op beide servers worden uitgevoerd). Binnen mysql heb je nog een heleboel keuzes mbt typen tabellen die elk hun voors en tegens hebben, dus wellicht dat je daar nog wat mee kunt verbeteren. Maar als het propere SQL is, zou je eens kunnen kijken of je het bij wijze van test kunt verhuizen naar een postgres doos. Ik heb hele fraaie verbeteringen gezien met dat soort migraties, al moet je daarbij wel even kijken hoe je de voorzieningen van postgres optimaal kunt inzetten om de boel snel te krijgen. Dat de gebruikte database niet jouw keuze is, wil niet zeggen dat er niemand naar je luistert als je zegt dat het beter kan ;-)
De querys optimaliseren hebben we allang gedaan. Dit heeft even geholpen, maar als je spelers-aantal blijft groeien is dit maar tijdelijk
Als er dingen in je database veranderen dan zul je ook je optimalisatie opnieuw moeten uitvoeren. Queries die met een kleine dataset geen problemen opleveren kunnen dat met een flink gegroeide dataset wel doen. Je moet er actief mee bezig zijn.
De meest gemaakte fout is door problemen op te lossen door middel van snelleren hardware. Dat gaat je uiteindelijk niet heel veel verder helpen.
Verraad ik mijn leeftijd als ik vooral heel erg de geur van X.500 en later LDAP in dit verhaal ruik?
Nee hoor, dat deed je foto al ;-)
LDAP was ook het eerste waar ik aan dacht: light-weight lezen, niet noodzakelijk up-to-date met laatste wijzigingen, en schrijfacties uitstellen en bundelen. Niets nieuws onder de zon dus. Alleen heeft het nu opeens een hippe naam.
Een database zonder structuur, zonder SQL en zonder management. Waar je zelf nog een DBMS bij moet gaan schrijven om de structuur en inhoud te bewaken en op te schonen. Ergens tussen veredelde key-value paren en IBM DB/2. Wat vervolgens gaat evolueren, tot het punt dat iemand een plugin schrijft die SQL lust en uitspuugt. "Want dat is toch wel handig."
SQL-databases kunnen prima schalen met grotere workloads, alleen moet je daar je database-structuur en je queries op afstemmen. Voor serieuze applicaties is dat geen probleem (specs en acceptatietesten en alles wat daartussen zit). Frivole apps echter, zoals Twitter, die eigenlijk vooral veel te snel uit hun hobby-jasje gegroeid zijn... daar zal dat nog wel even wat moeite kosten. Vanwege het karakter van dat soort applicaties is een minder accurate weergave wellicht acceptabel, maar of het echt op de lange termijn veel helpt? Je zult alle mutaties toch een keer moeten doen, en bij twitter is er nooit zoiets als een rustige nachtperiode.
Als er meer van dit soort artikelen verschijnen dan zou ik als vanouds vaker op webwereld terecht komen.
Qua content begrijp ik nog niet helemaal de kern van de zaak. Betekent het nou dat als je Oracle, DB2, SqlServer gebruikt dat je dit aan je voorbij kunt laten gaan? En alleen als je MySQL gebruikt dat je tegen tekortkomingen aanloopt die je moet oplossen d.m.v. dit soort oplossingen?
Nee, want voor mijn webwinkel software zie ik totaal niets in NoSql. nu is MySQL ook niet heilig, maar voor het gros van de toepassingen prima toelaatbaar.
Uiteindelijk wil ik altijd exacte data, wie/waar/wat/hoe en zeker niet "ongeveer"
Wat wil je als je in een wereld leeft, waar op de lagere school op de volgende manier met rekenen omgegaan wordt:
Onderwijzeres: "Wat is 3 x 4?"
Jantje: "Ongeveer 10 juffrouw."
Onderwijzeres: "Dat heb je goed uitgerekend, Jantje."
En dit is realiteit! Niet fantasie.
@ edelwater: nee. Het is wat blah blah bij elkaar maar het gaat om relationele databases en dat die soms niet het meest geschikte vehikel voor data opslag zijn.
Dwz. dat als je tegen grenzen aanloopt die MySQL specifiek zijn, je nog steeds niet noodzakelijkerwijs iets in de NOSQL hoek hoeft te zoeken. Als je echter tegen de grenzen van relationele databases aanloopt of eenvoudigweg requirements hebt die niet logisch op het relationele model mappen, dan zou je voorbij dat model moeten kijken en kom je misschien in de NOSQL hoek terecht.
@ M Wegman: uiteraard, uiteraard, je hebt helemaal gelijk. Stel nu echter dat jouw webwinkel de omvang van Amazon of Ebay krijgt. Dan zou je in een situatie kunnen komen dat (een deel van) je data realistisch gezien niet meer goed relationeel verwerkt kan worden, hoeveel optimalisatie je er ook op los laat.
@ perry1: Nu komt Jantje een klas hoger en de docent vraagt hoeveel 37 * 46 is. Jantje is een slim kind van deze tijd en haalt een rekenmachine tevoorschijn. Toch is het op zich niet gek als 'ie een idee heeft van de orde van grootte van het uiteindelijke antwoord. "Ergens tussen 1500 en 2000" is misschien in veel gevallen al best bruikbaar.
Dus die couchDB en NoSql is dus gewoon een soort MsSQL met een stored procedure en een webservice endpoint die XML of JSON uitbraakt en dus direct door bijvoorbeeld javascript kan worden gebruikt. Hierdoor haal je een abstract bijvoorbeeld PHP laagje weg en leg je meer bij de DB server neer die veel krachtiger is geworden.
Lijkt me goed zolang je niet teveel hoeft te rekenen met data. DB servers zijn daar niet zo sterk in. Eigenlijk niet echt iets nieuws.
"Het is sneller om de diagonaal te pakken dan de breedte en de lengte, althans als je gewoon van a naar c wilt."
Ehm... Nee. Alhoewel het beide (uiteindelijk) programma's zijn die grote brokken gegevens op een bepaalde manier slim opslaan om er vervolgens vlug allerlei bewerkingen mee te laten doen, zit 'm de clou in de manier van opslag. De relationele database van MySQL legt alles aan als een tabel van rijen en kolommen, zeg een groot Excel-sheet, met honderden kolommen en duizenden zo niet miljoenen rijen. Elke nieuwe rij reserveert ruimte voor honderden kolommen, ook al worden die niet meteen gevuld. De database van CouchDB is daarentegen opgebouwd rond documenten: verzamelingen van losse key-value paren die op een slimme manier (met B-trees, als ik me goed herinner) worden opgeslagen om zoeken te vergemakkelijken. Er is geen echte structuur en nieuwe kenmerken toevoegen gebeurt op basis van enkele documenten; dit in tegenstelling tot MySQL waar een nieuwe eigenschap meteen in de complete DB zichtbaar is (de tabel wordt immers groter).
Ik ervaar de verhouding CouchDB : MySQL als scripttaal : gecompileerde taal. CouchDB maakt het heel eenvoudig om even vlug iets werkbaars in elkaar te zetten en te laten evolueren zonder dat je je meteen in de toch rigidere syntax van een relationele DB hoeft te wurmen, zonder dat je voorzichtig moet zijn met manipulatie van de DB. Eén fout in een relationele DB en het geheel ligt aan gruzelementen; in een document-geöriënteerde DB, waar geen overkoepelende structuur bestaat, is hooguit een klein aantal documenten vernaggeld. Een relationele DB is daarentegen veel handiger als je zeker weet dat de gegevensstructuur star is, en elk 'record' dezelfde gegevens nodig heeft/gebruikt.
Beide hebben zo hun plek in de wereld van de data-opslag; zeggen dat de één altijd beter is dan de ander is onzin.
Goed dat er aandacht voor is, maar erg slechte argumentatie.
In de PHP-pagina moet je bijvoorbeeld strings in elkaar timmeren om de SQL-statements bij de database af te leveren. Vervolgens komt er weer data terug van de server, dat moet je dan converteren naar een array of iets dergelijks, daar moet je weer doorheen lopen.
Dat heeft verder weinig te maken met de werking van een relationele database, eerder met de grote achterstand die php en mysql hebben ten opzichte van bijvoorbeeld asp.net. (denk aan Linq language integrated query)
Met bijvoorbeeld Javascript worden enorm rijke client-side webapplicaties gebouwd
Waardoor de compatibility, performance en dergelijke erg afhankelijk worden van de client.
Het manco zit vooral in de manier waarop je de data van de server terugkrijgt. Als je bijvoorbeeld bij een webwinkel klantgegevens opvraagt, wil je ook de ordergegevens enzovoorts hebben. SQL kan alleen tabellen terugsturen, waardoor je de databehoefte moet vullen met meerdere queries.
Dan moet hij zijn programmeur vragen om betere querys te maken.
Je zit met de latency die een verzoek inneemt. Dat zou niet het geval zijn geweest als SQL in staat was om alle gegevens met een enkele query op te vragen
Ooit gehoord van JOIN statements en INDEXES?
Dat probleem speelt bij NoSQL helemaal niet. “Bij CouchDB bijvoorbeeld stuur je een query, en krijg je direct een document terug met alle mogelijke gegevens.
Ooit gehoord van sqlxml?
Maar, zo waarschuwt Bouman, je moet als ontwikkelaar voor al die voordelen wel een prijs betalen. “Je moet zelf aan gegevensbeheer doen. Je moet er zelf voor zorgen dat het bestand niet vervuild raakt en er geen dubbelingen in voorkomen.
Werken developers dan in hun ééntje aan een database?
Je kunt dus een database bouwen die altijd beschikbaar is en goed presteert, maar dan is hij niet consistent.
WTF?
Als Microsoft SQL gebruiker heb je inderdaad bijna alle features al die genoemd worden als voordelen van NoSQL. En dat helemaal zonder de nadelen. Behalve één, het nadeel van de licentieprijs...
En dat helemaal zonder de nadelen.
Mwoa, vrijheid van operating system is ernstig beperkt, hetgeen ook nog eens doorwerkt in de licentiekosten. En naar goed database gebruik is het licentiesysteem schier ondoorzichtig.
Nu gaat het hier verder niet over de nadelen van een specifieke relationele database maar van mij mag je proberen om Twitter, Digg of Facebook op SQL Server te draaien. Veel succes.
Ik moet de eerste webdeveloper die enig gevoel heeft voor dataconsistentie en beheer nog tegenkomen.
Volgens mij is de kracht van NoSQL het volgende: webdevelopers hebben de balen van die stijve en onhippe dba-ers, die niet elke verandering klakkeloos voor ze uitvoeren. Met NoSQL hebben ze dat zelf in de hand en kunnen ze snel manouvreren. Daar zijn ze in eerste instantie blij mee. Maar zodra blijkt dat ze door gebrek aan beheer enorm in de problemen komen en ze elkaar in de weg gaan zitten met hun gegevens, zijn ze heel gauw weer terug bij een solide database die dit soort dingen voor ze oplost.
Die stijfkoppigheid van de klassieke sql databases is er met een reden, en met het overboord gooien ervan wordt die reden snel genoeg weer ontdekt en gaat het wiel een tweede keer uitgevonden worden.
Hi Allemaal,
allereerst wile ik graag kwijt dat ik het enorm leuk vind om zoveel reacties te zien op dit artikel. Verder wilde ik, aangezien ik door Michiel ben geinterviewd t.b.v. dit artikel, graag even ingaan op een aantal punten die in de comments naar voren zijn gebracht.
@uranis: je snijdt hier een goed punt aan. De term NoSQL wordt tegenwoordig begrepen als "Not Only SQL". Deze term drukt uit dat de NoSQL en relationele databases complementair zijn, en dat een hybride architectuur wel eens de beste oplossing kan zijn voor het probleem.
@Caesar Tjalbo: het klopt dat NoSQL een containerbegrip is - met name op het gebied van het onderliggende datamodel kun je een nuttige indeling maken in de NoSQL vergaarbak. Ik heb dit in het interview wel naar voren gebracht maar dit heeft het artikel niet gehaald.
Over caching en sharding: In het interview heb ik naar voren gebracht dat voor veel (grote) webapplicaties de datalaag is gegroeid, vaak eerst vanuit MySQL, waarna na toegenomen datavolume en aantal requests caching in de applicatielaag (vaak op basis van memcached) wordt toegevoegd en sharding wordt toegepast. Deze middelen zijn moeilijk te verenigen met een pure relationele aanpak en SQL - zo is het eigenlijk niet meer mogelijk om de consistentie te garanderen, en kun je over de shards heen in de praktijk niet joinen. Dit alles diende ter illustratie van het feit dat indien er echt voor een NoSQL oplossing gekozen wordt, een puur relationele aanpak vaak al eerder werd prijsgegeven. Zo bezien is NoSQL niet meer zo'n onlogische keuze, omdat dergelijke producten de noodzaak om zelf in de applicatielaag de caching en sharding logica te schrijven kunnen wegnemen.
Over SQL en abstractielagen: ik doelde vooral op hetgeen je in CouchDB ziet - directe HTTP toegang, en JSON queryresultaten. Veel webontwikkelaars zijn niet uit op de expressiviteit die je met SQL kunt bereiken. Hoewel het misschien mogelijk is dit met een ORM achtige oplossing toch op een RDBMS te bouwen, het blijft een extra stap.
(Overigens werk ik sinds 1998 op professionele basis met Oracle.)
@Nixpro, @Zwoop over LDAP: op een NoSQL conferentie zal niemand je gek aankijken als je een snelle LDAP store zou gebruiken om je webapplicatie op te bouwen (mits het LDAP model en querytaal een goede fit zou zijn voor het applicatiedomein). Maar NoSQL is wel breder - er zijn eental verschillende typen data modellen te onderscheiden (document store, key/value store, column family, graph), terwijl LDAP toch vooral een hierarchisch data model is. (ik ben LDAP expert, dus laat het gerust weten als je denkt dat ik de plank daar missla).
@edelwater Zeker is het zo dat Oracle, DB2 etc meer geavanceerd zijn, beter op te schalen zijn, en meer complexe queries aankunnen. Dus het is best mogelijk dat een applicatie die met moeite op een enkele MySQL instance draait, geen problemen ondervindt op een meer geavanceerd RDBMS. Maar in de praktijk draaien de hele grote websites zoals facebook en twitter geen Oracle of DB2. Laten we zeggen dat als ze het wel zouden doen het hoogstwaarschijnlijk geen gratis diensten zouden zijn. Verder is het zo dat als het aantal verzoeken en het data volume maar genoeg groeit, het met elk RDBMS een uitdaging zal zijn op performance te blijven leveren. Dus als je voor bepaalde databehoeftes met een NoSQL oplossing je RDBMS kunt ontlasten, dan moet je dit zeker overwegen, ook al draai je Oracle of DB2.
@DanielSan en @cymric over CouchDB als MS SQL met een SP die JSON/XML uitbraakt: de HTTP/JSON is slechts 1 aspect. @cymric noemde al het onderliggende datamodel als verschil; verder is CouchDB inherent gedistribueerd - meerdere instances repliceren data naar elkaar toe, dus je kunt op eenvoudige wijze een cluster bouwen, en daarmee dus uitschalen op basis van standaard (goedkope) hardware (in plaats van opschalen). Verder geldt natuurlijk ook weer dat je met CouchDB geen softwarelicentiekosten hebt.
@keesdewit: zie wat ik ook al eerder schreef aan @Caesar Tjalbo. Overigens is de trend juist dat browsers steeds meer standardiseren - juist moderne Javascript frameworks maken het mogelijk om goede platform onafhankelijkheid te bereiken. Dus de wens om vanuit de webapplicatie direct via JSON met de data service te praten is zo gek nog niet.
Over "betere queries": een voorbeeld van een probleem waar ik op doelde is dat je bij 1 master (laten we zeggen, "gebruiker") twee verschillende details wilt ophalen (laten we zeggen, "favoriete boeken" en "vrienden") - dit soort gegevens zou je op de profielpagina van een sociaal netwerk kunnen aantreffen. In SQL is er geen voor de handliggende manier op dit te doen in een enkele query (geef maar een voorbeeld als je er anders over denkt :)
Kortom, ergens ga je dit met meerdere verzoeken richting database oplossen. Uiteraard ga je uit van een geoptimaliseerde database structuur en de aanwezigheid van indexes. Maar die helpen niets om de de latency die je hebt omdat er een netwerk zit tussen ofwel je applicatie server en de database server, of tussen de client en de webserver te verkleinen. Ik hoop dat dit nu duidelijker is.
@Lampredi: Ik denk dat er inderdaad ontwikkelaars zijn die zich aangetrokken voelen tot NoSQL om deze redenen. De NoSQL producten zelf zijn nog relatief jong, en inderdaad zullen er dingen misgaan indien het te snel of voor de verkeerde redenen wordt ingezet. Aan de andere kant zijn de mensen achter de NoSQL oplossingen niet de minsten, en de ontwikkeling wordt wel degelijk gedreven vanuit de noodzaak een meer flexibele en snellere data store te hebben.
met vriendelijke groet,
Roland Bouman
http://rpbouman.blogspot.com/
Om te kunnen reageren, dient u ingelogd te zijn.
2 jaar geleden: 13 februari 2010
3 jaar geleden: 13 februari 2009
4 jaar geleden: 13 februari 2008
5 jaar geleden: 13 februari 2007
14 jaar geleden: 13 februari 1998
IDG Nederland is uitgever van: AppFish
, CIO, Computer!Totaal, Computerworld, ITworld, Jobworld, MacWorld, RAW fotomagazine, TechFish, Tips & Trucs, Webwereld en Zoom.nlMeer informatie: IDG Nederland, IDG.com, Privacy-statement, Cookie-statement Hosting by Terremark.
