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

16

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

So sehe ich es mit REST:

Sie erstellen ein Objekt in Ihrem Code, um die REST-Methode aufzurufen
Rufen Sie die http-Methode auf
Code in Ihrer REST-API fragt die Datenbank ab
Die Datenbank gibt einige Daten zurück
Der REST-API-Code packt die Daten in Json und sendet sie an Ihren Client
Client empfängt Json / XML-Antwort
Ordnen Sie die Antwort einem Objekt in Ihrem Code zu

Auf der anderen Seite können Sie eine Datenbank direkt abfragen:

Sie erstellen ein Objekt mit einer Abfragezeichenfolge, um die Datenbank abzufragen
Die Datenbank gibt einige Daten zurück
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 von der Art der Datenbank ab (SQL vs NoSQL)?

database rest sql

— Mikro
quelle

3

Eine REST-API ist kein Datenbankzugriffsprotokoll, daher ist die Frage ein großer Kategoriefehler. Eine REST-API ist ein Dokumentenspeicher. Es KANN eine Datenbank auf der Serverseite verwenden (oder nicht). Wenn Sie keine REST-API benötigen, verwenden Sie offensichtlich keine. Aber das gilt dann für alles. Wenn Sie keine Datenbank benötigen, verwenden Sie keine, das Schreiben in das Dateisystem ist schneller als eine Datenbank. Wenn Sie kein Dateisystem benötigen, verwenden Sie keines. Das Schreiben in den Arbeitsspeicher ist schneller als auf der Festplatte. Wenn Sie keinen RAM benötigen, verwenden Sie ihn nicht. Das Schreiben in den CPU-Cache ist schneller usw. usw. usw.

— Cormac Mulhall

1

Das "auf der anderen Seite" erfordert, dass Sie Ihre Datenbank der großen bösen Welt aussetzen.

— Pieter B

@PieterB: Nein, das "auf der anderen Seite" macht die Datenbank für die vertrauenswürdige Web-App verfügbar.

— JacquesB

@JacquesB und die Web-App werden auf dem Client-Computer ausgeführt. Es sollte also nicht vertrauenswürdig sein, da es sich um eine modifizierte Version handeln könnte.

— Pieter B

@PieterB: Die Frage gibt nichts über die Webanwendung an, die auf einem nicht vertrauenswürdigen Server ausgeführt wird. Das wäre ein sehr ungewöhnlicher Aufbau.

— JacquesB

18

Wenn Sie die Komplexität erhöhen, wird der Code langsamer ausgeführt. Wenn Sie einen REST-Service einführen, der nicht erforderlich ist, wird die Ausführung verlangsamt, da das System mehr tut.

Die Zusammenfassung der Datenbank ist eine gute Praxis. Wenn Sie sich Gedanken über die Geschwindigkeit machen, sollten Sie die Daten im Speicher zwischenspeichern, damit die Datenbank nicht berührt werden muss, um die Anforderung zu verarbeiten.

Bevor ich die Leistung optimiere, überlege ich mir, welches Problem Sie lösen möchten und welche Architektur Sie verwenden. Ich habe Mühe, mir eine Situation vorzustellen, in der die Datenbankoptionen Direktzugriff oder REST sind.

— Klee
quelle

+1 für die Erwähnung von Caching. Obwohl es tut extra work. Tatsächlich könnte es jedoch schneller sein, wenn wiederholte Abfragen zwischengespeichert werden.

— Yana Agun Siswanto

3

@Klee Deine Antwort ist nicht ganz richtig. »Wenn Sie einen REST-Service einführen, der nicht benötigt wird, wird die Ausführung verlangsamt, da das System mehr tut.« Nicht in jedem Fall besteht überhaupt Datenverkehr zum Endpunkt, wenn z. B. ein Reverse-Proxy cahced-Ergebnisse verarbeiten könnte.

— Thomas Junk

