it-swarm.com.de

Verwendung von XML als Datenspeicher

Ich habe über das XML-Format und das folgende Zitat nachgedacht:

„XML ist keine Datenbank. Es war nie als Datenbank gedacht. Es wird niemals eine Datenbank sein. Relationale Datenbanken sind bewährte Technologien mit mehr als 20 Jahren Implementierungserfahrung. Sie sind feste, stabile und nützliche Produkte. Sie gehen nicht weg. XML ist eine sehr nützliche Technologie zum Verschieben von Daten zwischen verschiedenen Datenbanken oder zwischen Datenbanken und anderen Programmen. Es ist jedoch selbst keine Datenbank. Verwenden Sie es nicht wie eines. “- Effektives XML: 50 spezifische Möglichkeiten zur Verbesserung Ihres XML von Elliotte Rusty Harold (Seite 230, Teil 4, Punkt 41, 2. Absatz )

Dies scheint wirklich zu betonen, dass XML nicht für die Datenspeicherung und nur für die Interoperabilität von Programm zu Programm verwendet werden sollte.

Persönlich bin ich anderer Meinung und .NETs app.config Die Datei, in der die Einstellungen eines Programms gespeichert werden, ist ein Beispiel für die Speicherung von Daten in einer XML-Datei. Für Datenbanken anstelle von Konfigurationen usw. sollte XML jedoch nicht verwendet werden.

Um meinen Standpunkt zu erläutern, werde ich zwei Beispiele verwenden:
A) Daten über Kunden mit Feldern, die sich alle auf einer Ebene befinden, d. H. Es gibt eine Reihe von Feldern, die sich alle auf einen Kunden ohne Kinder beziehen
B) Daten zur Konfiguration einer Anwendung, bei der verschachtelte Felder und Eigenschaften sehr sinnvoll sind

Meine Frage lautet also: Ist dies noch eine gültige Aussage und ist es jetzt akzeptabel, Daten mithilfe von XML zu speichern?

BEARBEITEN: Ich habe eine E-Mail an den Autor dieses Zitats gesendet, um ihn nach seiner Eingabe/seinem zusätzlichen Kontext zu fragen.

12
Kian

In diesem Zitat geht es nicht um die Verwendung von XML als Speicherformat im Allgemeinen (für das es je nach Anforderungen in Ordnung ist), sondern um Speicher vom Typ Datenbank -.

Wenn von Datenbanken die Rede ist, sind damit normalerweise Speichersysteme gemeint, in denen große Datenmengen gespeichert werden, häufig im Gigabyte- oder Terabyte-Bereich. Eine Datenbank ist möglicherweise viel größer als die verfügbare Menge RAM auf dem Server, auf dem sie gespeichert ist. Da niemand alle Daten in einer Datenbank auf einmal benötigt, sollten Datenbanken für das schnelle Abrufen von selektiven Daten optimiert werden Teilmengen ihrer Daten: Dafür ist die Anweisung SELECT gedacht, und relationale Datenbanken sowie NoSQL-Lösungen optimieren ihr internes Speicherformat für das schnelle Abrufen solcher Teilmengen.

XML entspricht diesen Anforderungen jedoch nicht wirklich. Aufgrund seiner verschachtelten Tag-Struktur ist es unmöglich zu bestimmen, wo in der Datei ein bestimmter Wert gespeichert ist (in Form eines Byte-Offsets in einer Datei), ohne den gesamten Dokumentbaum zumindest bis zur Übereinstimmung zu durchlaufen. Eine relationale Datenbank verfügt über Indizes, und das Nachschlagen eines Werts in einem Index ist selbst bei einer primitiven binären Suchimplementierung eine einzelne O (log n) -Suche, und das Aufrufen der tatsächlichen Werte ist nichts anderes als eine Dateisuche (z fseek(data_file_handle, row_index * row_size)), das ist O (1). In einer XML-Datei ist es am effizientesten, einen SAX-Parser über Ihr Dokument auszuführen und dabei eine Menge Lese- und Suchvorgänge durchzuführen, bevor Sie zu Ihren tatsächlichen Daten gelangen. Sie können dies kaum besser als O (n) erreichen, es sei denn, Sie verwenden Indizes, aber dann müssten Sie den gesamten Index für jede Einfügung neu erstellen (siehe unten).

