Betere forum performance: DB of FS?

[Olaf van der Spek]

Veel forums gebruiken tegenwoordig PHP/MySQL. Dit is een goede combinatie, maar toch vroeg ik me laatst af wat sneller was (zelf ben ik bezig met C++/MySQL).
Een DataBase of een FileSystem?
De DB manier heeft als voordeel dat je een script taal kunt gebruiken voor de rest van je forum en dat de DB locking regelt. Als nadeel heb je de relatief trage netwerk-link (tenzij je db- en web-server op dezelfde machine werken).
De FS manier heeft dus als voordeel vooral de snelheid waarmee je bij de data kunt.

[MisterData]

Een FS heeft daarbij als nadeel dat je moeilijk over meerdere machines kan verspreiden. Daarom is een database zo handig... Verder is je data denk ik makkelijker querie-baar (vaag woord ) met een database dan met een FS.

[Olaf van der Spek]

Maar ik vraag me dan af of het nog wel nodig is om meerdere servers in te zetten voor een enkel forum.

De enige moeilijke queries voor een FS lijken mij de search queries.

[ Voor 27% gewijzigd door Olaf van der Spek op 22-11-2002 19:44 ]

[gorgi_19]

En de posts per user? Wijzigende usernames? Hoe wil je dit dan oplossen?

[Olaf van der Spek]

Voor de posts/user kun je per user toch een counter bijhouden?
En een user-name kun je toch ook gewoon veranderen?

[Varienaja]

Een FileSystem is eigenlijk ook gewoon een soort database. Speciaal gemaakt om bestandsnamen in terug te kunnen vinden.

Zo staan in FAT-partities de bestandnamen mooi in willekeurige volgorde op een rijtje. Als je in een directory van 1000 bestanden een bepaald bestand zoekt, dan moet dat FS gemiddels 500 bestandsnamen bekijken.

In NTFS staan de bestandsnamen in aflabetische volgorde, en daarom kan je hier een binary search toepasen. In NTFS kan je dus al *veel* sneller je bestandje vinden.

Mocht je op iets anders willen zoeken dat de bestandsnaam, dan ben je fucked, en moet je alle bestanden 1 voor 1 doorzoeken. Je kan namelijk de inhoud van bestanden niet 'indexeren' (hoe graag de indexing-service ook zou willen ). Altans, niet indexeren zoals dat in een database gaat.

Kortom: je kan met een schaar ook prima grasmaaien, en voor hele kleine stukjes gras gaat dat misschien ook sneller dan de 100 meter naar het tuinshuisje heen en weer lopen om de grasmaaier op te halen. Maar eigenlijk ben je gewoon stom bezig

[pjonk]

Als je met een DBMS werkt is wordt het locking gedeelte allemaal automatisch geregeld. Met een filesystem kan dit behoorlijk lastig zijn.

[MisterData]

maw een database is gewoon een bestandssysteem, maar dan uitgebreider. Waarom zou je die 'extra's' dan niet gebruiken?

[Olaf van der Spek]

MisterData schreef op 22 November 2002 @ 20:46:
maw een database is gewoon een bestandssysteem, maar dan uitgebreider. Waarom zou je die 'extra's' dan niet gebruiken?

Omdat die extra's met een nadeel komen: minder performance.

[ Voor 7% gewijzigd door Olaf van der Spek op 22-11-2002 20:52 ]

[whoami]

Een databank is net gemaakt om gestructureerde data te beheren, dus waarom zou je die niet gebruiken?
Een dbms is snel (en gebruikt ook het filesystem, met die nuance dat het DBMS de gegevens geindexeerd gaat gaan opslaan -> dus sneller).
Als jij gewoon puur van het FS wilt gebruik maken, dan zul je zelf alle functionaliteiten die het DBMS biedt (indexeren, relaties, ...) moeten implementeren wil je het minstens zo snel krijgen als een DBMS.

Doorloop maar eens sequentieel een bestand om een bepaalde waarde te zoeken , en vergelijk dat eens met het geindexeerd zoeken.

[ Voor 13% gewijzigd door whoami op 22-11-2002 20:57 ]

[Olaf van der Spek]

whoami schreef op 22 november 2002 @ 20:56:
Een databank is net gemaakt om gestructureerde data te beheren, dus waarom zou je die niet gebruiken?

Zie vorige post.

Een dbms is snel (en gebruikt ook het filesystem, met die nuance dat het DBMS de gegevens geindexeerd gaat gaan opslaan -> dus sneller).
Als jij gewoon puur van het FS wilt gebruik maken, dan zul je zelf alle functionaliteiten die het DBMS biedt (indexeren, relaties, ...) moeten implementeren wil je het minstens zo snel krijgen als een DBMS.

Doorloop maar eens sequentieel een bestand om een bepaalde waarde te zoeken , en vergelijk dat eens met het geindexeerd zoeken.

Maar een DBMS is veel complexer dan nodig voor een forum. Stel dat ik bijvoorbeeld twee files maak om de users relatie te implementeren. De eerste file bevat een int[] met offsets in de tweede file. De tweede file bevat alle user data.
Als ik nu de user data voor een user nodig heb, kost dat maximaal twee (logical) reads. Als ik dit vergelijk met bijvoorbeeld MySQL lijkt het me dat het FS in dit geval wint van de DB.

[pjonk]

Er komen een hoop complicaties bij kijken hoor en naarmate de files groter worden zal de sequentiele benadering steeds trager worden.

[Olaf van der Spek]

JonkieXL schreef op 22 November 2002 @ 21:15:
Er komen een hoop complicaties bij kijken hoor en naarmate de files groter worden zal de sequentiele benadering steeds trager worden.

Welke sequentiele benadering? Files kunnen prima 'random' gelezen worden (zoals ik uitleg in de vorige post).

[Verwijderd]

Stel je hebt een forum database op een filesysteem draaien. Nu komt er een nieuwe user bij, laten we zeggen Henk.

Probleem 1: In de alfabetische lijst van users moet Henk ergens in het midden komen staan aangenomen dat er al flink wat willekeurige usernames in je lijst staan. Dit resulteert in een hoop administratieve rompslomp (data tijdelijk kopiëren etc.) om Henk in het midden van deze lijst te krijgen, om maar niet te spreken over wederzijdse uitsluiting (stel op het zelfde moment wil Pietje zich registreren). Een DBMS regelt deze wederzijdse uitsluiting, en zorgt tevens voor het op een slimme manier plaatsen van Henk in de username lijst.

Probleem 2: Nu Henk zich geregistreerd heeft, zul je ook meteen het bestand van de userstatistieken moeten updaten, het bestand dat de hoeveelheid users bijhoudt, etc. etc. Het mooie van een database is dat er geen redundancy van informatie is, waar je bij een filesystem aanpak wellicht wel snel last van krijgt.

[pjonk]

Natuurlijk kan het. Sterker nog ik heb in Perl ook een forum gebouwd die buiten een DBMS werkt.

Een groot voordeel van een DBMS IMO is dat je SQL kan gebruiken en het daardoor ook heel makkelijk kan porten naar een andere database formaat. Je bent dus een stuk flexibeler.

[Olaf van der Spek]

Verwijderd schreef op 22 november 2002 @ 21:29:
Probleem 1: In de alfabetische lijst van users moet Henk ergens in het midden komen staan aangenomen dat er al flink wat willekeurige usernames in je lijst staan. Dit resulteert in een hoop administratieve rompslomp (data tijdelijk kopiëren etc.) om Henk in het midden van deze lijst te krijgen, om maar niet te spreken over wederzijdse uitsluiting (stel op het zelfde moment wil Pietje zich registreren). Een DBMS regelt deze wederzijdse uitsluiting, en zorgt tevens voor het op een slimme manier plaatsen van Henk in de username lijst.

Ik zou users op user ID sorteren, niet op name. Je hebt inderdaad een write lock op beide files nodig (maar dat heeft de DB ook).

Probleem 2: Nu Henk zich geregistreerd heeft, zul je ook meteen het bestand van de userstatistieken moeten updaten, het bestand dat de hoeveelheid users bijhoudt, etc. etc. Het mooie van een database is dat er geen redundancy van informatie is, waar je bij een filesystem aanpak wellicht wel snel last van krijgt.

Klopt, maar bij een DB heb je ook vaak redundancy. Veel forums houden het aantal posts/user bij terwijl dit ook uit de posts relatie valt af te leiden. Dit wordt gedaan voor hogere performance.

[Olaf van der Spek]

JonkieXL schreef op 22 November 2002 @ 21:33:
Natuurlijk kan het. Sterker nog ik heb in Perl ook een forum gebouwd die buiten een DBMS werkt.

Ik heb er ook een (in C++) en zelfs met seqential access is het nog verassend snel. Maar dat komt omder er maar 6000 berichten in staan.

Een groot voordeel van een DBMS IMO is dat je SQL kan gebruiken en het daardoor ook heel makkelijk kan porten naar een andere database formaat. Je bent dus een stuk flexibeler.

Dat is dus minder flexibel (IMO), want voor een ander FS hoef je helemaal niets te porten.

[ Voor 14% gewijzigd door Olaf van der Spek op 22-11-2002 21:44 ]

[Verwijderd]

Ik denk dat je het zo moet zien: een DBMS is natuurlijk niets meer en niets minder dan een schil om een filesystem heen. In principe is het dus mogelijk om het filesystem als DB te gebruiken, maar je zult er nog altijd extra zaken aan toe moeten voegen, zoals hoe ga je met concurrency om. Je bent dan eigenlijk al bezig met je eigen mini-DBMS. Nadeel: minder features, voordeel: waarschijnlijk betere performance (?). Over dat laatste valt nog te discussiëren overigens, omdat DBMS'en op heel veel vlakken optimaliseren (zowel opslag, als performance).

[whoami]

OlafvdSpek schreef op 22 november 2002 @ 21:38:
[...]

Dat is dus minder flexibel (IMO), want voor een ander FS hoef je helemaal niets te porten.

Al eens een textfile die in Unix gemaakt is op een Windows bak geopend of omgekeerd?

OlafvdSpek schreef op 22 November 2002 @ 21:36:
[...]

Klopt, maar bij een DB heb je ook vaak redundancy. Veel forums houden het aantal posts/user bij terwijl dit ook uit de posts relatie valt af te leiden. Dit wordt gedaan voor hogere performance.

En hoe denk je dat je met behulp van een FS zonder redundante gegevens op een performante manier het aantal posts van een users zult ophalen?

En hoe ga je ervoor zorgen dat je makkelijk een username kunt veranderen als een user dat wil?

Gebruik een DBMS voor wat het gemaakt is: voor het opslaan van gestructureerde data. Een DBMS is daarop gericht en is dus zeker supersnel daarvoor (mits het goed gebruikt wordt).
Als jij puur het FS wilt gebruiken om jouw gestructureerde data op te slaan, ja, dan doe je dat maar....

[ Voor 64% gewijzigd door whoami op 22-11-2002 21:48 ]

[Olaf van der Spek]

Verwijderd schreef op 22 november 2002 @ 21:42:
Ik denk dat je het zo moet zien: een DBMS is natuurlijk niets meer en niets minder dan een schil om een filesystem heen. In principe is het dus mogelijk om het filesystem als DB te gebruiken, maar je zult er nog altijd extra zaken aan toe moeten voegen, zoals hoe ga je met concurrency om. Je bent dan eigenlijk al bezig met je eigen mini-DBMS. Nadeel: minder features, voordeel: waarschijnlijk betere performance (?). Over dat laatste valt nog te discussiëren overigens, omdat DBMS'en op heel veel vlakken optimaliseren (zowel opslag, als performance).

Als je het simpel bekijkt is data uit lokaal RAM of van lokale disks sneller beschikbaar dan uit remote RAM of van remote disks (vooral met een fast-ethernet connectie, maar ook met een gigabit-ethernet connectie).

