MySQL database server met Opterons

[Verwijderd]

Ik heb een paar vragen betreffende een nieuw systeem wat mogelijk gekocht gaat worden voor een online database.

De database bestaat uit meer dan 3 milioen records waaronder veel grote records(MySQL). De database is al zoveel mogelijk geoptimaliseerd voor een zo hoog mogelijke snelheid. De server waar het nu op draait is een pentium 4 3Ghz met 2GB gebeugen en met een raidsysteem met 15.000 rpm schijfen.

Maar met het oog op de toekomst moet er een nieuwe server komen en nu dachten wij aan een dual opteron systeem met rond de 8 a 10 GB geheugen zodat de hele database + indexen in het geheugen kan. Dit systeem word dan alleen gebruikt voor de searches en de oude voor de rest.

Mijn vraag is nu of dit een grote snelheidswinst zal betekenen. En zo ja komt dit dan doorda het 64bits draait of door het vele geheugen? Het systeem zou uiteraard oplinux 64 draaien met MySQL 64.

[elevator]

Dit al gezien? http://www.tomshardware.com/cpu/20030422/opteron-17.html

[McMiGHtY]

Zo te zien kan je beter voor een Dual Xeon gaan

[Verwijderd]

aangezien deze server puur voor zoeken gebruikt gaat worden lijkt mij de opteron het snelst, of ben ik nou scheel ? ik heb gekeken bij de Database test.


edit:
een andere vraag die ik heb is hoe zit het met het geheugen op een dual systeem... aangezien er een eigen databse driver word gemaakt waardoor alles in het geheugen kan worden geplaatst. Wij denken dat wanneer alles in het geheugen draait dit een erg grote performence boost moet geven. Alleen hoe werkt dit met een dual systeem omdat elke processor zijn eigen geheugen heeft? kan 1 proccesor allegeheugen banken aanspreken?

[ Voor 61% gewijzigd door Verwijderd op 22-06-2003 12:40 ]

[Predator]

McMiGHtY schreef op 22 June 2003 @ 11:53:
Zo te zien kan je beter voor een Dual Xeon gaan

Waar zie jij dat dan ?

In de select & insert benches is er toch een duidelijk verschil.
Ik heb zelf mijn bedenkingen bij het nut/waarde van die alter table test.

---

Denk aub de volgende keer na over een wat betere titel.

[ Voor 13% gewijzigd door Predator op 22-06-2003 13:34 . Reden: woordje vergeten :/ ]

[ACM]

McMiGHtY schreef op 22 June 2003 @ 11:53:
Zo te zien kan je beter voor een Dual Xeon gaan

Hoezo? Omdat die sneller de alter-tables verwerkt

Verwijderd schreef op 22 June 2003 @ 11:41:
Maar met het oog op de toekomst moet er een nieuwe server komen en nu dachten wij aan een dual opteron systeem met rond de 8 a 10 GB geheugen zodat de hele database + indexen in het geheugen kan. Dit systeem word dan alleen gebruikt voor de searches en de oude voor de rest.

Dus je wilt _en_ een (veel) snellere machine _en_ de database opsplitsen?
Heeft het opsplitsen van je database niet een aantal grote nadelen? (zoals het openen van twee connecties naar twee databaseservers per applicatie-run)?

Mijn vraag is nu of dit een grote snelheidswinst zal betekenen. En zo ja komt dit dan doorda het 64bits draait of door het vele geheugen? Het systeem zou uiteraard oplinux 64 draaien met MySQL 64.

De (dual-)opteron zal zeker sneller zijn dan die P4 server van je.
Al is het alleen maar omdat je er enorm veel geheugen in wilt gooien en de 64bits versie van je OS/mysql daar ook een stuk beter mee overweg kunnen.

Maar de opteron is sneller (op 32bits) en het 64bits rekenen is in principe maximaal 2x zo snel als een 32bits berekening (niet dat dat in de praktijk zo is )

Verwijderd schreef op 22 June 2003 @ 12:10:
een andere vraag die ik heb is hoe zit het met het geheugen op een dual systeem... aangezien er een eigen databse driver word gemaakt waardoor alles in het geheugen kan worden geplaatst. Wij denken dat wanneer alles in het geheugen draait dit een erg grote performence boost moet geven. Alleen hoe werkt dit met een dual systeem omdat elke processor zijn eigen geheugen heeft? kan 1 proccesor allegeheugen banken aanspreken?

