it-swarm.com.de

Was ist schneller? Verwenden Sie REST API oder fragen Sie eine Datenbank direkt ab?

Was ist schneller in Bezug auf die Leistung? Erstellen Sie eine REST API und lassen Sie Ihre Web-App die REST API verwenden, um alle Interaktionen mit Ihrer Datenbank durchzuführen OR Abfragen Ihrer Datenbank direkt (dh mit einem typischen Objekt, das Ihre Sprache zum Abfragen einer Datenbank wie JDBC für Java verwendet)?

So wie ich es mit REST sehe:

  1. Sie erstellen ein Objekt in Ihrem Code, um die Methode REST] aufzurufen
  2. Rufen Sie die http-Methode auf
  3. Code in Ihrer REST API fragt die Datenbank ab
  4. Die Datenbank gibt einige Daten zurück
  5. Der REST-API-Code packt die Daten in Json und sendet sie an Ihren Client
  6. Der Client erhält eine Json/XML-Antwort
  7. Ordnen Sie die Antwort einem Objekt in Ihrem Code zu

Auf der anderen Seite direkt eine Datenbank abfragen:

  1. Sie erstellen ein Objekt mit einer Abfragezeichenfolge, um die Datenbank abzufragen
  2. Die Datenbank gibt einige Daten zurück
  3. Ordnen Sie die Antwort einem Objekt in Ihrem Code zu

Würde dies nicht bedeuten, dass die Verwendung einer REST API) langsamer wäre? Vielleicht hängt es vom Typ der Datenbank ab (SQL vs NoSQL)?

17
Micro

Wenn Sie die Komplexität erhöhen, wird der Code langsamer ausgeführt. Die Einführung eines REST -Dienstes, wenn dieser nicht erforderlich ist, verlangsamt die Ausführung, da das System mehr tut.

Das Abstrahieren der Datenbank ist eine gute Praxis. Wenn Sie sich Sorgen über die Geschwindigkeit machen, können Sie die Daten im Speicher zwischenspeichern, damit die Datenbank nicht berührt werden muss, um die Anforderung zu bearbeiten.

Bevor ich die Leistung optimiere, obwohl ich untersuchen möchte, welches Problem Sie lösen möchten und welche Architektur Sie verwenden, fällt es mir schwer, mir eine Situation vorzustellen, in der die Datenbankoptionen direkter Zugriff im Vergleich zu REST sind.

19
Klee

Wenn Sie Bedenken hinsichtlich der Geschwindigkeit haben, ist ein Rest-Service aus den oben genannten Gründen langsamer. Die Geschwindigkeit des von Ihnen beschriebenen Typs ist jedoch selten das Hauptanliegen und kann, falls dies der Fall ist, auf andere Weise angegangen werden. Vorzeitige Optimierung ist die Wurzel allen Übels .

Überlegen Sie, ob Ihr Hauptanliegen die Interoperabilität (Mobil, Web, B2B) ist. Jetzt REST ist sehr attraktiv, da es technologieunabhängig ist.

Angenommen, Sie codieren für eine Datenbank. Was würden Sie tun, wenn Sie Ihren zugrunde liegenden Datenspeicher ändern möchten? Wie schwer wäre es, wenn Sie eng mit dem zugrunde liegenden Geschäft verbunden wären?

Die wirkliche Antwort ist , es kommt darauf an , aber hoffentlich habe ich Ihnen einige Dinge zum Nachdenken gegeben!

9
Romski

Wenn es schwierig ist, diese Frage zu beantworten.

Die richtige allgemeine Antwort sollte lauten: Es kommt darauf an.

So wie ich es mit REST sehe:

  1. Sie erstellen ein Objekt in Ihrem Code, um die Methode REST] aufzurufen
  2. Rufen Sie die http-Methode auf
  3. Code in Ihrer REST API fragt die Datenbank ab
  4. Die Datenbank gibt einige Daten zurück
  5. Der REST-API-Code packt die Daten in Json und sendet sie an Ihren Client
  6. Der Client erhält eine Json/XML-Antwort
  7. Ordnen Sie die Antwort einem Objekt in Ihrem Code zu

