Ankündigung

Einklappen
Keine Ankündigung bisher.

Lösung für performanten Umgang mit großen XML-Files gesucht

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Lösung für performanten Umgang mit großen XML-Files gesucht

    Hallo PHP.de-Mitglieder,

    Zwei Mitstudenten und Ich arbeiten gerade an einer Software, bei der XML-Dateien ausgelesen werden, Werte verglichen und präsentiert werden müssen.

    Hier erst einmal die Eckdaten zu den XML-Dateien:
    Anzahl: 20.000 Files
    Größe pro Datei: 5Kb bis 5Mb
    Elemente pro Datei: bis zu 40.000, hauptsächlich numerische Werte
    Parallele Vergleiche: bis zu 100 Dateien

    Unser Hauptproblem liegt jetzt in der Speicherung und dem Auslesen der Dateien. Beim Auslesen können wir uns nicht auf wenige Elemente konzentrieren und müssen daher alle - bis zu 40.000 - Elemente auslesen können. Dementsprechend fällt eine Speicherung der Elemente in MySQL schonmal weg.

    Unsere Theorien gehen hin und her, aber wir finden bisher keinen optimalen Lösungsansatz, außer die XML-Dateien auf der Festplatte zu speichern und On-Demand auszulesen.

    Kennt ihr möglicherweise performantere Lösungen?

    Wir sind für jede Hilfe und jeden Hinweis dankbar.

    Mit freundlichen Grüßen
    Marco

  • #2
    Dementsprechend fällt eine Speicherung der Elemente in MySQL schonmal weg.
    Bitte erklären.
    [COLOR="#F5F5FF"]--[/COLOR]
    [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
    [COLOR="#F5F5FF"]
    --[/COLOR]

    Kommentar


    • #3
      Zitat von RedFin Beitrag anzeigen
      Kennt ihr möglicherweise performantere Lösungen?
      Performanter als ...?

      An "Laden & Parsen" wirst du wohl kaum vorbeikommen. Wenn das bereits euer Flaschenhals ist, benutzt schnellere Festplatten oder lasst euch per Gigabit Netzwerk die Daten von einem Host liefern, der es schneller kann als euer lokales System.

      Wenn ihr alles im Speicher halten wollt, dann braucht ihr wohl ne Menge RAM (ist aber bei ner Datenbank auch nicht anders)

      Eine andere Programmiersprache als eine Scriptsprache/Bytecode wäre ebenfalls überlegenswert, falls Codeausführung ein Flaschenhals ist.

      Präsentation von der Verarbeitung komplett abtrennen.

      Parallele Vergleiche: Definitiv nicht mit PHP. Bevor ihr da 100 PHP Instanzen spawnt, machts lieber in einer thread-fähigen Sprache.
      Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

      Kommentar


      • #4
        Zitat von nikosch Beitrag anzeigen
        Bitte erklären.
        Schonmal eine MySQL-Datenbank mit 40.000 Spalten betrieben?

        Zitat von lstegelitz Beitrag anzeigen
        Wenn ihr alles im Speicher halten wollt, dann braucht ihr wohl ne Menge RAM (ist aber bei ner Datenbank auch nicht anders)
        Dazu hab ich wohl einige Fragen, da ich mich auf diesem Gebiet wenig auskenne.
        Gibt es denn eine Möglichkeit (vorallem bei Benutzung von PHP) diese Files dauerhaft im Speicher zu halten?
        Das PHP (z.B. per xpath) nicht auf die Platte, sondern auf den RAM zugreift? Das wäre ja schonmal ein performanterer Lösungsansatz als es auf der Platte liegen zu lassen, auch wenn ich mir bewusst bin, dass RAM um einiges teurer ist.

        Kommentar


        • #5
          Schonmal eine MySQL-Datenbank mit 40.000 Spalten betrieben?
          Ich sehe bisher keinen Grund, warum die Tabelle 40000 Spalten haben sollte.
          [COLOR="#F5F5FF"]--[/COLOR]
          [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
          „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
          [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
          [COLOR="#F5F5FF"]
          --[/COLOR]

          Kommentar


          • #6
            Schonmal eine MySQL-Datenbank mit 40.000 Spalten betrieben?
            Und wie wäre es wenn Du die Spalten zu Zeilen machst:

            id:element:elementValue:datei_fid
            -

            Kommentar


            • #7
              mutliplex comparsion auf multi-XML Ebene ist am performantesten via Stylesheets und Compare-Templates die auf document()-Pfade arbeiten. 500 MB In-Memory DOM ist kein Problem für XSLT.

              Und ja, ich rede hier von einer Datei-XML, die die Dateipfade vorhält, einem Stylesheet die Comparsion-Logik enthält und die Document()-Mechanik die aus den 100 XMLs dann eure Ergebnisse erzeugt. XSLT ist da schneller als DOMDocument, da es auch für sehr große XMLs gedacht ist. ( Das größte was ich mit XSLT verarbeitet habe waren 1,5 GB Dateien )

              Versucht das ganze aber nicht "im Browser lauffähig zusammenzubauen", der kann zwar XSLT, aber begrenzt sein können in der Same Origin Policy, file://-wrapper-Pfade gelten jeder für sich als "eine Domain".
              [URL="https://gitter.im/php-de/chat?utm_source=share-link&utm_medium=link&utm_campaign=share-link"]PHP.de Gitter.im Chat[/URL] - [URL="https://raindrop.io/user/32178"]Meine öffentlichen Bookmarks[/URL] ← Ich habe dir geholfen ? [B][URL="https://www.amazon.de/gp/wishlist/348FHGUZWTNL0"]Beschenk mich[/URL][/B].

              Kommentar


              • #8
                Die Präsentation der Frage lässt nicht unbedingt viele klare Schlüsse zu, weshalb ich mich bis auf weiteres der Meinung anschließe, dass eine Datenbanklösung erst mal wegargumentiert werden sollte. (Im Zweifel durch genauere Beschreibung der Aufgabe.)

                Das mache ich auch an der Rückantwort zu den „40.000 Spalten“ fest, die – na ja – sehr zweidimensional gedacht ist, obwohl vermutlich eher relational gedacht werden sollte.

                Kommentar


                • #9
                  Ich stell einfach mal BaseX in den Raum.

                  Kommentar


                  • #10
                    Hallo,

                    vielen Dank für die zahlreichen Antworten. Einige haben uns doch schon sehr viel weiter geholfen. Das Kippen der Datensätze von horizontal in vertikal ist uns nichtmal in den Sinn gekommen? Wie sieht es da mit der Performanz aus? Zu den o.g. Daten kommen jährlich etwa 1000 Files, sprich 40.000.000 Datensätze hinzu.

                    Zitat von mermshaus
                    Die Präsentation der Frage lässt nicht unbedingt viele klare Schlüsse zu, weshalb ich mich bis auf weiteres der Meinung anschließe, dass eine Datenbanklösung erst mal wegargumentiert werden sollte. (Im Zweifel durch genauere Beschreibung der Aufgabe.)

                    Das mache ich auch an der Rückantwort zu den „40.000 Spalten“ fest, die – na ja – sehr zweidimensional gedacht ist, obwohl vermutlich eher relational gedacht werden sollte.
                    Dann muss ich mich für das Missverständnis entschuldigen. Wir sind nur drei Studenten, die mit einem so großen Projekt noch nicht viel Erfahrung haben und sind demnach für jede Hilfe dankbar. Bisher schien uns eine Umsetzung in einer Datenbank der falsche Ansatz, durch die besagten 40.000 Spalten, die wir irgendwie umsetzen müssten.

                    Hast du noch ein paar genauere Vorschläge, wie du so etwas ungefähr umsetzen würdest? Wie gesagt, unsere Erfahrung ist leider in diesen Dingen ausgeschöpft? Was ich in den Raum werfen kann: Pro Element ein Table anlegen? Die Struktur ganz kippen (in die Vertikale), was dann bis zu 40.000 Zeileneinträge pro File mit sich führt? Über einen Ansatz wäre ich dankbar.

                    Zitat von erc
                    Ich stell einfach mal BaseX in den Raum.
                    Danke, das schau ich mir jetzt mal an.


                    Um die Frage und das Problem nochmal in einigen Sätzen zu definieren:
                    Wir befinden uns vor dem Problem, dass unser Backend wirklich stabil und performant agieren muss. Wir müssen diese vielen XML-Files sowieso auf der Festplatte des Servers abspeichern, die Frage, die die Performanz betrifft ist aber eigentlich diejenige, wie man diese XML-Files performant vergleichen kann. Konkretes Beispiel: Ich habe bis zu 100 XML-Files von verschiedenen Universitäten, die unterschiedlich viele Elemente haben können. Rein intuitiv wäre ein Zugriff auf die Festplatte und das Lesen der XML-Files, um diese danach zu vergleichen, eher inperformant.

                    Davon ausgehend suchen wir eine Lösung, die performante Vergleiche solcher Dateien zulässt. Bisher kamen wir da nur auf eine gewöhnliche Datenbank, die wir aufgrund der 40.000 Spalten schnell aus den Augen verloren haben. Deshalb sind wir auf Ansätze Eurerseits angewiesen.

                    Wie wir auch wissen, ist die Umsetzung eines solchen Vorhabens in PHP sicher nicht ganz so geeignet. Von einer Umsetzung in einer anderen Sprache sehen wir allerdings ab.

                    Was haltet ihr - basierend auf Euren Vorschlägen - von dieser Lösung?
                    Wir speichern die XML-Files auf der Festplatte und lesen diese einmal aus und schreiben alles wichtige in eine MySQL-Datenbank. Hierbei verteilen wir die Elemente so, dass wir eher eine vertikale Struktur haben, wie jack88 mit id:element:elementValue:datei_fid schon angedeutet hat. Verbesserungsvorschläge an der Stelle gerne gesehen. Falls wir dann noch Performanzprobleme haben, könnte man das ganze noch hiermit beschleunigen: http://memsql.com/ .

                    Grüße
                    Marco

                    Kommentar


                    • #11
                      Sofern man das pauschal sagen kann: Alle Daten aller Dateien in eine Tabelle dürfte der sinnvolle Ansatz sein.
                      [COLOR="#F5F5FF"]--[/COLOR]
                      [COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
                      „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                      [URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
                      [COLOR="#F5F5FF"]
                      --[/COLOR]

                      Kommentar


                      • #12
                        Die Beschreibung des Problems ist leider zu allgemein für einen konkreten Lösungsvorschlag. Was wollt Ihr denn eigentlich konkret vergleichen:

                        - Dateien gleich/unterschiedlich
                        - Anzahl der Elemente
                        - alle Elemente/bestimmte Elemente
                        - vielleicht nur bestimmte Keys oder Values
                        etc…

                        Wie soll ein Vergleich also konkret ablaufen - man könnte ja erst mal z.B. mit zwei Files anfangen
                        -

                        Kommentar


                        • #13
                          Hier könnte man eventuell mit MySQLs ExtractValue spielen - wie das vom Speed her mithalten kann, müsste man testen. Zumindest könntest du möglichst viele zu vergleichende Daten im RAM cachen, dann per stored procedure durchiterieren. Wobei ich nicht einschätzen kann, ob dir der mysql-Funktionsumfang dafür reicht.

                          Falls auch andere DBs in Frage kommen, schau dir mal Postgre an, per xml-exists und co. könntest du relativ bequem vergleichen.

                          Alternativ aus dem XML ein binary tree basteln und damit arbeiten. Würde auch super in eine schemalose DB passen. Für den Ansatz: http://ejohn.org/blog/javascript-tri...ance-analysis/
                          I like cooking my family and my pets.
                          Use commas. Don't be a psycho.
                          [URL="http://jscouch.de"]Blog[/URL] - [URL="http://coverflowjs.github.io/coverflow/"]CoverflowJS[/URL]

                          Kommentar


                          • #14
                            Vllt. wäre auch eine NoSQL-Datenbank einen Blick wert.

                            Grüße.

                            Kommentar


                            • #15
                              Zitat von RedFin Beitrag anzeigen
                              Unser Hauptproblem liegt jetzt in der Speicherung und dem Auslesen der Dateien. Beim Auslesen können wir uns nicht auf wenige Elemente konzentrieren und müssen daher alle - bis zu 40.000 - Elemente auslesen können. Dementsprechend fällt eine Speicherung der Elemente in MySQL schonmal weg.
                              Das ist natürlich wie vorher schon angemerkt quatsch. Datenbanken sind genau dazu da sich Unmengen von Daten zu merken, und diese mit hinnehmbarer Performance zu verarbeiten.
                              Zitat von RedFin Beitrag anzeigen
                              Kennt ihr möglicherweise performantere Lösungen?

                              Wir sind für jede Hilfe und jeden Hinweis dankbar.
                              Ihr möchtet womöglich ein Data-Warehouse!
                              Im Prizip ist das eine Kombination aus einer Datenspeicherungschicht(Datenbank,xml-files...) und einer Intelligenten Komponente(OLAP,ROLAP...) die Aggregationen vornimmt.

                              Wir arbeiten z.B. mit Mondrian

                              Kommentar

                              Lädt...
                              X