't Is dat de Opteron een NUMA-architectuur gebruikt, maar in principe hebben processoren geen "eigen geheugen" in een SMP-systeem hoor
En uiteraard kunnen alle processoren al het geheugen aanspreken, alleen zal het wel (iets) sneller zijn als het geheugen dat de opteron aanspreekt in zijn eigen "deel" staat
Of je je daar druk om moet maken? Lijkt me niet -> dat zit dus wel goed.

Btw, over wat voor searchengine hebben we het hier? Want fulltext-searches is, imho, niet iets waar mysql in uitblinkt. Wat vooral de reden is dat we hier op GoT er van af gestapt zijn en xapian zijn gaan gebruiken voor het fulltext-searchen.

[ Voor 6% gewijzigd door ACM op 22-06-2003 12:52 ]

[jochemd]

McMiGHtY schreef op 22 June 2003 @ 11:53:
Zo te zien kan je beter voor een Dual Xeon gaan

Jij denk dat een benchmark met maximaal 1 GB RAM (wat met 32 bit geadresseerd kan worden) representatief is voor een systeem met 10 GB RAM (waarbij Xeons met PAE moeten gaan werken omdat het niet met 32 bit geadresseerd kan worden maar de Opterons nog steeds native werken)?

[Verwijderd]

wij gebruiken wel full text search maar we hebben een soort eigen dictionary tables gemaakt waardoor het wel snel gaat.

[ACM]

Verwijderd schreef op 22 June 2003 @ 14:01:
wij gebruiken wel full text search maar we hebben een soort eigen dictionary tables gemaakt waardoor het wel snel gaat.

Als je op 3 termen zoekt, krijgen jullie dan queries ala:

code:

select ... 
from 
  zoektabel as A
   straight_join zoektabel as B using (documentid)
   straight_join zoektabel as C using (documentid)
where 
A.term = 'term1'
AND
B.term = 'term2'
AND
C.term = 'term3'

In mijn ervaring zijn dat soort queries relatief sloom op mysql en als je op 1 term zoekt is dat iets trager dan op 2 termen zoeken, maar op 3 of meer termen zoeken is weer trager dan op 2 termen...

MySQL's eigen fulltext search kan daar geloof ik wel wat beter mee overweg, maar de beperkingen die mysql ons oplegde zorgden ervoor dat we toch overstapten op een engine die ervoor ontwikkeld is, ipv een engine die er enigszins geschikt voor is

Anyway, dat is nogal offtopic verder

jochemd schreef op 22 June 2003 @ 13:59:
(waarbij Xeons met PAE moeten gaan werken omdat het niet met 32 bit geadresseerd kan worden maar de Opterons nog steeds native werken)?

Sterker nog, mysql zal in zo'n setting maar 2 tot 4GB memory kunnen krijgen... Bij linux is dat default maximaal 3GB en als je een buggy glibc hebt en innodb gebruikt (geloof dat ze dat in de context van mysql-innodb allemaal zijn) is dat maximum zelfs effectief slechts 2GB op een 32bits platform...

[ Voor 22% gewijzigd door ACM op 22-06-2003 14:43 ]

[Femme]

Heb je deze benchmarks van Ace's Hardware al gezien? De dual Opteron 1,8GHz is hier gemiddeld 30 procent sneller dan de dual Xeon 2,8GHz (op 32-bit Linux):

http://www.aceshardware.com/read.jsp?id=55000261

64-bit Linux en MySQL zal 10 tot 20 procent sneller zijn vanwege het dubbele aantal registers dat beschikbaar is in AMD64-modus.

PAE in combinatie met MySQL kan alleen onder Windows gebruikt worden. Windows en MySQL is niet echt een ideale combinatie.

[PolarBear]

Dit is wellicht enigszins off topic maar is het ook niet goed eens kritisch te kijken of een andere DB niet beter geschikt is voor het werk dat je nu doet ?

[jochemd]

Femme schreef op 22 June 2003 @ 17:28:
PAE in combinatie met MySQL kan alleen onder Windows gebruikt worden. Windows en MySQL is niet echt een ideale combinatie.

