Utilizzo di XML come archivio dati [chiuso]

Questa citazione non riguarda l'uso dell'XML come formato di archiviazione in generale (per il quale va bene, a seconda dei requisiti), ma per lo spazio di database .

Quando le persone parlano di database, di solito indicano sistemi di archiviazione che memorizzano enormi quantità di dati, spesso nell'intervallo di gigabyte o terabyte. Un database è potenzialmente molto più grande della quantità di RAM disponibile sul server che lo memorizza. Dal momento che nessuno ha mai bisogno di tutti i dati in un database in una volta, i database dovrebbero essere ottimizzati per il recupero rapido di sottoinsiemi selettivi dei loro dati: questo è l'istruzione SELECT e i database relazionali e le soluzioni NoSQL ottimizzano la loro memoria interna formato per il recupero veloce di tali sottoinsiemi.

XML, tuttavia, non si adatta veramente a questi requisiti. A causa della sua struttura di tag nidificata, è impossibile determinare dove nel file viene memorizzato un determinato valore (in termini di un offset di byte in un file) senza percorrere l'intero albero del documento, almeno fino alla corrispondenza. Un database relazionale ha indici e la ricerca di un valore in un indice, anche con un'implementazione di ricerca binaria primitiva, è una sola ricerca O (log n), e quindi ottenere i valori effettivi non è altro che una ricerca di file (ad es. fseek(data_file_handle, row_index * row_size) ), che è O (1). In un file XML, il modo più efficace è di eseguire un parser SAX sul documento, facendo moltissime letture e ricerche prima di arrivare ai dati reali; difficilmente puoi ottenerlo meglio di O (n), a meno che non usi gli indici, ma poi, dovresti ricostruire l'intero indice per ogni inserimento (vedi sotto).

L'inserimento è ancora peggio. I database relazionali non garantiscono l'ordine delle righe, il che significa che possono semplicemente aggiungere nuove righe o sovrascrivere qualsiasi riga contrassegnata come "eliminata". Questo è estremamente veloce: il DB può solo tenere un gruppo di posizioni scrivibili in giro; ottenere una voce dal pool è O (1) a meno che il pool non sia vuoto; Nel peggiore dei casi, il pool è vuoto e deve essere creata una nuova pagina, ma anche questa è O (1). Al contrario, un database basato su XML dovrebbe spostare tutto dopo il punto di inserimento per creare spazio; questo è O (n). Quando gli indici entrano in gioco, le cose diventano ancora più interessanti: gli indici tipici dei database relazionali possono essere aggiornati con una complessità relativamente bassa, ad esempio O (log n); ma se si desidera indicizzare i file XML, ogni inserimento modifica potenzialmente la posizione su disco di ogni valore nel documento, quindi è necessario ricostruire l'intero indice . Ciò vale anche per gli aggiornamenti, poiché l'aggiornamento, ad esempio, del contenuto di testo di un elemento, può modificarne le dimensioni, il che significa che l'XML consecutivo deve spostarsi. Un database relazionale non deve assolutamente toccare l'indice se si aggiorna una colonna non indicizzata; un database XML dovrebbe ricostruire l'intero indice per ogni aggiornamento che modifica la dimensione del nodo XML aggiornato.

Questi sono i lati negativi più importanti, ma ce ne sono altri. L'XML è molto prolisso, e va bene per le comunicazioni da server a server, perché aggiunge sicurezza (il server ricevente può eseguire tutti i tipi di controlli di integrità sull'XML e se qualcosa è andato storto nel trasferimento, è improbabile che il documento convalidi ). Per l'archiviazione di massa, tuttavia, si tratta di uccisioni: non è raro avere il sovraccarico del 100% o più per i dati XML (non è raro vedere rapporti di sovraccarico nell'intervallo del 1000% per cose come i messaggi SOAP), mentre l'archiviazione DB relazionale tipica gli schemi hanno solo un overhead costante per i metadati della tabella, più un piccolo bit per riga; la maggior parte del sovraccarico nei database relazionali proviene da larghezze di colonna fissa. Se hai un terabyte di dati, un overhead del 500% è semplicemente inaccettabile, per molte ragioni.

