Server voor bedrijf

[Wessels - IT Projectmanager]

Ons bedrijf heeft een server nodig om een database te draaien die gegevens ophaalt van andere databases op een heel andere lokatie. :) We zullen starten met 18 lokaties waar de data van word onttrokken, maar dit zal tot maximaal 135 locaties komen in de nabije toekomst. Daarnaast zullen zo'n 5 mensen achter een client zitten om zoekacties te doen op de database.

 

Om niet een heel verhaal op te hangen kan ik zeggen dat het hier om een gigantische database gaat met enorm veel rows en weinig tabellen. :-[

 

Nu weet ik wel het een en ander van data servers en webservers af, maar ik heb nog nooit te maken gehad met een gigant als dit. ??? Ik verwacht zelf dat ik veel ruimte nodig heb om die database te laten draaien en het gaat waarschijnlijk om een SQL database. Maar omdat ik nog niet de grootte kan inschatten van de database loop ik vast op een keuze die ik moet maken voor een server en de software.

 

Kunnen jullie mij tips geven waarop ik moet letten bij de aankoop van een server voor dit doel?

Bijvoorbeeld:

• Welk platform ik moet draaien, is dat windows server, linux, unix?
  
• Waar hangt de grootte van de schijf vanaf?
  
• Snelheid van de processor... Dual?

Misschien is dit wel een nieuwe toevoeging aan de FAQ die nog in dit topic moet komen :P

[willemj]

Ik zal me eens buigen over een faq als er wat vrije tijd over is (geloof dat de andere heren zich nogal verkeken hebben op de hoeveelheid tijd die daarvoor nodig is :))

 

Ik denk dat je iets verder moet kijken naar je data en hoe deze gebruikt gaat worden.

 

Je kunt een aantal databases bijvoorbeeld clusteren (twee servers die om en om gebruikt worden zonder dat de gebruiker dit merkt) Of en hoe de database ondersteunt kan je keuze al makkelijker maken. Als de ene database 10 minuten achterloopt kan dit voor je applicatie vrij vervelend zijn (gebruiker 1 ziet wat anders dan gebruiker 2)

 

Als de applicatie altijd beschikbaar moet zijn moet je ook kijken naar de mogelijkheden van failover. Als de ene server kapot gaat dan moet de andere het overnemen zonder dataverlies. Ook hier verschilt de ondersteuning per database.

 

Hoe belangrijk is data integriteit voor je applicatie. Als het voornl. gaat om ruwe data (hits van een website o.i.d.) is mysql een prima database. Heb je tabellen aan elkaar gelinkt en moet die link altijd gegarandeerd zijn dan moet je vooral wegblijven bij mysql. Idem voor transacties; ga je een aantal queries uitvoeren die van elkaar afhankelijk zijn en of allemaal of geen van allen uitgevoerd moeten worden dan heb je transactie support nodig.

 

Als je op basis van dit soort informatie een keus voor je database hebt gemaakt zou ik eens gaan kijken naar welke hardware je nodig hebt.

 

[NederWeb]

De keuze op zich hangt van een aantal factoren af, die ik hier niet genoemd zie worden.

De keuze van het platform zelf hangt ook van de te gebruiken SQL database af.

Bijvoorbeeld, als je MS SQL moet gebruiken, dan ontkom je niet aan Windows (Server).

Als je vrij bent in de keuze van de DBM, dan zou je idd kunnen overwegen om een Linux, of misschien zelfs bij voorkeur FreeBSD te gebruiken, dat bespaart je wat licensie kosten, wat je weer kan steken in betere hardware ;)

De grote van de schijf hangt uiteraard af van de hoeveelheid data die je er op kwijt wilt.

Aangezien een Database gebruik maakt van de harde schijf om de data op op te slaan, is het aan te raden om niet te bezuinigen op dat gedeelte.

Een ideale situatie zou zijn een aparte systeem schijf, en een RAID configuratie voor de (SQL data), voor de ultieme snelheid gebaseerd op SCSI, hoewel dat tegenwoordig met de Ultra ATA niet zo heel veel meer uitmaakt, qua prijs/prestatie.

 

Qua snelheid van de CPU, zoals altijd, hoe sneller hoe beter, Dual nog beter, maar wel afhankelijk van de snelheid/configuratie van de schijven, en uiteindelijk ook van de toepassing, worden er moeilijke query's gedaan, of zijn het simpele fetch opdrachten.

 

En plaats er veel, heel veel geheugen in, met goede cache instellingen op de DBM geeft dat veel snelheidswinst.

 

 

 