Zelfs als MySQL geen gebruik kan maken van PAE kan het OS dat wel, en het OS kan ook cachen. Misschien iets minder effcient dan MySQL, maar toch nog wel een heel stuk sneller dan een harddisk.

[Verwijderd]

hier wat uileg

We hebben een database met beschrijvingen van boeken. Website bezoekers
kunnen hierin zoeken naar allerlei criteria, bijvoorbeeld woorden in de titel veld,
woorden in de auteur veld, jaar van uitgave, etc. Om woorden te kunnen zoeken
zou het te traag gaan om een 'full-scan' uit te voeren. De fulltext index van
MySQL werkt niet ideaal. We hebben dus tabellen gemaakt voor elk veld dat
doorzocht moet worden, gevuld met alle voorkomende woorden. Elk woord
heeft een uniek nummer. Er is een tweede collectie tabellen met verwijzingen
tussen de woorden tabellen en de boeken tabel. Bijvoorbeeld: In de woorden
tabel staat het woord "road" met als woord nummer 1234. Dit woord komt
voor in boek nummer 5678. In de koppel tabel staat dus een record met deze
inhoud:

WordNumber = '1234', BookNumber = '5678'

Er zijn dus meerdere records per boek aanwezig in de koppel tabel. De grootste
koppel tabel bevat 80 miljoen records. Deze tabellen worden automatisch
bijgehouden als boeken worden toegevoegd of verwijderd.

Als iemand een query doet, zoekt het systeem eerst de bijbehorende WordNumber
waarden. Vervolgens doet het een query dat er ongeveer zo uit ziet:

SELECT
B.BookNumber
FROM
books AS B,
authorlist AS A1,
authorlist AS A2,
keywordlist AS K1
WHERE
A1.WordNumber = 7631264 AND
A1.BookNumber = B.BookNumber AND
A2.WordNumber = 4582743 AND
A2.BookNumber = B.BookNumber AND
K1.WordNumber = 4354534 AND
K1.BookNumber = B.BookNumber
LIMIT 0,50

Hier wordt een query uitgevoerd waar de bezoeker 2 woorden in de auteur
veld zoekt, en 1 woord in de keywords veld. De koppel tabellen zijn zo
geindexeerd dat het efficient deze ranges kan selecteren.
Nou is deze zoekmethode vrij snel, maar het kan sneller. MySQL doet
namelijk altijd een full scan op de kleinste sub-query. Het zou sneller
gaan als het een 'sort-merge-join' algoritme toepast. Dit is mogelijk omdat
alle resultaten van de sub-queries al gesorteerd zijn op BookNumber.
In het bovenstaande voorbeeld worden dus 3 lijsten van BookNumber
waarden gemerged op zo'n manier dat alleen de BookNumber waarden
overblijven die in alle 3 de sub-lijsten voorkomen.
We zijn nu de source van MySQL aan het aanpassen zodat deze algoritme
wordt toegepast. De eerste resulaten laten al zien dat in ons geval het aantal
index reads per query gemiddeld 200 is i.p.v. 30.000 (!). Het is dus veel sneller
geworden. Ik heb MySQL hierover gemaild, maar ze zijn niet zo geintreseerd
om dit algoritme standaard in hun distributie in te bouwen ("te veel werk"
zeggen ze).

[ACM]

Verwijderd schreef op 23 juni 2003 @ 11:55:
Nou is deze zoekmethode vrij snel, maar het kan sneller. MySQL doet
namelijk altijd een full scan op de kleinste sub-query.

Dat was inderdaad wat ik bedoelde

Het zou sneller
gaan als het een 'sort-merge-join' algoritme toepast. Dit is mogelijk omdat
alle resultaten van de sub-queries al gesorteerd zijn op BookNumber.
In het bovenstaande voorbeeld worden dus 3 lijsten van BookNumber
waarden gemerged op zo'n manier dat alleen de BookNumber waarden
overblijven die in alle 3 de sub-lijsten voorkomen.

En als je nu dus in je bovenstaande query nog wat statements toevoegd (bijv omdat iemand op 4 of 5 termen zoekt) wordt het nog weer slomer, althans in een simpele test bij mij. 1, 2, 3 termen werd steeds sneller en 4 of 5 was weer slomer.

