Skulle nog aldrig rekommendera nån att använda blobbar om man absolut inte måste. Speciellt inte i ett högtillgänglighetssystem där prestanda är ett krav.

Och sessioner hade jag ogärna sparat på klientsidan även om man krypterade dom - kakor är inte alltid gott.

Vad krångligt att ha filer i databas. Filsystem är ju den smidigaste sortens databas att ha filer i... :D

Om man replikerar en MySQL-databas som du beskriver så kommer alla bilder ligga på alla MySQL-servrar. Onödigt slöseri med hårddisk och prestanda. NFS (eller SMB för Windows) är ju gjort för delning av filer över nätverk :D

Visst kan man lägga en del icke-kritiska sessionvariabler krypterat på klientsidan, men man vill ändå inte lägga all sessiondata där (såsom vilken användare man är inloggad som)? Isf är det ju ingen mening att lägga en del hos klienten.

Bör väl gå rätt bra att använda någon form av nätverkslagring för bilder och framförallt att ha dem på en egen server.

Vore kul att höra hur ni löser det på sikt. Det finns ju också relativt enkla lösningar som att uppgradera servern med flera processorer och liknande...

Det tycker jag är "fel" ställe att börja på, i längden kostar det bara mer än att använda det otrevliga uttrycket "gör om, gör rätt".
Kasta hårdvara på problemen skjuter bara upp dom till imorgon :-)
Dessutom är det ju så otroligt roligt att optimera saker! (Tycker jag på riktigt) :)

Hårddiskutrymme? Alltså så här ÄR det: Om du vill eliminera din "one single point of failure" måste du lagra datat redundant.

Ett sätt är det att göra som jag sa, replikerat över MySQL-servrar. Annat sätt är att utnyttja någon form av distribuerat filsystem från en filserver. Ett tredje sätt är att haka på flera servrar på samma diskarray (fast där är det HA vi pratar om och inte LB eftersom bara EN server kan komma åt filerna åt gången).

Prestandamessigt är det ju naturligtvis MySQL-lösningen som har störst överhead. Men ifall man pratar om små datamängder kan den överheaden vara försumbar med tanke på att priset blir annorlunda.

Vad jag kan tänka mig är att den här lösningen inte är värst skalbar.


Vad bertäffar sessionsdata, så visst, om jag hade en internetbank skulle jag väl inte förlita mig på det. Däremot tror jag bestämt att du kan få tillräckligt god säkerhet ifall du ska driva ett community eller liknande.

Om du sparar username i kakan, samt på serversidan ser till att du genererar en checksumma från username + någothemligt-innehåll + IP + whatsoever (för varje användare olika), och sen lagrar checksumman som kaka, så har du kommit en bit på väg. (se till bara att använda ssl).

/Zoran

Standardlösningen man bygger i ett sånt här läge är ju en enklare form av lastbalansering. Det är bäst i form av pris och prestanda.

* N antal webservrar som står i ett lastbalans-"cluster", antingen bakom en riktig lastbalanserare eller bakom t.ex. en maskin som kör gnu balance.

* En filserver (eller fler beroende på hur stabilt man ska ha det) som kör t.ex. NFS och delar ut alla webfiler.
Evt kan man även rsynca över filerna till varje webserver.
* En databas-server. Vill du ha det mer redundant får du replikera den också.

Billig-varianten här är att köra filserver & databas-server på samma maskin - har du inte nån vidare last på databasen så går det oftast alldeles utmärkt, och eftersom du ändå har SPOF (single point of failure) på en replikerad databas i.o.m. att den inte står i ett riktigt cluster, så behöver du inte ha en extra maskin i onödan om prestandan inte är problemet.

Men att lagra bilder i BLOB'ar och göra selects, det är förkastligt. Och att lagra användardata på klientmaskinen, det skulle jag av säkerhetsskäl aldrig göra - det är nog att nån öppnar sin session efter dom har fattat hur du krypterat din nyckel och byter sitt användarid t.ex.
Tänk om Lunarstorm hade lagrat allt hos dig, den hade varit knäckt för länge sen och massvis av människor hade varit inne på olika personers konton. Nej, det är _inte_ en bra lösning.