Strategie Drupal 7 per grandi quantitativi di dati

Con così tanti dati è il database e il server che contano, il primo lo devi mantenere e sul secondo devi spendere.

Drupal se la cava benissimo (di per se') con milioni di nodi: vedi ad esempio drupal.org (è vero che è D6, ma su queste cose non conta)

Come dice @ealmuno, il problema è il server DB e, aggiungo io, che tipo di query farai sui dati: query complesse non ottimizzate su tabelle con milioni di records == morte civile...

Quindi molta attenzione alle query che farai, forse conviene prevedere moduli ad hoc invece di Views (che per quanto sia rimane molto general-purpose)

Argomento davvero interessante, quindi i dati li memorizzereste tramite nodi utilizzando field per definire la struttura (content type)?
il fatto che poi tutti questi dati sono memorizzati fisicamente nel db in tabelle diverse (una tabella per field) non può essere un problema per le prestazioni?

Lo rallenta si, ma aumenta la scalabilità.

E cosa mi dite delle entity? mi pare di aver capito che i nodi non sono altro che entity. Quindi si potrebbe creare una entità per i dati "standard" (e quindi una tabella sola per questi dati) e utilizzare i field per quelli che non lo sono

@PaoloP2P: Drupal 7 supporta storage SQL in configurazioni master-slave, quindi (a meno di enormi/veloci immissioni di dati) non dovresti avere grossi problemi, eventualmente estendendo il DB con istanze slave MySQL.
In alternativa MySQL ha anche un supporto iniziale a MongoDB per lo storage di oggetti, una cosa che -nel caso realmente servisse- potresti pensare di fare è di andare a salvare istanze complete di nodi all'interno di MongoDB/CouchDB e poi andare a fare ricerche/aggregazioni su queste. Considera anche che puoi procedere per step, quindi tiri su in fretta una configurazione M-S di MySQL e se non dovesse bastare tiri su altri slave, oppure crei meccanismi di ricerca/aggregazione più efficienti (vedi sopra).

@ealmuno: in che senso aumenta la scalabilità? forse volevi dire flessibilità?

Oltre che flessibile, anche scalabile secondo me perché va sia bene con piccoli siti che con grossi siti, poi è un po' complicato definire scalabilità.

Scalabilità (per come credo venga intesa in questo contesto) è aumentare il numero di utenti a partà di risorse.
In questo caso la suddivisione degli elementi con la strutturazione a field, in cui l'estrazione dei diversi dati richiede diverse JOIN (o tante query singole), forse non è proprio il modo migliore per "scalare" il sistema...

Quote:

1) Vorrei poter definire tramite l'interfaccia grafica di Drupal7 i widget associati ai campi della tabella sopra descritta e le loro impostazioni.
Come è possibile farlo?

Quote:

2) Vorrei che in un futuro mi sia possibile modificare/aggiungere/eliminare in modo semplice i campi della sopra descritta tabella (sempre con l'interfaccia grafica di Drupal7).
Come è possibile farlo?

@PaoloP2P: dato un Entity (definita dal core, quindi node, user, taxonomy, ...) o creata da 0 usando Entity API, puoi comunque aggiungere i vari field da interfaccia grafica.
Per l'estrazione delle informazioni, dipende da come decidi di strutturare/archiviare i dati. Se stori su MySQL/SQL usando il DBL di Drupal, dovresti poter interrogare il tutto con views, andando a scegliere come estrarre le informazioni e come presentale. Se questo non fosse e decidessi di utilizzare altri strumenti di archiviazione, potresti pensare di usare Views andando a scrivere un tuo backend di interfaccia (dovrebbe essere sufficiente andare a implementare l'interfaccia di query per la search, non ho link sottomano ma nell'API sicuramente la trovi). Un alternativa è di usare un meccanismo di ricerca basato sulle SearchAPI, andando a spostare i dati indicizzati su strumenti dedicati (Apache Solr, tanto per dirne uno). In ogni caso ti consiglio di capire cosa vuoi ottenere e alcuni dei caso d'uso, ed in base a questo andare a fare valutazioni sullo strumento da usare (se la tua ricerca è pressoché statica, potrebbe non convenire usare strumenti di ricerca esterni, ma adare di caching, così come in altre situazioni è conigliabile il contrario).

Ad ora mi pare che i requisiti siano un pò troppo "vaghi" per individuare la strada migliore (o per lo meno, io non me la sentirei di consigliarti una strada con queste info).

Ciao!

@PaoloP2P: definisci "conveniente". In pratica, puoi avere tutto gestito attraverso un unica memorizzazione delle informazioni in un unica tabella, ovviamente questo è più "performante" nel caso di estrazione/ricerca dati, al tempo stesso è molto meno "flessibile". La convenienza dipende da quali sono i tuoi vincoli architetturali (risosrse/tempi/velocità di adattamento/..).

Personalmente propenderei per una strutturazione a field definendo al "entity di base" e usando i field ove possibile. Il secondo step, però riguarda la necessità di avere grandi quantità di informazioni facilmente consultabili. In questo caso potrebbe essere interessante procedere a una memorizzazione del dato in forma documentale su altri strumenti, al mero scopo di ricerca/data mining.

La soluzione dell'entity che gestisce tutto da codice è più "veloce" di implementazione e probabilmente ha una complessità di avvio rispetto a quello suggerito da me, minore, ma al tempo stesso ha una rigidità immensamente maggiore.

Grazie della discussione interessante che stai portando avanti :D

Salve a tutti,
dal basso della mia scarsa esperienza con Drupal, mi chiedo (e chiedo a voi, vista la vostra immensa esperienza ;)), "What about webform?"
Veloce da configurare e, da quel che ne so, non dovrebbe creare una tabella per ogni campo...
Sono incerto, però, sulla capacità di questo modulo di gestire moli di dati così ampie!
Cosa ne pensate?