Misschien dat het aardig zou zijn om eens een read-only prototype te bouwen?

[Olaf van der Spek]

whoami schreef op 22 November 2002 @ 21:45:
Al eens een textfile die in Unix gemaakt is op een Windows bak geopend of omgekeerd?

Ja, via UltraEdit of een text FTP verbinding. Maar als we over performance praten maak ik geen gebruik van text files. Jij wel?

En hoe denk je dat je met behulp van een FS zonder redundante gegevens op een performante manier het aantal posts van een users zult ophalen?

Net als in een DB een full-scan van de messages relatie uitvoeren. Maar als een index in een DB niet als redundant geldt is het niet eerlijk een index in een FS wel als redundant te laten gelden.

[ Voor 7% gewijzigd door Olaf van der Spek op 22-11-2002 21:49 ]

[whoami]

[nohtml]

OlafvdSpek schreef op 22 November 2002 @ 21:49:
[...]
Ja, via UltraEdit of een text FTP verbinding. Maar als we over performance praten maak ik geen gebruik van text files. Jij wel?

Neen, maar als we over performance praten bij structured data, dan gebruik ik geen filesystem maar een databank..... Jij wel?

[Olaf van der Spek]

whoami schreef op 22 november 2002 @ 21:52:
Neen, maar als we over performance praten bij structured data, dan gebruik ik geen filesystem maar een databank..... Jij wel?

Ik ben nu inderdaad bezig met een versie die een DB gebruikt, maar ik vraag me dus serieus af of dat de beste performance geeft.

[whoami]

OlafvdSpek schreef op 22 November 2002 @ 21:54:
[...]

Ik ben nu inderdaad bezig met een versie die een DB gebruikt, maar ik vraag me dus serieus af of dat de beste performance geeft.

Zullen we eens benchmarken?
je neemt een databank met 100000 records die gaat gaan updaten, en je neemt jouw systeem met het FS dat ook 100000 records gaat gaan updaten...
Of je gaat eens een gaan tellen hoeveel posts een user heeft oid....

[Olaf van der Spek]

whoami schreef op 22 November 2002 @ 21:56:
Zullen we eens benchmarken?
je neemt een databank met 100000 records die gaat gaan updaten, en je neemt jouw systeem met het FS dat ook 100000 records gaat gaan updaten...
Of je gaat eens een gaan tellen hoeveel posts een user heeft oid....

Wat wil je precies updaten?
En wil je dat van alle users weten of van slechts een user?

[whoami]

Stel bv dat je wilt weten hoeveel posts een user heeft: in SQL ga je gewoon een SELECT COUNT() doen, en als je database goed ontworpen is en je de juiste indexen gelegd hebt, dan heb je dat resultaat in een fractie van een seconde.
Hoe ga jij dat met bhv het FS system doen en hoelang gaat dat duren?

[.oisyn]

New_York schreef op 22 november 2002 @ 22:14:
Het lijkt me best opwindend om met jou eens te benchmarken

viezerik

ook nog even een nuttige reply:
Ik schat dat een FS systeem sneller is, daar je het precies kunt ontwerpen op je doel: een forum. Een database is een algemenere oplossingen voor datastructuren, maar dat hoeft lang niet altijd de efficientste te zijn (zie bijvoorbeeld het full-text search mankement @ GoT). Ook kennen SQL queries bepaalde limitaties, die bovendien eerst over een netwerkverbinding moeten (das echter een non-argument, dat kan met files net zo het geval zijn, en ze kunnen ook beide op hetzelfde systeem draaien)

[ Voor 58% gewijzigd door .oisyn op 22-11-2002 22:21 ]

[MSalters]

Wat ik me afvraag, hoe efficient is een memory-mapped file? Zolang ik genoeg geheugen heb is het ongetwijfeld sneller dan een DBMS, en zelfs met de grootte van t.net zou je't nog allemaal in het fysieke RAM van een enkele server kunnen stampen (working set ~1G, denk ik). Als je daar net overheen gaat daalt de performance niet onredelijk ( langzaam lopende topics gaan naar file en zo ).
Het enige gevaar is natuurlijk een crash, maar dat lijkt met redelijk te ondervangen. Alleen de posts moeten gesaved worden, en die zijn behoorlijk beperkt. En zelfs als dat met enige vertraging gebeurt raak je hooguit 1 minuut aan posts kwijt.

[Orphix]

Er zijn inderdaad ook genoeg gastenboeken die gebruik maken van textfiles. Je kan CSV zien als een database in een bestand. Tuurlijk kan je er ook een forum omheenmaken.
MAAR .. kijk eens naar de functionaliteit die je er omheen wilt gaan bouwen, je zal zien dat je dan uiteindelijk uitkomt op een (simpele)DBMS.

En ik snap niet helemaal waarom jouw programma sneller gegevens uit een bestand zou kunnen halen dan bv MySQL. Er zijn veel features (bv referentiele integriteit, transactions, user-roles, indexen) die jij misschien oninteressant vindt voor jouw forum. Maar dit hoef je niet te gebruiken, en MySQL zal niet veel langzamer lopen omdat het enkele van deze features niettemin toch ondersteund.

En .oisyn in hoeverre past een 'datastructuur' wel in een FS ? Hierarchische databases?

Maar apart hiervan, waarom zou je niet gaan voor een jaren-doorontwikkelde snelle en efficiente database (MySQL) ?
Software verandert altijd, de eisen aan je software ook. Ik heb liever een database die teveel biedt dan een FS die het precies biedt.

offtopic:
Hey kijk allemaal meer onzinnige gadgets, ik schat nu dat ik zo'n 22% heb aangepast

[ Voor 23% gewijzigd door Orphix op 23-11-2002 01:37 ]

[ACM]

OlafvdSpek schreef op 22 november 2002 @ 21:49:
Net als in een DB een full-scan van de messages relatie uitvoeren. Maar als een index in een DB niet als redundant geldt is het niet eerlijk een index in een FS wel als redundant te laten gelden.

Een tellertje bijhouden is wat anders dan een index gebruiken he?
(maar got gebruikt ook het tellertje, omdat de index alsnog slomer is hier)

OlafvdSpek schreef op 22 november 2002 @ 21:46:
Als je het simpel bekijkt is data uit lokaal RAM of van lokale disks sneller beschikbaar dan uit remote RAM of van remote disks (vooral met een fast-ethernet connectie, maar ook met een gigabit-ethernet connectie).

En waarom zou een database niet in je lokale RAM kunnen zitten?
MySQL cached een grote hoeveelheid data als je dat toelaat hoor en dat zit dan allemaal in je RAM, waarsch sneller toegankelijk dan de data in je file/disk-cache.
(enige nadeel is dat er weer een extra schil is, waardoor het in de praktijk vast niet zoveel sneller, even snel of zelfs langzamer is)

Misschien dat het aardig zou zijn om eens een read-only prototype te bouwen?

Ik denk dat een read/write prototype juist veel interessanter is Maar ook moeilijker te maken.

OlafvdSpek schreef op 22 november 2002 @ 21:54:
Ik ben nu inderdaad bezig met een versie die een DB gebruikt, maar ik vraag me dus serieus af of dat de beste performance geeft.

"De beste", moet je perse de beste?
Een database levert waarschijnlijk voldoende performance. Met een database kan je waarsch beter schalen (multithreading, de optie de database-engine op een andere server te plaatsen en de mogelijkheid je frontend over meerdere servers uit te spreiden).
Maar je c++ oplossing kan best "beter" presteren, tot op zekere hoogte En dan heb je er wel veel meer moeite voor moeten doen.

[Olaf van der Spek]

whoami schreef op 22 November 2002 @ 22:00:
Stel bv dat je wilt weten hoeveel posts een user heeft: in SQL ga je gewoon een SELECT COUNT() doen, en als je database goed ontworpen is en je de juiste indexen gelegd hebt, dan heb je dat resultaat in een fractie van een seconde.
Hoe ga jij dat met bhv het FS system doen en hoelang gaat dat duren?

Dan doe ik een read van de array size van de array die van elke user de posts bijhoudt. Dat kost me twee (logical) reads.

[Olaf van der Spek]

.oisyn schreef op 22 november 2002 @ 22:18:
viezerik

Waarom kan ik de post van New_York niet vinden?

ook nog even een nuttige reply:
Ik schat dat een FS systeem sneller is, daar je het precies kunt ontwerpen op je doel: een forum. Een database is een algemenere oplossingen voor datastructuren, maar dat hoeft lang niet altijd de efficientste te zijn (zie bijvoorbeeld het full-text search mankement @ GoT). Ook kennen SQL queries bepaalde limitaties, die bovendien eerst over een netwerkverbinding moeten (das echter een non-argument, dat kan met files net zo het geval zijn, en ze kunnen ook beide op hetzelfde systeem draaien)

Zo'n non-argument is het niet. Als je forum een bepaalde performance nodig heeft, dan kan het zijn dat je meerdere servers nodig hebt voor de DB manier en maar een server voor de FS manier.

[Olaf van der Spek]

MSalters schreef op 22 november 2002 @ 22:33:
Wat ik me afvraag, hoe efficient is een memory-mapped file?

Dat is inderdaad de hamvraag (en de reden dat ik op de FS idee kwam) ;->

Zolang ik genoeg geheugen heb is het ongetwijfeld sneller dan een DBMS, en zelfs met de grootte van t.net zou je't nog allemaal in het fysieke RAM van een enkele server kunnen stampen (working set ~1G, denk ik). Als je daar net overheen gaat daalt de performance niet onredelijk ( langzaam lopende topics gaan naar file en zo ).
Het enige gevaar is natuurlijk een crash, maar dat lijkt met redelijk te ondervangen. Alleen de posts moeten gesaved worden, en die zijn behoorlijk beperkt. En zelfs als dat met enige vertraging gebeurt raak je hooguit 1 minuut aan posts kwijt.

Wat is de total size van de GoT DB?
Het enige probleem dat ik zie op 32-bit systems is de 2, 3 of 4 GB limiet. Omdat je memory maps gebruikt heb je dus niks aan grotere files.

[Olaf van der Spek]

Orphix schreef op 23 November 2002 @ 01:33:
Maar apart hiervan, waarom zou je niet gaan voor een jaren-doorontwikkelde snelle en efficiente database (MySQL) ?
Software verandert altijd, de eisen aan je software ook. Ik heb liever een database die teveel biedt dan een FS die het precies biedt.

Omdat het forum misschien op deze manier sneller is en je daar ook nog minder hardware voor nodig hebt.

[Olaf van der Spek]

ACM schreef op 23 November 2002 @ 10:23:

[...]

Een tellertje bijhouden is wat anders dan een index gebruiken he?
(maar got gebruikt ook het tellertje, omdat de index alsnog slomer is hier)

Ja, ik denk dat ik me verkeerd heb uitgedrukt (of jij het verkeerd hebt begrepen). Het gaat erom dat het FS zo'n 'query' op precies dezelfde manier kan doen als een DB.

[...]
En waarom zou een database niet in je lokale RAM kunnen zitten?

Dat zou natuurlijk wel kunnen. Maar zit de DB dat? Op GoT niet.

MySQL cached een grote hoeveelheid data als je dat toelaat hoor en dat zit dan allemaal in je RAM, waarsch sneller toegankelijk dan de data in je file/disk-cache.
(enige nadeel is dat er weer een extra schil is, waardoor het in de praktijk vast niet zoveel sneller, even snel of zelfs langzamer is)

[...]

Ik denk dat een read/write prototype juist veel interessanter is Maar ook moeilijker te maken.
[...]

Ja, ;-> Daarom stelde ik RO voor. Maar RW is ook niet zo moeilijk denk ik.

"De beste", moet je perse de beste?

Ja. Het heeft weinig zin een forum te gaan bouwen dat slechter is dan de bestaande forums.