We zijn nu de source van MySQL aan het aanpassen zodat deze algoritme
wordt toegepast. De eerste resulaten laten al zien dat in ons geval het aantal
index reads per query gemiddeld 200 is i.p.v. 30.000 (!). Het is dus veel sneller
geworden. Ik heb MySQL hierover gemaild, maar ze zijn niet zo geintreseerd
om dit algoritme standaard in hun distributie in te bouwen ("te veel werk"
zeggen ze).

Je zou nog naar postgresql kunnen kijken, die is met complexere queries wel wat intelligenter en vlotter dan mysql en kent iig ook zaken als mergejoins (ook/juist op indices meen ik). jochemd kan je er vast meer over vertellen als je daar vragen over zou hebben

En bovenstaande is dus de reden dat we hier vanuit got naar een niet-sql oplossing zijn gaan zoeken en bij xapian uitkwamen

[igmar]

Femme schreef op 22 juni 2003 @ 17:28:
64-bit Linux en MySQL zal 10 tot 20 procent sneller zijn vanwege het dubbele aantal registers dat beschikbaar is in AMD64-modus.

En je hebt een veel grotere (virtual) address-space, er even vanuitgaande dat de ia64 architectuur de ia32 beperkingen kwijt is.

PAE in combinatie met MySQL kan alleen onder Windows gebruikt worden. Windows en MySQL is niet echt een ideale combinatie.

Ook onder Windows is je max address-space 4 GB.

[igmar]

Verwijderd schreef op 22 June 2003 @ 11:41:
Maar met het oog op de toekomst moet er een nieuwe server komen en nu dachten wij aan een dual opteron systeem met rond de 8 a 10 GB geheugen zodat de hele database + indexen in het geheugen kan. Dit systeem word dan alleen gebruikt voor de searches en de oude voor de rest.

Koop een 64 bits machine, de ia32 architectuur kan niet met > 4 GB overweg. Zelfs met PAE is je addressspace 32 bits, wat dus betekend dat je process nooit meer dan 4 GB geheugen in gebruik kan hebben (en vanwege de 3:1 split betekend dit zelfs in de praktijk 3 GB).

[ACM]

igmar schreef op 23 June 2003 @ 13:37:
Koop een 64 bits machine, de ia32 architectuur kan niet met > 4 GB overweg. Zelfs met PAE is je addressspace 32 bits, wat dus betekend dat je process nooit meer dan 4 GB geheugen in gebruik kan hebben (en vanwege de 3:1 split betekend dit zelfs in de praktijk 3 GB).

Zijn vraag is dan ook of het echt beter is

Btw, bij windows is/was die split toch 2:2 ?

[Verwijderd]

igmar schreef op 23 June 2003 @ 13:35:
En je hebt een veel grotere (virtual) address-space, er even vanuitgaande dat de ia64 architectuur de ia32 beperkingen kwijt is.

Pas op hoor, IA32 en IA64 is Intel. Het gesprek gaat hier over AMD, welke x86 en x86-64 als architecturen heeft. Even om misverstanden te voorkomen

[Femme]

InnoDB kan onder Windows op 32-bit systemen met meer dan 4GB geheugen mbv Address Windowing Extensions tot 64GB gebruiken voor de buffer pool. Op die manier kun je toch iets nuttigs doen met het geheugen boven 4GB, hoewel het trager zal zijn dan wanneer al het geheugen direct aangesproken kan worden.

Casemaster heeft hier niets aan aangezien hij waarschijnlijk MyISAM tables wil gebruiken. Met de grootte van zijn database kan ik me voorstellen dat hij 8GB tot 10GB geheugen wil gaan gebruiken. Alleen al de indices van z'n koppeltabellen zullen enorm zijn. Die indices wil je zeker in RAM hebben.

MySQL is zonder die AWE-zut van InnoDB beperkt tot een proceslimiet van 2GB, wat eigenlijk al te weinig is voor de Casemaster z'n toepassing. Reden voor die 2GB limiet:

The Mysql binary distribution for IA32-linux is statically linked with
glibc. glibc malloc limits memory allocations to 2GB, which means that a
buffer in mysql can't grow beyond 2GB. This is due to some paranoia in
glibc malloc - they don't rely on the size to be an unsigned int - which
limits the size to 2^31 on any 32-bit platform.

