Tree based architecture, sql problemen?

[Verwijderd]

Hey Gotters,
Ik heb een cms geprogrammeerd op basis van Cake.
Het is een cms die alle content in een database table gooit, de 'content' table.
Het is een tree table met id/parent_id relatie. Het cms gebruik ik om snel een db website in elkaar te kunnen zetten die 'higly' customizable is. Dit vanwege de Cake basis.

Nu heb ik mn eerste grote project online gezet, een reizen site. Daarin query ik op de eerste pagina een groot deel van de bestemmingen. In totaal ongeveer 100 queries waarvan een groot deel direct op dezelfde tabel, de 'content' tabel. Het zijn queries als deze:

code:

SELECT * FROM content AS Content WHERE Content.alias = 'topmenu' 

// hierin request ik de menu structuur, dit is een laag zoals: home | bestemmingen | nieuws. In een loop // query ik het volgende

SELECT * FROM content AS Content WHERE Content.id = $val['Content']['id']
// Hierin selecteerd ik de submenu items van de hoofdmenu items.

Wanneer bv het bestemmingen menu uit 50 items bestaat en per bestemming 5 lokaties , dan query ik dus 51 x in zeer korte tijd op dezelfde tabel. Hiernaast selecteer ik ook nog eens een aantal andere zaken zoals:

code:

SELECT * FROM content AS Content, content_roles AS Contentrole, roles AS Role  WHERE Content.id = $id AND Contentrole.content_id = Content.id AND Contentrole.role_id = Role.id;
// hierin selecteer ik de restricties die gelden per item.

Bij elkaar komt het op ongeveer 100 queries, 100 queries op veelal dezelfde tabel.
Mijn vraag is of dit wel goed is voor de database server, kan mysql dit aan wanneer 5 mensen tegelijk die homepage laden...

[whoami]

Als ik het goed begrijp, heb je dus 100 queries nodig, omdat je een boom-structuur wil opbouwen ?
Denk je niet dat het beter is om alle gegevens met één query op te halen (in één keer), en dan op basis van al die gegevens de boom-structuur op te bouwen ?

[Verwijderd]

Dat kan wel wanneer ik weet waar ik moet beginnen. De hele content table kan wel bestaan uit 9000 records, het lijkt me niet goed om elke keer die 9000 records op te halen.

Het kan wel anders, met het Tree Traversal gebeuren. Maar bij een heel dynamische site is dat volgens mij een crime voor de database, bij elk nieuw toegevoegde row moet de hele volgorde opnieuw opgebouwd worden. Hiermee kun je zo selecteren:

code:

SELECT * FROM content BETWEEN lft= no, rght = no
// Dit is voor select statements heel lekker maar het instant houden van de lft + rghts vergt veel power.

Opzich denk ik dat 100 queries niet te veel heoven te zijn, hij selecteert het in minder dan een halve seconde dus dat valt mee. Maar of er ook 10/50/100 gebruikers tegelijk die 100 queries op de db kunnen loslaten..?

Ik las ook dat een mysql server op de zelfde server als de webserver trager is. Bovendien is het shared hosting. Mijn kennis van de database/server distributing is niet zo goed dat ik direct weet of het misschien daar wel mee te makien heeft.

Het probleem is het volgende. De site laad op het ene moment in 3 seconden, gister in 26 seconden. Nu heb ik een goede connectie maar voor iemand met een mindere connectie laad de site gewoon helemaal niet. Een uur later kan het weer optimaal zijn.

Dit moet ik onderzoeken en daarom moet ik ook weten wat ik in de op vraag.

[silverstorm]

Hoe zit je tabelstructuur er uit voor content? Beschrijf de velden en de inhoud van die velden eens.

Verder als het eenmalig is dat een site minder te bereiken is en dat sommige mensen de site helemaal niet kunnen benaderen, zal ik eerder zeggen dat er netwerkverbinding niet lief aan het doen was. Is het dus een eenmalig/willekeurig probleem? Gebeurt het op een bepaald tijdstip (denk dan aan backups etc).

[Not Pingu]

Verwijderd schreef op zaterdag 11 november 2006 @ 12:23:
Dat kan wel wanneer ik weet waar ik moet beginnen. De hele content table kan wel bestaan uit 9000 records, het lijkt me niet goed om elke keer die 9000 records op te halen.

Het kan wel anders, met het Tree Traversal gebeuren. Maar bij een heel dynamische site is dat volgens mij een crime voor de database, bij elk nieuw toegevoegde row moet de hele volgorde opnieuw opgebouwd worden.

Ik neem aan dat je altijd vanaf een bepaald niveau de tree wilt selecteren? Dus bijv. altijd vanaf paginaniveau ofzo. Je kunt natuurlijk een extra veld PageId opnemen voor elk tree-item, zo kun je op basis van je page id de hele zwik ophalen en in je applicatielaag verwerken naar een treestructuur die je vervolgens door je applicatie transporteert.

Tree traversal heb je hier niet perse voor nodig, maar zelfs dan is het updaten van een aantal records binnen een branch natuurlijk minder bezwaarlijk dan elke keer 100 select statements doen. Update/Insert/Delete acties komen in de regel veel minder voor dan Select acties.

[Verwijderd]

Ik bedenk me net dat ik de menuquery idd veel efficienter kan uitvoeren. Heb ook een aantal relatie tabelletjes zoals pageconfigoption, daarin staat een item dat heet topmenu. Ik tag alle items aan deze configoptie. Vervolgens kan ik ze dan selecteren en uitsluiten per level in php.
Heb het net getest en het werkt goed.
Hiermee kan ik 50 queries minder uitvoeren (in het voorbeeld van de 50 lokaties)
Maar nog staat de vraag, kan een mysql server zo veel queries op een tabel aan van verschillende gebruikers

[mrFoce]

Verwijderd schreef op zaterdag 11 november 2006 @ 14:04:
Ik bedenk me net dat ik de menuquery idd veel efficienter kan uitvoeren. Heb ook een aantal relatie tabelletjes zoals pageconfigoption, daarin staat een item dat heet topmenu. Ik tag alle items aan deze configoptie. Vervolgens kan ik ze dan selecteren en uitsluiten per level in php.
Heb het net getest en het werkt goed.
Hiermee kan ik 50 queries minder uitvoeren (in het voorbeeld van de 50 lokaties)
Maar nog staat de vraag, kan een mysql server zo veel queries op een tabel aan van verschillende gebruikers

Kan een auto 200 rijden?

Ja, maar wat voor auto. Precies Oftewel, wat voor server etc, welke mysql versie etc.

Maar lijkt mij opzich geen probleem

[MBV]

Ik ken jouw CMS niet, maar de meesten hebben toch een caching-optie? Daarmee wordt de frontpage elke 5 min geupdate, en verder alleen uit zijn cache gehaald. Als je met PHP werkt kom je daar al snel op uit bij drukbezochtte websites

[GX]

Waarom zit je content sowieso in de structuur?! Nu ja, het zal. Pre-ordererd Tree Traversal is sowieso al sneller en al helemaal zolang er meer selects dan updates zijn; tot zover ik weet word de data van een CMS vaker uitgevraagd dan aangepast, dus is het simpelweg effectiever.

En dan nog; als je je content aanpast verplaats je niet per definitie een pagina in de structuur; dus het valt allemaal /best/ mee.