Quali sono i vantaggi dell'archiviazione?

7

Vedo sempre siti che conservano solo nuovi contenuti in casa o sottosezioni e il resto del contenuto è conservato in una sezione separata chiamata "archivio".

Recentemente ho anche sentito che i DB NoSQL come MongoDB sono buoni per l'archiviazione (il che mi fa pensare che questo sia legato alle prestazioni)

Quindi perché i siti archiviano i loro contenuti? Qual è il vantaggio, ad esempio, di un semplice cercatore attraverso il quale è possibile raggiungere tutti i contenuti?

L'archiviazione è fatta per le prestazioni? O SEO? O solo l'esperienza utente?

    
posta HappyDeveloper 15.11.2011 - 17:11
fonte

2 risposte

6

Storia vera

Il motivo più semplice per separare il contenuto più recente dai contenuti più vecchi è che il tuo database sta diventando grande. Alcuni anni fa sono stato coinvolto nella creazione di un'enorme applicazione finanziaria basata su un database preesistente. Conservava una varietà di dati fiscali, e aveva già diversi anni di dati in esso, quando sono stato coinvolto per la prima volta nel progetto. Avere un unico archivio di database con anni di dati ha senso solo quando ci sono effettivamente tutti questi dati, in qualsiasi momento. Il resto della squadra ha detto che era così, quindi non ci ho pensato molto.

Alcune settimane nel team ho capito che la realtà era leggermente diversa. I nostri utenti avevano solo bisogno di accedere ai dati dell'anno fiscale corrente, tranne:

  • Quando si producono report annuali, qualcosa che è successo una volta all'anno
  • Quando si producono rapporti di tre anni, qualcosa che è successo una volta ogni tre anni

Abbiamo deciso di suddividere il database in diversi database all'anno. Non è stata una decisione facile, ma ha funzionato: il database dell'anno fiscale corrente ha avuto risposte fulminee, poiché era solo la scansione di un sottoinsieme molto piccolo di tutti i dati. Le relazioni annuali sono state generate anche al volo, per lo stesso motivo. Le relazioni triennali erano un po 'più lente da generare rispetto a prima e ci voleva molta creatività per combinare tre archivi, ma quello era un piccolo svantaggio del processo.

Quindi il nostro database è stato diviso in piccoli database di archivio e tutti erano felici. (Non proprio, molti aspetti approssimativi e naturalmente questa è una versione semplificata della storia, ma nel complesso la decisione di archiviare è stata buona).

Dati eterogenei

Un altro motivo per archiviare è quando si ha una mancanza di omogeneità dei dati nel tempo. Quando lo schema del database cambia, specialmente per enormi database, la soluzione migliore è un database orientato ai documenti come MongoDB . I database orientati ai documenti hanno schemi flessibili, il che significa che non gli interessa se non si usano gli stessi campi per descrivere un record, quindi non si hanno campi vuoti come si farebbe con un database relazionale.

E come Jeff O note correttamente in un commento a altra risposta , i dati archiviati per definizione non cambieranno, quindi non è necessario preoccuparsi delle transazioni e di altre funzionalità relazionali. (Aggiunto qui, nel caso in cui il commento o la risposta vada in AWOL)

Archiviazione su siti Web orientati alle notizie

I siti web orientati alle notizie con molti dati possono scegliere di archiviare i loro contenuti più vecchi in un database orientato ai documenti, perché poiché trattano notizie, i loro contenuti più recenti sono molto più preziosi per loro dal punto di vista del business.

SEO & impaginazione

Infine, non ha nulla a che fare con la SEO e / o l'impaginazione (Pagination funzionerà indipendentemente da dove i tuoi contenuti sono archiviati). Un bot eseguirà la scansione del contenuto impaginato, seguendo i collegamenti di impaginazione come qualsiasi altro link. Se adotti uno schema URI ragionevole per tutti i tuoi contenuti, non hai nulla di cui preoccuparti. Ad esempio, immagina di avere un blog con dieci anni di articoli e hai deciso di spostare tutti gli articoli precedenti al 2010-12-31 in un archivio di archiviazione dei documenti.

La tua home page avrebbe probabilmente un elenco di articoli più recenti, qualcosa del tipo

http://example.com/articles/2011-11-1/title
http://example.com/articles/2011-10-30/title
http://example.com/articles/2011-10-20/title

Passando attraverso le pagine che finalmente imbattersi in una pagina:

http://example.com/articles/2011-1-1/title
http://example.com/articles/2010-12-30/title
http://example.com/articles/2010-12-25/title

Lo stesso schema URI, indipendentemente dal fatto che l'articolo sia memorizzato nel database corrente o nel database di archivio. Tutto quello che devi fare è un semplice controllo lato server quando i tuoi visitatori (umani o bot) cliccano sull'articolo 2010-12-30:

if(date <= 2010-12-31) {
    // get article information from archive
} else {
    // get article information from current database
}

Ora perché alcuni siti possono scegliere di spostare il contenuto archiviato in una sezione di archivio speciale, è qualcosa che è comprensibile solo a coloro che li hanno creati. Potrebbero esserci alcuni fattori di esperienza utente coinvolti, ma questo è fuori tema per i programmatori, puoi provare a interrogare la gente all'indirizzo Scambio pila esperienza utente .

    
risposta data 15.11.2011 - 19:41
fonte
-2

"NoSQL" è in realtà una categoria piuttosto ampia, quindi la designazione non significa molto. E no, quei DB non sono migliori nell'archiviazione di vecchi contenuti rispetto ai DB relazionali. Devi solo mantenere i vecchi contenuti nello stesso archivio dati che stai utilizzando per i nuovi contenuti: non è necessario complicare le cose.

    
risposta data 15.11.2011 - 17:50
fonte

Leggi altre domande sui tag