XML è pessimo per l'archiviazione dei dati. Innanzitutto, è molto prolisso. I dati archiviati in un file XML occupano molto più spazio su disco degli stessi dati memorizzati in qualsiasi ragionevole sistema di database. In un record XML, il nome di un particolare campo verrà memorizzato due volte, insieme alla rappresentazione in formato stringa dei dati. Quindi, per esempio, per memorizzare un singolo file in un campo chiamato "foobar", si finisce con questa stringa da 19 byte:

<foobar>42</foobar>

D'altra parte, un vero database lo memorizzerà come un singolo valore intero, prendendo 4 byte. Se il tuo database è piccolo, non significa molto, ma se hai 10.000 record, questo è un problema.

In secondo luogo, un XML deve essere analizzato dal testo ogni volta che viene letto il file. Per il campo sopra, un vero database semplicemente legge i dati binari in memoria dall'offset sa che ha memorizzato il campo "foobar" in. Se il file è memorizzato come XML, deve leggere il campo "foobar", analizzare quel testo determinare quale campo è, quindi analizzare la stringa "42" e convertirla nel file binario 42.

Quindi le penalizzazioni delle prestazioni per l'utilizzo di XML sono enormi. I vantaggi dell'XML sono che è in qualche modo leggibile dall'uomo e che consente un facile trasferimento di dati tra sistemi completamente separati. Nessuno di questi vantaggi si applica a un database locale.

L'unica eccezione sono i file di configurazione, che in genere sono piccoli e generalmente devono essere modificabili dagli utenti.

Un database XML sarà assolutamente più grande e più lento di qualsiasi ragionevole sistema SQL. A meno che non si riesca a trovare un vantaggio di controbilanciamento nella leggibilità o nell'interoperabilità umana, non ha senso utilizzarlo per la memorizzazione dei dati.

XML è fattibile a seconda del contesto. Se i tuoi dati sono piuttosto statici e non cambiano molto (ad esempio i dati di esempio), sì XML è un buon uso.

Le impostazioni di configurazione, i dati di esempio (anche se sono milioni di righe, ma cambiano raramente), sono tutti buoni usi di XML.

Le letture / scritture sul disco rigido sono costose, molto più che accedere ai dati da uno stack Oracle / Sql.

This seems to really stress that XML should not be used for data storage and should only be used for program to program interoperability.

La tua premessa è imperfetta.

Il paragrafo che citi sta dicendo che XML non sostituisce un database , non che non dovrebbe essere usato per archiviazione dati .

È chiaro che un file di impostazioni non è la stessa cosa di un database, quindi è possibile utilizzare diverse tecnologie (e dovrebbe?).

Correggimi se sbaglio, ma sembra che tu abbia più esperienza con i linguaggi di markup rispetto ai database. Se hai un po 'di esperienza con i database, ti rendi conto di quali domini le due diverse tecnologie sono adatte.

Questo è davvero soggettivo. Quella citazione è, come, opinione di qualcuno, uomo.

Onestamente, penso che XML sia un'alternativa valida a un database in quanto presenta numerosi vantaggi rispetto a un RDMS, compreso un sovraccarico basso, che equivale a uno spazio di archiviazione più economico (specialmente quando si utilizza un servizio di hosting che addebita separatamente i database).

Dai un'occhiata a dasBlog e BlogEngine . Entrambe queste applicazioni utilizzano xml come spazio di archiviazione predefinito.

Detto questo. Non è un RDMS, e se hai un'elevata volatilità (molti aggiornamenti, inserti o eliminazioni) nei tuoi dati o richiedi disponibilità elevata, usa un database. XML va bene per la memorizzazione di piccole cose come dati di configurazione e dati di bassa volatilità.