Das Einfügen ist noch schlimmer. Relationale Datenbanken garantieren keine Zeilenreihenfolge. Dies bedeutet, dass sie nur neue Zeilen anhängen oder als "gelöscht" gekennzeichnete Zeilen überschreiben können. Dies ist extrem schnell: Die Datenbank kann nur einen Pool beschreibbarer Speicherorte in der Nähe aufbewahren. Ein Eintrag aus dem Pool zu erhalten ist O(1), es sei denn, der Pool ist leer; im schlimmsten Fall ist der Pool leer und eine neue Seite muss erstellt werden, aber auch dies ist O (1) Im Gegensatz dazu müsste eine XML-basierte Datenbank alles nach der Einfügemarke verschieben, um Platz zu schaffen. Dies ist O (n). Wenn Indizes ins Spiel kommen, werden die Dinge noch interessanter: Typische relationale Datenbankindizes können mit aktualisiert werden relativ geringe Komplexität, z. B. O (log n); wenn Sie jedoch Ihre XML-Dateien indizieren möchten, ändert jede Einfügung möglicherweise den Speicherort jedes Werts im Dokument auf der Festplatte, sodass Sie Erstellen Sie den gesamten Index neu . Dies gilt auch für Aktualisierungen, da durch die Aktualisierung beispielsweise des Textinhalts eines Elements dessen Größe geändert werden kann, was bedeutet, dass das aufeinanderfolgende XML verschoben werden muss. Eine relationale Datenbank tut dies nicht Sie müssen den Index überhaupt berühren, wenn Sie eine nicht indizierte Spalte aktualisieren. Eine XML-Datenbank müsste den gesamten Index für jedes Update neu erstellen, das die Größe des aktualisierten XML-Knotens ändert.

Das sind die wichtigsten Nachteile, aber es gibt noch mehr. XML ist sehr ausführlich, was für die Server-zu-Server-Kommunikation gut ist, da es die Sicherheit erhöht (der empfangende Server kann alle Arten von Integritätsprüfungen für XML durchführen, und wenn bei der Übertragung ein Fehler aufgetreten ist, ist es unwahrscheinlich, dass das Dokument validiert wird ). Für die Massenspeicherung ist dies jedoch tödlich: Es ist nicht ungewöhnlich, dass XML-Daten einen Overhead von 100% oder mehr aufweisen (es ist nicht ungewöhnlich, dass Overhead-Verhältnisse im Bereich von 1000% für Dinge wie SOAP) angezeigt werden = Nachrichten), während typische relationale DB-Speicherschemata nur einen konstanten Overhead für Tabellenmetadaten sowie ein kleines Bit pro Zeile haben, stammt der größte Teil des Overheads in relationalen Datenbanken aus festen Spaltenbreiten. Wenn Sie ein Terabyte an Daten haben, 500% Overhead ist aus vielen Gründen einfach inakzeptabel.

12
tdammers

XML ist für die Datenspeicherung mies. Erstens ist es sehr ausführlich. In einer XML-Datei gespeicherte Daten belegen viel mehr Speicherplatz als dieselben Daten, die in einem vernünftigen Datenbanksystem gespeichert sind. In einem XML-Datensatz wird der Name eines bestimmten Felds zusammen mit der Zeichenfolgendarstellung der Daten zweimal gespeichert. Wenn Sie beispielsweise eine einzelne Ganzzahl in einem Feld namens "foobar" speichern möchten, erhalten Sie diese 19-Byte-Zeichenfolge:

<foobar>42</foobar>

Andererseits speichert eine echte Datenbank dies als einen einzelnen ganzzahligen Wert, der 4 Bytes benötigt. Wenn Ihre Datenbank klein ist, bedeutet das nicht viel, aber wenn Sie 10.000 Datensätze haben, ist das ein Problem.

Zweitens muss ein XML jedes Mal, wenn die Datei gelesen wird, aus dem Text analysiert werden. Für das obige Feld liest eine reale Datenbank die Binärdaten einfach aus dem Offset in den Speicher, von dem sie weiß, dass sie das Feld "foobar" gespeichert haben. Wenn die Datei als XML gespeichert ist, muss sie das Feld "foobar" lesen und diesen Text analysieren , bestimmen Sie, um welches Feld es sich handelt, analysieren Sie dann die Zeichenfolge "42" und konvertieren Sie sie in die Binärdatei 42.