[Wessels - IT Projectmanager]

Als je op basis van dit soort informatie een keus voor je database hebt gemaakt zou ik eens gaan kijken naar welke hardware je nodig hebt.

 

Dus met andere woorden Willem, zou ik eerst moeten weten welke soort database ik ga gebruiken en dan naar de systeemeisen. Ik kan me dat wel voorstellen. Ik denk aan SQL, dit zal niet MySQL zijn Nederweb ;) maar bijvoorbeeld SQL server 2000, omdat die denk ik voldoende is voor de gegevens. Ik zeg er bij dat het om gigantisch veel data gaat en dat er veelvuldig word geupdate door het systeem zelf, automatisch. Een aantal keer in een uur zal een link worden gemaakt met de database op afstand en die zal worden geupdate met gewijzigde gegevens in die database.

 

Verder denk ik eraan om twee serversneer te zetten in een mirror om bij uitval toch nog te beschikken over de gegevens.

[NederWeb]

Ik zat totaal niet te hinten naar MySQL, hoewel leuk en snel voor veel doeleinden, niet altijd even ideaal.

 

Ikzelf ben nogal gecharmeerd van Oracle, hoewel ik besef dat niet iedereen in de gelegenheid is om de developer license te kunnen gebruiken ;)

 

MS SQL is ook heel goed, maar dat bepaals direct je OS, en het krikt gelijk je kosten een stuk op. Wat betreft Open Source, er zijn meer Open Source DMB's dan alleen MySQL...

[willemj]

Ik denk aan SQL, dit zal niet MySQL zijn Nederweb ;) maar bijvoorbeeld SQL server 2000, omdat die denk ik voldoende is voor de gegevens. Ik zeg er bij dat het om gigantisch veel data gaat en dat er veelvuldig word geupdate door het systeem zelf, automatisch.

 

Over welke orde grootte hebben we het? 10-100 gig, 100-1000gig, 1-5 terra? Gigantisch betekend voor iedereen wat anders.

[R.I.P. - Benm]

Gigantisch is inderdaad een nogal relatief begrip... een tabel met 10 kolommen en een miljoen records kan een gigantische bak informatie lijken, maar is prima te stallen op een simpele mysql db op je thuispc.

 

Wat je uiteindelijk moet hebben hangt van veel factoren af, niet alleen van de data zelf. Vooral het gebruikspatroon is belangrijk, maar ook eisen aan integriteit/betrouwbaarheid en ondersteuning voor features zoals transacties en locking.

 

Het lijkt me eigenlijk het beste je te laten adviseren door degene die de software bouwt, die heeft meer inzicht in wat er nodig is dan de meeste anderen.

[NederWeb]

10 kolommen en een miljoen records is niets.

Afhankelijk van hoeveel data of karakters er in elke cel komen uiteraard, heb je te maken met in mijn geval ongeveer 400 MB voor 5 miljoen records.

 

[Rooseboom]

5 miljoen rijen met 400MB is een relatief kleine database die MySQL makkelijk aankan en indien gewenst nu ook MET transactie ondersteuning.

 

MySQL begint bij 50 miljoen rijen met TEXT-velden echt moeite te krijgen en dan nog alleen met updates en vooral deletes.

 

Vergeleken met Oracle en MS zal MySQL in een situatie met vooral selects vergelijkbaar en misschien wel beter scoren (select is waar mySQL voor is gemaakt). Daarnaast is het een volledig ander prijskaartje

[willemj]

Zo, hebben we in ieder geval vastgesteld dat de keuze van server/database niet zomaar te beantwoorden is en dus misschien wel een frequent gestelde vraag is maar niet als zodanig te beantwoorden.

 

Ik heb via pm wat details gekregen en een natte vinger rekenmethode voor de omvang gestuurd. Met een beetje geluk kan Nightwalker binnenkort dus een indicatie over de omvang van z'n database geven. Misschien kunnen we op basis daarvan verder discussieren (om te voorkomen dat we al te ver afdwalen in technische gebieden waar de vraagsteller weinig aan heeft :D)

 

@Bishop: je hebt gelijk, de laatste versie(s) van mysql ondersteunen transacties en foreign keys. Zat met m'n hoofd bij shared-hosting-mysql installaties.

 

[R.I.P. - Benm]

Het is inderdaad jammer dat veel hostingbedrijven met oudere versies van mysql blijven zitten, je ziet nog steeds hier en daar 3.x... en dat zorgt ervoor dat je als ontwikkerlaar veel nieuwe features niet goed kunt gebruiken als iets compatible moet blijven met allerlei servers.

 

