Mehrere Datenbankzugriffe oder ein massiver Zugriff?

Was ist ein besserer Ansatz , wenn es um Leistung und optimale Ressourcennutzung kommt: eine Datenbank mehrere Male durch AJAX Zugriff auf nur die genaue Informationen erhalten benötigt , wenn es benötigt wird, oder das Durchführen einer Zugriffs ein Objekt abzurufen , das alle Informationen enthält , die möglicherweise erforderlich sein , , mit einer hohen Wahrscheinlichkeit, dass nicht alles tatsächlich benötigt wird?

Ich weiß, wie man die tatsächlichen Abfragen bewertet, aber ich weiß nicht, wie man testet, was für die Datenbankleistung am besten ist, wenn Tausende von Benutzern gleichzeitig auf die Datenbank zugreifen und wie das Verbindungspooling funktioniert.

Darauf gibt es keine richtige Antwort. Wie jede Optimierung hängt sie stark vom Kontext / der Verwendung ab.

Beachten Sie jedoch Folgendes als Faustregel:

x
+: Data is stable / static
-: Data is dynamic / volatile

y
+: Data is frequently used
-: Data is infrequently used

++: fetch large chunks in the fewest number of fetches 
    and persist the data as long as possible within tolerances for staleness.

+-: do what is expedient to the logic & usage; if it is convenient to 
    fetch / calc as needed do so, if it is convenient to pre-fetch and 
    persist then do so. Seek to optimize only if absolutely necessary.

-+: fetch / calc as needed; but if optimization is required consider 
    pre-fetching or pre-calculating if possible, or negotiate a tolerance 
    for less than real time accuracy to reduce volatility.

--: fetch / calc as needed and don't worry about it further unless a 
    specific case is unacceptably expensive; if so see -+.

Denken Sie an die erste Optimierungsregel: Messen, nicht raten . Probieren Sie beide aus, instrumentieren Sie sie mit einem Stoppuhrcode und sehen Sie, was länger dauert.

Und denken Sie auch an den alten Witz, dass "es in der Informatik nur zwei schwierige Probleme gibt: die Ungültigkeit des Caches und die richtige Benennung." Wenn Sie alles auf einmal aus der Datenbank ziehen und im Speicher behalten, haben Sie einen Cache. Und jetzt haben Sie ein neues Problem: Wenn sich irgendwo im System etwas ändert , muss es an zwei Stellen die gleiche Änderung vornehmen: in der Datenbank und im Cache. Wenn mehr als ein Server mit der Datenbank kommuniziert oder mehrere APIs, damit der Server Daten ändert, kann dies sehr schnell sehr schwierig werden.

Es gibt KEINE Patentlösung für diese Frage. Ich denke, Sie müssen die möglichen Kompromisse VERSUCHEN und Ihre Server optimieren, um das Beste daraus zu machen.

Erster Punkt: Bevor Sie anfangen, Verbesserungen vorzunehmen, müssen Sie Ihren aktuellen Leistungsmaßstab festlegen , ihn messen und einen Vergleich möglicher Lösungen anstellen, um ihn zu verbessern.

Die zweite Sache ist, dass die Anwendungsnutzung nachverfolgt werden muss. Die Art und Weise, wie die Anwendung von Endbenutzern verwendet wird. Wenn Sie die Anzahl der zurückgegebenen Rohdaten reduzieren , die für Endbenutzer nicht erforderlich sind, sparen Sie möglicherweise wertvolle Serverressourcen . Beispiel: Es hat keinen Sinn, 5000 Datensätze zurückzugeben, wenn Benutzer an den ersten 50 interessiert sind.

Dritter Punkt: Sie müssen die Häufigkeit von Anrufen und mögliche Auswirkungen verstehen. Beispiel: Wenn es sich bei den meisten Aufrufen um Suchwerttabellenabfragen handelt, würden Sie möglicherweise eine Infrastruktur zum Zwischenspeichern dieser Aufrufe erstellen . Mit anderen Worten, wenn sich Ihre Daten nicht häufig ändern, ziehen Sie die Caching-Option in Betracht. Und natürlich sollte die Minimierung der Anzahl der Anrufe immer dazu beitragen, die Leistung zu steigern.

Wenn Sie alles auf einmal erhalten, erzielen Sie eine bessere Leistung, es sei denn, "alles" enthält BLOBs oder ähnlich große Datenobjekte. Der Performance-Aufwand, um alles zu serialisieren, über das Kabel zu verschieben und dann am anderen Ende zu deserialisieren, ist ziemlich hoch, wobei die Netzwerklatenz ein großer Teil davon ist. Der Speicher ist billiger als die Netzwerkbandbreite und wird dies wahrscheinlich noch eine Weile bleiben. Ihre einzige wirkliche Antwort wird von einem Benchmark kommen, aber wenn Sie nur versuchen, eine über die andere abzuschätzen, würde ich mich so lehnen.

Wenn Sie eine architektonische Entscheidung treffen, ist REST eine Option. Mit REST fordern Sie eine Ressource immer mehrmals an, dh Sie senden keine Anforderung zum Abrufen von zwei Objekten, da jedes Objekt eine eigene URL hat. Das Leistungsproblem bei diesem Stil wird wahrscheinlich gelöst, wenn HTTP / 2.0 herauskommt. Ansonsten optimieren Sie einfach, um es so schnell wie möglich zu machen. Viele Unternehmen machen das so.