Daher sind die Leistungseinbußen bei der Verwendung von XML enorm. Die Vorteile von XML bestehen darin, dass es für Menschen lesbar ist und eine einfache Datenübertragung zwischen vollständig getrennten Systemen ermöglicht. Keiner dieser Vorteile gilt für eine lokale Datenbank.

Die einzige Ausnahme bilden Konfigurationsdateien, die im Allgemeinen klein sind und im Allgemeinen von Menschen bearbeitet werden müssen.

Eine XML-Datenbank ist absolut größer und langsamer als jedes vernünftige SQL-System. Wenn Sie keinen Ausgleichsvorteil in Bezug auf die Lesbarkeit oder Interoperabilität des Menschen finden, macht es keinen Sinn, ihn für die Datenspeicherung zu verwenden.

21
Gort the Robot

XML ist je nach Kontext realisierbar. Wenn Ihre Daten ziemlich statisch sind und sich nicht viel ändern (z. B. Beispieldaten), ist XML eine gute Verwendung.

Konfigurationseinstellungen und Beispieldaten (auch wenn es sich um Millionen von Zeilen handelt, die sich jedoch selten ändern) sind gute Verwendungsmöglichkeiten für XML.

Das Lesen/Schreiben von Festplatten ist teuer, weit mehr als der Zugriff auf Daten von einem Oracle/SQL-Stack.

8
Ryan Ternier

Dies scheint wirklich zu betonen, dass XML nicht für die Datenspeicherung und nur für die Interoperabilität von Programm zu Programm verwendet werden sollte.

Ihre Prämisse ist fehlerhaft.

Der Absatz, den Sie zitieren, besagt tatsächlich, dass XML kein Ersatz für Datenbank ist, nicht, dass es nicht für Datenspeicherung verwendet werden sollte.

Es ist klar, dass eine Einstellungsdatei nicht mit einer Datenbank identisch ist und daher unterschiedliche Technologien verwendet werden können (und sollten?).

Korrigieren Sie mich, wenn ich falsch liege, aber Sie scheinen mehr Erfahrung mit Auszeichnungssprachen als mit Datenbanken zu haben. Wenn Sie ein wenig Erfahrung mit Datenbanken haben, werden Sie feststellen, für welche Domänen die beiden unterschiedlichen Technologien geeignet sind.

7
deadly

Das ist wirklich subjektiv. Dieses Zitat ist wie jemandes Meinung, Mann.

Ehrlich gesagt denke ich, dass XML eine praktikable Alternative zu einer Datenbank ist, da es gegenüber einem RDMS mehrere Vorteile bietet, einschließlich eines geringen Overheads, der einem günstigeren Speicher entspricht (insbesondere bei Verwendung eines Hosting-Dienstes, der Datenbanken separat berechnet).

Schauen Sie sich dasBlog und BlogEngine an. Beide Anwendungen verwenden standardmäßig XML zum Speichern.

Das gesagt. Es handelt sich nicht um ein RDMS. Wenn Ihre Daten eine hohe Volatilität aufweisen (viele Aktualisierungen, Einfügungen oder Löschungen) oder eine hohe Verfügbarkeit erforderlich ist, verwenden Sie eine Datenbank. XML eignet sich gut zum Speichern kleiner Dinge wie Konfigurationsdaten und Daten mit geringer Volatilität.

4
Kyle Trauberman

XML sollte niemals eine Datenbank sein oder diese ersetzen.

XML wird hauptsächlich für Webdokumente definiert, die allows for the creation of customized tags for individual information fields. Damit würden Sie jedoch niemals ein relationales zentrales Datenmanagement erreichen.

1
Yusubov

meine Frage ist: Ist dies noch eine gültige Aussage und ist es jetzt akzeptabel, Daten mithilfe von XML zu speichern?

Ich sehe Ihren Standpunkt in Ihrem Beispiel zu .NET-Konfigurationsdateien. Es könnte jedoch auch ein anderes Dateiformat verwendet werden. Früher wurden solche Einstellungen in regulären Textdateien mit dem Namen INI files) gespeichert.

Ich sehe, dass die Aussage, die Sie in grau dargestellt haben , gültig und korrekt ist, wenn Sie eine Datenbank als Softwaresystem definieren.

