[forum] & schaalbaarheid

[wasigh]

Ik zit er aan te denken een forum in java (J2EE) te gaan programmeren. Maar een belangrijke eis (zoals te merken is aan GoT) is dat het forum schaalbaar moet zijn. Dat wil zeggen dat het makkelijk over meerdere database servers verdeeld moet kunnen worden.
Dus als er load problemen zijn dat het een kwestie is van een server erbij zetten max 30 min configureren en dat het dan moet draaiien. (utopie, ik weet het )

Ik dacht zelf aan 2 oplossingen:
1: een database nemen die schaalbaar is. (welke )
2: je forum zo schrijven dat ie schaalbaar is
(een laag tussen de database en het forum die het verkeer afhandeld) maar hoe zou ik dit het beste kunnen implementeren. Ik heb helaas nog weinig ervaring met dit soort dingen. Iemand tips?

[Verwijderd]

Op zaterdag 13 oktober 2001 10:02 schreef wasigh het volgende:
1: een database nemen die schaalbaar is. (welke )

Ik denk dat je een keuze moet maken: Of sql queries schrijven die compatible zijn met alle/meeste database servers. Of heel specifiek voor een bepaalde database server schrijven. Bijvoorbeeld Oracle8i ofzo (wordt veel gebruikt in combinatie met Java, een gratis developers versie is wel bij oracle.com te krijgen).

2: je forum zo schrijven dat ie schaalbaar is
(een laag tussen de database en het forum die het verkeer afhandeld) maar hoe zou ik dit het beste kunnen implementeren. Ik heb helaas nog weinig ervaring met dit soort dingen. Iemand tips?

Dus je wilt dat je forum meerdere database servers gebruikt? Hoe had je dat in gedachten? De members database op de een, de posts op de ander ofzo? Ik weet niet of dat wel zo'n goed idee is. Verder zou je je database op meerdere servers kunnen mirroren, maar of dat de snelheid en schaalbaarheid op den duur ten goede komt kun je je ook afvragen.

[Verwijderd]

als je nu eens bepaalde taken gaat opsplitsen (naar aparte servers, maar met de mogelijkheid dat een server meerdere taken doet)?

Dus als je even got als voorbeeld neemt:

- een server doet de frontpage met de verschillende forums.
- een aantal servers doen de overzichten van de diverse forums.
- een aantal servers slaan de diverse topics op (een topic bevindt zich altijd in het geheel op een bepaalde server)

Bij een toevoeging van een topic moeten de servers die de lijst van topics van het forum bevatten geupdate worden, door over een geopende socket "efficient" de belangrijkste dingen zaken over te sturen.

Als je kijkt naar got, betekent het wel dat je een aantal features zal moeten laten vallen... omdat je anders nogal veel verkeer tussen de topic servers en de overzicht/voorpagina servers krijgt.

Wanneer je als bezoeker een forum uitkiest, bepaald de voorpagina server welke overzicht-server wordt uitgekozen. De overzicht-server bepaald vervolgens welke topic server er genomen moet worden om het vervolgens gekozen topic te bekijken, nieuwe topic aan te maken, topic te wijzigen. Dit kan dus simpel gedaan worden door de url's te veranderen in het ip-nummer van de server die die info bevat (dat kan dus ook zijn eigen ip-nummer zijn!).

[Verwijderd]

umm... als je J2EE gebruikt/die standaard aanhoudt,
waarom dan niet meteen EJB's gebruiken? dan heb je die schaalbaarheid bijna meteen... tenminste, zoiets staat in de specs dat je app's gedistribueerd kunt draaien

[wasigh]

Op zaterdag 13 oktober 2001 10:47 schreef joeblade het volgende:
umm... als je J2EE gebruikt/die standaard aanhoudt,
waarom dan niet meteen EJB's gebruiken? dan heb je die schaalbaarheid bijna meteen... tenminste, zoiets staat in de specs dat je app's gedistribueerd kunt draaien

