Tavolo Django con milioni di righe

Question

Ho un progetto con 2 applicazioni (libri e lettore).

applicazione

Libri ha un tavolo con 4 Milioni di righe con questi campi:

book_title = models.CharField(max_length=40) 
book_description = models.CharField(max_length=400) 

Per evitare di interrogare il database con 4 Milioni di righe, sto pensando di dividerlo per argomento (20 modelli con 20 . tabelle con 200.000 righe (book_horror, book_drammatic, ecc)

In "lettore" di applicazione, sto pensando di inserire questi campi:

reader_name = models.CharField(max_length=20, blank=True) 
book_subject = models.IntegerField() 
book_id = models.IntegerField() 

Così, invece di ESTERA nKey, sto pensando di usare un intero "book_subject" (che consente di accedere alla tabella appropriata) e "book_id" (che consente di accedere al libro nella tabella specificata in "book_subject").

È una buona soluzione per evitare di interrogare una tabella con 4 milioni di righe?

Esiste una soluzione alternativa?

Grazie^__^

Answer 1

Come molti hanno già detto, è un po 'prematuro dividere il tavolo in tabelle più piccole (partizionamento orizzontale o persino sharding). I database sono fatti per gestire tabelle di queste dimensioni, quindi il tuo problema di prestazioni è probabilmente da qualche altra parte.

Gli indici sono il primo passo, sembra che tu l'abbia fatto. 4 milioni di file dovrebbero essere ok per gestire il db con un indice.

In secondo luogo, controllare il numero di query in esecuzione. Puoi farlo con qualcosa come la barra degli strumenti di debug di Django, e sarai spesso sorpreso di quante query inutili sono state fatte.

Il caching è il passaggio successivo, utilizzare memcached per pagine o parti di pagine che sono invariate per la maggior parte degli utenti. Questo è dove vedrai il tuo più grande incremento di prestazioni per il piccolo sforzo richiesto.

Se davvero, davvero bisogno di dividere i tavoli, l'ultima versione di django (1.2 alpha) può gestire lo sharding (es. Multi-db), e dovresti essere in grado di scrivere una soluzione di partizionamento orizzontale (offerte postgres un modo in-db per farlo). Per favore non usare il genere per dividere i tavoli! scegli qualcosa che non vorresti mai, mai cambiare e che saprai sempre quando fai una query. Come autore e dividi per prima lettera del cognome o qualcosa del genere. Questo è un grande sforzo e ha un certo numero di inconvenienti per un database che non è particolarmente grande --- questo è il motivo per cui la maggior parte delle persone qui sta sconsigliarlo!

[modifica]

ho lasciato fuori denormalizzazione! Inserisci i conteggi comuni, le somme ecc. Nella tabella dell'autore, ad esempio, per evitare join su query comuni. Il rovescio della medaglia è che devi mantenerlo da solo (fino a quando Django aggiunge un campo denormalizzato). Guarderei questo durante lo sviluppo per casi chiari e semplici o dopo che la cache ha fallito - ma well prima di sharding o partizionamento orizzontale.

Answer 2

ForeignKey viene implementato come IntegerField nel database, in modo da risparmiare poco o niente a costo di paralizzare il vostro modello.

Modifica: E per l'amor del cielo, tenerlo in una tabella e utilizzare gli indici in modo appropriato.

Answer 3

Non ho familiarità con Django, ma ho una conoscenza generale di DB.

Quando si dispone di database di grandi dimensioni, è normale per index your database. In questo modo, il recupero dei dati dovrebbe essere piuttosto veloce.

Quando si associa un libro a un lettore, è necessario creare un'altra tabella che colleghi il lettore ai libri.

Non è una cattiva idea dividere i libri in soggetti. Ma non sono sicuro di cosa intendi con 20 applicazioni.

Answer 4

Si verificano problemi di prestazioni? In tal caso, potrebbe essere necessario add a few indexes.

Un modo per avere un'idea di dove un indice sarebbe utile è guardare il log delle query del server db (instructions here se si è su MySQL).

Se non si verificano problemi di prestazioni, è sufficiente seguirlo. I database sono fatti per gestire milioni di record e django è abbastanza bravo a generare query ragionevoli.

Answer 5

Un approccio comune a questo tipo di problema è Sharding. Sfortunatamente dipende principalmente dall'ORM (Hibernate lo fa meravigliosamente) e Django non lo supporta. Tuttavia, non sono sicuro che 4 milioni di file siano davvero così male. Le tue domande dovrebbero essere ancora interamente gestibili.

Forse dovresti cercare nella cache con qualcosa come memcached. Django supports this abbastanza bene.

Answer 6

Non hai menzionato quale database stai usando. Alcuni database, come MySQL e PostgreSQL, hanno impostazioni estremamente conservative out-of-the-box, che sono fondamentalmente inutilizzabili per qualsiasi cosa, tranne piccoli database su server minuscoli.

Se ci dici quale database stai usando, e su quale hardware è in esecuzione, e se tale hardware è condiviso con altre applicazioni (è anche in grado di servire l'applicazione web, per esempio) allora potremmo essere in grado di dare qualche consiglio specifico sull'ottimizzazione.

Ad esempio, con MySQL, sarà probabilmente necessario regolare le impostazioni di InnoDB; per PostgreSQL, dovrai modificare shared_buffers e una serie di altre impostazioni.