Qual è un buon equilibrio tra il riutilizzo dei campi e la creazione di nuovi campi nel contesto della scalabilità dei campi?

34

Ho letto la seguente frase su un sito Web:

Invece di aggiungere nuovi campi a un tipo di contenuto, l'aggiunta di campi esistenti è un'opzione migliore per ridurre la complessità del sistema e migliorare la scalabilità.

E sorgono alcuni dubbi.

Nel sistema che stiamo sviluppando, abbiamo la possibilità di riutilizzare un campo attraverso 3 o 4 tipi di contenuto ma invece di migliorare la scalabilità come dice la frase citata, temo che lo diminuirà, perché la tabella del campo diventerebbe più rapidamente un collo di bottiglia (almeno questo è il mio ragionamento in questo caso, dato che tutti i valori di quel campo insieme sarebbero un paio di milioni all'anno e ciò renderebbe il tavolo troppo grande). Sei d'accordo?

Quante file sarebbe un massimo ragionevole a cui puntare quando si progetta? In questo modo potremmo decidere quando riutilizzare i campi e quando crearne di nuovi (anche se c'è la possibilità di riutilizzarli).

entities performance

— rafamd
fonte

6

Mi piacerebbe vedere le risposte salvate con metriche effettive.

— mpdonadio

Penso che abbiamo raccolto commenti molto costruttivi e informativi su questa domanda. Tuttavia, aspetterò uno o due giorni prima di contrassegnare la risposta, poiché qualcosa dentro di me insiste sul fatto che mantenere uno o due campi più pesanti separati (nonostante possano essere riutilizzati) potrebbe essere una buona idea :) ... specialmente conoscendo quelli i fileds potrebbero facilmente crescere di 5, 10 o 20 milioni di articoli all'anno.

— rafamd,

24

La quantità di dati in un campo di solito non è un problema. Se sei preoccupato, cerca plugin di archiviazione sul campo alternativi o scrivi il tuo. Ad esempio MongoDB , che può gestire praticamente qualsiasi cosa tu ci inserisca. È ad esempio utilizzato su http://examiner.com .

Un vero problema tuttavia è il numero di campi che hai. Poiché attualmente in Drupal 7, la configurazione di campo completa di tutti i campi, indipendentemente dal fatto che siano caricati o meno, viene recuperata dalla cache su ogni singola richiesta.

Ho visto siti con oltre 250 campi, dove caricare e annullare la serializzazione della configurazione del campo richiede 13 MB + memoria.

Modifica: la cache delle informazioni sui campi è stata migliorata (vedi http://drupal.org/node/1040790 per i dettagli) con Drupal 7.22, solo i campi dei bundle visualizzati su una determinata pagina vengono caricati dalla cache e sono voci della cache separate. Funziona solo se non ci sono chiamate API errate che richiedono istanze su più bundle.

— Berdir
fonte

Ciao Berdir, grazie per la tua risposta. Non sapevo di quel sovraccarico per il numero di campi. Quindi, dovremmo cercare di riutilizzare il più possibile, ma non dovremmo cercare di dividere quelli che sappiamo essere i più pesanti? Non so molto di mongo e simili, ma è davvero che a loro non importa delle dimensioni di un gruppo che devono interrogare? Grazie !

— rafamd,

In realtà non lo so. Dipende, immagino. Fare un test come suggerito da MPD potrebbe non essere una cattiva idea. Puoi persino confrontarlo a un livello molto basso direttamente in Mysql. Crea due tabelle con lo stesso layout e indici delle tabelle dei dati dei campi, scrivi 10m (assicurati di utilizzare effettivamente valori diversi per entity_id) righe in una e 5m nella seconda. Quindi confrontare le prestazioni di scrittura e le prestazioni di lettura (in base a entity_id aka un indice). Ho il sospetto che le prestazioni di lettura saranno quasi uguali grazie all'indice, ma le prestazioni di scrittura potrebbero fare la differenza.

— Berdir,

Detto questo, avere una manciata di campi più o meno non farà davvero la differenza, quindi se ti senti più a tuo agio in questo modo, non dovrebbe essere un problema.

— Berdir,

Le scritture sono la parte difficile, quindi la mia raccomandazione di fare un test. Ciò che può essere controintuitivo è il fatto che MySQL elimina le voci memorizzate nella cache in base alla tabella e non alla riga (l'ultima volta che ho controllato). Non sono sicuro di quale sarebbe un impatto maggiore, l'overhead di memoria di più campi e tabelle o cache-miss dalle scritture sulla stessa tabella. Tuttavia, dipende sicuramente dal traffico / uso. I sistemi con più cache (cache Drupal, codice operativo APC, utente APC, cache delle query MySQL, memcached, vernice, ecc.) Rendono le decisioni basate sull'intestino molto difficili senza profilazione.

— mpdonadio

questo non è più il caso: drupal.org/node/1040790

— jackbravo

13

Sono totalmente d'accordo con Berdir. Ecco le mie esperienze con un progetto con milioni di righe e 30-40 campi su alcuni tipi di nodo.

Il numero di righe in una tabella dei campi non è un grosso problema per le prestazioni di lettura, poiché tutti i campi vengono recuperati dalla chiave primaria.
Il numero di campi per tipo di nodo può crescere rapidamente in grossi problemi di prestazioni durante la scrittura di nuovi nodi. Avere più di 30 campi per un tipo di nodo risulta in oltre 60 istruzioni INSERT quando si crea un nuovo nodo. Questa operazione richiede alcuni secondi. Se sei utenti che creano molti dati, ciò influirà sulle tue prestazioni. Gli inserti in blocco di 1000 nodi impiegheranno quasi un'ora. Se devi aggiornare 100'000 nodi, questo è un grosso problema.
Se pensi che il problema del numero di campi ti colpirà, dovresti seriamente pensare di scrivere la tua memoria di campo o semplicemente non usare i campi. (Puoi comunque far funzionare il tuo nodo con le viste con qualche sforzo in più.)
Una parola su MongoDB. È un progetto molto interessante e spero lo stia trasformando nell'olimpo dei grandi DB. Purtroppo rispetto alla maturità di MySql o PgSql è un bambino. Preparati ad affrontare un prodotto molto giovane.

— BetaRide
fonte

Ciao @BetaRide, grazie per la tua comprensione. Circa 2), stiamo già cercando di ridurre al minimo il numero di campi per tipo di contenuto e non è esattamente quello di cui stiamo discutendo qui. Il vero affare è: dovrei riutilizzare ciecamente i campi ogni volta che è possibile o dovrei provare (almeno) a separare uno o due più pesanti (anche se potrebbero facilmente essere gli stessi, ad esempio: hanno effettivamente lo stesso nome, ecc.). Sì, mongo dovrebbe essere la nostra ultima alternativa per ora :)

— rafamd,

5

Se sei davvero preoccupato per ciò che accadrà, penso che una simulazione sia in ordine.

Ottieni un account su Rackspace Cloud, Amazon, Linode o in qualsiasi altro luogo in cui puoi facilmente creare un VPS. Crea due istanze identiche. Installa Drupal su ciascuno. Crea alcuni tipi di contenuto fittizio e imposta i campi in un modo in un sistema e in un altro modo nell'altro. Utilizzare il modulo di sviluppo per creare un carico di contenuti. Regola le impostazioni delle prestazioni per assicurarti che Drupal stia memorizzando nella cache, se necessario. Esegui mysqltuner e regola MySQL su ciascuno per raccomandazioni. Ricontrolla le impostazioni di PHP e APC in modo da non colpire lo swap e che non stai sfornando la cache APC.

Una volta ottenuta una buona configurazione di base per ciascuno, inizia a simulare il traffico (sia i visitatori normali che gli aggiornamenti dell'amministratore) con wget e drush, quindi il profilo.

Le simulazioni non sono mai perfette, ma possono portarti nella giusta direzione.

— mpdonadio
fonte

2

Un problema con la scalabilità nei campi nell'uso degli indici su ogni singolo campo della tabella in ogni campo della tabella creata. L'indice cluster della chiave primaria è un composto della maggior parte dei campi, quindi ha creato indici separati su ogni singolo campo. Gli indici creano un sacco di scritture generali per il database e nella maggior parte dei casi non vengono mai utilizzati.

— jozwikjp
fonte

2

un altro consiglio: avere un sacco di campi causerà problemi anche con molti moduli diversi. La GUI token, ad esempio, farà rallentare il browser per minuti se, ad esempio, si tenta di modificare gli alias degli URL. Questo comportamento può essere visualizzato su tutte le pagine in cui il token verrà caricato e visualizzato (incluso devel - dpm () ecc.)

Non vi è alcun vantaggio in termini di prestazioni nella suddivisione di questi dati su più tabelle quando si utilizza InnoDB (MyISAM è diverso a causa del blocco delle tabelle). Quindi - se sai che avrai molti tipi di contenuto simili con campi simili (le cui configurazioni saranno uguali, forse differiranno solo nell'etichettatura) riutilizzi i tuoi campi!

Potrebbe anche facilitare la creazione di modelli a causa di attributi di nodo simili.

— Andre Baumeier
fonte

1

Solo condividendo la mia storia, stiamo usando Drupal Commerce e abbiamo circa 40 campi nelle nostre varianti di prodotto (Sku) e poi altri 460 (sì, pazzi) nel nostro Product Display. Avevamo alcune viste di confronto dei prodotti che avrebbero esaminato tutti questi campi. Senza memorizzazione nella cache, alcuni caricamenti di pagina potrebbero richiedere fino a un minuto!

Tuttavia, ha funzionato. Se hai usato la cache e Varnish, il tempo di attesa dell'utente non è stato poi così male.

Il problema principale che abbiamo riscontrato in così tanti campi è con Display Suite, in quanto ciò diventerebbe molto lento (a volte non reattivo) se provassimo a riorganizzare o spostare un campo.

Fortunatamente, abbiamo deciso di ricodificare un po 'i nostri prodotti in modo da poter sperare di portare il nostro numero massimo di campi nella gamma 200-250 per i nostri prodotti più complessi (siamo in strumentazione scientifica, quindi sono necessarie misure e specifiche complesse) .

— Waterskier19
fonte

0

È una domanda interessante Ci ho pensato prima, a volte riutilizzare un campo può essere conveniente per non avere un sacco di campi simili 'in giro' ma sembra sciocco avere un certo tipo di contenuto che deve selezionare da un grande carico di dati che noi sapere non è pensato per essere restituito nel risultato.

Avrei bisogno di maggiori informazioni sul progetto per consigliarmi sulle migliori pratiche per il ridimensionamento. Qual è il traffico previsto, quanti di quegli utenti devono accedere, ecc.? Ad esempio, se tutto il traffico, ad eccezione di quello degli utenti amministratori, non è autenticato e viene memorizzato nella cache in modo anonimo

— joevallender
fonte

Ciao @drupaljoe, grazie per la tua risposta. Il traffico previsto è difficile da stimare, perché è un sito nuovo di zecca. È stato sviluppato con molta cura e ci aspettiamo una sorta di successo, quindi diciamo che riusciamo ad avere circa duecento utenti simultanei (molti dei quali autenticati). È esattamente quello che stavo pensando, interrogare quell'enorme tabella deve essere una seccatura, quindi forse dovremmo progettare di riutilizzare quei campi che non cresceranno troppo e tenere separati quelli che conterranno più dati. Cosa potrebbe essere considerato troppo? 1 milione ? 100 milioni ? 300 milioni ? ...

— rafamd,

Penso che i commenti degli altri due su come non dovrebbe importare troppo perché le selezioni sono sulla chiave primaria sono buoni punti. Immagino che direi di provarlo per ora, ma assicurati di aver fatto qualche lettura sulle tue opzioni per il futuro, mongo per i campi ecc. Non puoi sempre indovinare tutto sul futuro del tuo sito

— joevallender

0

Finora ho sempre riutilizzato i campi, ma ora sto considerando di utilizzare campi univoci per tipo di nodo per un nuovo progetto. In realtà voglio mantenere tutto ben separato (campi, viste, regole, contesti, ecc.) Per ogni gruppo di entità. Quindi ha sollevato la questione della scalabilità che mi ha portato qui. Sono confortato dalla modifica di Berdir (la cache delle informazioni sul campo è stata migliorata (vedi http://drupal.org/node/1040790 per i dettagli) con Drupal 7.22, solo i campi dei bundle visualizzati su una determinata pagina vengono caricati da la cache e sono voci cache separate. Funziona solo se non ci sono chiamate API errate che richiedono istanze su più bundle).

Voglio solo sottolineare che esiste un modulo molto interessante che utilizzo da mesi su più siti complessi: https://www.drupal.org/project/render_cache . È una di quelle gemme nascoste secondo me.

Come indicato nella pagina del progetto, la parte dei commenti viene effettivamente utilizzata su DO stesso.

Quindi, tenendo a mente tutto ciò, cambierebbe il consenso a favore di campi separati? L'avvertimento che viene citato su DS è comunque un peccato. È estremamente fastidioso il modo in cui salva tramite Ajax anziché, ad esempio, come l'interfaccia di amministrazione del blocco core gestisce il riordino. Sento che è un problema di DS, anche se ...

— Oscar
fonte

-3

Come da mio suggerimento, è una buona idea usare gli stessi campi in un tipo di contenuto separato. Perché migliorerà le prestazioni del tuo sito. In Drupal 7, quando si utilizza l'operazione di selezione in quel momento, L'uso degli stessi campi nel tipo di contenuto è davvero utile per il sito Drupal7.

— Purab
fonte

1

In Drupal 7, hanno iniziato a usare Doctrine ORM ... no, non lo hanno fatto. Drupal 8 non usa nemmeno Doctrine

— Clive

"La dottrina restituisce sempre l'oggetto da tutti i dati mappati", è anche una dichiarazione falsa. Gli oggetti possono essere annotati per indicare alla dottrina che il comportamento predefinito non è adatto. Non è quello che è terribilmente rilevante, dato che, come dice Clive, Drupal non usa Dottrina.

— Letharion,