my question is, Is this still a valid statement and is it now acceptable to store data using XML?

Vedo il tuo punto nel tuo esempio sui file di configurazione di .NET. Tuttavia, qualsiasi altro formato di file avrebbe potuto essere utilizzato. In effetti, ai vecchi tempi, tali impostazioni venivano solitamente archiviate in normali file di testo chiamati file INI.

Vedo che l'affermazione presentata in grigio, è valida e corretta se si definisce un database come sistema software.

La definizione di XML in XML-Definition afferma che "(XML) è un linguaggio di marcatura che definisce un insieme di regole per la codifica di documenti in un formato che sia leggibile sia leggibile da una macchina."

Questa definizione si concentra sulla leggibilità e sul linguaggio piuttosto che sui meccanismi per gestire i dati.

Rispetto a un RDBMS, XML non fornisce mezzi per inserire ed eliminare a caso le righe in un file XML. Ad esempio, se si dispone di 1000000 righe e si desidera eliminare le righe casualmente anche in un singolo ambiente utente, il file basato su XML non sarebbe una buona scelta per un database. Inoltre, XML non fornisce alcun meccanismo nativo per il blocco dei dati. Infatti, poiché XML non è un software, tutte le proprietà ACID (atomicità, consistenza, isolamento, durata) che garantiscono che le transazioni del database siano elaborate in modo affidabile in un ambiente condiviso sono lasciate allo sviluppatore da costruire (ad eccezione della durabilità). XML non ha una specifica robusta per gestire l'integrità dei dati tra file XML, per non parlare di server diversi (ad esempio file xml del cliente e file xml degli ordini - Nessun FK per rafforzare l'integrità).

Quanto sopra non è un'enumerazione di ciò che manca XML, invece, potrebbe server come una giustificazione rapida della dichiarazione che XML non è un software di database.

XML non ha mai significato essere un database o sostituirlo.

L'XML è principalmente definito per i documenti Web che allows for the creation of customized tags for individual information fields. Tuttavia, con esso non si otterrebbe mai la gestione centralizzata dei dati relazionale.

Perché in realtà vorresti usare XML per memorizzare dati in primo luogo? Voglio dire, è una lingua dopo tutto ...

Mentre si potrebbe sostenere che si tratta di un formato flessibile e di facile comprensione, ciò si applica solo quando è necessario apportare modifiche manuali ai file. Quando interagisci effettivamente con il database con un'interfaccia comune (recupera i dati X che soddisfano i requisiti Y e Z, memorizza / aggiorna i dati X, ...) questi vantaggi diventano nulli.

Risposta breve: Dipende.

Risposta lunga: Dal mio punto di vista questo dipende strongmente dalla quantità di dati che si desidera memorizzare. Per esempio. se hai un paio di oggetti nella tua applicazione durante il runtime e vuoi memorizzarli dopo aver eseguito lo strumento, un file XML è perfettamente a posto. Tuttavia, se il tuo negozio online ha 5000 clienti e un numero ancora maggiore di ordini, un database sarebbe uno spazio di archiviazione dei dati più appropriato.

Inoltre penso che memorizzare le impostazioni in un database e non in un file come app.config nella maggior parte dei casi non sia molto utile, ma non credo che questo esempio provi la citazione sbagliata.

XML è una scelta eccellente per le impostazioni di configurazione. Non solo i file XML sono facili da analizzare / evidenziare in un IDE, sono molto facili da modificare per i non programmatori. Li trovo incredibilmente utili in scenari di sviluppo web in cui le attività di manutenzione vengono eseguite da progettisti e gestori di contenuti.

In genere, l'XML non deve essere utilizzato come origine dati primaria per qualsiasi applicazione non banale. Il sovraccarico di serializzazione / deserializzazione richiede solo una soluzione diversa.

Il termine database può riferirsi sia ai soli dati grezzi, sia al sistema di gestione del database. Questa definizione fa una grande differenza nell'intero argomento.

