Ist es effizienter, externes XML zu analysieren oder die Datenbank zu treffen?

Question

Ich frage mich, wenn es um eine Web Service API geht, die XML zurückgibt, ob es besser (schneller) ist, den externen Dienst jedes Mal aufzurufen und die XML (mit ElementTree) für die Anzeige auf Ihrer Site zu analysieren oder die Datensätze in der Datenbank (nach dem Parsing einmal oder wie oft Sie jeden Tag benötigen) und stattdessen Datenbankaufrufe für die gleichen Informationen durchführen.

Answer 1

Jeder ist sehr höflich bei der Beantwortung dieser Frage: "Es kommt darauf an" ... "Sie sollten testen" ... und so weiter.

Wahr ist, die Frage geht nicht sehr detailliert über die Anwendung und Netz Topographien beteiligt, aber wenn die Frage überhaupt gestellt wird, dann ist es wahrscheinlich a) die DB ist "lokal" für die Anwendung (im gleichen Subnetz oder die gleiche Maschine oder im Speicher), und b) der Webservice ist nicht. Schließlich verwendet das OP die Ausdrücke "externer Dienst" und "Anzeige auf Ihrer eigenen Website". Der Satz "einmal analysieren oder so oft wie nötig für jeden Tag" schlägt auch eine Menge von Daten vor, die sich nicht genau jede Sekunde ändert.

Der klassische SOA Mythos ist, dass das Netzwerk immer verfügbar ist; Wenn ich einen Schritt weiter gehe, würde ich sagen, dass es ein Mythos ist, dass das Netzwerk immer mit geringer Latenz verfügbar ist. Sofern Ihre eigenen internen Systeme nicht beschissen sind, ist das Senden einer HTTP-Abfrage über das Internet immer langsamer als eine Abfrage an eine lokale DB oder einen DB-Cluster. Es gibt eine Reihe von Gründen dafür: Anzahl der Hops zum Remote-Server, Ausfall- oder Verschlechterungsprobleme, die Sie auf der Remote-Seite nicht kontrollieren können, und die interne Verarbeitungszeit für die Remote-Web-Service-Anwendung, um Ihre Anfrage zu analysieren eigene Persistenz Backend (aka DB), und ein Ergebnis zurückgeben.

Starten Sie Ihre App. Führen Sie einige Warte- und Antwortzeiten für Ihre Datenbank aus. Führen Sie das gleiche für einen Remote-Webdienst aus. Wenn Ihre Datenbank nicht auch über das Internet verfügbar ist, werden Sie einen großen Unterschied feststellen.

Es ist überhaupt nicht schwer für einen kompetenten Technologen, eine Datenbank zu skalieren, oder für Sie, die DB vollständig aus dem Zwischenspeichern mit Memcached und anderen Paradigmen zu entfernen; Die Latenzzeit zwischen Servern, die im Rechenzentrum nebeneinander sitzen, ist monumental geringer als zwischen Computern über das Internet (und sicherer, zu booten).Auch wenn das Erreichen dieses Maßstabs einige Überlegungen erfordert, ist es unter Ihrer Kontrolle, im Gegensatz zu einem Remote-Webdienst, dessen Skalierung und Latenzzeit für Sie vollkommen undurchsichtig ist. Ich für meinen Teil, wäre nicht allzu glücklich mit der Idee, dass die Verfügbarkeit und Reaktionsfähigkeit meiner Website auf jemand anderem basiert.

Was passiert schließlich, wenn der Remote-Webdienst nicht verfügbar ist? Stellen Sie sich eine Welt vor, in der jede Anfrage an Ihre Site eine Anfrage über das Internet an eine andere Site beinhaltet. Was passiert, wenn diese andere Website nicht verfügbar ist? Beobachten Ihre Benutzer mehrere Stunden lang einen sich drehenden Todescursor? Mögen sie einen Error 500, während Ihre Website auf diese unerwartete externe Abhängigkeit trifft?

Wenn Sie feststellen, dass Sie eine Architektur verwenden, deren grundlegende Merkmale für jede Anforderung von einem Internetanruf abhängig sind, denken Sie sehr genau über Ihre Anwendung nach, bevor Sie entscheiden, ob Sie mit den Konsequenzen leben können.

Answer 2

Der Verbrauch der Webservices ist effizienter, da es viel mehr Dinge gibt, die Sie tun können, um Ihre Webservices und Webserver zu skalieren (via Caching, etc.). Durch die Verwendung der mittleren Ebene haben Sie auch die Möglichkeit, das zurückgegebene Datenformat zu ändern (z. B. können Sie JSON anstelle von XML verwenden). Scaling-Datenbank ist viel schwieriger (mit Replikation, etc.) so im Allgemeinen reduzieren Sie die Treffer auf DB wenn Sie können.

Answer 3

Zuerst aus - messen. Nimm nicht einfach an, dass einer besser oder schlechter ist als der andere.

