Ho bisogno di costruire un social network che si aspetta un traffico molto alto, 10k - 50k + registrazioni in un giorno, nemmeno i visitatori inclusi, visualizzazioni di pagina, upload di immagini, ecc ..., un sacco di attività del database. Al momento abbiamo un solido server dedicato quad-core con 8GB ddr3 e 2tb hdd sata. La dottrina dovrà rallentare per quanto riguarda le query e il tempo di caricamento per gestire un sito Web con un traffico così elevato?
Risposta breve: peggiorerai sicuramente le prestazioni e nasconderai funzionalità specifiche del database che potrebbero fornire più prestazioni.
Suggerimento: utilizzare MongoDB - e un database solo dove sono richiesti dati ACID altamente relazionali e transazionali. Non c'era bisogno di ORM. Orm nasconde le implementazioni del data-store sottostante. Questa è una grande cosa e una cosa terribile allo stesso tempo. Usiamo MongoDB e Postgres nella mia azienda; Questo non cambierà per molto tempo. Il nostro codice è facile da leggere, al punto, e non si basa su "middleware". Quando sono diventate disponibili le nuove funzionalità di Postgres 9, potremmo approfittarne immediatamente. Quando il driver Python MongoDB è stato aggiornato, è possibile effettuare il refactoring molto facilmente: non è necessario modificare il livello di ORM per ottenere questo risultato.
Se stai costruendo qualcosa del genere avrai bisogno di una combinazione di database. Un database di ricerca testo, un database relazionale e un database senza schema veloce, forse? In che modo un ORM aiuta a risolvere questo problema? - Non è così.
La risposta è sempre Utilizza query normali anziché ORM per ottenere prestazioni migliori. Se stai pianificando di modificare il database dopo un periodo più lungo, ORM ti aiuta a farlo facilmente. Devi sacrificare le prestazioni per comodità.
Ti suggerisco di creare una classe separata in cui puoi eseguire operazioni DML ottenendo gli input come parametri e creare la query e utilizzarla per eseguirla. Invece di scrivere la frase di inserimento ogni volta o per molte occorrenze. ma assicurati anche di creare la query che è più ottimizzata.