La domanda generale

Quali sono le differenze tra algoritmi che utilizzano strutture di dati e algoritmi che utilizzano database?

Un po 'di contesto

Questa è una domanda che mi ha infastidito da un po 'di tempo e non sono stato in grado di trovare una risposta convincente per questo.

Attualmente, sto lavorando per rafforzare la mia comprensione degli algoritmi che, ovviamente, coinvolgono pesantemente le strutture di dati. Queste sono strutture di base come Bag, Queue, Stack, Priority Queue e Heap.

Uso anche database su base giornaliera per archiviare i dati che sono stati elaborati e inviati dall'utente finale o elaborati dal programma. Recupero e invio i dati tramite un DAL, che ha strutture di dati proprie generate sulla base delle tabelle nel database.

Le mie domande arrivano quando ho la possibilità di ordinare i dati utilizzando il database per inviarmeli in ordine crescente / decrescente o recuperare e caricare i dati nella mia logica, elaborare questi dati in una coda prioritaria e ordinare l'heap tutto. Oppure un altro sarebbe cercare i record usando il database piuttosto che caricare un sottoinsieme dei record e usare qualcosa come la ricerca binaria per trovare il record o i record che mi interessano.

Nella mia mente, proverei a fare quante più operazioni avvengono sull'estremità del database prima di inviarlo perché la comunicazione è costosa. Questo mi fa anche chiedermi quando usi algoritmi e strutture di dati strettamente definiti nella tua logica piuttosto che elaborare i dati rispetto a quelli del database?

Quindi ecco le domande ...

Domande

1. Quali sono le differenze tra strutture dati e database?
2. Quando utilizziamo algoritmi che utilizzano strutture di dati definite esclusivamente all'interno della propria logica e non di quelle del database?
3. @Harvey post: quando i metodi nel database diventano meno efficienti da usare rispetto ai metodi nella tua logica?
   • @mirculixx post: cosa rende efficiente un metodo?
4. @Harvey post: in che modo l'elaborazione dei dati con le strutture dati è più rapida rispetto a quella nel database?

chiarimenti

1. @Grant post: i database con cui lavoro normalmente sono relazionali, e queste domande non ci riescono . Tuttavia, penso che queste domande siano applicabili a qualsiasi framework di persistenza (quando dico framework, intendo nel senso più generale).

So che le risposte senza un contesto specifico sono difficili. Spunti di riflessione, consigli o discussioni sono principalmente ciò che cerco e sarei molto apprezzato!

Le strutture dati sono, per la maggior parte:

1. Residente in memoria,
2. Transient,
3. Dimensioni limitate,
4. Non rientrare senza aggiungere meccanismi di concorrenza come blocchi o immutabilità,
5. Non conforme ACID ,
6. Veloce, se scelto con cura.

I database sono, per la maggior parte:

1. Disk-bound,
2. Persistente,
3. Grande,
4. Contemporaneamente sicuro,
5. Conformità ACID, con funzionalità transazionali ,
6. Più lento delle strutture dati

Le strutture dati sono pensate per essere passate da una posizione all'altra e utilizzate internamente all'interno di un programma. Quando è stata l'ultima volta che hai inviato i dati da una pagina Web a un server Web utilizzando un database o eseguito un calcolo su un database che era interamente residente in memoria?

I sistemi di database utilizzano le strutture di dati come parte della loro implementazione interna. È una questione di dimensioni e portata; usi le strutture di dati all'interno del tuo programma, ma un sistema di database è un programma a sé stante.

Quali sono le differenze tra strutture dati e database?

A livello astratto, non ce n'è nessuno: un database è una struttura di dati.

A un livello specifico, i database hanno generalmente lo scopo di conservare i dati, di solito in un formato ottimizzato per inserimenti, aggiornamenti, recupero, unione o altri scopi (o una combinazione).

Ad esempio, se si confronta una tabella in un RDBMS per dire una matrice di dati, la differenza potrebbe essere nel tempo di esecuzione dell'algoritmo, nella quantità di codice che è necessario scrivere, nella quantità di memoria necessaria per eseguire l'algoritmo o la flessibilità di lavorare / accedere ai dati dall'esterno del programma / algoritmo.

Quando utilizziamo algoritmi che utilizzano strutture di dati definite esclusivamente all'interno della propria logica e non di quelle del database?

In tendenza direi