Meer info hier .

De Opteron is de meest elegante en betaalbare oplossing voor je probleem.

[elevator]

ACM schreef op 23 juni 2003 @ 13:42:
Btw, bij windows is/was die split toch 2:2 ?

http://support.microsoft....aspx?scid=kb;EN-US;283037

Als je PAE niet enabled is het ofwel 2:2 of wel 1:3 (afhankelijk van een kernel parameter)

[ACM]

elevator schreef op 24 juni 2003 @ 13:27:
[...]
http://support.microsoft....aspx?scid=kb;EN-US;283037

Als je PAE niet enabled is het ofwel 2:2 of wel 1:3 (afhankelijk van een kernel parameter)

Apart verhaaltje over die /3GB switch trouwens, als je meer dan 16GB hebt kan ie maar tot 16GB gebruiken. Effectief dus 4x3GB = 12GB.
Als je die niet meegeeft krijg je de 2:2 split -> tot 64GB = max 32GB effectief voor applicaties.

Gelukkig wordt de rest (die max 4GB of die max 32GB) wel voor zaken als diskcache enzo gebruikt. Maar wat ik me dan afvraag is of ie wel _al_ die 32GB voor diskcache kan gebruiken of dat ie 16x 2GB max neemt?? (aannemend dat er 64GB in de doos zou zitten met dus 16x2:2 )
Zelfde geldt trouwens voor linux natuurlijk

anyway, met de opteron heb je daar geen last van.

[igmar]

Verwijderd schreef op 23 June 2003 @ 13:42:
Pas op hoor, IA32 en IA64 is Intel. Het gesprek gaat hier over AMD, welke x86 en x86-64 als architecturen heeft. Even om misverstanden te voorkomen

Klopt, ik ben slecht in termen Voor AMD geldt het verhaal echter ook, je virtual address space blijft ook met PAE 4 GB. Wil je wat groters : een 64 bits doos kopen.

[Femme]

En een Opteron is een 64-bit doos . Je hebt alleen nog 64-bit Windows (waarvan de AMD64-port momenteel beta is) nodig om in Windows gebruik te maken van >32-bit adressering.

[igmar]

Femme schreef op 23 juni 2003 @ 13:50:
InnoDB kan onder Windows op 32-bit systemen met meer dan 4GB geheugen mbv Address Windowing Extensions tot 64GB gebruiken voor de buffer pool.

PAE heeft een performance hit : Elke wijziging aan de pgd (page global directory) vereist dat je je TLB flushed. D'as niet zo erg als een page fault, aangezien de page tables in geheugen staan. Verder blijf je met het feit zitten dat je alles boven de 4 GB met een window moet addresseren : wil je een andere 4 GB zien heb je een ander window nodig.

Op die manier kun je toch iets nuttigs doen met het geheugen boven 4GB, hoewel het trager zal zijn dan wanneer al het geheugen direct aangesproken kan worden.

Idd. Geen idee wat je aan snelheid precies inlevert, ik heb geen machines met > 4GB liggen

Casemaster heeft hier niets aan aangezien hij waarschijnlijk MyISAM tables wil gebruiken. Met de grootte van zijn database kan ik me voorstellen dat hij 8GB tot 10GB geheugen wil gaan gebruiken. Alleen al de indices van z'n koppeltabellen zullen enorm zijn. Die indices wil je zeker in RAM hebben.

MySQL is zonder die AWE-zut van InnoDB beperkt tot een proceslimiet van 2GB, wat eigenlijk al te weinig is voor de Casemaster z'n toepassing.

[RvdH]

Inmiddels hebben we dus de sort-merge-join methode ingebouwd, en alles is daardoor wel iets sneller geworden.

De reden dat we de database willen/kunnen splitsen, is omdat we onze klanten van tevoren vertellen dat het 24 uur kan duren voordat veranderingen zichtbaar worden in de database. Dat is dus niet zo erg. Het idee is om boeken-updates aan de ene machine te laten gebeuren, en dan 1 a 2 maal per etmaal de dbfiles te kopieren naar de search-server, de dual Opteron.

We zijn afgelopen weekend naar LinuxTag geweest waar we de developers van MySQL en PHP hebben gesproken, frappant was dat 1 van de MySQL guys zei dat MySQL op 64 bit absoluut niet aan te raden was, terwijl Sergei (devver van de fulltext-search) juist beweerde dat het goed mogelijk was.