Die Definition von XML in XML-Definition besagt, dass "(XML) eine Auszeichnungssprache ist, die eine Reihe von Regeln zum Codieren von Dokumenten in einem Format definiert, das sowohl für Menschen als auch für Maschinen lesbar ist."

Diese Definition konzentriert sich eher auf Lesbarkeit und Sprache als auf Mechanismen zur Verwaltung der Daten.

Im Vergleich zu einem RDBMS bietet XML keine Möglichkeit, Zeilen in eine XML-Datei zufällig einzufügen und zu löschen. Wenn Sie beispielsweise 1000000 Zeilen haben und Zeilen auch in einer einzelnen Benutzerumgebung zufällig löschen möchten, ist eine XML-basierte Datei für eine Datenbank keine gute Wahl. Außerdem bietet XML keine nativen Mechanismen zum Sperren von Daten. Da XML keine Software ist, werden alle ACID-Eigenschaften (Atomizität, Konsistenz, Isolation, Haltbarkeit), die gewährleisten, dass Datenbanktransaktionen in einer gemeinsam genutzten Umgebung zuverlässig verarbeitet werden, dem Entwickler überlassen (mit Ausnahme der Haltbarkeit). XML verfügt nicht über eine robuste Spezifikation für die Datenintegrität in XML-Dateien, geschweige denn für verschiedene Server (z. B. XML-Datei des Kunden und Bestellung der XML-Datei - Keine FKs zur Durchsetzung der Integrität).

Das Obige ist keine Aufzählung dessen, was XML fehlt, sondern könnte als schnelle Rechtfertigung für die Aussage dienen, dass XML keine Datenbanksoftware ist .

1
NoChance

Warum sollten Sie eigentlich XML für Speichern von Daten verwenden? Ich meine, es ist eine Sprache schließlich ...

Man könnte zwar argumentieren, dass es sich um ein flexibles und leicht verständliches Format handelt, dies gilt jedoch nur, wenn Sie die Dateien manuell bearbeiten müssen. Wenn Sie tatsächlich mit Datenbank mit einer gemeinsamen Schnittstelle interagieren (Daten X abrufen, die die Anforderungen Y und Z erfüllen, Daten X speichern/aktualisieren, ...), werden diese Vorteile ungültig.

0
zxcdw

Kurze Antwort: Es kommt darauf an.

Lange Antwort: Aus meiner Sicht hängt dies stark von der Datenmenge ab, die Sie speichern möchten. Z.B. Wenn Sie zur Laufzeit einige Objekte in Ihrer Anwendung haben und diese nach dem Ausführen des Tools speichern möchten, ist eine XML-Datei vollkommen in Ordnung. Wenn Ihr Webshop jedoch 5000 Kunden und noch mehr Bestellungen hat, wäre eine Datenbank eine geeignetere Datenspeicherung.

Außerdem denke ich, dass das Speichern von Einstellungen in einer Datenbank und nicht in einer Datei wie app.config in den meisten Fällen nicht sehr nützlich ist, aber ich denke nicht, dass dieses Beispiel beweist, dass das Zitat falsch ist.

0
Simon

XML ist eine ausgezeichnete Wahl für Konfigurationseinstellungen. XML-Dateien lassen sich nicht nur einfach in einer IDE analysieren/hervorheben, sondern auch für Nicht-Programmierer sehr einfach bearbeiten. Ich finde sie unglaublich nützlich in Webentwicklungsszenarien, in denen Wartungsaufgaben von Designern und Content Managern ausgeführt werden.

XML sollte normalerweise nicht als primäre Datenquelle für nicht triviale Anwendungen verwendet werden. Allein der Aufwand für Serialisierung/Deserialisierung erfordert eine andere Lösung.

0
Traxxus

Ich bin damit einverstanden, dass es sich nicht um eine relationale Datenbank handelt. Ich denke, der Autor sagt im Zitat einfach, es nicht als eins zu verwenden.

Trotzdem, obwohl Sie vielleicht einen brauchen oder nicht. Wenn Sie die Daten nicht wirklich abfragen müssen und sie nur speichern und später anhand einiger begrenzter Abfragekriterien abrufen möchten, benötigen Sie das Speichern und Abrufen von XML-DOKUMENTEN - keine relationale Datenbank.