@klee Der Grund, warum ich diese Frage gestellt habe, war von diesem SO-Beitrag, programmers.stackexchange.com/questions/277701/… - eine Antwort spricht davon, wie Amazon großen Erfolg hatte, indem es ein vollständig REST-fähiges System anstelle des direkten Zugriffs verwendete. Ich habe gerade nachgedacht ...

— Micro

9

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 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 ist REST sehr attraktiv, weil 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 schwierig wäre es, wenn Sie eng mit dem zugrunde liegenden Geschäft verbunden wären?

Die wirkliche Antwort ist, dass es darauf ankommt , aber ich hoffe, ich habe Ihnen einige Dinge zum Nachdenken gegeben!

— Romski
quelle

6

Wenn es schwierig ist, diese Frage zu beantworten.

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

So sehe ich es mit REST:

Sie erstellen ein Objekt in Ihrem Code, um die REST-Methode aufzurufen

Rufen Sie die http-Methode auf

Code in Ihrer REST-API fragt die Datenbank ab

Die Datenbank gibt einige Daten zurück

Der REST-API-Code packt die Daten in Json und sendet sie an Ihren Client

Client empfängt Json / XML-Antwort

Ordnen Sie die Antwort einem Objekt in Ihrem Code zu

In deinem Denken liegt ein Fehler.

Dieser Fehler beruht auf der Tatsache, dass Sie REST und seine Prinzipien nicht vollständig verstehen. REST wurde nicht erfunden, weil einige Nerds es cool fanden (natürlich ist es das), Javascript-Objekte über HTTP über das Kabel zu senden. Der Hauptvorteil der Verwendung von HTTP ist die Möglichkeit der Verwendung von Caching . Wenn Sie Ihre Ergebnisse machen zwischenspeicherbar , dann gibt es weniger Anfragen an die DB gemacht werden. Und kein Rangieren ist beteiligt. Die Antwort könnte direkt geliefert werden.

Insofern ist @Klees Antwort nicht ganz richtig :

Wenn Sie die Komplexität erhöhen, wird der Code langsamer ausgeführt. Wenn Sie einen REST-Service einführen, der nicht erforderlich ist, wird die Ausführung verlangsamt, da das System mehr tut.

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

— Thomas Junk
quelle

4

Wenn die Daten in einer Rest-Service-Schicht zwischengespeichert werden können, können sie in der Web-App zwischengespeichert werden, was für die Leistung wesentlich besser wäre.

— JacquesB

Der schnellste Weg ist, die Web-App überhaupt nicht zu treffen.

— Thomas Junk

1

Und nur um es interessanter zu machen, sind nicht alle "Treffer" in der Datenbank gleich, wenn Sie im Arbeitsspeicher auf die Festplatte zugreifen können.

— JeffO

@ThomasJunk: Wenn ich die ursprüngliche Frage richtig verstehe, ist der Client eine Web-App und die Frage ist, ob die Web-App eine direkte Verbindung zur Datenbank herstellen oder über einen Rest-Service anrufen soll.

— JacquesB

1

Das ändert nichts an meiner Antwort. Das Aufrufen eines REST-Service beinhaltet das Aufrufen eines Web-Servers, der sich hinter einem Reverse-Proxy befindet, wo mögliche Antworten zwischengespeichert werden können - wie ich bereits sagte.

— Thomas Junk

2

Die Einführung einer zusätzlichen Serviceschicht ist immer mit Kosten für Komplexität und Leistung verbunden. Es gibt einige bestimmte Arten von Architekturen, bei denen die Einführung einer Shared-Service-Schicht (wie einer REST-API) die Leistung aufgrund des Shared-Caching verbessern kann. Dies scheint jedoch nicht die Art von Architektur zu sein, die Sie haben.

Stellen Sie sich eine Architektur vor, in der mehrere Webanwendungen oder Desktopanwendungen 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. Besonders wenn Sie sagen, dass Hunderte von Desktop-Apps direkt auf dieselbe Datenbank zugreifen (nicht über eine Web-App!) Und dieselben Abfragen ausführen, könnte dies eine wesentliche Verbesserung bedeuten. 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 ist die Einführung einer zusätzlichen Serviceschicht nicht vorteilhaft. Caching, Datenbankabstraktion usw. können auf der Datenzugriffsebene in derselben Anwendung ausgeführt werden.