Zweitens, wenn Sie wirklich nicht messen möchten, würde ich vermuten, dass die Datenbank ein wenig schneller ist (vorausgesetzt, die Datenbank ist relativ lokal im Vergleich zum Web-Service). Netzwerklatenz ist in der Regel mehr als nur Zeit, es sei denn, wir sprechen eine wirklich komplexe Datenbank oder wirklich komplexe XML.

Answer 4

Es gibt nicht genug Informationen, um im allgemeinen Fall sicher sagen zu können. Warum tust du nicht ein paar Tests und findest es heraus? Da es sich anfühlt, als ob Sie Python benutzen, werden Sie wahrscheinlich das Timit-Modul verwenden wollen.

Einige Dinge, die das Ergebnis beeinflussen könnte:

• Performance der Web-Service, den Sie
• Zuverlässigkeit des Webdienstes Sie
• Entfernung zwischen Servern
• Datenmenge verwenden verwenden ist zurückgegeben

Ich würde vermuten, dass, wenn es cachefähig ist, dass eine zwischengespeicherte Version der Daten wird schneller sein, aber das bedeutet nicht unbedingt, dass Sie ein lokales RDBMS verwenden müssen, es könnte etwas wie memcached oder ein in-memory-cache in Ihrer Anwendung bedeuten.

Answer 5

Es kommt darauf an - wer ruft den Webservice an? Wird der Webdienst jedes Mal aufgerufen, wenn der Benutzer auf die Seite klickt? Wenn das der Fall ist, würde ich empfehlen, eine Caching-Schicht einzuführen - viele Web-Service-APIs drosseln die Anzahl der Treffer pro Stunde.

Ob Sie sich entscheiden, das zwischengespeicherte XML im laufenden Betrieb zu analysieren oder die Daten aus einer Datenbank abzurufen, spielt wahrscheinlich keine Rolle (es sei denn, wir sprechen hier von Unternehmensskalierung). Persönlich würde ich lieber einen einfachen SQL-Aufruf machen, als einen DOM-Parser zu schreiben (der viel anfälliger für außergewöhnliche Szenarien ist).

Answer 6

Es hängt von Fall zu Fall ab, Sie müssen messen (oder zumindest eine fundierte Schätzung machen).

Sie müssen mehrere Dinge berücksichtigen.

Web Service

• es könnte sich Hit-Datenbank
• es zwischengespeichert werden können
• es Netzwerk-Latenz einführen und könnte
• oder es könnte in lokalen Netzwerk sein und schneller als der Zugriff auf unzuverlässig auch lokale Festplatte

DB

• möglicherweise langsam, da es Platte zugreifen muss (obwohl Datenbanken internen Caches haben, aber die sind in der Regel gezielt nicht)
• sollte

Technologie selbst nicht viel bedeutet in Bezug auf die Geschwindigkeit zuverlässig sein - In einem Fall analysiert die Datenbank SQL, in einem anderen XML-Parser wird XML analysiert, und die Datenbank wird normalerweise auch über den Socket verarbeitet, so dass Sie sowohl Parsing als auch Netzwerk haben.

Caching Daten in Ihrer Anwendung, falls zutreffend ist wahrscheinlich eine gute Idee.

Answer 7

Wie ein paar Leute gesagt haben, es kommt darauf an, und Sie sollten es testen.

Oft sind externe Dienste langsam und ihre lokale Speicherung (in einer Datenbank im Speicher, z. B. mit memcached) ist schneller. Aber vielleicht nicht.

Glücklicherweise ist es billig und einfach zu testen.

Answer 8

Testen Sie auf jeden Fall. Als Faustregel gilt, dass XML für die Kommunikation zwischen Apps geeignet ist, aber sobald Sie die Daten in Ihrer App haben, sollte alles in eine Datenbanktabelle gehen. Dies gilt möglicherweise nicht in allen Fällen, aber 95% der Zeit hat es für mich. Jedes Mal, wenn ich jemals versucht habe, Daten auf eine andere Art und Weise zu speichern (zB XML in einem Content-Management-System), wünschte ich mir, ich hätte nur gute alte Sprocs und SQL-Server verwendet.

Answer 9

Es klingt wie Sie im Wesentlichen wollen Cache Ergebnisse, und fragen sich, ob es das wert ist. Aber wenn das so ist, würde ich KEINE Datenbank verwenden (ich nehme an, Sie denken an eine relationale DB): RDBMS sind nicht gut zum Caching; obwohl viele sie benutzen. Sie brauchen weder Persistenz noch ACID. Wenn die Wahl zwischen Oracle/MySQL und externem Webservice war, würde ich einfach mit dem Service beginnen.

Betrachten Sie stattdessen echte Caching-Systeme; lokal oder nicht (Memcache, einfache In-Memory-Caches usw.). Oder wenn Sie eine DB verwenden müssen, verwenden Sie Schlüssel/Wert speichern, BDB funktioniert gut. Speichern Sie die Antwortnachricht in ihrer serialisierten Form (XML), versuchen Sie, aus dem Cache zu holen, falls nicht, vom Dienst, parsen. Oder wenn es eine bequeme und kompaktere Serialisierung gibt, speichern und holen Sie diese.