L'uso di un server di database ha senso se l'applicazione fa le cose solo localmente?

41

Ho visto alcune applicazioni che sono fondamentalmente software applicativi che funzionano localmente sul sistema (quindi non hanno molto da comunicare in rete). Queste applicazioni sembrano dipendere dai server di database per archiviare i loro dati.

Un esempio di applicazione è Amarok (un popolare lettore musicale su Linux). Non so se lo fanno ancora, ma ricordo che c'è stato un tempo in cui l'installazione di Amarok significava che dovevi installare un server MySQL e farlo funzionare sempre in background.

Qual è il vantaggio dell'utilizzo di un server per l'archiviazione locale rispetto all'utilizzo di una soluzione SQL integrata più piccola come sqlite? Sto parlando di software applicativo in generale, non necessariamente amarok (quello era solo un esempio). Ci sono situazioni in cui l'uso di un server di database ha senso rispetto a un database incorporato?

database applications

— 9a3eedi
fonte

4

Avere un database può essere molto importante. Avere un database in-process o un database di processo separato è una scelta / dettaglio di implementazione.

— 9000

2

Lo capisco. La domanda è di più sul perché scegliere un database di processo separato (come il server mysql) su un database in-process (come SQLite) per le applicazioni locali.

— 9a3eedi

29

SQLite offre una panoramica abbastanza buona di quando usarlo o meno rispetto alle alternative:

https://www.sqlite.org/whentouse.html

Questa riga di riepilogo cattura estremamente bene il caso d'uso di SQLite nella mia esperienza:

SQLite non compete con i database client / server. SQLite compete con fopen ().

L'articolo si espande a lungo su questo punto. Ha anche una sezione intitolata "Situazioni in cui un client / server RDBMS può funzionare meglio". In breve, sono:

Applicazioni client / server : più utenti su una rete.
Siti Web ad alto volume : scrivere intensivamente o leggere abbastanza intensamente da richiedere lo sharding.
Set di dati molto grandi : più grandi di quelli che possono essere ragionevolmente memorizzati su un disco.
Elevata concorrenza : in particolare le scritture simultanee.

— Denis de Bernardy
fonte

@ 9a3eedi: in realtà, tra questi quattro punti non c'è nessuno che descriva uno scenario con un server di database completo in combinazione con l'archiviazione locale (in particolare i primi due sono l'esatto contrario) - quindi ti dispiacerebbe illuminarci perché hai scelto questo risposta, anche se non si adatta alla tua domanda originale? A proposito, ho dato a questa risposta un voto negativo proprio per questo motivo.

— Doc Brown,

@DocBrown: casi specifici in cui è necessario utilizzare un RDBMS client / server sono [vedi risposta]; per tutto il resto SQLite funziona bene. Non sono sicuro di cosa non sia chiaro, quindi sentiti libero di modificare la risposta se ritieni che sia necessario.

— Denis de Bernardy,

La domanda originale riguardava casi specifici in cui il database ac / s ha senso se l'applicazione fa le cose solo localmente (cita dal titolo) o usa un server per l'archiviazione locale (cita dal testo della domanda). I quattro scenari sopra riportati sono esattamente l'opposto di quello (i primi due) o molto improbabili o non comuni come scenari "locali" (i secondi due). Quindi ciò che hai scritto non è sbagliato, ma non si adatta alla domanda.

— Doc Brown,

@DocBrown - e la risposta breve è: non ha alcun senso se non hai a che fare con set di dati fuori misura o che necessitano di scritture simultanee. (O, per ovvie ragioni, ha bisogno di qualcosa che SQLite non offre.) Ancora una volta, sentiti libero di modificare la risposta se quel punto non ti è chiaro.

— Denis de Bernardy,

Bene, se pensi davvero che l'elenco sia completo (e quindi dai una dichiarazione nascosta che per uno scenario locale l'uso di un server C / S DB non ha alcun senso), allora non sono d'accordo, e non penso di poter migliorare la tua risposta aggiungendo alcuni chiarimenti.

— Doc Brown,

28

Anche per un singolo sistema con un singolo utente, un server di database "reale" ha senso:

Utilizza un linguaggio familiare ( SQL ). SQLite utilizza SQL, ma alcuni database incorporati (ad esempio database di oggetti , NoSQL ) non utilizzano SQL. Quelli tendono ad avere una curva di apprendimento più elevata perché sono meno comuni.
Fornisce integrità referenziale, vincoli, trigger ecc. Che prodotti come SQLite potrebbero non fornire o almeno non fornire per intero.
Mirando a un vero database di rete conforme a più utenti e ACID , l'applicazione ha la possibilità di lavorare in uno scenario a singolo utente / workstation singola o come applicazione ospitata da più utenti utilizzando la stessa base di codice .
L'utente ha la possibilità di esaminare i dati offline utilizzando strumenti standard (ad esempio SQL Developer, MySQL Workbench, SQL Server Management Studio), caricare o eseguire il backup dei dati utilizzando tali strumenti, ecc. Mentre è possibile farlo con molti database incorporati di vari tipi, forse le persone hanno più familiarità con quegli strumenti dal mondo del database C / S.

Lo svantaggio principale è la necessità di installare e gestire il software del server di database, che è un po 'complesso per gli utenti non tecnici (e anche per molti utenti tecnici). I sistemi operativi come Linux lo rendono più semplice: ho PostgreSQL e MySQL in esecuzione sul mio sistema Linux. Ho installato applicazioni che mi hanno agganciato con poca o nessuna interazione da parte mia.

— Doc Brown
fonte

9

In realtà, esiste un sistema di database (vale a dire Sybase SQL Anywhere) con supporto SQL completo, integrità referenziale, ACID, procedure memorizzate, che non richiede una configurazione del server o un'installazione come servizio quando eseguito in una configurazione locale (anche se può essere configurazione per un ambiente multiutente). Non conosco nessun altro sistema di database con queste proprietà, se qualcuno ne conosce uno, sarei interessato.