— JacquesB
quelle

1

Es hängt davon ab, ob.

Je mehr Ebenen sich in Ihrem Code befinden, desto langsamer wird es. Aber ... irgendwann spielt die direkte End-to-End-Leistung weniger eine Rolle als die Skalierbarkeit. Wenn Sie 1 Benutzer haben, der auf Ihre Datenbank auf einem lokalen PC zugreift, kann es schnell gehen. Wenn tausend Benutzer auf demselben PC 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. Für 1 Benutzer ist die Leistung jedoch langsamer. Wenn die Tausenden darauf zugreifen, wird sie schneller. (Das ist eine vereinfachende Antwort, aber im Prinzip wahr).

Es gibt andere Gründe, Ihre Datenbank hinter einer Mittelschichtebene zu verstecken, z. B. Sicherheit.

— gbjbaanb
quelle

-2

Ich weiß nicht, wo Sie sich verlaufen, aber es ist ziemlich klar, dass Sie bei Verwendung der REST-API zusätzliche Schritte ausführen und zusätzliche Schritte "immer" bedeuten, dass die Programmierung langsamer ist.

Es gibt Vor- und Nachteile, aber wenn Sie direkt von Ihrer Anwendung aus auf die Datenbank zugreifen können, ist es immer besser, sie direkt aufzurufen, anstatt die Web-API zu verwenden. Wenn Sie die Web-API verwenden, können Sie Ihre Anwendung problemlos auf eine andere Plattform portieren.

— kirie
quelle

1

»Ich weiß nicht, wo Sie sich verlaufen, aber es ist ziemlich klar, dass Sie bei Verwendung der REST-API zusätzliche Schritte ausführen und zusätzliche Schritte bei der Programmierung" immer "langsamer sind.« Wenn dies eine langsamere Ausführung bedeutet, das ist nicht richtig.

— Thomas Junk

1

Gibt es nicht Situationen, in denen der Zugriff auf die Datenbank eine schlechte Idee ist, abgesehen von der Portabilität? Manchmal kann eine REST-API usw. mehr Logik (und mehr Sicherheit?) Auf der Serverseite bewahren, oder?

— J Trana

@JTrana, das ja oder nein sein kann, hängt wirklich davon ab, wie Sie vorgehen, während die Einführung einer zusätzlichen Ebene eine zusätzliche Sicherheitsebene bietet. Das Hinzufügen einer zusätzlichen Ebene bedeutet auch, dass Sie mehr Chancen haben, etwas zu vermasseln und Sicherheitslücken freizulegen. Ich denke, der Sinn der Web-API ist es, Ihre "API" verfügbar zu machen. Große Anwendungen wie Facebook, Amazon, Google, die Zugriff auf Drittanbieter und eine Vielzahl von Plattformen benötigen, müssen über eine Web-API verfügen. Bei kleinen Anwendungen müssen Sie jedoch überlegen, bevor Sie dies tun.

— kirie

-2

SICH AUSRUHEN :

offen für mehrere Frontends und 1 Backend
müssen Sie Ihre eigene API erstellen (oder eine wie Loopback verwenden)
nicht offline arbeiten

Lokale DB:

Nicht für "Tiers" geöffnet, müssen sie Zugriff auf Ihr Backend haben, um synchronisieren zu können
Es muss keine API erstellt werden. Verwenden Sie die DB-Schnittstelle
offline arbeiten

DAS IST EIN GROSSER UNTERSCHIED, DIE MENSCHEN VERGESSEN DIESE PUNKTE

— Benjamin Fuentes
quelle

2

-1. Zwar muss keine API erstellt werden, das Erstellen einer DAL führt jedoch häufig zu erheblichen Problemen, falls das Datenbank-Backend geändert werden muss. Auch kein Grund, warum, wenn Sie die DB "offline" haben, der Rest-Service dort auch nicht verfügbar gemacht werden konnte.

— James Snell