Datenbanken im XML Format - Ist das die Zukunft der Datenbanken?
-
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.
-
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.
Du sprichst mir aus der Seele
-
Schon mal darüber nachgedacht, warum es so eine Sch... wie xml usw gibt,
anstatt Binärformate (genormt) für Datenaustausch ?
Je weniger Info in mehr Bytes gepackt wird, um so mehr Platten, Sicherungsbänder
usw können auch verkauft werden.Gleichzeitig msß die Hardware aufgerüstet
werden usw usw.
Man braucht doch nur mal ne alte Cobol- Anwendung mit ner neuen SAP-Anwendung
bei gleicher Fallzahl zu vergleichen -da wird einem (aus eigener Erfahrung)
einfach nur schlecht.
Einmal alle Beiträge auslesen - alt (IMS Z/OS COBOL) ca 30 Minuten.
Wir reden hier von ca 900.000 Konten mit ca 10 Buchungen pro Monat.
Jetzt - paralleisiert, weil der Tag halt nur 24 Stunden hat, mit
SAP - schön modern - und mit 6 App-Servern usw ca 2 Stunden.
Das ist Fortschritt - aber die Anzeige im SAP ist bunt, was ja heute wichtiger
ist, wie performante Anwendungen.
Schnittstellen zu SAP haben z. B seit einigen Jahren das IDOC-FOrmat.
Sprich - für 1 Information, z B die Telefonnumer werden 3 Segmente mit ca
90 Byte Vorspann verbraten.sprich 270 Byte für ein 20-Stelliges Feld - und
so zieht sich das durch.
Wenn man sich dann mal die Tabelleninfos des Datenbanksystems anschaut und
dabei feststellt, daß z. b ein einstelliges Feld mit varchar gespeichert wird,
sprich 2 Byte Längenfeld für nix pro Tabelleneintrag - hier teilweie 85.000.000 und mehr, da denke ich gerne an die alten Zeiten zurück, wo man bei
gepackten Datumsfeldern das Vorzeichen entfernte, um ein Byte zu sparen.
(x'0900502f' wurde zu x'900502' (EBCDIC Decimal))
-
Nimm BaseX (www.basex.org), die beste und performanteste XML Datenbank die es gibt.
-
eXalite schrieb:
Nimm BaseX (www.basex.org), die beste und performanteste XML Datenbank die es gibt.
Woher hast du diese Information? Die mir bekannten XML-Benchmarks sind zwar schon älter, kommen aber alle zu anderen Ergebnissen ...
Neugierige Grüße