a) utilizzare un database se è necessario conservare i dati in modo che siano accessibili oltre il tempo di esecuzione o lo scopo dell'algoritmo specifico.

b) utilizzare la propria struttura di dati (in memoria) se la velocità di runtime è importante o non è richiesta la persistenza

Ad esempio, se il tuo algoritmo elabora i record dei clienti, potresti voler archiviare tali record dei clienti (diciamo per trovare tutti i clienti in una particolare area) per un uso successivo da parte di altri programmi / algoritmi e per uno scopo completamente diverso (diciamo per trovare i clienti più preziosi ). In tal caso, utilizzare un database per persistere nei dati è probabilmente una buona idea.

Si noti, tuttavia, che esiste il concetto di database in memoria che non conservano necessariamente i dati, per motivi di prestazioni. Ad esempio Redis o HANA .

Quando i metodi nel database diventano meno efficienti da utilizzare rispetto ai metodi nella propria logica?

La risposta dipende molto dalle circostanze e dal (tipo di) database in uso. Vorrei riformulare la domanda a "cosa rende efficiente un metodo?" Diventa quindi un esercizio di valutazione dei metodi (= algoritmo) che useresti per la tua struttura di dati rispetto ai metodi usati dal database. Vedi anche il prossimo punto.

In che modo l'elaborazione dei dati con le strutture dei dati è più rapida rispetto a quella eseguita nel database?

Ancora una volta, questo dipende dalle specifiche. In generale, l'elaborazione dei dati in memoria, direttamente accessibile al processo che esegue l'algoritmo, è più rapida rispetto all'invio di una richiesta a un altro processo (nello stesso computer o attraverso una rete) e la richiesta di rinviare i risultati . Tuttavia, se i dati risiedono già all'interno del database, l'invio di un comando, ad esempio un'istruzione SQL per unire due tabelle e calcolare alcune funzioni di aggregazione, e recuperare solo un piccolo riassunto o sottoinsieme dei dati potrebbe essere molto più efficiente rispetto al primo trasferimento di tutti i dati e calcolo dei risultati a livello locale (utilizzando le proprie strutture dati).

L'accesso al disco è principalmente ciò che è più costoso in questa operazione, più spesso dell'accesso alla rete (http://serverfault.com/questions/238417/are-networks-now-faster-than-disks). A meno che il database non si trovi su almeno una rete da 1 Gbps e sulla stessa rete del server web \ application, le prestazioni della rete non saranno importanti quanto le prestazioni del disco per set di dati più grandi. O se i tuoi dati risiedono su dischi a stato solido molto veloci, che saranno più veloci dell'accesso tipico alla rete. Inoltre, i database di solito forniscono un meccanismo IPC come named pipe invece di utilizzare TCP / IP se il database risiede sullo stesso server del server delle applicazioni.

Se riesci a mantenere la maggior parte della struttura dei dati di \ enire in memoria tra le richieste, questa sarà generalmente la tua scommessa più veloce. Se non ci riesci, è difficile battere una buona struttura di database con tabelle normalizzate e indici adeguati per la ricerca e l'aggiornamento delle prestazioni su qualcosa di diverso da piccoli set di record, specialmente in un sistema con milioni di record.

I database relazionali in genere usano un albero B + o una loro variante sotto il cofano e hanno molte ottimizzazioni come l'allineamento dei dati su pool di dischi e buffer per i record a cui si accede frequentemente. Ciò li rende eccellenti nell'elaborare rapidamente set di dati di grandi dimensioni, soprattutto se sono coinvolti aggregazione o filtro.

Cosa intendi per database? Intendi un database relazionale come MySQL o SQL Server? Un database relazionale è una struttura di metadati che supporta alcuni sottogruppi delle operazioni definite dal modello relazionale . La teoria del modello relazionale che fu per lo più elaborata da Edgar Codd negli anni '60.

Il modello relazionale è molto generico e flessibile, ma ciò significa che non può trarre alcun vantaggio dalla struttura dei dati o dai modelli di accesso. Le strutture di dati sono utili quando si conoscono i dati e come saranno accessibili. Ad esempio, se si conosce che gli ultimi dati inseriti in una struttura di dati saranno i primi dati desiderati, è possibile utilizzare uno stack.

Ho chiamato il database relazionale una struttura di metadati perché in genere è un bel po 'di software che utilizza molte strutture di dati come stack, code, alberi ed elenchi per creare la struttura di dati astratta di una tabella relazionale.