Een database levert waarschijnlijk voldoende performance. Met een database kan je waarsch beter schalen (multithreading, de optie de database-engine op een andere server te plaatsen en de mogelijkheid je frontend over meerdere servers uit te spreiden).
Maar je c++ oplossing kan best "beter" presteren, tot op zekere hoogte En dan heb je er wel veel meer moeite voor moeten doen.

De vraag is dus hoeveel beter het zal presteren.

[Nielsz]

OlafvdSpek schreef op 23 november 2002 @ 12:25:
[...]
Dat is inderdaad de hamvraag (en de reden dat ik op de FS idee kwam) ;->
[...]

Wat is de total size van de GoT DB?
Het enige probleem dat ik zie op 32-bit systems is de 2, 3 of 4 GB limiet. Omdat je memory maps gebruikt heb je dus niks aan grotere files.

Kees schreef op 12 November 2002 @ 16:51:
[

Databasegrootte? niet echt heel interessant, magoed:
615.812 Topics
7.776.494 Messages
57.426 Users

en de backup ervan:
- Grootte op de schijf: 2,4 GB
- Ongecomprimeerd: 6,5 GB
- Ratio: 63.6%

[TheOneLLama]

Een SQL database heeft natuurlijk bepaalde overhead, maar ook bepaalde optimalisaties. Vergeet echter niet dat een filesystem die ook heeft! (en is natuurlijk sterk afhankelijk van welk filesystem je gebruikt) Met name alles maar in losse files steken.

Je kan natuurlijk ook een tussenoplossing overwegen, een niet SQL database zoals Berkeley DB. Ik denk dat je er een hele kluif aan krijgt om jou eigen filesystem based opslag sneller te maken.

[Olaf van der Spek]

6 gb voor 8 miljoen berichten (ongeveer)? Dat is 768 kbyte per bericht. Zelfs als je maar 1 gb voor de berichten neemt kom je nog op 128 kbyte uit. Is dat niet een beetje veel?

Foutje, bedankt. ;-> Dat moet 768 byte zijn en dat is wel 'normaal'.

[ Voor 17% gewijzigd door Olaf van der Spek op 23-11-2002 20:27 ]

[Verwijderd]

Er zijn ook tabellen voor users, catogerieen, fora, bans, etc.

[Olaf van der Spek]

Natuurlijk, maar heb je daar 5 gb voor nodig?

[thomaske]

dat zijn vooral de indexen die zo groot zijn (volgens mij)

[Verwijderd]

Wat schiet je er mee op man.
Een database is bij simpele selects inderdaad trager dan een filesystem.
Dan koop je maar een snellere computer, als je die performance echt nodig hebt.
Wedden dat je me dankbaar bent als je iets moet veranderen aan je applicatie dat met data te maken heeft?

Met een dbms is dat een kwestie van een nieuwe query (1 min. werk)
Met een zelfbedacht systeem dat op het filesystem werkt, wordt het uren of dagen ploeteren om uit te zoeken hoe je die data nou weer moet extraheren/toevoegen in je eigengemaakte kneuzensysteem, wat door database makers al honderd keer beter is geimplementeerd.
Ik kan je garanderen dat je je erop verkijkt hoeveel haken en ogen er nog zitten aan het imiteren van een sql query met eigen programmeer huisvlijt.

Algemeen advies: altijd standaard-oplossingen gebruiken, altijd andermans werkende oplossingen gebruiken. Als je ooit echt meer performance nodig hebt, kun je altijd nog zelf gaan knutselen aan een revolutionaire nieuwe implementatie van bubble sort.

[ Voor 8% gewijzigd door Verwijderd op 23-11-2002 15:30 ]

[Olaf van der Spek]

thomaske schreef op 23 november 2002 @ 15:25:
dat zijn vooral de indexen die zo groot zijn (volgens mij)

Worden die gebackuped dan?

Verwijderd schreef op 23 november 2002 @ 15:27:
Wat schiet je er mee op man.
Een database is bij simpele selects inderdaad trager dan een filesystem.
Dan koop je maar een snellere computer, als je die performance echt nodig hebt.

Niet elk bedrijf en iedere particulier heeft geld om even een paar servers erbij te zetten hoor.

Wedden dat je me dankbaar bent als je iets moet veranderen aan je applicatie dat met data te maken heeft?

Het gaat hier niet over willekeurige DB-apps, maar specifiek over een forum.

Met een dbms is dat een kwestie van een nieuwe query (1 min. werk)

Als ik zie hoe lang GoT down was duurt ook dat wel wat langer.

Met een zelfbedacht systeem dat op het filesystem werkt, wordt het uren of dagen ploeteren om uit te zoeken hoe je die data nou weer moet extraheren/toevoegen in je eigengemaakte kneuzensysteem, wat door database makers al honderd keer beter is geimplementeerd.

Kneuzensysteem? Hartelijk dank.
Ik heb mijn oude forum keer op keer kunnen updaten zonder downtime. Als ik andere sites zie gaat het lang niet zo vloeiend.

Ik kan je garanderen dat je je erop verkijkt hoeveel haken en ogen er nog zitten aan het imiteren van een sql query met eigen programmeer huisvlijt.

Algemeen advies: altijd standaard-oplossingen gebruiken, altijd andermans werkende oplossingen gebruiken. Als je ooit echt meer performance nodig hebt, kun je altijd nog zelf gaan knutselen aan een revolutionaire nieuwe implementatie van bubble sort.

[Verwijderd]

databases zijn voor dit soort zaken echt VEEL sneller dan fileparsers. Tenzij je zelf alle indexers gaat schrijven, sorting/grouping optimizers/ etc. Maar dan heb je dus gewoon een DB gemaakt. Als je niet van foreign-key relaties gebruik wilt maken gebruik je toch gewoon MySQL? Dat is dacht ik een niet-relationele database (mis je dus ook gelijk die overhead ) en die is gewoon retesnel. Waarom denk je dat vrijwel alle grote fora op MySQL draaien?

[Verwijderd]

overigens : databases slaan over het algemeen de data niet in het RAM op (hoewel je bij alle grote DBMSen de optimalisatieparameters kan instellen) maar gewoon op disk. Ze managen zelf de caching (zodat records die veel gebruikt worden in de cache van de DB staan, niet in de diskcache van het OS). De truc is namelijk dat er wordt opgeslagen waar je welke data kan vinden (indexing). Daardoor hoeft niet iedere keer de hele tablespace geparsed te worden. Anders zou een database van >1GB ook wel heel erg traag worden...
Verder wordt output data van intensieve bewerkingen (grouping/sorting) gecached. Het komt erop neer dat bij bv. DB/2 er al minstens 1000 manjaar aan besteed is om het hele zaakje zo snel/optimaal mogelijk te maken door 's werelds beste DBMS architecten/designers/proggers. Dat ga je zelf echt niet even in een weekendje nadoen. Daarom is een DB oplossing altijd sneller dan als je zelf zoiets maakt. Mits je DB functionaliteit nodig hebt natuurlijk, maar dat heb je dus aangezien je een forum wilt bouwen. Als het echt allemaal zo performance kritisch is, dan zou ik eens gaan kijken naar DBMSen die stored procedures ondersteunen, dat wil nog wel eens schelen. Maar aangezien je zelf al aangeeft dat het een klein forumpje is (6000 posts? da's niks, kijk eens naar T.net, >1miljoen) lijkt me dat allemaal nog wel meevallen. Gewoon je optimilisatieparameters in je DBMS goed instellen en ik kan je garanderen dat iedere professionele databaseoplossing een file-based oplossing eruit blaast.

Ik kan nog wel even een leuk voorbeeldje noemen : op m'n werk bouwen we een compleet software platform (os/apps) en daarvan wordt in files administratie bijgehouden. Als die administratie bewerkt moet worden is het sneller om alle data van de files in een DB te laden en de data dan te bewerken en vervolgens uit de DB weer naar de files schrijven dan om de files zelf te parsen. Performanceverschil was destijds factor 10, maar wordt groter naarmate de hoeveelheid data groter wordt. Gewoon omdat DB/2 die indexes zo verdomd goed maakt, waardoor de queries gewoon supersnel zijn.

[Verwijderd]

1 woord voor de man:
postgresql

[Orphix]

Verwijderd schreef op 23 November 2002 @ 17:38:
1 woord voor de man:
postgresql

Want?

[Twan V]

Het lijkt mij eigenlijk ook wel dat een databeest sneller is dan een filesystem. De db doet immers waar ie voor gemaakt is, en de database is niet ontworpen omdat een aantal mensen tijd teveel hebben.

Als ie op een andere server komt, wat ik opmaak uit je verhaal, komt die server dan aan de andere kant van het land te staan? Zogezegd: Een forumbladzijde doorsturen over 10Mbit is zo gebeurd.

En waarom zou je het jezelf makkelijk maken als het makkelijk kan? Een db als SQL is altijd makkelijker om bij te houden, aan te passen en voor meer toepassingen te gebruiken dan een fs.

Het argument van dat GoT te lang down was vind ik niet helemaal terecht. We hebben het hier niet over een query aanpassen, maar een compleet forum vervangen. Daar vind ik nogal behoorlijk wat verschil in zitten.

[whoami]

Verwijderd schreef op 23 november 2002 @ 17:38:
1 woord voor de man:
postgresql

Mooi.
We zien hier in P&W wel graag onderbouwde posts. Dus als je een opmerking/mening hebt, onderbouw die dan ook, en kom niet af met dergelijke posts die niets toevoegen aan het topic.

[Olaf van der Spek]

Verwijderd schreef op 23 November 2002 @ 17:02:
databases zijn voor dit soort zaken echt VEEL sneller dan fileparsers. Tenzij je zelf alle indexers gaat schrijven, sorting/grouping optimizers/ etc. Maar dan heb je dus gewoon een DB gemaakt. Als je niet van foreign-key relaties gebruik wilt maken gebruik je toch gewoon MySQL? Dat is dacht ik een niet-relationele database (mis je dus ook gelijk die overhead ) en die is gewoon retesnel. Waarom denk je dat vrijwel alle grote fora op MySQL draaien?

Wat moet er aan files geparsed worden? Het worden binary files, geen text files. Er is niet eens fread nodig, de file kan direct in memory gemapped worden.

Dat alle grote fora op MySQL draaien komt omdat het eenvoudiger is een forum in PHP/MySQL te bouwen dan in C++.

[Olaf van der Spek]