In deinem Gedanken liegt ein Fehler.

Und dieser Fehler rührt von der Tatsache her, dass Sie REST und seine Prinzipien nicht vollständig verstehen. REST wurde nicht erfunden, weil einige Nerds es cool fanden (von) Natürlich ist es) Javascript-Objekte über HTTP über das Kabel zu senden. Der Hauptvorteil der Verwendung von HTTP ist die Möglichkeit, Caching zu verwenden. Wenn Sie Ihre Ergebnisse zwischenspeicherbar machen , dann müssen weniger Anfragen an die DB gestellt werden. Und es ist kein Marshalling beteiligt. Die Antwort könnte sein direkt geliefert.

Insofern ist @Klees Antwort nicht ganz richtig :

Wenn Sie die Komplexität erhöhen, wird der Code langsamer ausgeführt. Die Einführung eines REST -Dienstes, wenn dieser nicht erforderlich ist, verlangsamt die Ausführung, da das System mehr tut.

Wenn Sie mit Cacheables-Ergebnissen arbeiten, hat dies keine Auswirkungen auf Ihre Anwendung: Die Bereitstellung bekannter Antworten auf bekannte Fragen kann über Reverse-Proxys erfolgen.

8
Thomas Junk

Die Einführung einer zusätzlichen Serviceebene ist immer mit Kosten für Komplexität und Leistungsaufwand verbunden. Es gibt einige bestimmte Arten von Architekturen, bei denen die Einführung einer gemeinsam genutzten Serviceebene (z. B. eine REST API)) die Leistung aufgrund des gemeinsam genutzten Caching verbessern kann. Es scheint jedoch, dass dies nicht die Art von Architektur ist, die Sie haben.

Stellen Sie sich eine Architektur vor, in der mehrere Web-Apps oder mehrere Desktop-Apps direkt mit derselben Datenbank verbunden sind. Wenn sie häufig dieselben Abfragen ausführen, kann dies die Leistung verbessern, wenn Abfrageergebnisse in einem gemeinsam genutzten Dienst zwischengespeichert werden. Insbesondere wenn Sie sagen, dass Hunderte von Desktop-Apps direkt auf dieselbe Datenbank zugreifen (nicht über eine Web-App!) Und dieselben Abfragen ausführen, kann dies zu einer erheblichen Verbesserung führen. Selbst in dieser Architektur wäre der Hauptgrund für die Einführung eines gemeinsam genutzten Dienstes wahrscheinlich eher die Sicherheit und Datenabstraktion als die Leistung.

Es hört sich jedoch so an, als hätten Sie eine einzige Web-App, die eine direkte Verbindung zur Datenbank herstellt. In diesem Fall bietet die Einführung einer zusätzlichen Serviceschicht keinen Vorteil. Caching, Datenbankabstraktion usw. können auf der Datenzugriffsebene in derselben Anwendung ausgeführt werden.

2
JacquesB

Es hängt davon ab, ob.

Je mehr Ebenen in Ihrem Code enthalten sind, desto langsamer wird es. Aber ... irgendwann kommt die direkte End-to-End-Leistung weniger wichtig als die Skalierbarkeit. Wenn 1 Benutzer auf einem lokalen PC auf Ihre Datenbank zugreift, kann dies schnell gehen. Wenn tausend Benutzer auf derselben Datenbank auf dieselbe Datenbank zugreifen, werden sie wahrscheinlich alle frustriert sein. Die Lösung besteht darin, die Datenbank in eine andere Box zu verschieben, eine Ebene in der Mitte hinzuzufügen, und obwohl sie für einen Benutzer langsamer ist, wird sie schneller ausgeführt, wenn die Tausenden darauf zugreifen. (Das ist eine vereinfachte Antwort, aber im Prinzip wahr).

Es gibt andere Gründe, Ihre Datenbank hinter einer Ebene der mittleren Ebene zu verstecken, z. B. die Sicherheit.

1
gbjbaanb