PS: Ragazzi, discussione interessantissima! :)

Ciao, alcune considerazioni (non conosco D7 al momento quindi prendile per come sono)

- se devi creare dei tipi di contenuto con campi che sono uguali, ma che non dovresti mai usare insieme per le viste allora non utilizzare lo stesso campo, ma creane due diversi: ti togli una JOIN che è sempre un vorace di risorse. Sprechi un po' di spazio, ma chi se ne frega (una volta si doveva prestare attenzione alle dimensioni ora con gli HD e le tecniche moderne non c'è quasi più limite).

- ad un certo punto potresti arrivare con il DB che ti restituisce in modo molto lento la tua query (creata tramite views). Ci sono casi in cui non puoi migliorarla più di tanto (c'è un mio thread sull'argomento), pero' puoi agire a livello di query SQL delle views (con i vari hook) e bypassare il blocco delle prestazioni creando delle tabelle più piccole che trattano solamente di un subset della vista. Io ho fatto così per l'ecommerce multilingua del thread di cui parlavo prima e sono passato da 15secondi a 0.2 solamente con l'uso di una tabella di appoggio creata da uno script in automatico ogni giorno.

M.

@PaoloP2P: immaginati la situazione seguente:

I dati sono memorizzati usando le entity ed i filed, in questo modo che i dati vengano memorizzati sul DB (anche in 50k tabelle) e la struttura (aggiunta/rimozione campi) è facilmente gestibile dall'interfaccia, anche per la prototipazione/test delle interfacce di inserimento/editing.

Al salvataggio dell'informazione del nodo, oltre a lasciare il meccanismo "classico" di Drupal che inserisce il tutto nel DB, memorizzi lo stesso dato (in pratica lo ridondi) all'interno di un sistema documentale (MongoDB, CouchDB, Hadoop, .. qui dipende un filo dalle tue competenze ed esperienze) che lo usi per l'estrazione/filtraggio delle informazioni.

Pro:

• altamente scalabile
• facilmente estendibile

Contro:

• l'infrastruttura applicativa si complica
• la parte di gestione delle ricerche richiede competenze un pò più vaste

Esatto, dovresti occuparti di fare tu la modifica degli oggetti del db documentale. Tra l'altro, essendoc he il DB documentale non mantiene il dato, ma serve solo a velocizzare la ricerca, potresti tranquillamente "cancellare il tutto" e ripopolarlo in maniera patch (anche di notte, con step incrementali, ...).

Il beneficio dello strumento esterno è la flessibilità/velocità di ricerca delle informazioni, in pratica con un 10^6 oggetti neel MongoDB ha dei tempi di ricerca (senza passare per M-R o simili, ma pura ricerca) praticamente nulli, cosa che con un DB SQL non è per nulla vero, sopratutto con un pò di join. Per quanto riguarda CouchDB le cose migliorano ulteriormente, ma andarsi a gestire i dati e tutte le funzioni di estrazioni diventa un pò più complesso e IO preferisco evitare (fino a che non si può fare altrimenti).