Verwijderd schreef op 23 november 2002 @ 17:13:
Maar aangezien je zelf al aangeeft dat het een klein forumpje is (6000 posts? da's niks, kijk eens naar T.net, >1miljoen) lijkt me dat allemaal nog wel meevallen. Gewoon je optimilisatieparameters in je DBMS goed instellen en ik kan je garanderen dat iedere professionele databaseoplossing een file-based oplossing eruit blaast.

Mijn forum is nog/al FS based, maar wel op de verkeerde manier.

Ik kan nog wel even een leuk voorbeeldje noemen : op m'n werk bouwen we een compleet software platform (os/apps) en daarvan wordt in files administratie bijgehouden. Als die administratie bewerkt moet worden is het sneller om alle data van de files in een DB te laden en de data dan te bewerken en vervolgens uit de DB weer naar de files schrijven dan om de files zelf te parsen. Performanceverschil was destijds factor 10, maar wordt groter naarmate de hoeveelheid data groter wordt. Gewoon omdat DB/2 die indexes zo verdomd goed maakt, waardoor de queries gewoon supersnel zijn.

Als je echt ingewikkelde queries hebt kan ik met dat goed voorstellen.

[Verwijderd]

Wat moet er aan files geparsed worden? Het worden binary files, geen text files. Er is niet eens fread nodig, de file kan direct in memory gemapped worden.

Hoeze, direct in memory gemapped worden? Je zal hem toch eerst van disk moeten lezen. Daarna kan je hem in memory houden, maar wat als je server dan crasht?
Je moet bovendien ook rekening houden met het feit dat als je een zooitje files van een gigabyte hebt dat dus ook minstens een gigabyte aan geheugen gaat gebruiken...

Je queries worden al snel intensief genoeg. Wat dacht je van :
- alle posts van een user opvragen
- alle posts van de laatste 10 minuten opvragen
Als je je posts per thread organiseert natuurlijk. Als je het per user doet wordt het lastig om alle posts in een thread bij elkaar te zoeken.

En niet alle grote fora zijn in php hoor... De oudste zullen toch echt wel gewoon in C/C++ geschreven zijn, waarna er een cgi'tje van gemaakt is. Perl kan ook maar performt minder.

[Olaf van der Spek]

Verwijderd schreef op 23 november 2002 @ 21:52:
Hoeze, direct in memory gemapped worden? Je zal hem toch eerst van disk moeten lezen. Daarna kan je hem in memory houden, maar wat als je server dan crasht?

Nee. Via een memory map kun je de file benaderen zonder dat deze in het RAM staat. Zeg maar als een soort pagefile. Als je iets benadert wat niet present is wordt het ingepaged. Als je RAM tekort komt worden de 'oudste' pages uigepaged. En als je iets veranderd wordt dat naar disk geschreven.

Je moet bovendien ook rekening houden met het feit dat als je een zooitje files van een gigabyte hebt dat dus ook minstens een gigabyte aan geheugen gaat gebruiken...

Een of twee GB lijkt me geen probleem.

Je queries worden al snel intensief genoeg. Wat dacht je van :
- alle posts van een user opvragen
- alle posts van de laatste 10 minuten opvragen
Als je je posts per thread organiseert natuurlijk. Als je het per user doet wordt het lastig om alle posts in een thread bij elkaar te zoeken.

En niet alle grote fora zijn in php hoor... De oudste zullen toch echt wel gewoon in C/C++ geschreven zijn, waarna er een cgi'tje van gemaakt is. Perl kan ook maar performt minder.

Volgens mij was vroeger bijna alles Perl (in ieder geval het oude wwwboard). C++ ben ik eigenlijk nog nooit tegengekomen (behalve bij mezelf).

[Verwijderd]

Er bestaan er toch maar liefst () 15: http://www.hotscripts.com...ograms/Discussion_Boards/ C++ wordt nog wel eens gebruikt voor totale CMS oplossing, maar voor fora niet zo snel nee.

Over de vraag DB/FS: Zelf ben ik een PHP programmeur in hart en nieren en heb dus geleerd met MySQL om te gaan. Ik ben echter te begonnen met een zeer simpel forum (wat trouwens niet werkte ), dat textfiles gebruikte. Tegenwoordig gebruik ik een nog steeds een textfile-constructie, maar alleen voor zeer simpele projecten als shoutbox's ed, waar dat een ongeloofelijke performance boost geeft (dat komt omdat ik het als pure PHP code opsla, wat in C++ natuurlijk niet kan). Voor een forum, wat toch al heel snel een stuk complexer is, is een database echt veel makkelijker in gebruik en de snelheid is zeer ok. Kijk naar GoT: Acceptabel snel en als jij maar 600 berichten krijgt zal het op 1 server wel lukken lijkt me zo. IIG scheelt het een hoop tijd, nu ben je vooral dingen aan het implementeren, zodat je vooral maar geen database hoeft te gebruiken...

Performance is trouwens meestal niet de bottleneck van een forum, plaatjes ed moeten ook geladen worden en HTML geparset. Voor een normaal forum hoef je je daar echt geen zorgen over te maken... Je bent nu vooral je tijd aan het verspillen.

[ Voor 2% gewijzigd door Verwijderd op 23-11-2002 23:47 . Reden: URL werdt niet helemaal gerparset ]

[Verwijderd]

Orphix schreef op 23 November 2002 @ 17:42:
[...]

Want?

Okee dan.
Postgres is snel. Dat weet ik uit eigen ervaring, en ik heb een aantal artikelen gelezen die het afzetten tegen MySQL en MS-SQL (maar over die laatste wil ik het geeneens hebben) waarbij Postgres de andere dbmsen er vet uit benchmarkte.

Wat opvallend is, omdat zoals gezegd MySQL geeneens foreign keys heeft of subqueries kan, dus door die minder overhead Postgres er natuurlijk uit zou moeten trekken. Maar dat doet het niet, het is echt een "my first database", en de reden dat het zo populair is, is dat het om historische redenen een soort lievelingskindje van de open source gemeenschap is geworden.

Postgres had daarbovenop tot begin 2001 een aantal zwaarwegende beperkingen (8k row limit etc.) die nu lang en breed opgeheven zijn.

Verder zeg ik dit omdat Postgres een uitgebreid stored procedure systeem heeft (iets waar mysql nog geeneens van kan dromen) waarin je zelfs je eigen taal kunt toevoegen als taal waarin stored procedures geschreven kunnen worden.
Met die stored procedures kun je een database zo uitgebreid als je wil customisen, optimisen en tunen voor een bepaalde applicatie, om die bijvoorbeeld zo veilig of snel mogelijk te maken. Heeft meneer zijn performance zonder dat hij zelf een sql parser hoeft te schrijven.

[CyberSnooP]

Jabberwockie - Je post is wat flamerig opgesteld. Doe dat nou niet, wij zijn allemaal best bereid overtuigd de worden door de kwaliteiten van PostgreSQL, maar dat gaat niet lukken door te zeggen hoe stom je MySQL wel niet vind.

Ik denk dat je in je overweging de gewenste functionaliteit van je forum mee moet nemen. Als je allerlei ingewikkelde zoek methodes (zo uitgebreid als het bij React wordt gepoogd bijv) wilt kunnen uitvoeren ontkom je er niet aan zelf een DBMSje om je files heen te schrijven. Ik vraag me af of je dan in je uppie slim genoeg bent dat net zo efficiënt te maken als een bestaand DBMS wat door tientallen mensen wordt onderhouden. Dit is geen verwijt naar jou, maar ik kan me zo voorstellen dat je snel ergens een klein performance verliesje maakt t.o.v. bijvoorbeeld MySQL.

Wat misschien intressant is is proberen het abstractie niveau te vinden waardoor je je DBMS later redelijk eenvoudig kunt vervangen door een File-Based opslagsysteem. Op dat moment kun je dezelfde features meten tegen de 2 systemen en zo zelf de conclusie trekken.

Ik denk echter dat je, zonder van een bestaand DBMS af te zien, nog makkelijk performance winst kunt boeken ten opzichte van bestaande open-source fora. Daar zou ik me primair op richten.

[ProgrammerX]

Zelf loop ik ook al zeker 2 maanden (niet aan een stuk uiteraard) te denken over het zelf ontwikkelen van een database. Natuurlijk niet meteen zo uitgebreid als de bekende dbms want dat is onmogelijk in me eentje

Maar ik denk dat er misschien in het algemeen nog wel snelheidswinst valt te behalen in vergelijking met de standaard dbms. De hele wereld denkt hoofdzakelijk dat de gekozen aanpak die de huidige dms gebruiken de beste/snelste is (relationeel, opzet indexen enz). Ik kan me gewoon niet voorstellen dat het niet sneller kan.

Ik denk als je al een ander systeem kunt ontwikkelen voor het indexeren dat het de algemene snelheid enorm kan verbeteren (zelf weet ik niet meteen welke kant dit dan wel op moet gaan, maar het gaat ff om de gedachte).

Of als je bijvoorbeeld een kaal besturingsysteem pakt (bijvoorbeeld een linux kernel) en daarin je database verweeft, dat je misschien al een hoop overhead van het os kwijt bent (soort van dedicated db systeem. Bestaat zoiets eigenlijk ?).

Tevens denk ik dat het (beter) analyseren van de queries misschien nog wel snelheids winst kan opleveren. Eventueel i.c.m. met een stuk kunstmatige intelligentie wat na verloop van tijd zelf leert welke gegevens het beste kunnen worden gecached worden enzo (neuraal netwerk misschien ?).

Trouwens afgezien van de optimalisaties van een dbms, is denk een fs altijd sneller dan een dbms:

- gezien een dbms ook op een fs is gebouwd
- het dbms veel overhead met zich meedraagt
- het fs voor een specifieke taak ontwikkeld kan worden (in dit geval een forum)

Kortom denk ik dat het maken van een (specifiek) fs best goed te doen is en ook sneller is dan menig dbms

[Olaf van der Spek]

whoami schreef op 22 November 2002 @ 21:56:
Zullen we eens benchmarken?
je neemt een databank met 100000 records die gaat gaan updaten, en je neemt jouw systeem met het FS dat ook 100000 records gaat gaan updaten...
Of je gaat eens een gaan tellen hoeveel posts een user heeft oid....

Heb jij een dataset die we als testset kunnen gebruiken? Ik heb er wel een, maar die bevat slechts 6000 messages. Ik denk niet dat een GoT admin het P&W forum wil exporteren. ;->
Dat zou misschien ook een te grote tgz worden.

[Verwijderd]

Eventjes uit kosten oogopzicht. Als je deze opdracht volgens een bepaald budget moet gaan uitvoeren en de snelste oplossing moet selecteren kom je toch op een DBMS systeem uit.

Voor het bedrag aan ontwikkelingskosten wat je extra moet gaan uitgeven voor een FS based database systeem tov dbms, kun je weer een extra flinke server neerzetten voor een hogere dbms snelheid.

[ProgrammerX]

Verwijderd schreef op 24 November 2002 @ 14:47:
Eventjes uit kosten oogopzicht. Als je deze opdracht volgens een bepaald budget moet gaan uitvoeren en de snelste oplossing moet selecteren kom je toch op een DBMS systeem uit.

Voor het bedrag aan ontwikkelingskosten wat je extra moet gaan uitgeven voor een FS based database systeem tov dbms, kun je weer een extra flinke server neerzetten voor een hogere dbms snelheid.

Ben ik helemaal met je eens, maar volgens mij gaat het hier niet zo zeer om de economische kant van het verhaal.

[Not Pingu]

OlafvdSpek:

je zegt dat het nadeel van een DB is dat ie geserved moet worden, en dat je bij veel traffic dus niet meer genoeg hebt aan 1 server. volgens jou kan het dmv. FS altijd op 1 server.

maar dat is toch ook niet waar? files serven is toch ook nogal intensief, dus als volgens jou 1 server bij veel bezoek NIET web en db tegelijk kan serven, waarom zou ie dan wel web en file tegelijk kunnen serven?

opzich is er niks mis met een FS aanpak, het YaBB1Gold forum maakte daar ook gebruik van. maar dat had als nadeel dat je een hele hoop textfiles* kreeg, waardoor het erg onoverzichtelijk was. ook heb je daarbij meer kans op inconsistentie, omdat een DB dat zelf regelt, maar je dat bij een FS allemaal zelf zou moeten inbouwen in het forum.

bijkomend nadeel bij yabb1gold was dat bij groter wordende bestanden uiteindelijk een moment kwam waar het boeltje het helemaal liet afweten: bestanden werden corrupted als ik me niet vergis.

de beste aanpak hangt natuurlijk af van wat je er allemaal mee wilt: voor iets simpels als een thread->post structuur en verder niks (ook geen user accounts) zijn files als opslag waarschijnlijk wel sneller, maar als je dingen als zoekfuncties, editen of deleten van posts/topics/users wilt mogelijk maken, dan moet je zoveel scripten dat dat het executen van de code volgens mij de snelheidswinst teniet doet...

maar wat dacht je dan van XML als opslag? de files zijn klein, en hebben toch een aantal interessante functies om opzoeken te vergemakkelijken. iig geen DBMS-type overhead

* textfiles als in plain ASCII. jij had het over binaire files, maar dat zijn dan toch nog steeds verzamelingen van 8 bits om een letter weer te geven?

[ Voor 7% gewijzigd door Not Pingu op 24-11-2002 15:14 . Reden: toevoeging ]

[Olaf van der Spek]

Verwijderd schreef op 24 November 2002 @ 02:43:
Okee dan.

Ok dan? De onderbouwing is (eigenlijk) het verschil tussen een waardeloze en een waardevolle post in een discussie.

Postgres is snel. Dat weet ik uit eigen ervaring, en ik heb een aantal artikelen gelezen die het afzetten tegen MySQL en MS-SQL (maar over die laatste wil ik het geeneens hebben) waarbij Postgres de andere dbmsen er vet uit benchmarkte.

Bron?

Wat opvallend is, omdat zoals gezegd MySQL geeneens foreign keys heeft of subqueries kan, dus door die minder overhead Postgres er natuurlijk uit zou moeten trekken. Maar dat doet het niet, het is echt een "my first database", en de reden dat het zo populair is, is dat het om historische redenen een soort lievelingskindje van de open source gemeenschap is geworden.

Verder zeg ik dit omdat Postgres een uitgebreid stored procedure systeem heeft (iets waar mysql nog geeneens van kan dromen) waarin je zelfs je eigen taal kunt toevoegen als taal waarin stored procedures geschreven kunnen worden.
Met die stored procedures kun je een database zo uitgebreid als je wil customisen, optimisen en tunen voor een bepaalde applicatie, om die bijvoorbeeld zo veilig of snel mogelijk te maken. Heeft meneer zijn performance zonder dat hij zelf een sql parser hoeft te schrijven.

Volgens mij ondersteund MySQL ook custom functies, maar niet op SQL level.

[DeBolle]

Er is nog een methode die ik hier nog niet heb zien noemen, raw devices. De database gaat dan buiten het filesystem om een device rechtstreeks gebruiken, wat je de mogelijkheid geeft desnoods een eigen 'intern filesystem' te gebruiken.
Nadelen zijn er wel - een simpele backup moet al via een export of dump naar het filesystem, metadata moet dubbel worden vastgelegd, raw devices zijn lastig(er) te beheren.
Het voordeel bestond voornamelijk uit I/O performance. Tegenwoordig is dat niet meer helemaal valide door gebruik van (snellere) filesystems, dynamic cache, redundancy, virtualisatie en volumemanagers.

[Olaf van der Spek]

Verwijderd schreef op 24 november 2002 @ 14:47:
Eventjes uit kosten oogopzicht. Als je deze opdracht volgens een bepaald budget moet gaan uitvoeren en de snelste oplossing moet selecteren kom je toch op een DBMS systeem uit.

Het is (momenteel) een theoretische discussie.

Voor het bedrag aan ontwikkelingskosten wat je extra moet gaan uitgeven voor een FS based database systeem tov dbms, kun je weer een extra flinke server neerzetten voor een hogere dbms snelheid.

Dan neem je wel aan dat:
De ontwikkelingskosten relatief hoog zijn
Een paar extra servers dezelfde performance levert
De ontwikkelingskosten niet worden gedekt door het commercieel verkopen van de software

[Olaf van der Spek]

Gunp01nt schreef op 24 November 2002 @ 15:10:
OlafvdSpek:

je zegt dat het nadeel van een DB is dat ie geserved moet worden, en dat je bij veel traffic dus niet meer genoeg hebt aan 1 server. volgens jou kan het dmv. FS altijd op 1 server.

maar dat is toch ook niet waar? files serven is toch ook nogal intensief, dus als volgens jou 1 server bij veel bezoek NIET web en db tegelijk kan serven, waarom zou ie dan wel web en file tegelijk kunnen serven?

Er hoeven toch geen files geserved te worden? Ik neem wel aan dat je een server (relatief) dedicated voor het forum gebruikt.

opzich is er niks mis met een FS aanpak, het YaBB1Gold forum maakte daar ook gebruik van. maar dat had als nadeel dat je een hele hoop textfiles* kreeg, waardoor het erg onoverzichtelijk was. ook heb je daarbij meer kans op inconsistentie, omdat een DB dat zelf regelt, maar je dat bij een FS allemaal zelf zou moeten inbouwen in het forum.

bijkomend nadeel bij yabb1gold was dat bij groter wordende bestanden uiteindelijk een moment kwam waar het boeltje het helemaal liet afweten: bestanden werden corrupted als ik me niet vergis.

Textfiles gebruiken zou ik zoiezo niet doen, dan maar binary files.

de beste aanpak hangt natuurlijk af van wat je er allemaal mee wilt: voor iets simpels als een thread->post structuur en verder niks (ook geen user accounts) zijn files als opslag waarschijnlijk wel sneller, maar als je dingen als zoekfuncties, editen of deleten van posts/topics/users wilt mogelijk maken, dan moet je zoveel scripten dat dat het executen van de code volgens mij de snelheidswinst teniet doet...

maar wat dacht je dan van XML als opslag? de files zijn klein, en hebben toch een aantal interessante functies om opzoeken te vergemakkelijken. iig geen DBMS-type overhead

XML lijkt me helemaal geen optie, om dezelfde reden dat parsing nog steeds nodig is.

* textfiles als in plain ASCII. jij had het over binaire files, maar dat zijn dan toch nog steeds verzamelingen van 8 bits om een letter weer te geven?

Ja, maar er hoeft dan niet geparsed te worden. In plaats van <string>\0 doe je <length><string>.

[Olaf van der Spek]

Twan V schreef op 23 November 2002 @ 18:04:
Als ie op een andere server komt, wat ik opmaak uit je verhaal, komt die server dan aan de andere kant van het land te staan? Zogezegd: Een forumbladzijde doorsturen over 10Mbit is zo gebeurd.

En waarom zou je het jezelf makkelijk maken als het makkelijk kan? Een db als SQL is altijd makkelijker om bij te houden, aan te passen en voor meer toepassingen te gebruiken dan een fs.

Ik had gedacht dat er wel een 100 mbit/s of zelfs een 1 gbit/s link tussen zat. De forum page gaat trouwens niet over die link, alleen de queries en query results. Maar vergeleken met RAM (16 gbit/s) blijft het langzaam. Behalve de bandbreedte is ook de latency natuurlijk belangrijk.

Een ander voordeel van een FS based oplossing is dat je bijvoorbeeld makkelijker een recursieve 'query' kunt doen.

[Verwijderd]

Bron?

Open Source Databases: As The Tables Turn, van Tim Perdue, de (mede)oprichter/developer van Sourceforge en oprichter van PHPBuilder. In een eerder artikel van dezelfde auteur, komt MySQL nog wel als sneller naar voren.

[_JGC_]

Success met je C++ programma buiten een DBMS om. Ik ben blij dat ik van Ultraboard 2000 PE afgestapt ben naar Invisionboard welke wel gewoon een database gebruikt.

Als jij je C++ programmaatje net zo snel wilt maken als een DBMS, zul je het volgende moeten doen:
- daemon die alle data in de cache houdt, als dat past, anders ongebruikte zooi swappen naar disk
- C++ programma die connect naar die daemon

Wat heb je dan gemaakt? een DBMS. Je kunt wel mooi een bestand in geheugen openen, daar wat in prutsen en dan naar disk terugschrijven, maar tegen een database daemon met caching voor meerdere clients kan je echt niet op. Wel eens gehoord van delayed transactions?

[Olaf van der Spek]

_JGC_ schreef op 24 November 2002 @ 16:31:
Success met je C++ programma buiten een DBMS om. Ik ben blij dat ik van Ultraboard 2000 PE afgestapt ben naar Invisionboard welke wel gewoon een database gebruikt.

Als jij je C++ programmaatje net zo snel wilt maken als een DBMS, zul je het volgende moeten doen:
- daemon die alle data in de cache houdt, als dat past, anders ongebruikte zooi swappen naar disk
- C++ programma die connect naar die daemon

Wat heb je dan gemaakt? een DBMS. Je kunt wel mooi een bestand in geheugen openen, daar wat in prutsen en dan naar disk terugschrijven, maar tegen een database daemon met caching voor meerdere clients kan je echt niet op. Wel eens gehoord van delayed transactions?

Je vergelijkt een Perl implementatie die textfiles gebruikt met een C++ implementatie (waarvan je de details nog niet kent) die binary memory-mapped files gebruikt.

Wat uitleg over memory-mapped binary files:

C++:

bool Cxhpf_mmf::open(const string& name, int size)
{
    HANDLE fh = CreateFile(name.c_str(), GENERIC_READ | GENERIC_WRITE, 0, NULL, OPEN_ALWAYS, 0, NULL);
    if (fh == INVALID_HANDLE_VALUE)
        return true;
    HANDLE mh;
    return !(mh = CreateFileMapping(fh, NULL, PAGE_READWRITE, 0, size, NULL)) 
        || !(m_p = static_cast<byte*>(MapViewOfFile(mh, FILE_MAP_WRITE, 0, 0, 0)));
}

Met deze code wordt een file gemapped. Daarna kun je via pointers de data benaderen. Het uitvoeren van deze code kost zelfs voor 1 gb files nog geen ms. De data wordt gecached door het OS. De data wordt niet eens via 'memcpy' binnen het RAM verplaatst.

Het prototype dat ik heb kan binnen 90 s 1000 pagina's (605 mb totaal) genereren met elk 1000 random geselecteerde berichten (en bijbehorende user name) (uit > 50000 users, 1000000 messages).
En het kan binnen 53 s als je die 1000 pagina's in een enkel bestand zet.

Zijn er performance stats van GoT beschikbaar?

[ Voor 15% gewijzigd door Olaf van der Spek op 24-11-2002 18:01 ]

[djazete]

ik ben niet zo erg into dit gebied maar volgens mij is een db een soort schil op je fs die dus de boel op een bepaalde manier handled.
ik denk dus, dat als je tijd en intelligentie genoeg hebt je best een soort dbms kan maken die specifiek gericht is op de functionaliteit die jouw forum wil hebben, maar uiteindelijk maak je dan het zelfde stukje software wat waarschijnlijk zoveel mogelijk geoptimaliseerd is voor jouw functie, maar gezien de ontwikkelings tijd van 'echte' dbms-en lijkt het me onhaalbaar om dezelfde functionaliteit te halen, maar afhankelijk van de grootte kan je volgens mij vrij veel performance winst halen, mits je een goede programmeur bent....
schaalbaarheid etc wordt wel weer lastiger imo

[ACM]

[nohtml]

OlafvdSpek schreef op 23 November 2002 @ 12:33:
Dat zou natuurlijk wel kunnen. Maar zit de DB dat? Op GoT niet.

Het belangrijkste deel zit wel continue in het RAM, je kan dat heel leuk na een reboot/restart van de (sql)server merken. Eerst is ie erg traag en na een paar minuten werkt alles lekker soepel (kortom, de belangrijkste blocks moesten nog gecached worden enzo)

Ja. Het heeft weinig zin een forum te gaan bouwen dat slechter is dan de bestaande forums.

Je hoeft niet perse "sneller" te zijn om beter te zijn dan anderen
Sowieso kan je aardig wat winnen door c++ te gebruiken en je zou daarmee zelfs een module voor apache kunnen bouwen (en misschien doe je dat ook al )

OlafvdSpek schreef op 23 November 2002 @ 15:09:
6 gb voor 8 miljoen berichten (ongeveer)? Dat is 768 kbyte per bericht. Zelfs als je maar 1 gb voor de berichten neemt kom je nog op 128 kbyte uit. Is dat niet een beetje veel?

Foutje, bedankt. ;-> Dat moet 768 byte zijn en dat is wel 'normaal'.

[quote]
Ik denk dat het in de database in totaal wel wat meer inneemt, rond de 8GB geloof ik zelfs. Dat is dan dus inclusief indices (indices op userid, topicid, datum, etc en dat gaat vrij hard), deels geindexeerde search-engine, topicdata etc etc.
Maar het grootste deel zit hem in de messages (die ook nog eens geparsed en ongeparsed opgeslagen worden).
Dat dubbel opslaan verdubbeld de database-grootte trouwens niet, maar is iets van 1/3e van het totaal dat nodig is voor de messages.

OlafvdSpek schreef op 23 November 2002 @ 15:15:
Natuurlijk, maar heb je daar 5 gb voor nodig?

Snelle opslag en compacte opslag sluiten elkaar ten dele uit. Vooral omdat je bij snelle opslag alle benodigde ingangen zo snel mogelijk toegankelijk wilt hebben (per topic opvragen van messages, per user, op datum gesorteerd etc etc).
Als je hier knappe algoritmes voor weet te bedenken win je gigantisch veel, maar als je dat niet kan (danwel door tijdgebrek, danwel door "intelligentie gebrek" (je bent echt niet dom als je dat niet kan hoor )) dan heb je kans dat je voor snelle opslag van je data flink veel opslag kwijt bent.

thomaske schreef op 23 November 2002 @ 15:25:
dat zijn vooral de indexen die zo groot zijn (volgens mij)

Indices bepalen deels hoe groot het is, maar de dump-size is natuurlijk de asci-inhoud van het forum (dus een tabel die enkel uit getallen bestaat wordt minder efficient opgeslagen als ze gemiddeld meer dan 4 cijfers bevatten (bij een int iig))
De indices nemen wel een aardig deel van de totale database-grootte in natuurlijk, maar niet zo significant als de messages zelf.

OlafvdSpek schreef op 23 November 2002 @ 22:01:
[...]
Als je RAM tekort komt worden de 'oudste' pages uigepaged. En als je iets veranderd wordt dat naar disk geschreven.
[...]
Een of twee GB lijkt me geen probleem.

OlafvdSpek schreef op 23 November 2002 @ 15:42:
Niet elk bedrijf en iedere particulier heeft geld om even een paar servers erbij te zetten hoor.

* ACM glimlacht als ie deze twee opmerkingen naast elkaar legt

Als ik zie hoe lang GoT down was duurt ook dat wel wat langer.

Dat kwam vooral omdat er een dump gemaakt moest worden en die daarna weer ingelezen moest worden. Anders was het met een kwartier - half uur klaar geweest.

[Olaf van der Spek]

ACM schreef op 24 November 2002 @ 21:23:
Het belangrijkste deel zit wel continue in het RAM, je kan dat heel leuk na een reboot/restart van de (sql)server merken. Eerst is ie erg traag en na een paar minuten werkt alles lekker soepel (kortom, de belangrijkste blocks moesten nog gecached worden enzo)

Maar dat is remote RAM, niet lokaal, toch?

Je hoeft niet perse "sneller" te zijn om beter te zijn dan anderen
Sowieso kan je aardig wat winnen door c++ te gebruiken en je zou daarmee zelfs een module voor apache kunnen bouwen (en misschien doe je dat ook al )

Dat was inderdaad een idee, maar geen plan. Ik heb niet eens een dedicated server. Maar voor high-performance is dat zeker nodig ja. Maar het negatieve punt van veel forums is toch de snelheid.

* ACM glimlacht als ie deze twee opmerkingen naast elkaar legt

Een paar GB RAM is vele malen goedkoper dan een paar extra servers.

Dat kwam vooral omdat er een dump gemaakt moest worden en die daarna weer ingelezen moest worden. Anders was het met een kwartier - half uur klaar geweest.

Hoe lang was GoT down dan?
En restore/backup, duurt dat echt uren?

[ Voor 4% gewijzigd door Olaf van der Spek op 24-11-2002 21:49 ]

[ACM]

Voorop gesteld, ik zou postgresql kiezen boven mysql waar ik de keus zelf kan maken en die niet af te leiden is uit andere requirements.

Verwijderd schreef op 24 november 2002 @ 02:43:
Okee dan.
Postgres is snel. Dat weet ik uit eigen ervaring, en ik heb een aantal artikelen gelezen die het afzetten tegen MySQL en MS-SQL (maar over die laatste wil ik het geeneens hebben) waarbij Postgres de andere dbmsen er vet uit benchmarkte.

En er zijn ook zat benchmarks waar Postgresql vet verliest, als je belangrijkste queries simpele selects op indices zijn (een forum bijv) dan komt Postgresql er niet zo mooi meer uit.
Als je bepaalde requirements hebt als goed werkende relational integrity dan is postgresql ineens een stuk betere keus. En als je het met andere OS concurrenten vergelijkt hou je alleen SAPdb en Firebird over. De eerste ken ik niet, maar is volgens zeggen vrij snel, de tweede heb ik een paar keer getest en was bij alle queries slomer dan postgresql (meen ik) zelfs als je geavanceerdere indices ging toepassen (wat bij postgres ook kan).

Wat opvallend is, omdat zoals gezegd MySQL geeneens foreign keys heeft of subqueries kan, dus door die minder overhead Postgres er natuurlijk uit zou moeten trekken. Maar dat doet het niet,

Hoevaak heb _jij_ zelf een serieuze vergelijking tussen postgres en mysql gedaan? Ik een aantal keer en daarbij won mysql alle "simpele" queries zeer royaal. De moeilijkere queries (een paar lastigere joins erin oid) won postgres het mee, omdat het daar goedkoper is een uitgebreider executieplan te bouwen en dat kan mysql niet.
De standaard planner van mysql is echter weer wel beter dan de "simpele" planner van postgres (wat performance betreft).
Echter kan je sowieso al niet direct 1-1 queries op de ene vs de andere vergelijken. Dan gebruik je niet perse de meest optimale keuzes voor de ene vs de andere (oa subselects in postgres, of functional indices).

het is echt een "my first database", en de reden dat het zo populair is, is dat het om historische redenen een soort lievelingskindje van de open source gemeenschap is geworden.

Ik erger me regelmatig kapot aan dingen van mysql, maar om het nou _zo_ denigrerend te behandelen is bullshit.

Postgres had daarbovenop tot begin 2001 een aantal zwaarwegende beperkingen (8k row limit etc.) die nu lang en breed opgeheven zijn.

Postgresql was vooral daardoor niet bijster bruikbaar voor een forum. Maar er zijn nog steeds nadelen die het minder goed kunnen maken. Voornamelijk het niet automatisch vacuumen (multi version control) en het daarmee gepaard gaande ruimte verlies als je niet vaak genoeg vacuumed (en het performance verlies als je dat te vaak doet).
Ik heb een simpel tabelletje met 60+1 entries en deed daarop elke 5 minuten een update (op een van die 60 en dan die ene). Daarmee zou het in principe een mini-database moeten zijn en blijven. Ik was vergeten dat te vacuumen en daardoor waren er in een paar maanden tijd iets van 38000 records die "in gebruik" waren... Dat is natuurlijk bij grote databases nog veel erger, zeker als er veel updates, deletes en inserts plaatsvinden.

Verder zeg ik dit omdat Postgres een uitgebreid stored procedure systeem heeft (iets waar mysql nog geeneens van kan dromen) waarin je zelfs je eigen taal kunt toevoegen als taal waarin stored procedures geschreven kunnen worden.

Das idd een leuke feature, maar ik vind het nog niet _zo_ handig werken, vooral de triggers niet trouwens.

Met die stored procedures kun je een database zo uitgebreid als je wil customisen, optimisen en tunen voor een bepaalde applicatie, om die bijvoorbeeld zo veilig of snel mogelijk te maken. Heeft meneer zijn performance zonder dat hij zelf een sql parser hoeft te schrijven.

Er zijn grensen natuurlijk en het is zeer wel mogelijk dat een FS-based systeem vele malen sneller is dan een db-based systeem.

Kortom, je mag Postgresql een goed systeem vinden, het is imho zelfs een goed systeem. Maar pas op dat je het niet _te_ ophemelt.

OlafvdSpek schreef op 24 november 2002 @ 15:31:
Volgens mij ondersteund MySQL ook custom functies, maar niet op SQL level.

Niet op een bruikbare manier imho

OlafvdSpek schreef op 24 november 2002 @ 15:49:
Ik had gedacht dat er wel een 100 mbit/s of zelfs een 1 gbit/s link tussen zat. De forum page gaat trouwens niet over die link, alleen de queries en query results. Maar vergeleken met RAM (16 gbit/s) blijft het langzaam. Behalve de bandbreedte is ook de latency natuurlijk belangrijk.

Maar een database kan nog steeds ook lokaal gebruikt worden. Er wordt nergens geeist dat dat een aparte machine is.

OlafvdSpek schreef op 24 november 2002 @ 16:42:
Met deze code wordt een file gemapped. Daarna kun je via pointers de data benaderen. Het uitvoeren van deze code kost zelfs voor 1 gb files nog geen ms. De data wordt gecached door het OS. De data wordt niet eens via 'memcpy' binnen het RAM verplaatst.

goh en hoe zal het DBMS de files benaderen?
Vast via allerlei kostbare operaties of niet?
MySQL is ook maar ms bezig om een compleet topic uit de GoT db op te zoeken en te serveren.

Het prototype dat ik heb kan binnen 90 s 1000 pagina's (605 mb totaal) genereren met elk 1000 random geselecteerde berichten (en bijbehorende user name) (uit > 50000 users, 1000000 messages).
En het kan binnen 53 s als je die 1000 pagina's in een enkel bestand zet.

1000 random berichten is zinloos. Je zal ze voornamelijk op topic-basis pakken en dan moet je dus random topicid's nemen en daarbij de message van 1 pagina trekken (of gewoon allemaal).
Vergeet niet dat je dan nog een erg synthetische test hebt.

Zijn er performance stats van GoT beschikbaar?

Je kan onderaan de pagina de witte tekst selecteren, de DB tijd is in sec. de tijd die er in totaal voor de DB (en de communicatie) nodig was voor die pagina.

[ACM]

OlafvdSpek schreef op 24 november 2002 @ 21:45:
Maar dat is remote RAM, niet lokaal, toch?

Als jij je MySQL en apache op dezelfde machine installeert zal het natuurlijk wat langzamer gaan dan wanneer je het direct kan inlezen, maar je kan dan via een unix-socket communiceren en volgens mij is de performance dan wel een stukje beter dan 100Mbit/s
Maar dan nog, aangezien je sql-server zelf de complete selectie uit dat remote-ram neemt en alleen dat deel opstuurt dat je nodig hebt maakt dat niet eens zoveel uit, de latency is veel belangrijker dan de bandbreedte (ik geloof dat er maar 1-5Mbit/sec gebruikt wordt tussen de web- en dbservers van GoT...)

Dat was inderdaad een idee, maar geen plan. Ik heb niet eens een dedicated server. Maar voor high-performance is dat zeker nodig ja. Maar het negatieve punt van veel forums is toch de snelheid.

Domweg door het in c++ te programmeren wordt het er niet perse sneller op, je kan beter kijken welke onderdelen er sloom zijn en of die efficienter toegepast kunnen worden. Een MySQL server kan vaak veel efficienter toegepast worden, waar je ook nog aan kan denken is in je c++ applicatie een (kleine) (persistent) object-cache bijhouden (of whatever je je data intern in representeert), dan maakt het niet zoveel meer uit dat je een dbms gebruikt voor de (slomere) backend opslag. Maar zo'n object cache lijkt me veel eenvoudiger te bouwen en hoef je niet perse "af te hebben" als je je eerste prototypes van je forum gaat testen.
Terwijl je toch een goede opslag backend hebt.

Een paar GB RAM is vele malen goedkoper dan een paar extra servers.

Uiteraard, maar neemt niet weg dat het wel grappig is als je eerst "tegen" een extra server bent want dat is te duur, maar dan wel over een doos met 2GB ram gaat praten

Hoe lang was GoT down dan?
En restore/backup, duurt dat echt uren?

Ja, dat schijnt lang te moeten duren bij MySQL
De backup was zo gemaakt trouwens, maar de restore kan MySQL niet zo efficient als je de table definities wijzigt (postgres ook niet heel efficient dan trouwens)

[Olaf van der Spek]

ACM schreef op 24 November 2002 @ 21:47:
Niet op een bruikbare manier imho

Ik wilde even de MySQL docs nakijken, maar ik kan niet op de ToC naam van deze feature komen. Weet jij toevallig hoe die heet?

Maar een database kan nog steeds ook lokaal gebruikt worden. Er wordt nergens geeist dat dat een aparte machine is.

Klopt.

goh en hoe zal het DBMS de files benaderen?
Vast via allerlei kostbare operaties of niet?
MySQL is ook maar ms bezig om een compleet topic uit de GoT db op te zoeken en te serveren.

Het was niet in vergelijking met een DBMS, maar met andere FS based storage methods (text files).

1000 random berichten is zinloos. Je zal ze voornamelijk op topic-basis pakken en dan moet je dus random topicid's nemen en daarbij de message van 1 pagina trekken (of gewoon allemaal).
Vergeet niet dat je dan nog een erg synthetische test hebt.

Mee eens, maar dan moet ik ook de topics table implementeren en dat heb ik nog niet gedaan. Heb jij een beter benchmark idee?

Maar het geeft in ieder geval wel aan dat simpele queries supersnel zijn. En om eerlijk te zijn verwacht ik niet veel/geen performance verlies als ik alle messages in een topic nodig heb.

Je kan onderaan de pagina de witte tekst selecteren, de DB tijd is in sec. de tijd die er in totaal voor de DB (en de communicatie) nodig was voor die pagina.

Maar er zijn geen gegevens over gemiddelden van die waarden? Of pages/s bijvoorbeeld.

[ Voor 8% gewijzigd door Olaf van der Spek op 24-11-2002 22:07 ]

[Olaf van der Spek]

ACM schreef op 24 November 2002 @ 21:55:
Domweg door het in c++ te programmeren wordt het er niet perse sneller op, je kan beter kijken welke onderdelen er sloom zijn en of die efficienter toegepast kunnen worden. Een MySQL server kan vaak veel efficienter toegepast worden, waar je ook nog aan kan denken is in je c++ applicatie een (kleine) (persistent) object-cache bijhouden (of whatever je je data intern in representeert), dan maakt het niet zoveel meer uit dat je een dbms gebruikt voor de (slomere) backend opslag. Maar zo'n object cache lijkt me veel eenvoudiger te bouwen en hoef je niet perse "af te hebben" als je je eerste prototypes van je forum gaat testen.
Terwijl je toch een goede opslag backend hebt.

Ik gebruik C++ niet (alleen) voor de snelheid, maar omdat ik het beter vind werken (een forum is best al complex) en er meer ervaring mee heb.

Uiteraard, maar neemt niet weg dat het wel grappig is als je eerst "tegen" een extra server bent want dat is te duur, maar dan wel over een doos met 2GB ram gaat praten

Is een server met 2 GB RAM zo high-end dan? Ik heb zelf al 512 mb RAM (was toen zeer goedkoop), maar 1 a 2 GB zou ik eigenlijk in elke server verwachten.

Ja, dat schijnt lang te moeten duren bij MySQL
De backup was zo gemaakt trouwens, maar de restore kan MySQL niet zo efficient als je de table definities wijzigt (postgres ook niet heel efficient dan trouwens)

Ik heb ook een keer drie uur gedaan over het importeren van data, maar dat kwam doordat ik MySQL nog in tiny-mode had staan. Toen ik medium-mode had gekozen was het binnen een paar minuten gepiept.

[ Voor 4% gewijzigd door Olaf van der Spek op 24-11-2002 22:04 ]

[ACM]

OlafvdSpek schreef op 24 november 2002 @ 21:58:
Ik wilde even de MySQL docs nakijken, maar ik kan niet op de ToC naam van deze feature komen. Weet jij toevallig hoe die heet?

UDF / User Defined Functions is een manier en de andere is domweg de source van MySQL aanpassen en recompilen...
Tenminste, ik geloof dat dat de twee manieren waren

Het was niet in vergelijking met een DBMS, maar met andere FS based storage methods (text files).

Ok

Mee eens, maar dan moet ik ook de topics table implementeren en dat heb ik nog niet gedaan. Heb jij een beter benchmark idee?

Niet echt. Behalve dus "random" een stel topics "complete" eruit trekken en vergeet dan niet dat maar uit een gedeelte te doen, zodat je een flinke last aan niet gebruikte topics hebt, die dus wel je files groter maken, maar niet in je selecties voorkomen, simpelweg omdat de topics "te oud zijn". (Hooguit 5% selecteren ofzo en de andere 95% af en toe er tussendoor een van pakken)

Maar er zijn geen gegevens over gemiddelden van die waarden? Of pages/s bijvoorbeeld.

Niet echt, nadeel is dat je dan namelijk de complete setup test en dan heb je gelijk al een loadbalancer, vijf webservers en een database.

Maar die servers worden dan ondertussen ook nog in productie toegepast, etc etc. En er zijn wel wat getallen gelogd, maar vooral tijdens de tijd dat het forum erg slecht presteerde. Dus die getallen zijn ook niet helemaal reeel

[ACM]

OlafvdSpek schreef op 24 November 2002 @ 22:03:
Ik gebruik C++ niet (alleen) voor de snelheid, maar omdat ik het beter vind werken (een forum is best al complex) en er meer ervaring mee heb.

Dat zijn twee hele valide redenen om C++ te gebruiken hoor

Is een server met 2 GB RAM zo high-end dan? Ik heb zelf al 512 mb RAM (was toen zeer goedkoop), maar 1 a 2 GB zou ik eigenlijk in elke server verwachten.

2GB betekent vaak al een module van 1GB gebruiken, die zijn _erg_ duur. Zeker als je ze voor een server in de ECC-registered uitvoering neemt.
Al onze webservers hebben trouwens 1GB ram en dat is heel ruim voldoende voor wat ze doen, maar daar doen ze geen database-taken bij natuurlijk.
512MB ram is weer wat aan de krappe kant vanwege de grootte per process dat bij apache+php best aardig kan oplopen.

Ik heb ook een keer drie uur gedaan over het importeren van data, maar dat kwam doordat ik MySQL nog in tiny-mode had staan. Toen ik medium-mode had gekozen was het binnen een paar minuten gepiept.

Zodra je een dump moet doen in een aangepaste tabeldefinitie kan je niet meer de erg snelle "extended" insert methodes meer gebruiken, daarmee kost het dus vrij snel vrij veel tijd (zeker als ie ook de indices tegelijkertijd gaat lopen vullen/checken), helaas biedt MySQL niet zo heel veel controle over dat proces zodra het niet meer standaard gebeurt (v4 zou dat wat beter moeten doen trouwens).

[Olaf van der Spek]

ACM schreef op 24 november 2002 @ 22:11:
[nohtml]
Dat zijn twee hele valide redenen om C++ te gebruiken hoor

Misschien dat ik morgen maar een nieuw topic open ;->
Betere dynamic content generation performance: DB of FS, C++ of PHP

2GB betekent vaak al een module van 1GB gebruiken, die zijn _erg_ duur. Zeker als je ze voor een server in de ECC-registered uitvoering neemt.
Al onze webservers hebben trouwens 1GB ram en dat is heel ruim voldoende voor wat ze doen, maar daar doen ze geen database-taken bij natuurlijk.
512MB ram is weer wat aan de krappe kant vanwege de grootte per process dat bij apache+php best aardig kan oplopen.

Ik dacht dat server borden wel 4 sloten zouden hebben. Misschien is 2 GB wat overdreven en kan een FS-based forum heel goed met 512 MB overweg.

[/nohtml]
Zodra je een dump moet doen in een aangepaste tabeldefinitie kan je niet meer de erg snelle "extended" insert methodes meer gebruiken, daarmee kost het dus vrij snel vrij veel tijd (zeker als ie ook de indices tegelijkertijd gaat lopen vullen/checken), helaas biedt MySQL niet zo heel veel controle over dat proces zodra het niet meer standaard gebeurt (v4 zou dat wat beter moeten doen trouwens).

Is het niet veel sneller om die indices pas te bouwen nadat de import compleet is?

[ACM]

OlafvdSpek schreef op 24 november 2002 @ 22:21:
Misschien dat ik morgen maar een nieuw topic open ;->
Betere dynamic content generation performance: DB of FS, C++ of PHP

Denk dat dat niet zo zinvol is, er zijn weinig redenen om af te stappen van C++ als dat de taal is die jij geschikt vindt voor je product.
Portabiliteit en gebruiksgemak zijn de twee belangrijkste voor php vs c++ denk ik. Portabiliteit -> php draait op vele platformen, C++ code kan dat ook zeker wel, maar je kan natuurlijk ook weer op libs bouwen die dat in de weg staan.
Plus dat je voor C++ wel een recompile nodig hebt en voor php niet.

Gebruiksgemak bedoel ik meer mee dat een willekeurige hostingprovider vaak al php meelevert en je een apache module zeer waarschijnlijk niet geinstalleerd krijgt op een shared-hoster.
Op een dedicated server is dat een ander verhaal natuurlijk.

Ik dacht dat server borden wel 4 sloten zouden hebben. Misschien is 2 GB wat overdreven en kan een FS-based forum heel goed met 512 MB overweg.

Tuurlijk, maar ik denk dat je het hardware kosten plaatje iets minder aanwezig moet laten meewegen
Die situaties waarbij de hardware de beperkende factor wordt is het toch wel al erg lastig om veel performance te krijgen.
Als jouw software dan 2x zo snel is, is dat fantastisch natuurlijk Maar zodra de belasting dan verdubbeld is, dan ben je verplicht een (duurdere, hangt er vanaf hoe lang het duurt, anders is ie even duur en toch sneller) vervangende server te kopen en dan wordt het dus duurder dan wanneer je er een "licht servertje" bij kan kopen die gewoon dezelfde taken kan oppaken en ernaast doen heb je daarmee wel meer performance uit je geld.

Dit is wat ik met schaling bedoel (en je vast al begreep). Bij tweakers.net kunnen we simpelweg een webserver erbij plaatsen en deze kan dan met een kleine moeite ingezet worden voor GoT (en tweakers.net maar das niet interessant verder), zonder dat er ineens geen toegang tot de data meer mogelijk is.
Het verhaal wordt natuurlijk wat vervelender als de databaseserver ontoerijkent wordt, simpelweg omdat de gemiddelde clusteringsetup bij ons waarsch geen performance winst oplevert, misschien zelfs verlies (er is tenslotte 'simpele" highspeed access op een relatief kleine database nodig en laat dat nou net de sterke kant van mysql zijn ).

Is het niet veel sneller om die indices pas te bouwen nadat de import compleet is?

Ja, tuurlijk. Maar zo goed is de controle daarover niet en handmatig is ook niet alles. Magoed, opzich kwam het ook niet zo slecht uit dat het zo lang duurde hoor we moesten de files toch nog goed kopieren en een laatste test uitvoeren of alles wel werkte

[Olaf van der Spek]

ACM schreef op 24 November 2002 @ 23:14:
Tuurlijk, maar ik denk dat je het hardware kosten plaatje iets minder aanwezig moet laten meewegen
Die situaties waarbij de hardware de beperkende factor wordt is het toch wel al erg lastig om veel performance te krijgen.
Als jouw software dan 2x zo snel is, is dat fantastisch natuurlijk Maar zodra de belasting dan verdubbeld is, dan ben je verplicht een (duurdere, hangt er vanaf hoe lang het duurt, anders is ie even duur en toch sneller) vervangende server te kopen en dan wordt het dus duurder dan wanneer je er een "licht servertje" bij kan kopen die gewoon dezelfde taken kan oppaken en ernaast doen heb je daarmee wel meer performance uit je geld.

Ok, maar wat als mijn software 5 - 10 x zo snel is?
'Mijn' software ontwerp sluit een web-server FS-server ontwerp trouwens niet uit. De web-server verzorgt dan alleen de compressie en de transmissie naar de client, niet het opbouwen van de pages.
Waar kan ik de specs van het Tweakers server-park vinden? Ik heb me rot gezocht.

Dit is wat ik met schaling bedoel (en je vast al begreep). Bij tweakers.net kunnen we simpelweg een webserver erbij plaatsen en deze kan dan met een kleine moeite ingezet worden voor GoT (en tweakers.net maar das niet interessant verder), zonder dat er ineens geen toegang tot de data meer mogelijk is.
Het verhaal wordt natuurlijk wat vervelender als de databaseserver ontoerijkent wordt, simpelweg omdat de gemiddelde clusteringsetup bij ons waarsch geen performance winst oplevert, misschien zelfs verlies (er is tenslotte 'simpele" highspeed access op een relatief kleine database nodig en laat dat nou net de sterke kant van mysql zijn ).

Ik dacht dat MySQL ook een master/slave setup ondersteunde.

[ Voor 11% gewijzigd door Olaf van der Spek op 25-11-2002 11:02 ]

[ACM]

OlafvdSpek schreef op 25 November 2002 @ 10:12:
Ok, maar wat als mijn software 5 - 10 x zo snel is?

Dan is het het zelfde verhaal, maar dan met een andere factor waar jouw systeem interessanter blijft

'Mijn' software ontwerp sluit een web-server FS-server ontwerp trouwens niet uit. De web-server verzorgt dan alleen de compressie en de transmissie naar de client, niet het opbouwen van de pages.

Of je daarmee wel je FS-server voldoende ontlast betwijfel ik, maar het kan schelen. Maar vergeet niet dat je dan gelijk al je "remote ram vs local ram" argumenten moet vergeten
Het gaat me er meer om dat je maar een constante factor sneller bent, waarna het toch potentieel minder schaalt. Het verschil met het tweakers.net geheel is dat er juist niet zo veel door de DB gedaan, behalve bij elkaar zoeken van de benodigde data. En dat is al een vrij zwaar werkje.
Of het de beste setup is weet ik niet, maar wel een beproefde die in de praktijk best goed schaalt.

Waar kan ik de specs van het Tweakers server-park vinden? Ik heb me rot gezocht.

www.tweakers.net/stats en daar dan rondneuzen.

Ik dacht dat MySQL ook een master/slave setup ondersteunde.

Dat zegt nog niet dat onze setup er goed mee presteert, een clustering-setup is echt niet per definitie sneller. Zeker als elke pageview al meerdere updates kost.

[Olaf van der Spek]

ACM schreef op 25 november 2002 @ 16:20:
[nohtml]
[...]

Dan is het het zelfde verhaal, maar dan met een andere factor waar jouw systeem interessanter blijft

Alleen als je aanneemt dat de performance lineair toeneemt met het toevoegen van webservers.

[...]

Of je daarmee wel je FS-server voldoende ontlast betwijfel ik, maar het kan schelen. Maar vergeet niet dat je dan gelijk al je "remote ram vs local ram" argumenten moet vergeten

Alleen als er nu maar een (1) query gedaan wordt. Anders heeft mijn oplossing nog steeds maar een keer de remote latency.

Maar tegen wat kan ik nu benchmarken? Uit die stats valt volgens mij het aantal pages/s voor forum-data niet af te leiden

[ Voor 35% gewijzigd door Olaf van der Spek op 25-11-2002 17:30 ]

[Olaf van der Spek]

Durft niemand meer een benchmark voor te stellen die het tegen mijn oplossing opneemt?

[ACM]

OlafvdSpek schreef op 26 November 2002 @ 17:59:
Durft niemand meer een benchmark voor te stellen die het tegen mijn oplossing opneemt?

Je zult op 'hetzelfde' systeem een benchmark moeten opstellen.

Dus bijv apache + php-app/c++-app + mysql (op een enkel systeem)
vs
apache + c++-app + eigen DB

Uiteraard hoef je dan niet perse moeilijk te doen met complete applicaties, zolang ze maar voldoende functionaliteit bieden om wat output te krijgen.
En die kan je dan random een stel topics op laten halen, bijv door een stuk of 10.000 topics te vergaren/simuleren (pak die "latijnse tekst" en maak berichten van gemiddeld zo'n 500-700 tekens lang, met minima rond de 5 tekens en maxima rond de 65000 tekens. Maak daarnaast een X aantal topics waarbij de titel niet zo boeiend is (min 10 max 80 tekens ofzo) en stop daar gemiddeld 10 reacties onder met 1 reactie als minimum (de topicstart) en 1000 reacties als maximum.

En selecteer dan at random de verschillende topics. Maar dan weer met een verdeling waarbij de laatste 500 bijv 10-20x zo vaak opgevraagd worden als de overige 9500.

Tot zover je read-only test
De read-write wordt vervelender, de readtests kan je wel hetzelfde houden. Maar dan moet je nog bij de laatste 500 topics ook gemiddelde 1 op de 10-50x een reactie plaatsen oid en natuurlijk zo nu en dan een nieuw topic starten.

Mijn statistische kennis is niet wat het zou moeten zijn, maar als je dat voor elkaar hebt heb je volgens mij wel een hele mooie forum-benchmark-kit
Enige nadeel is dat het best veel werk is om op te zetten.

[CyberSnooP]

Eigenlijk moet je gewoon een stel "FakeUser" objecten spawnen die precies datgeen doen wat een echte user ook zou doen. Het spawnende progje zorgt gewoon dat hij realistische users aan maakt, een hoopje read-only-bezoekers, een paar searchers en hk-poppetjes etc. Betrek hierbij ook nog wat langzame internetverbindingen (i.v.m. eventuele slechte lock-ing van je database).
Al met al een ingewikkeld klusje wat misschien erg leuk is voor een React vs. Topix meeting.

Wat je echter wel moet bedenken (hoewel natuurlijk alles een uitdaging is) is de relevantie van schaalbaarheid tegen efficientie per server. Op het moment dat de forumsoftware voor een erg groot forum wordt ingezet waarbij dit sowieso uitmaakt gaat het meestal om een site die inkomsten genoeg genereerd zodat dat ene servertje extra ook niet meer uitmaakt. Echter software die op een gegeven moment niet meer schaalt is redelijk onbruikbaar.

Wat me ook nog niet duidelijk is is wat voor optimalisaties t.o.v. een bestaand DBMS je voor een forum-specifiek DBMS in gedachten hebt. Of gaat het puur om niet gebruikte overhead strippen? (zoals SQL-parsing).

[Olaf van der Spek]

CyberSnooP schreef op 26 November 2002 @ 22:34:
Eigenlijk moet je gewoon een stel "FakeUser" objecten spawnen die precies datgeen doen wat een echte user ook zou doen. Het spawnende progje zorgt gewoon dat hij realistische users aan maakt, een hoopje read-only-bezoekers, een paar searchers en hk-poppetjes etc. Betrek hierbij ook nog wat langzame internetverbindingen (i.v.m. eventuele slechte lock-ing van je database).
Al met al een ingewikkeld klusje wat misschien erg leuk is voor een React vs. Topix meeting.

Wil je die FakeUser objecten over HTTP laten communiceren of gewoon in de forumsoftware zelf zetten? Langzame internetverbindingen zouden geen invloed op locks moeten hebben.

Wat je echter wel moet bedenken (hoewel natuurlijk alles een uitdaging is) is de relevantie van schaalbaarheid tegen efficientie per server. Op het moment dat de forumsoftware voor een erg groot forum wordt ingezet waarbij dit sowieso uitmaakt gaat het meestal om een site die inkomsten genoeg genereerd zodat dat ene servertje extra ook niet meer uitmaakt. Echter software die op een gegeven moment niet meer schaalt is redelijk onbruikbaar.

Ook kleine forums hebben vaak last van performance problemen. En het is nog maar de vraag of dat ene servertje extra genoeg is.

Wat me ook nog niet duidelijk is is wat voor optimalisaties t.o.v. een bestaand DBMS je voor een forum-specifiek DBMS in gedachten hebt. Of gaat het puur om niet gebruikte overhead strippen? (zoals SQL-parsing).

Ik ga er vanuit dat de FS-oplossing op een server werkt en de DB-oplossing op meerdere web-servers en een DB-server. Dan verlies 'ik' geen tijd door:
Latency van request/response voor queries
Op DB-server: Copy van data van OS/DB-buffer naar query response (en van daar naar netwerk stack).
Op web-server: Copy van data van netwerk stack naar 'DB-client' (libmysql) en van daar naar forum app.
Door C++ vs PHP hoop ik ook nog wat tijd te winnen.

[ACM]

OlafvdSpek schreef op 27 november 2002 @ 16:41:
Ik ga er vanuit dat de FS-oplossing op een server werkt en de DB-oplossing op meerdere web-servers en een DB-server. Dan verlies 'ik' geen tijd door:
Latency van request/response voor queries
Op DB-server: Copy van data van OS/DB-buffer naar query response (en van daar naar netwerk stack).
Op web-server: Copy van data van netwerk stack naar 'DB-client' (libmysql) en van daar naar forum app.
Door C++ vs PHP hoop ik ook nog wat tijd te winnen.

En imho ga je daar de fout in. Je vergelijking is dan niet veel meer waard, je moet _juist_ die netwerk overhead elimineren (unix-socket connectie bijv), wil je de ruwe-performance van je DB-setup vs jouw FS-setup kunnen vergelijken.

Als je iets wilt vergelijken moet je natuurlijk zo min mogelijk variabelen veranderen, zeker de gene die je in de hand hebt.

Voor schalingsvergelijkingen kan het nog nut hebben, maar dan tellen er weer meer factoren mee.

[ Voor 7% gewijzigd door ACM op 27-11-2002 18:57 ]

[Olaf van der Spek]

ACM schreef op 27 november 2002 @ 18:53:
En imho ga je daar de fout in. Je vergelijking is dan niet veel meer waard, je moet _juist_ die netwerk overhead elimineren (unix-socket connectie bijv), wil je de ruwe-performance van je DB-setup vs jouw FS-setup kunnen vergelijken.

Kan ook, maar ik vind de vergelijking juist wel veel waard.

Als je iets wilt vergelijken moet je natuurlijk zo min mogelijk variabelen veranderen, zeker de gene die je in de hand hebt.

Voor schalingsvergelijkingen kan het nog nut hebben, maar dan tellen er weer meer factoren mee.

Als je de configuratie gelijk houdt en het performance verschil wilt weten heb je gelijk, maar als je de performance gelijk houdt en het configuratie 'verschil' wilt weten niet.

[CyberSnooP]

OlafvdSpek schreef op 28 november 2002 @ 17:21:
Kan ook, maar ik vind de vergelijking juist wel veel waard.

Je hebt in die zin gelijk dat je daarmee duidelijk kunt aantonen dat jou forum als totaal oplossing beter presteerd dan een DB-forum. Dat is natuurlijk helemaal relevant, maar vooral als je daarmee een aanzienlijke versnelling haalt. Volgens mij ben je het er zelf mee eens dat je FS-forum niet schaalt over meerdere servers. Dat is niet erg, mits je ervoor zorgt dat dat ook zelden nodig is. Dus je zou een massa mensen zoals React verwerkt aan moeten kunnen.

Ik ben echt serieus benieuwd of je dat gaat lukken en hoop dat je ook wat test resultaten hier post. Soms zit ik ook nog wel eens met de zelfde vraag en die moet toch eens een keer beantwoord worden.

[THIJZEL]

eeeh is het niet zo dat een dbms eigenlijk ook op een fs werkt, maar dan geoptimaliseerd en met vel mogelijkheden..