C'è qualche vantaggio nell'avere più di una tabella per la memorizzazione dello stesso tipo di oggetti?

0

Diciamo che voglio memorizzare i brani nel mio database. Invece di avere solo una tabella Song , ho dieci tabelle. La tabella Song ha anche una chiave esterna per la tabella Artist . Quando un artista viene aggiunto al database, controlliamo esattamente quanti brani ci sono in ciascuna delle tabelle Song , e assegniamo la tabella con il minor numero di canzoni dell'artista. Tutte le canzoni dell'artista verranno memorizzate in quella tabella Song .

Non voglio memorizzare oggetti 1M in una tabella, ma piuttosto dividerli in dieci pezzi, ciascuno di circa 100k oggetti, e archiviarli in dieci tabelle diverse, ma strutturalmente simili. Ora, a condizione che il riferimento alla tabella delle canzoni negli oggetti dell'artista non venga mai modificato, il mio sistema generale sarà più veloce e avrà prestazioni migliori?

Capisco che un grosso problema potrebbe essere trovare singole canzoni, ma per favore rispondi a questa domanda nel contesto in cui le canzoni possono essere recuperate dal database solo fornendo 2 parametri:

  • artist_id
  • song_id

Se ho artist_id, posso usarlo per ottenere il mio oggetto artista, che contiene un riferimento alla tabella delle canzoni che contiene la canzone con la canzone con il brano_data. Quindi non devo interrogare dieci diverse tabelle per trovare una canzone, se ho l'artist_id, che sarà sempre il caso.

Sarà completamente inutile? O avrà un impatto positivo sulle prestazioni del mio sistema?

Nota: mi rendo conto che le canzoni non dovrebbero mai essere archiviate in questo modo, dal momento che si vorrebbe interrogare le canzoni senza conoscere l'artista, ma questo è solo per un esempio, anche se povero. Inoltre, si prega di ignorare il fatto che questi sarebbero un disastro da codificare e gestire al momento della risposta. Voglio solo sapere dell'impatto sulle prestazioni.

    
posta darkhorse 04.11.2018 - 15:28
fonte

2 risposte

9

La divisione di una tabella logica in più tabelle all'interno dello stesso database presenta vantaggi zero . Ciò complicherà le query e potrebbe in effetti danneggiare le prestazioni, perché trovare elementi è più difficile. Invece di una semplice query, dovresti ripetere la query per ogni tabella e poi prendere l'UNION dei risultati.

In un database ben gestito, avere milioni o miliardi di elementi all'interno di una tabella non è affatto un problema. Avrai bisogno di indici adatti per ottenere prestazioni accettabili per le tue domande, ma dovresti farlo comunque.

A volte, una "tabella" viene effettivamente suddivisa in modo che possa essere distribuita su più database o più nodi di un database distribuito. Questo è chiamato sharding ed è utile se un singolo database non è sufficiente per fornire le prestazioni di lettura / scrittura richieste a causa di limitazioni hardware. Tuttavia, ci sono alcuni inconvenienti.

  • Possiamo tagliare solo con una chiave, ad es. l'ID della canzone.
  • In un approccio semplicistico di segmentazione in cui vengono suddivisi per intervalli di ID, un nodo potrebbe avere elementi vecchi e un nodo avere elementi più recenti, il che causa carichi non uniformi tra i nodi. Il database dovrebbe pertanto preferire GUID su ID sequenziali o utilizzare una funzione di hash.
  • Anche aggiungere o rimuovere nodi da un cluster di database semplice è difficile.
  • Se una query del database non può essere risolta con la chiave sharding, la query deve essere ripetuta per ogni frammento e i risultati combinati in seguito, lo stile di riduzione della mappa. Questo può amplificare i carichi invece di ridurli.
  • E lo svantaggio più importante: un database non standard in genere non può eseguire aggiornamenti transazionali che toccano più voci, ma questo dipende molto dal software.

Molti database hanno il supporto integrato per il sharding. Un database SQL può dividere in modo trasparente una tabella con la sua chiave primaria - senza dover modificare alcuna query (ma vedere il manuale del database per eventuali avvertimenti, ad esempio se questo ridurrà alcune garanzie ACID). Questa netta separazione tra la struttura della tabella logica (esposta tramite SQL) e la struttura fisica della tabella (ad esempio il motore di archiviazione e le strutture di dati dell'indice) è la caratteristica principale dei database SQL!

Se possibile, l'uso di un database di replica letto può essere preferibile rispetto alla condivisione. Tutte le scritture vanno al database principale, ma il carico di letture può essere distribuito tra le repliche. Gli aggiornamenti transazionali sono ancora possibili, anche se le letture delle repliche potrebbero non essere aggiornate.

Quindi i database hanno molte tecniche per migliorare le prestazioni, come il sharding su più nodi. Ma in molti casi questo può essere fatto in modo trasparente, non si dovrebbe modificare la struttura della tabella in previsione di ciò. Molto probabilmente, non hai bisogno di tecniche di ridimensionamento, e un singolo database sarebbe in grado di fornire prestazioni sufficienti quando è ben progettato (modellazione ER corretta, uso di indici, non normalizzare eccessivamente, ...).

    
risposta data 04.11.2018 - 16:33
fonte
2

Per estendere il commento precedente - i sistemi di database relazionali sono normalmente in grado di memorizzare miliardi (!) di voci, se necessario, e contengono meccanismi specifici - come "Tablespaces" - per gestire il back- fine logistica di immagazzinare effettivamente tutti quei dati. Le decisioni di bilanciamento, come quelle di cui parli, possono essere gestite, in modo trasparente, dal sistema stesso del database.

La maggior parte delle aziende finisce per dover archiviare i propri dati, "essenzialmente, per sempre". Loro potrebbero fare ciò creando tabelle "archivio" separate, ma i database moderni offrono altre alternative per separare i dati meno utilizzati o archiviati in altri luoghi, mantenendoli completamente accessibili come una singola immagine.

    
risposta data 05.11.2018 - 17:58
fonte

Leggi altre domande sui tag