Nu zitten we te overwegen, na een presentatie over de SQLite API, om SQLite te gebruiken voor de searches, maar dat moeten we nog maar even uittesten. Eigenlijk zijn we een beetje huiverig om af te stappen van MySQL omdat we daar erg veel kennis over in huis hebben, als we gaan overstappen moeten we weer een heel andere techniek ons eigen maken..

[ Voor 10% gewijzigd door RvdH op 15-07-2003 14:15 ]

[djluc]

Er zijn dus meerdere records per boek aanwezig in de koppel tabel. De grootste
koppel tabel bevat 80 miljoen records. Deze tabellen worden automatisch
bijgehouden als boeken worden toegevoegd of verwijderd.

Op welk moment doe je dit want hier kan misschien ook nog wat aan performance verbeterd worden.

Eigenlijk zijn we een beetje huiverig om af te stappen van MySQL omdat we daar erg veel kennis over in huis hebben, als we gaan overstappen moeten we weer een heel andere techniek ons eigen maken..

Je moet gewoon een lijstje maken met de plussen en minnen om over te stappen. Dan weet je meteen of het de moeite waard is.

De reden dat we de database willen/kunnen splitsen, is omdat we onze klanten van tevoren vertellen dat het 24 uur kan duren voordat veranderingen zichtbaar worden in de database.

Het is natuurlijk wel mooier om gewoon met een realtime database te werken, dat is toch weer een service naar de klant toe.

Is het een internationale organisatie of alleen in bijvoorbeeld Nederland? Als dit namelijk zo is dan heb je waarschijnlijk toch een flinke performance dip in je systeem zitten als je de gegevens door gaat sturen.

[RvdH]

djluc schreef op 15 July 2003 @ 14:41:
[...]
Op welk moment doe je dit want hier kan misschien ook nog wat aan performance verbeterd worden.

Op elk moment van de dag.
Mensen uploaden databasebestanden (flat-file) naar ons, die wij uitpluizen en er SQL queries van maken. Eerst was het zo dat elke nacht een proces werd gestart die elk ge-upload bestand aan een php bestand doorspeelde, maar nu is het zo dat er een queue wordt bijgehouden van de geuploade bestanden, en deze draait continue.
Voordeel daarvan is dat een geupload bestand dikwijls direct aan de beurt komt, en ze worden FIFO verwerkt.

Het is natuurlijk wel mooier om gewoon met een realtime database te werken, dat is toch weer een service naar de klant toe.

Dat is onhaalbaar. Het is wel zo dat als klanten klantinformatie veranderen dat dat direct doorgevoerd wordt, maar het is niet praktisch of nuttig of logisch om de boekendefinities realtime te updaten.

Is het een internationale organisatie of alleen in bijvoorbeeld Nederland? Als dit namelijk zo is dan heb je waarschijnlijk toch een flinke performance dip in je systeem zitten als je de gegevens door gaat sturen.

Internationaal, maar het meerendeel van de bezoekers komt uit Amerika, en dat geeft genoeg speling om 's ochtends of 's nachts veilig de db te verversen.

[jochemd]

strlen schreef op 15 July 2003 @ 14:13:
Nu zitten we te overwegen, na een presentatie over de SQLite API, om SQLite te gebruiken voor de searches, maar dat moeten we nog maar even uittesten.

Waarom verwacht je dat dat sneller is? Betere indexen? Minder overhead? Iets anders? Heb je je al weleens ingelezen over hoe SQLite omgaat met concurrent queries?

Ik zou eerder richting een meer feature complete database gaan kijken dan naar een nog verder uitgeklede.

[RvdH]

jochemd schreef op 15 juli 2003 @ 20:23:
[...]
Waarom verwacht je dat dat sneller is? Betere indexen? Minder overhead? Iets anders? Heb je je al weleens ingelezen over hoe SQLite omgaat met concurrent queries?