— Doc Brown,

3

@DocBrown IIRC MS SQLServer Compact ti offre questo come viene fornito come una dll, sebbene LocalDB sia probabilmente la scelta migliore - non richiede l'installazione come servizio ma richiede diritti di amministratore.

— gbjbaanb,

5

Per aggiungere alla discussione sulla validità dello svantaggio - oltre a SQLite curiosamente già menzionato nella risposta, un certo numero di database non SQL e sistemi simili a database, come OrientDB, Solr e altri, hanno un supporto per l'incorporamento dedicato .

— mikołak,

14

SQLite fornisce integrità referenziale (sebbene debba essere attivata) e vincoli di base. È anche significativamente più veloce della maggior parte dei server se usato correttamente. Il suo principale svantaggio rispetto al server è che è single-writer.

— Jan Hudec,

2

@DocBrown: il database incorporato di Firebird fornisce pieno supporto SQL, tra cui integrità referenziale, garanzie ACID, processi memorizzati e trigger. Non era utilizzato per supportare più connessioni simultanee a un database incorporato e non sono sicuro che tale limitazione sia ancora in atto o meno, ma l'intero set di funzionalità SQL è presente.

— Mason Wheeler,

21

Penso che abbia a che fare con l'inerzia.

Amarok è basato su XMMS che risale al 1997. Per avere buone capacità di database bisognava usare un server, perché era molto più potente delle soluzioni basate su file, che non avevano affatto buone capacità di database.

L'imminente e crescente popolarità di buoni database embedded locali come SQLlite è qualcosa di abbastanza recente.

— Pieter B
fonte

Da quello che ricordo, AmaroK 1 (che potrebbe essere stato basato su XMMS) non dipendeva da un server di database. È stato Amarok 2, che è stato rilasciato con KDE4, a introdurre la dipendenza, e al momento ho trovato molto strano che mi avrebbero richiesto di installare MySQL e di mantenerlo in esecuzione in background

— 9a3eedi

10

La caratteristica discriminante più importante è la concorrenza .

Se si dispone di una sola applicazione che viene eseguita in una sola istanza per l'utente, la soluzione incorporata (sqlite o alcuni oggetti di archiviazione) è generalmente OK.

Tuttavia, se si hanno più istanze che devono manipolare il database contemporaneamente, è necessario disporre di un server per sincronizzarlo. SQLite consente solo una scrittura alla volta, nell'intero database, così come la maggior parte delle altre soluzioni integrate. E se hai anche più applicazioni, è probabile che tu abbia bisogno di specifiche di vincolo più dettagliate che le soluzioni integrate generalmente non consentono neanche.

— Jan Hudec
fonte

5

Molte delle altre risposte parlano della concorrenza come un vantaggio, ma anche dal momento che il db è in esecuzione come server, il database può eseguire attività senza la necessità dell'applicazione in esecuzione. Potrebbe trattarsi di manutenzione, backup, sincronizzazione con un altro server o qualsiasi attività pianificata.

Se ritieni che la tua app possa trasformarsi in un'app client / server, potresti voler iniziare a utilizzare un RDBMS dall'inizio invece di portarlo in un secondo momento.

Non ho idea se l'esempio fornito ne approfitti o meno.

— Jeffo
fonte

2

A meno che tu non stia eseguendo un sistema embedded con memoria insufficiente e CPU, non penso che far funzionare un server in background ti faccia del male.

L'esecuzione locale di un server di database va bene. Il database ha lo scopo di accedere e manipolare i dati. L'accesso alla rete è un vantaggio, che potrebbe essere necessario o meno. Ci sono alcuni strumenti di ingegneria e scientifici che fanno questo.

Supponi di utilizzare i dati su un'applicazione locale. Perché non dovresti usare un database? al contrario di cosa?

— Cauchy
fonte

Se dovessi distribuire un'applicazione per utenti normali (diciamo un lettore musicale come AmaroK), penserei che farli installare il server MySQL e averlo eseguito in background sia un po 'troppo un requisito di sistema e sarebbe qualcosa che gli utenti dovrebbero non come. Ma immagino che dipenda dall'applicazione. Questo è contrario all'utilizzo di qualcosa come SQLite.

— 9a3eedi

2

Dipende dall'astrazione dei dati e dallo spazio complessivo dell'applicazione, dai requisiti di gestione degli accessi, dall'investimento che si sta pianificando sulla manutenzione dei dati, dall'urgenza del prototipo richiesto, da dove ci si trova nella curva di apprendimento, ecc.

Se si desidera garantire un database strettamente integrato a un'applicazione che non richiede l'accesso da altre applicazioni, creando isole di database incorporato. L'implementazione di Mozilla Firefox Web Storage con SQLite potrebbe essere fornita come esempio.

Se è necessaria una maggiore efficienza con dati limitati, è preferibile una selezione di design di database in memoria.

D'altra parte, se hai molte applicazioni che eseguono più query sugli stessi dati e richiede una migliore strutturazione dell'archiviazione dei dati per ottimizzare le prestazioni, è necessario un DBMS centralizzato. Lo preferirò assolutamente per la ricerca scientifica, quando richiede un'enorme quantità di dati e in cui il tempo di risposta alla query avrà un impatto drastico sull'esperienza complessiva dell'utente.

Per il caso Amarok, immagino fosse una selezione di DBMS open-source a quel tempo, prima che scegliessero il percorso dei database incorporati.

Se c'è una definizione di sistema specifica a portata di mano, sarà più facile valutare i pro ei contro.

V / r, Umut

— Umut Kahramankaptan
fonte