Es gibt viele Anwendungen, bei denen lediglich ein Dokument mit Daten gespeichert werden muss, damit es später vollständig abgerufen werden kann. Wenn dies der Fall ist, ist es sinnlos, ein SQL-basiertes Schema zu erstellen, das XML zu analysieren und es dann in die Datenbank zu serialisieren, um später genau das Gegenteil zu tun. Dies ist möglicherweise mit viel Code-Overhead verbunden. Es gibt jedoch weniger, wenn Sie es richtig machen.

Sie können ORM-Tools wie Hibernate und Tools wie Apache Axis verwenden, um praktisch den gesamten Code automatisch zu generieren, den Sie zum Erstellen eines Dienstes benötigen, der nur einfache CRU-Vorgänge verarbeitet. Sie müssten dies natürlich in die Authentifizierung einschließen und möchten möglicherweise die Daten nach Benutzer, Zugriffsebene usw. trennen. Möglicherweise möchten Sie sogar einschränken, welche Vorgänge ein bestimmter Benutzer über SOAP Service zum Beispiel.

In diesem Sinne machen Sie mehr wie Content Management als alles andere.

0
Shoey

Der Begriff Datenbank kann sich entweder nur auf die Rohdaten oder auch auf das Datenbankverwaltungssystem beziehen. Diese Definition macht einen großen Unterschied im gesamten Argument.

Wenn wir die RDBMS-Definition verwenden, hat XML in diesem Sinne sehr wenig. In Bezug auf ACID-Garantien erhalten Sie nur sehr wenig (Sie müssten Ihren eigenen Code schreiben, um diese zu erreichen). Wenn Sie diese benötigen (und die meisten Transaktionssysteme), sind Sie bereits in großen Schwierigkeiten. Ich könnte eine Liste von Hunderten von Funktionen geben, die für RDBMS als selbstverständlich gelten und die Sie neu erfinden und neu implementieren müssten. Denken Sie an Sicherheitsmodelle, Replikation, Backups, um nur einige grundlegende zu nennen.

Im obigen Sinne ist XML keine Datenbank, und Sie sollten nicht versuchen, sie als eine Datenbank zu verwenden.

Wenn wir die Definition "Rohdaten" verwenden, ist XML viel besser, aber immer noch nicht so gut. Wie andere bereits betont haben, ist es im Allgemeinen sehr ausführlich, es fehlt normalerweise die binäre Codierung und es gibt doppelte Tags usw. Dies sind Kompromisse, die getroffen wurden, damit XML für den Menschen lesbar ist - im Grunde ist Effizienz der Feind dieser Anforderung . XML eignet sich auch nicht besonders gut für die einfachsten Situationen, in denen Sie kontinuierlich Datensätze einfügen. Angenommen, Sie möchten, dass Ihre XML-Datei gültig ist, benötigen Sie ein einzelnes schließendes Tag. Wenn Sie also einen Datensatz anhängen, müssen Sie die Tags am Ende nach oben verschieben. Dies ist ziemlich teuer (woher wissen wir, wo dieses Tag beginnt? Was passiert, wenn es mehrere "Tabellen" gibt, verschieben wir nur die gesamte Datei nach oben?), Und wenn Sie es umgehen möchten, erfinden Sie einen ähnlichen Ansatz neu auf viele Datenbanken - Verteilen von Tabellen auf mehrere Dateien und dynamisches Erweitern dieser Dateien nach Bedarf.

Es gibt Situationen, in denen XML angemessen ist - Konfigurationsdateien sind ein gutes Beispiel, da sie normalerweise klein sind und die Lesbarkeit durch den Menschen eine hervorragende Funktion darstellt. Eine Datenbank nur für eine Konfigurationsdatei zu haben, kann übertrieben sein.

Datenbanken hingegen eignen sich hervorragend, wenn Sie Tausende (oder Millionen/Milliarden) Datensätze haben und viele Benutzer sie gleichzeitig aktualisieren. Ja, XML ist keine Datenbank, und Sie sollten sie nicht wie eine verwenden. Ihr Beispiel ist eine der Situationen, in denen Sie überhaupt keine Datenbank benötigten und XML besser passt.

Ich sehe das folgendermaßen: Wenn Sie XML als Datenbank verwenden (z. B. als Sicherungsspeicher für ein Transaktionssystem), werden Sie am Ende ein RDBMS neu erfinden und neu schreiben. Das ist eine wirklich schlechte Art, Zeit und Energie zu verbringen. Ich denke, das hat auch dieses Zitat gesagt.

0
Daniel B