Als je je eigen server draait is het uiteraard geen probleem, dan kun je een passende installatie doen met een recente versie en eventueel benodigde extra's.

[Anoniem6]

Nog even over het OS: onthoud ook dat het iets moet zijn waar jij (of wie het spul ook gaat beheren) genoeg verstand van heeft.

Ik ga er van uit dat je er allemaal wel mee om kan gaan (gezien de rest van je post(s), maar toch); dat is wel de belangrijkste factor eigenlijk.

Verder natuurlijk ook de DB die je kiest, inderdaad, MS SQL draait nu éénmaal lastiger op FreeBSD dan op Windows Server 2003 ;)

 

Nu ja, denk dat het toch wachten wordt op wat meer informatie - maar ga in ieder geval (voor de keuze van het OS na) of er wel genoeg kennis in huis is om het te beheren.

[Wessels - IT Projectmanager]

Over welke orde grootte hebben we het? 10-100 gig, 100-1000gig, 1-5 terra? Gigantisch betekend voor iedereen wat anders.

 

Met hulp van Willemj kan ik nu zeggen hoe groot deze database zal zijn. Thanks WillemJ, een reus erbij :D

 

Omdat we op kleinere schaal beginnen in eerste instantie zullen we, met behulp van de "formules" van Willem, ruim 250 MB nodig hebben. Dit kan schommelen tussen 250 MB en 300 MB. 8)

 

Met andere woorden we hebben het hier niet over een super grootte database. Echter wanneer we gaan uitbreiden heb ik het wel over een max. van 250 * factor 10 = 2,5 GB. Ik weet het das ook niet groot maar toch...

 

We kunnen veel meer met de database die we opzetten, maar ja in wat voor tijdsbestek weet ik niet precies. Ik schat dat we over een jaar of anderhalf al met een factor 5 zijn toegenomen, dus komen we net onder de 1,5 gig.

 

Wat denken jullie nu hiervan? beginnen met 250 a 300 MB en uitlopen tot 1,5 gig binnen een jaar of anderhalf met een max van 3 GB waarschijnlijk? ???

 

Toevoeging:

WillemJ wees mij nog even op het feit dat ik ook nog het aantal transacties zou moeten noemen. ik kan daarover niet precies zijn, maar zal toch een richting proberen te geven.

Ik denk volgens de berekeningen aan een 150 miljoen transacties per dag. Daarbij moet ik zeggen dat de database met protocollen gekoppeld is aan andere databases, zo'n 15 in de eerste fase, en naar alle waarschijnlijkheid real time veranderingen zal gaan maken in de database. Dus als er iets verandert in een gekoppelde database, dan zal onze database dit bijna meteen aan gaan passen.

 

Oh ja en het aantal records zullen in het begin zo'n 450.000 zijn in totaal. Er zullen zo'n 8 tabellen in de database te vinden zijn.

[BlueMelon]

Vergeet ook postgresql niet!

 

http://www.postgresql.org/

 

MySql, postgresql draaien zowel onder linux als windows.

 

[Zaphod]

Vergeet ook postgresql niet!

 

http://www.postgresql.org/

 

MySql, postgresql draaien zowel onder linux als windows.

 

Inderdaad! En PostgreSQL kan zich zeker meten met de commerciele databases qua functionaliteit en snelheid!

 

Overigens kan ik je van harte aanraden om voor een Linux of FreeBSD oplossing te gaan. Je zult hiermee meer performance uit je machine persen dan met Windows (alhoewel MS SQL lang niet slecht schijnt te zijn). Bovendien is niet alleen goedkoper in aanschaf (licentiekoste = nul) maar ook goedkoper in beheer. Remote beheer is met Linux / BSD ontzettend simpel en goed te doen. Je kunt -zelfs met een verbinding via een modem ofzo- nog steeds alles doen wat je moet doen.

 

Wat betreft de grootte van de database: dit lijkt me niet schrikbarend. Het is echter wel zaak dit goed te laten optimaliseren door een ervaren Database goeroe. Dit kan je een factoor 100 in performancewinst opleveren, alleen al door het leggen van goeie indexes en dergelijke.

 

Als je eens wilt praten over de mogelijkheden van Open Source oplossingen, zoals Linux en FreeBSD, of wat meer info over wat voor soort hardware je dan zou kunnen gebruiken, bel me gerust eens op of stuur een emailtje.