Come gestire milioni di utenti?

Sto per lanciare qualcosa di veramente grande. Devo preparare il mio server e database.

Vorrei raggruppare ogni set di 100.000 utenti in tabelle utente separate, ma non so come associare un utente che prova ad accedere alla tabella utenti appropriata.

Ad esempio, come faccio a sapere che l'utente jay@mail.comè correlato alla tabella utenti # 36?

Sarebbe lo stesso avere 10 milioni di utenti in una tabella utente o 100 su 100.000?

Come funziona Facebook? Non posso credere che avrebbero una tabella utenti globale con 950 milioni di voci.

Domani non avrai un miliardo di utenti e MySQL può gestire diversi milioni di righe senza alcun problema. Ho 5 milioni di utenti nella mia tabella utenti e mi fido di me, non è nemmeno sul mio radar di cose di cui preoccuparsi.

Non preoccupatevi di sharding fino a quando si ha bisogno di farlo. Stai tentando di ottimizzare prematuramente per un problema che potrebbe o non potrebbe mai esistere e nel processo, comprometterai gravemente la velocità con cui puoi innovare. Sii veloce nel lanciarti e trova i problemi man mano che arrivano. Non puoi prevedere in anticipo quali saranno le tue sfide di ridimensionamento.

Quando e se mai raggiungerai questa scala, avrai un bel po 'di soldi e risorse da dedicare a questo tipo di problema.

Non sono sicuro che i consulenti esterni rappresenterebbero il miglior supporto per la tua azienda se hai intenzione di gestire set di dati molto grandi e devi iniziare da zero. Per favore, non fraintendetemi, ma se uno rovina un progetto con così tanti clienti, avrà un impatto sulle pubbliche relazioni sulla vostra azienda.

Per quanto riguarda le tuple 10M in una tabella, se hai una buona indicizzazione andrà bene. Abbiamo bisogno di conservare diverse tuple 100M in un tavolo qui (articoli venduti) che funziona perfettamente su un grande oracolo 11g

Ecco un post del 2010 con una mappa del design db di Facebook : progettazione del database di Facebook

Potresti voler leggere la documentazione mysql sui tipi di partizione come questa: Documentazione MySQL: Partinioning

MySQL supporta questi tipi:

RANGE partizionamento. Questo tipo di partizionamento assegna le righe alle partizioni in base ai valori di colonna che rientrano in un determinato intervallo. Vedi Sezione 18.2.1, "GAMMA Partizionamento".

LISTA del partizionamento. Simile al partizionamento per RANGE, tranne per il fatto che la partizione è selezionata in base a colonne che corrispondono a una di una serie di valori discreti. Vedere la Sezione 18.2.2, "ELENCO partizionamento".

Partizionamento HASH . Con questo tipo di partizionamento, viene selezionata una partizione in base al valore restituito da un'espressione definita dall'utente che opera su valori di colonna nelle righe da inserire nella tabella. La funzione può consistere in qualsiasi espressione valida in MySQL che produce un valore intero non negativo. È disponibile anche un'estensione di questo tipo, LINEAR HASH. Vedere la Sezione 18.2.3, "Partizionamento HASH".

Partizionamento KEY . Questo tipo di partizionamento è simile al partizionamento tramite HASH, tranne per il fatto che vengono fornite solo una o più colonne da valutare e il server MySQL fornisce la propria funzione di hashing. Queste colonne possono contenere valori diversi da quelli interi, poiché la funzione di hashing fornita da MySQL garantisce un risultato intero indipendentemente dal tipo di dati della colonna. È disponibile anche un'estensione per questo tipo, LINEAR KEY. Vedere la Sezione 18.2.4, "Partizionamento chiave".

Prima di tutto, non separare gli utenti in tabelle separate. Renderà le cose complesse e inutili. Database come MySQL e altri possono funzionare con i database di milioni di record nella stessa tabella senza alcun problema (con i tasti PRIMARY giusti impostati). Utilizzare il campo chiave univoco AUTO_INCREMENT AND PRIMARY del database per ciascun utente (nella tabella utenti principale), quindi ogni record è univoco (UID). Quindi nelle altre tabelle ti riferisci usando quell'ID univoco. Quindi assicurarsi che in ogni tabella sia impostato come PRIMARY KEY, accelererà l'elaborazione delle informazioni nel server di database. Puoi imparare da Drupal CMS come memorizza le informazioni dell'utente. Testato in oltre 10 anni da milioni di utenti e aziende di grandi dimensioni (utilizzato da grandi società di media, governo, persino le più grandi banche del mondo). Su www.drupal. org troverai più di 1,6 milioni di pagine (nodi) memorizzati nella stessa tabella e ha più di milioni di visitatori unici al mese e il sito web funziona senza problemi. Tutto riguarda la corretta ottimizzazione e configurazione.

Dopo 10 milioni di record, se non sei soddisfatto delle prestazioni (dopo l'ottimizzazione corretta e le modifiche alla configurazione del db), puoi decidere se vuoi davvero separare gli utenti da tabelle diverse. Quindi puoi effettivamente estendere la funzionalità aggiungendo una nuova tabella che contiene informazioni su dove sono conservati i record degli utenti: UID e nome_tabella. Quindi in una qualsiasi delle altre tabelle richiedi queste informazioni, questa tabella cercherà la tabella giusta. Ma ti consiglio davvero di avere una grande tabella per gli utenti, a meno che tu non abbia più di 10-100 milioni di record. Ma non migliorerà molto le prestazioni (i database sono progettati per gestire i dati enormi). È meglio mantenere le informazioni semplici. Di solito le aziende decidono solo per un altro server di database (master e slave) e un altro, quindi ' collaborare con la funzionalità di bilanciamento del carico. Se avrai quei 10 milioni di utenti, potresti pagare per un altro server db, giusto?

Vedi l'esempio dello userschema delle tabelle nel file user.install .

Come suggeriscono le altre risposte, non è una buona idea dividere gli utenti in più tabelle. La maggior parte dei database con indici sull'id utente può gestire milioni di righe. Tuttavia, la latenza per query può aumentare a seconda del numero totale di voci nell'indice. Finché il set di dati è piccolo, è possibile gestirlo con una singola tabella in database normali.

Cercherò di dare un'idea diversa anche per la tua futura considerazione se cresci molto oltre un milione di dischi. Con un numero così elevato di clienti, non si desidera alcun downtime ecc. Quindi, ci sono un sacco di database nosql che potresti voler guardare. Faranno lo sharding per te invece che per te stesso gestendo lo sharding dall'applicazione. Forniranno inoltre ridondanza dei dati e quindi più tempo di attività. Facebook e tutti usano pesantemente memcache ecc. Per la loro cache. Ma non sono sicuro di cosa usino per il loro negozio permanente.

Una cosa importante da tenere presente è che non è possibile eseguire join, ecc. Con i database nosql. Quindi, pianifica il tuo caso d'uso e decidi. Se i join e le transazioni multi-record sono una necessità per te, i database nosql non fanno per te.

perché non dividere in base all'intervallo alfabetico? Se avrai milioni di utenti, crea una tabella separata per ogni lettera o per coppia di lettere (tabella 'a' per utenti con nome utente che inizia con 'a'). All'inizio sarà molto dispendioso, ma poiché ti aspetti un grande database e vuoi essere in grado di distinguere quale tabella dovrebbe essere utilizzata per un determinato utente - immagino che l'ordine alfabetico sia la scelta ovvia e più semplice.