Forum libero

> > > > Se volessi fare un database che possa raggiungere potenzialmente milioni di utenti, che possono fare il login e modificare i loro dati e per ora basta, che giri su un hosting gratuito o poco più senza problemi di lentezza, cosa mi conviene? SQLite? Esiste già qualcosa di pronto così non devo dissanguarmi su HTML.it?
> > >
> > > Puntare più in basso e affrontare al momento giusto l'incontrollabile afflusso di utenti.
> > > Fasciarti la testa non ti eviterà di batterla dopo.
> >
> > Sei diventato la Sibilla Cumana?
>
> Semplicemente un sistema "per raggiungere potenzialmente milioni di utenti" non nasce da zero, non viene progettato da zero, ma è il frutto dello sviluppo di qualcosa di esistente.
> Pensare di avere da subito la soluzione perfetta è un utopia, e serve solo a distrarsi dal problema reale, ad esempio attrarre milioni di utenti.
> Fino ad allora una qualunque soluzione va bene.
> Mi pare di ricordare che sarrusofero avesse detto (ma potrei sbagliare) che sqlite perde prestazioni in un battibaleno all'aumentare dei dati.
> Osserva grandi sistemi open source come approcciano ai problemi e usa il linguaggio che ti permette (a te o a chi svilupperà) di cambiare e rifattorizzare tutto il più velocemente possibile per venire incontro alle esigenze che verranno fuori.

Ma io voglio milioni di utenti subito!

La mia idea originaria era di far corrispondere ad ogni utente un file di etsto con i suoi dati, e di porre il file in una cartella che ha come nome i tre o quattro caratteri iniziali del nome utente. Ad esempio suoranciata starebbe nella cartella suo/. Considerando 26 lettere più 10 numeri, potrebbero esserci potenzialmente 36³ = 46656 cartelle, distinguendo fra maiuscole e minuscole 62³ = 238328. Nei fatti ce ne sarebbero di meno.

Ogni cartella conterrebbe un massimo di - poniamo - 10.000 file record. La verifica dell'esistenza di un utente avverrebbe per mezzo di due glob successivi, uno che verifica l'esistenza della cartella e l'altra per il file nella cartella. La funzione glob() in PHP m'è sempre parsa piuttosto veloce.

Verificata l'esistenza del nome utente, cioè individuato il file record, la verifica della password avverrebbe leggendo il nome o il contenuto del file. Anche questo mi sembra piuttosto veloce.

Problemi potrebbero ipoteticamente verificarsi con delle race conditions. Oppure certamente con limiti di memoria assegnata a un singolo processo. 10 milioni di utenti che compiono un accesso all'anno vorrebbe dire 27397,26 al giorno, 1141,55 all'ora, grossomodo uno ogni 3 secondi. Però gli utenti accederebbero solo quando devono modificare dei dati, si spera quasi mai (ad esempio sono anni che ho gli stessi indirizzi di posta elettronica).

Un problema più grave è che la mia velocità come sviluppatore consentirebbe di avere il programma pronto per la fine del millennio. Per questo chiedevo se esiste qualcosa di pronto.