Dat lijkt me nogal logisch, SQLite mist alle troep in MySQL die we toch niet gebruiken, juist omdat het zo uitgekleed is, is het zo snel. Zoek maar eens op internet naar tests waarin MySQL vs SQLite staat, SQLite is meestal 2 x zo snel.
SQLite is alleen niet snel met inserts, en omdat het een flock doet op een file voor een insert kun je die ook niet simultaan doen. Maar dat geeft niet, want zoals je natuurlijk gelezen hebt zal deze server alleen gebruikt worden voor selects.

Ik zou eerder richting een meer feature complete database gaan kijken dan naar een nog verder uitgeklede.

Wat voor vreemde logica zit hierachter? Met nog meer features die we toch niet gebruiken wordt het toch alleen maar trager?

[jochemd]

strlen schreef op 16 juli 2003 @ 09:06:

Dat lijkt me nogal logisch, SQLite mist alle troep in MySQL die we toch niet gebruiken, juist omdat het zo uitgekleed is, is het zo snel. Zoek maar eens op internet naar tests waarin MySQL vs SQLite staat, SQLite is meestal 2 x zo snel.

Ik kan eigenlijk geen tests vinden waar meerdere tabellen met miljoen+ records gejoined worden. Heb je linkjes?

Wat voor vreemde logica zit hierachter? Met nog meer features die we toch niet gebruiken wordt het toch alleen maar trager?

Ik heb het niet over features die je niet gaat gebruiken, maar over features die je wel gaat gebruiken. Nu gebruik je een workaround voor een full text index die niet snel genoeg is. Als je een database hebt waar de full text index wel snel werkt is dat misschien wel veel handiger dan te proberen de overhead verder te minimaliseren.

[RvdH]

jochemd schreef op 16 July 2003 @ 12:36:
[...]
Ik kan eigenlijk geen tests vinden waar meerdere tabellen met miljoen+ records gejoined worden. Heb je linkjes?

Nee, die kan ik ook niet vinden, heb het al gevraagd op de SQLite maillist.
Hier staan wel tests: www.sqlite.org/speed.html en een linkje naar een onafhankelijke test(er).

[...]
Ik heb het niet over features die je niet gaat gebruiken, maar over features die je wel gaat gebruiken. Nu gebruik je een workaround voor een full text index die niet snel genoeg is. Als je een database hebt waar de full text index wel snel werkt is dat misschien wel veel handiger dan te proberen de overhead verder te minimaliseren.

Noem mij eens een database waarbij de fulltext search wel goed werkt, en die overige selects verder net zo snel afhandelt als MySQL (en geef die tip meteen door aan tweakers.net, want dat zullen ze wel interessant vinden)? Als je er een kunt vinden, vind ik het heel knap..

[jochemd]

strlen schreef op 18 July 2003 @ 14:05:

Noem mij eens een database waarbij de fulltext search wel goed werkt, en die overige selects verder net zo snel afhandelt als MySQL (en geef die tip meteen door aan tweakers.net, want dat zullen ze wel interessant vinden)? Als je er een kunt vinden, vind ik het heel knap..

Heb je weleens met MS SQL Server full text indexing gewerkt?

[RvdH]

jochemd schreef op 18 July 2003 @ 15:28:
[...]
Heb je weleens met MS SQL Server full text indexing gewerkt?

Nee, wij werken alleen met open source producten. Omswitchen naar MS produkten is *echt* geen optie.

[ Voor 11% gewijzigd door RvdH op 21-07-2003 16:06 ]

[Verwijderd]

Waarom niet? Als je een dual Opteron kunt betalen, en het zo'n grootschalig product is, zijn de licentieprijzen van MSSQL te verwaarlozen.

[RvdH]

Misschien vallen de licentiekosten wel mee, maar de tijd die erin gaat zitten om alles (en dan heb ik het niet over 1 websitetje) om te zetten naar MSSQL-compatible dingen is heel erg veel en dat kost allemaal geld.

Daarbij zou er nog iemand aangenomen worden die verstand heeft van MSSQL/Windows servers, om maar niet te spreken over de mening die mijn baas heeft over Microsoft.

En dan moet je nog een server kopen die MSSQL/Windows snel genoeg draait (minstens net zo snel als MySQL op een P4/2.8), dus dat zullen dan wel Xeons moeten worden, ook geen goedkope oplossing.

Al met al niet zo goedkoop dus, wat je zelf ook had kunnen bedenken.

[ Voor 27% gewijzigd door RvdH op 22-07-2003 15:36 ]