Se utilizziamo la definizione RDBMS, XML ha molto poco in questo senso. Si ottiene molto poco in termini di garanzie ACID (dovresti scrivere il tuo codice per realizzarle). Se ne hai bisogno (e la maggior parte dei sistemi transazionali lo fa), sei già nei guai. Potrei fornire un elenco di centinaia di funzionalità che sono date per scontate con RDBMS, che dovresti reinventare e reimplementare. Pensa ai modelli di sicurezza, alla replica, ai backup, solo per citarne alcuni di base.

Nel senso precedente, no, XML non è un database e non dovresti provare a usarlo come tale.

Se usiamo la definizione di "dati grezzi", XML è molto più buono, ma non altrettanto eccezionale. Come altri hanno sottolineato, in generale è molto prolisso, tipicamente privo di codifica binaria e con tag duplicati, ecc. Si tratta di compromessi realizzati in modo che l'XML possa essere leggibile dall'uomo - in pratica, l'efficienza è il nemico di questo requisito . XML non è particolarmente adatto anche per le situazioni più semplici in cui si inseriscono continuamente i record. Supponendo che si desidera che il file XML sia valido, è necessario un singolo tag di chiusura, il che significa che l'aggiunta di un record significa che è necessario spostare i tag alla fine. Questo è piuttosto costoso (come sappiamo dove inizia quel tag? E se ci sono più "tabelle", spostiamo semplicemente l'intero file?), E se vuoi ovviare a questo, reinventerai un approccio simile a molti database - distribuendo tabelle su più file e crescendo dinamicamente quei file secondo necessità.

Ci sono situazioni in cui XML è appropriato - i file di configurazione sono un ottimo esempio, perché sono tipicamente piccoli e la leggibilità umana è una caratteristica eccellente da avere. Avere un database solo per un file di configurazione potrebbe essere eccessivo.

I database, d'altra parte, sono eccellenti quando si hanno migliaia (o milioni / miliardi) di record e molti utenti li aggiornano contemporaneamente. Quindi sì, XML non è un database e non dovresti usarlo come tale. Il tuo esempio sembra essere una di quelle situazioni in cui non avevi bisogno di un DB in primo luogo, e XML è la soluzione migliore.

Il modo in cui lo vedo è questo: se usi XML come DB (ad esempio, come backing store per un sistema transazionale), finirai per reinventare e riscrivere un RDBMS . Questo è un modo davvero scadente per spendere tempo ed energie. Penso che questo sia quello che diceva anche questa citazione.

Sono d'accordo che non è un database relazionale. Penso che l'autore stia semplicemente dicendo nella citazione di non usarlo come tale.

Detto questo anche se potresti averne bisogno o no. Se non è necessario eseguire molte query sui dati e si desidera solo memorizzarli e recuperarli in seguito in base a determinati criteri di query limitati, è necessario archiviare e recuperare XML DOCUMENT, non un database relazionale.

Ci sono un sacco di applicazioni che hanno semplicemente bisogno di archiviare un documento con i dati al suo interno per recuperarlo in un secondo momento. Se questo è il caso, è inutile creare uno schema basato su SQL, analizzare l'XML e quindi serializzarlo sul database solo per fare solo il contrario più tardi. C'è un sovraccarico di codice potenzialmente coinvolto nel farlo. C'è meno se lo fai bene.

È possibile utilizzare gli strumenti ORM come Hibernate e strumenti come Apache Axis per generare automaticamente tutto il codice necessario per creare un servizio che gestisca semplicemente operazioni CRU semplici. Dovresti ovviamente includerlo nell'autenticazione e, possibilmente, voler separare i dati in base all'utente, al livello di accesso, ecc. Potresti anche voler limitare le operazioni che un determinato utente può eseguire tramite il servizio SOAP per esempio.

In questo senso stai facendo più come la gestione dei contenuti che altro.