Datenbanken im XML Format - Ist das die Zukunft der Datenbanken?
-
nnn schrieb:
Benötigt viel zu viel Speicher und Zeit zum Parsen. Dementsprechend ist das noch um einiges schlechter als ein simples Textfile.
Nö.
XML Dateien kann man schön indizieren. Gibt ein paar recht gute XML Indexer bzw. "XML Datenbanken", die auch ne recht mächtige Query-Language haben.
-
ist doch schon bei css so das die selektoren end krass performace ziehen, wieso sollte das bei ner xml anders sein?
-
nnn schrieb:
Benötigt viel zu viel Speicher und Zeit zum Parsen. Dementsprechend ist das noch um einiges schlechter als ein simples Textfile.
Die Frage ist. Reden wir hier über XML-Dateien als Datenbank ( = Schwachsinn) oder über XML-Datenbanken?
-
hustbaer schrieb:
nnn schrieb:
Benötigt viel zu viel Speicher und Zeit zum Parsen. Dementsprechend ist das noch um einiges schlechter als ein simples Textfile.
Nö.
XML Dateien kann man schön indizieren. Gibt ein paar recht gute XML Indexer bzw. "XML Datenbanken", die auch ne recht mächtige Query-Language haben.Das mag durchaus sein, aber im richtigen Enterprise-Umfeld kommt man trotzdem nicht darum herum, Zeit & Speicher zu diskutieren. Datenbanken mit XML-Columns sind dort gang und gäbe, aber Datenbanken als XML Files kannst du gleich vergessen.
Stell dir mal vor, wie performant es ist, eine Datenbank mit bereits jetzt über 900 GB Datenfluss pro Monat (900 GB neue Daten pro Monat, jeweils am ersten Tag im Monat gesichert & truncated) als XML zu speichern. Und das ist erst der Anfang: Immer am Ende des Monats wird die gesamte Datenbank ins Data Warehouse verfrachtet. Dieses umfasst derzeit 16.4 Terrabyte (und wächst wie erwähnt mit ca 900 GB/Mt.).
Ich hatte ganz kurz Gelegenheit, ein solches System zu sehen. Und es war nicht lustig. Und es war ganz sicher keine Option, eine solche Datenbank als XML zu speichern
-
ProgChild schrieb:
nnn schrieb:
Benötigt viel zu viel Speicher und Zeit zum Parsen. Dementsprechend ist das noch um einiges schlechter als ein simples Textfile.
Die Frage ist. Reden wir hier über XML-Dateien als Datenbank ( = Schwachsinn) oder über XML-Datenbanken?
imho kein großer unterschied die schnellste structur ist eben leider kein object. so einfach ist das.
-
ProgChild schrieb:
nnn schrieb:
Benötigt viel zu viel Speicher und Zeit zum Parsen. Dementsprechend ist das noch um einiges schlechter als ein simples Textfile.
Die Frage ist. Reden wir hier über XML-Dateien als Datenbank ( = Schwachsinn) oder über XML-Datenbanken?
Jo, ein grosses XML-File als Datenbank misbrauchen halte ich auch für wenig sinnvoll. Für Kleinst-Projekte mag das gehen, aber viel Sinn macht es denke ich auch da nicht.
Was ich meinte sind "XML-Datenbanken". Aber nicht in dem Sinn wie z.B. MSSQL das anbietet, mit XML-Spalten in normalen Tabellen, sondern die Art, die einfach einen haufen kleiner XML Dateien "indiziert".
Daten hinzufügen/ändern/... wird dabei direkt mit den XML-Files gemacht, und die "XML-Datenbank" passt dann nur entsprechend den Index neu an.@/rant/:
Ich wollte damit nicht sagen dass XML-Datenbanken die Silver-Bullet sind mit der man alles totschiessen kann. Ich meinte nur, man kann damit durchaus vernünftig arbeiten, und das Parsen etc. ist kein Problem, da ein entsprechender Indexer sich darum kümmert. Der Index wird dabei ja persistiert, d.h. nicht bei jedem Start neu aufgebaut. Und immer nur die Teile aktualisiert wo sich in den entsprechenden XML-Files etwas geändert hat.
Der Unterschied zu XML-Spalten in einer normalen Datenbank ist da nicht sehr gross - was den XML-Teil und Performance angeht.@no_code:
Wieso sollte das keinen grossen Unterschied machen? Ein Index-Lookup ist schnell, das Parsen Durchsuchen von wigabyteweise XML Files dagegen ist langsam. Ich würde schon sagen dass das nen grossen Unterschied macht.----
Anderer Blickwinkel: XML-Datenbanken ermöglichen einem ohne Validierung beliebige Daten aufzunehmen. Mit klassischen relationalen Datenbanken geht das nicht, da muss man jedes mal das Schema anpassen.
Einerseits ist das eine Stärke der XML-Datenbanken, auf der anderen Seite natürlich auch eine grosse Schwäche.
Ähnlich wie es bei dynamisch typisierten Sprachen ala Python vs. statisch typisierte Sprachen ala C++, Eiffel etc. aussieht.
Mit Python & XML-Datenbanken kann man schnell was auf die Füsse stellen, dafür man man sich auch leichter in selbige schiessen wenn man nicht aufpasst, und verbrät etwas Performance.
-
Naja wie wird eine DB intern gehändelt, Tabellen sind Structs die in einer verkettelten Liste oder Binärem Baum liegen und Serialisiert werden bzw aus der Serialisierung gecached werden.
Inidzierung von XML Files kann da nicht wirklich in der Performance mithalten.
Und wenn ich so gerade an Banken denke die im Stundenrhythmus gigantische Tabellen replizieren, Buchungen mit anderen Banken durchführen in gigantischen Mengen bei gleichzeitig 5 oder 6 stelligen Zugriffen. Oder wenn mann sich vorstellt was so ein Media Markt oder anderes Unternehmen der Größe an Wareneingang, Kasse Kundenpflege Statistick bucht und abfragt.
XML wird eventuell im Bereich der Filesysteme irgendwann unsere Partitionstabelle ablösen oder so was in der Richtung.
-
Zabou schrieb:
Naja wie wird eine DB intern gehändelt, Tabellen sind Structs die in einer verkettelten Liste oder Binärem Baum liegen und Serialisiert werden bzw aus der Serialisierung gecached werden.
Inidzierung von XML Files kann da nicht wirklich in der Performance mithalten.
Wieso sollte das so sein?
-
Zabou schrieb:
Und wenn ich so gerade an Banken denke die im Stundenrhythmus gigantische Tabellen replizieren, Buchungen mit anderen Banken durchführen in gigantischen Mengen bei gleichzeitig 5 oder 6 stelligen Zugriffen. Oder wenn mann sich vorstellt was so ein Media Markt oder anderes Unternehmen der Größe an Wareneingang, Kasse Kundenpflege Statistick bucht und abfragt.
Und da das ja die einzigen Verwender von Datenbanken sind, sind sämtliche Datenbanken, die für diese Einsatz-Zwecke nichts taugen, unbrauchbar.
Die klassischen Relationalen-Datenbanken haben auch ihre Nachteile. Sonst wären nicht in letzter Zeit so viele alternativen wie Pilze aus dem Boden geschossen.
-
hustbaer schrieb:
Wieso sollte das so sein?
XML generiert einen massiven Overhead ohne jeden Gewinn an Funktionalität. Wozu also das Ganze? XML als Austauschformat ergibt Sinn, aber nur dann wenn der Austausch relativ selten erfolgt. Die ganzen XML Formate für IPC sind nur Performance Killer.
-
ixemel schrieb:
Siehe Titel.
MFG.Nein, totaler Performance und Resourcenkiller.
-
ProgChild schrieb:
Die klassischen Relationalen-Datenbanken haben auch ihre Nachteile. Sonst wären nicht in letzter Zeit so viele alternativen wie Pilze aus dem Boden geschossen.
... die auf dem Markt faktisch keine Bedeutung haben. Man darf sich hier nicht von XML-Dateien statt wie früher normaler Binärdateien blenden lassen.
-
~john schrieb:
hustbaer schrieb:
Wieso sollte das so sein?
XML generiert einen massiven Overhead ohne jeden Gewinn an Funktionalität. Wozu also das Ganze? XML als Austauschformat ergibt Sinn, aber nur dann wenn der Austausch relativ selten erfolgt. Die ganzen XML Formate für IPC sind nur Performance Killer.
Wenn Du als Dienstleister das nach Speicherplatz abrechnest das System der Wahl
Overhead (der Nutzlose) ca Faktor 10 bis 100.
Dazu das Chaos mit (vorher) nicht bekannten Datenbankfeldern die aus dem
Nichts auftauchen können.
-
~john schrieb:
hustbaer schrieb:
Wieso sollte das so sein?
XML generiert einen massiven Overhead ohne jeden Gewinn an Funktionalität. Wozu also das Ganze? XML als Austauschformat ergibt Sinn, aber nur dann wenn der Austausch relativ selten erfolgt. Die ganzen XML Formate für IPC sind nur Performance Killer.
Bestimmte Queries sind auf XML Datenbanken bzw. indizierte XML Spalten in klassischen Datenbanken oft schneller, als wenn man dasselbe mit Tabellen nachbilden würde.
Baumartige Strukturen sind in klassischen Datenbanken die Hölle.Das Erstellen/Updaten des Index kann einen Flaschenhals darstellen, wenn zu oft Daten geändert werden.
Genauso *kann* es ein Problem sein, dass XML Files grösser sind.
Es *kann* auch unnötig umständlich werden Updates auf XML-Spalten oder XML-Datenbanken zu machen.Es gibt aber IMO durchaus Anwendungsfälle wo XML Spalten und/oder XML Datenbanken praktisch sind.
Man muss auch immer die Entwicklungszeit beachten, und gerade da kann XML oft punkten. Ob nun in Datenbanken oder als IPC Standard. Alleine der Umstand dass XML Files ohne spezielle Tools lesbar und editierbar sind ist oft schon viel wert.
-
Dann kann man auch sqlite nehmen. Man braucht natürlich ein Extra Tool zum Erstellen der Tabellen, etc. aber letztendlich ist der Zeitaufwand verschwindet gering. Zusätzliche Tools braucht man anschließend im Betrieb nicht mehr.
Das Editieren nachdem die Datenbank angelaufen ist, stelle ich mir bei XML aber als denkbar schwierig vor. Stell dir vor, du willst eine neue Spalte einfügen.
-
SQLite kann auch Tabellen erstellen.
Beim Open prüfen ob die Datei/Tabelle existiert, notfalls erzeugen. No Prob.
-
Scheppertreiber schrieb:
SQLite kann auch Tabellen erstellen.
Beim Open prüfen ob die Datei/Tabelle existiert, notfalls erzeugen. No Prob.
Ich habe auch von SQLite gesprochen und meien Kritik richtete sich gegen XML Stuff.
-
Dann kann man auch sqlite nehmen. Man braucht natürlich ein Extra Tool zum Erstellen der Tabellen, etc. aber letztendlich ist der Zeitaufwand verschwindet gering. Zusätzliche Tools braucht man anschließend im Betrieb nicht mehr.
Seht praktisch ist da der SQLite Manager für den Fuchs. Genial ...
-
---- schrieb:
Dann kann man auch sqlite nehmen.
Hä? Von was redest du?
Ich rede davon, dass es praktisch sein kann, wenn man bestimmte Dinge ohne spezielles Tool lesen kann.
-
hustbaer schrieb:
Bestimmte Queries sind auf XML Datenbanken bzw. indizierte XML Spalten in klassischen Datenbanken oft schneller, als wenn man dasselbe mit Tabellen nachbilden würde.
Baumartige Strukturen sind in klassischen Datenbanken die Hölle.Aber auch beim Baumartigen Strukturen ist XML nur die zweitbeste Lösung. XML kann alles aber nichts richtig. (gut wäre noch zu ergänzen)
hustbaer schrieb:
Man muss auch immer die Entwicklungszeit beachten,
Das ist exakt der Grund weshalb eine modernen Textverarbeitung genauso träge ist, wie Wordstar auf einem CP/M System. Es wird sich viel zu wenig Gedanken darüber gemacht, wie schnell das Zeug am Ende läuft, und statt einen sauberen Ansatz zu wählen wird einfach 08/15 irgend etwas hingewurschtelt.