Het gaat om de schaalbaarheid van de database.
Ik wil mijn database over meerdere (oneindig veel)servers kunnen draaiien. En voor het programma (en de gebruikers)
moet het eruit zien dat het 1 server is.

In principe moet het programma dus totaal niets te maken hebben met hoe/of de database verdeeld is over meerdere server

[raptorix]

Als ik jou was zou ik veel tijd besteden aan goed caching systeem, en waarom? Omdat meer load in principe nauwelijks voor meer queries zou moeten zorgen, stel dat 90 procent van je website gecacht wordt, dat betekent dan dat een verdubbeling van load maar voor 10% meer extra db verkeer zorgt.

Als ik GOT zo zie vind ik het ongelovelijk dat er nog steeds niets gecacht wordt terwijl het zo makkelijk te implementeren is.

Als je een database neemt die niet via transacties werkt zou je misschien een soort systeem queing systeem kunnen maken, die de laatste update/insert achteraan in de rij zet, vervolgens ga je de boel bijwerken van de andere kant, het voordeel is dat je dan zelf meer controle hebt op je database.

[DiSiLLUSiON]

raptorix:

Ik heb me niet helemaal toppie verdiept in het hoe en wat van verschillende cache-manieren, maar waar heeft cacheing voor zin, op een forum? Bij een forum als GoT ben je volgens mij nog langer bezig alles in cachebestanden (of hoe je 't ook doet) te schrijven, dan dat ie bezig zou zijn de pagina direct uit de db te halen..

[Verwijderd]

Op zaterdag 13 oktober 2001 11:25 schreef DiSiLLUSiON het volgende:
raptorix:

Ik heb me niet helemaal toppie verdiept in het hoe en wat van verschillende cache-manieren, maar waar heeft cacheing voor zin, op een forum? Bij een forum als GoT ben je volgens mij nog langer bezig alles in cachebestanden (of hoe je 't ook doet) te schrijven, dan dat ie bezig zou zijn de pagina direct uit de db te halen..

Correct, zie ook de vele topics en berichten van o.a. Femme hierover in Lieve Adjes.

[ACM]

Op zaterdag 13 oktober 2001 11:25 schreef DiSiLLUSiON het volgende:
raptorix:

Ik heb me niet helemaal toppie verdiept in het hoe en wat van verschillende cache-manieren, maar waar heeft cacheing voor zin, op een forum? Bij een forum als GoT ben je volgens mij nog langer bezig alles in cachebestanden (of hoe je 't ook doet) te schrijven, dan dat ie bezig zou zijn de pagina direct uit de db te halen..

Sja, dan zul je de afzonderlijke posts moeten cachen (wordt geloof ik al gedaan ) of de "meest voorkomende" hist moeten cachen. Hoeveel mensen hebben de page-views op 25, 50 en 100 posts staan? het overgrote deel heb je daarmee afgevangen. Nog mooier is het als je het dan in chunks van 25 cached. En de posts/page verplicht op X*25 stelt.

Als je echter een goed(e) 'clusterende' database hebt zou het geen probleem moeten zijn om je queries 'zonder moeite' te schalen.
Om de webservers te kunnen schalen moet je eigenlijk niks "lokaal" opslaan (liefst zelfs de caches op een shared schijf oid, maar dat is natuurlijk erg gevaarlijk), maar vooral de session-data etc.

Maar ondanks dat raptorix beweert dat caches erg simpel zijn, is een goed caching algoritme (je moet de topics odd ook nog es wegsmijten als ze niet meer gebruikt worden) en het algoritme mag natuurlijk niet de executie vertragen...

[MoBi]

1 database die schaalbaar is heeft bij altijd clustering supoort of loadbalancing. Oracle, mssql. De grote dus. Daardoor lijkt 1 db op 1 machine te staan terwijl het er meerdere zijn.

2 je forum kan je zo schrijven dat je verschillende db's ondersteund door de query's in te includen. Dan kan je voor iedere db de query zo snel mogelijk kunnen schrijven zonder dat dat op een andere db server een negatieve preformance opleverd.

[MAZZA]

Op zaterdag 13 oktober 2001 10:07 schreef Zef het volgende:
Bijvoorbeeld Oracle8i ofzo (wordt veel gebruikt in combinatie met Java, een gratis developers versie is wel bij oracle.com te krijgen).

Is Oracle niet een beetje overkill voor een forum database

[ACM]

Op zaterdag 13 oktober 2001 19:27 schreef MAZZA het volgende:
Is Oracle niet een beetje overkill voor een forum database

Hangt ervanaf... Als je forum onderdeel van een veel grotere site is, waarom zou je dan meerdere DB's gaan gebruiken?

[The - DDD]

Verschillende databases: Ik zeg thin JDBC connectie. Da's namelijk de meest compatible manier van database connecties.

Maar euh, nooit gehoord over gedistribueerde databases?

Het is prima mogelijk om bijvoorbeeld twee machines te hebben die frontend als 1 database functioneren en die backend (dus via een eigen netwerkje onderling) de zaken up to date houden. MAAR!!, dit is vooral handig bij transactie systemen, omdat een transactie pas boeiend is als die gecommit wordt.

Load verdeling in een forum omgeving. Hmmm, nah loadbalancing http servers is iets wat we wel kennen.

Maar de database dat is het meest lastige denk ik. Een forum is nou eenmaal een immer groter wordende bak veelal statische informatie. Snel data kunnen weg pompen is dan het belangrijkste. Zorg dus dat je dataaanvraag van de database server zo min mogelijk is. Dus cachen. Probleem met cachen: Wat als iemand zijn reply wijzigt?

Wat wel mogelijk is, is om per sub forum (stuffis generalis, PW, etc...) eventueel een eigen database in te richten, die op een eigen server draait. Dan splits je de data dus op. Eventueel minder grote fora pleur je dan in 1 database. Daarnaast een centrale user database. (want face it, per reply, post, read wordt er een user check gedaan).

Als je dat nou dan gedistribueert opzet met EJB's. Dan moet je denk ik wel een aaridg systeempje hebben. De session beans krijgen een user request, deze session bean checked de rechten en onthoud deze voor de deur van de sessie, dus je hebt je user database al niet meer direct nodig. Schrap da's al iets wat dan weg valt. De session bean communiceerd dat via een te implementeren manier met de juiste databases.

De session beans staan bepaalde dingen wel of niet toe aan de hand van de gebruikers authorisatie. De session beans mogen overal komen, maar doen dat niet aan de hand van wat hij van de user authenticatei begrepen heeft wat wel mag. Je zou ook je session beans kunnen overerven, da's helemaal mooi. Een bean factory die dus een request krijgt, die beanfactory maakt dan een juiste sessionbean aan met de juiste gegevens. Dan krijg je dus een mod-bean, user-bean, fora-mod-bean. En bedenk nog maar wat.

Je merkt dat ik erg java denk, maar da's gewoon mijn favoriet en vele malen beter te schalen dan PHP of ASP. Bovenstaande is eigenlijk wat ik zo even in mijn hoofd uitdacht terwijl ik tiepte, het kan dus een niet al te samenhangend verhaal zijn, maar als je het goed leest dan is het wel te volgen denk ik.

[wasigh]

Als ik dus mysql over meerdere servers wil kunnen draaien
(geen replication, maar loadbalancing!)
dan zal ik zelf de tussenliggende laag moeten schrijven?

of een "grote" database nemen en daar flink wat geld voor neerleggen?

[Verwijderd]

Op zaterdag 13 oktober 2001 19:36 schreef wasigh het volgende:
Als ik dus mysql over meerdere servers wil kunnen draaien
(geen replication, maar loadbalancing!)
dan zal ik zelf de tussenliggende laag moeten schrijven?

of een "grote" database nemen en daar flink wat geld voor neerleggen?

Die "grote" databases kosten natuurlijk niet voor niks veel geld he

[The - DDD]

Op zaterdag 13 oktober 2001 19:36 schreef wasigh het volgende:
Als ik dus mysql over meerdere servers wil kunnen draaien
(geen replication, maar loadbalancing!)
dan zal ik zelf de tussenliggende laag moeten schrijven?

of een "grote" database nemen en daar flink wat geld voor neerleggen?

Yup, maar ik kdenk toch dat de grootste winst bij de databases voor een forum te halen zijn bij het ontlasten van de database server. Dus je data slim scheiden over meerdere database servers (dus technisch gezien GEEN gedistribueerde database, maar van elkaar onafhankelijk opgeslagen data), ergens toch een vorm van data caching (alhoewel dit bij een forum waarschijnlijk niet echt effectief zal zijn) en efficiente query's.

[wasigh]

Op zaterdag 13 oktober 2001 19:48 schreef The - DDD het volgende:

[..]

Yup, maar ik kdenk toch dat de grootste winst bij de databases voor een forum te halen zijn bij het ontlasten van de database server. Dus je data slim scheiden over meerdere database servers (dus technisch gezien GEEN gedistribueerde database, maar van elkaar onafhankelijk opgeslagen data), ergens toch een vorm van data caching (alhoewel dit bij een forum waarschijnlijk niet echt effectief zal zijn) en efficiente query's.

maar ik zou het dan zo willen hebben, dat het voor het programma lijkt alsof er maar 1 server is...

een mooie interface zeg maar.

Alleen ben ik bang dat dat wel erg moeilijk gaat worden
en helaas heb ik er geen tijd voor

[The - DDD]

Met java valt wel mee denk ik hoor. Denk eerder dat de middelen die je beschikbaar moet hebben erg kostbaar zullen zijn.

[wasigh]

Op zaterdag 13 oktober 2001 20:51 schreef The - DDD het volgende:
Met java valt wel mee denk ik hoor. Denk eerder dat de middelen die je beschikbaar moet hebben erg kostbaar zullen zijn.

Nou ik moet het met mysql doen..

[raptorix]

Op zaterdag 13 oktober 2001 13:15 schreef ACM het volgende:

[..]

Sja, dan zul je de afzonderlijke posts moeten cachen (wordt geloof ik al gedaan ) of de "meest voorkomende" hist moeten cachen. Hoeveel mensen hebben de page-views op 25, 50 en 100 posts staan? het overgrote deel heb je daarmee afgevangen. Nog mooier is het als je het dan in chunks van 25 cached. En de posts/page verplicht op X*25 stelt.

Als je echter een goed(e) 'clusterende' database hebt zou het geen probleem moeten zijn om je queries 'zonder moeite' te schalen.
Om de webservers te kunnen schalen moet je eigenlijk niks "lokaal" opslaan (liefst zelfs de caches op een shared schijf oid, maar dat is natuurlijk erg gevaarlijk), maar vooral de session-data etc.

Maar ondanks dat raptorix beweert dat caches erg simpel zijn, is een goed caching algoritme (je moet de topics odd ook nog es wegsmijten als ze niet meer gebruikt worden) en het algoritme mag natuurlijk niet de executie vertragen...

Een goed caching mechanisme hoef je echt niet zelf te verzinnen, er zijn diverse zeer goede objecten bescikbaar, die je met een paar regels code goed kan implementeren, daarnaast zal het in microsoft.net standaard aangeboden worden , voor de site waar ik de laatste tijd aan gewerkt hebt hebben we het caching object uit commerce server 2000 gebruikt, echt meer als 20 regeltjes code is het niet.

Overigens, kan ik me de reacties van femme nog wel herinderen, volgens hem zou de site qualiteit minder zijn als caching goed toegepast wordt merk je er geen fuck van.