Dies ist ein Problem ohne eine vollkommen zufriedenstellende Lösung, da Sie versuchen, im Wesentlichen inkompatible Anforderungen zu kombinieren:
-
Senden Sie bei Bedarf nur die erforderliche Datenmenge an den Client, d. h. Sie können nicht den gesamten Datensatz herunterladen und dann clientseitig paginieren.
-
Minimieren Sie den Status pro Client, den der Server verfolgen muss, um die Skalierbarkeit mit einer großen Anzahl von Clients zu gewährleisten.
-
Behalten Sie für jeden Client einen anderen Status bei
Dies ist eine Situation, in der Sie zwei beliebige auswählen können. Sie müssen Kompromisse eingehen; Akzeptieren Sie, dass Sie den Paginierungsstatus jedes Clients nicht genau richtig halten können, akzeptieren Sie, dass Sie einen großen Datensatz auf den Client herunterladen müssen, oder akzeptieren Sie, dass Sie eine riesige Menge an Serverressourcen verwenden müssen, um den Clientstatus aufrechtzuerhalten.
Es gibt Variationen innerhalb dieser, die die verschiedenen Kompromisse mischen, aber darauf läuft alles hinaus.
Beispielsweise senden einige Leute dem Client einige zusätzliche Daten, genug, um die meisten Kundenanforderungen zu erfüllen. Wenn der Client dies überschreitet, wird die Paginierung unterbrochen.
Einige Systeme speichern den Client-Status für kurze Zeit (mit kurzlebigen, nicht geloggten Tabellen, Tempfiles oder was auch immer), verfallen aber schnell, sodass, wenn der Client nicht ständig nach neuen Daten fragt, seine Paginierung unterbrochen wird.
usw.
Siehe auch:
- Wie stellt man einem API-Client 1.000.000 Datenbankergebnisse zur Verfügung?
- Verwenden von "Cursors" zum Paging in PostgreSQL
- Über große externe Postgres-DB iterieren, Zeilen manipulieren, Ausgabe in Rails-Postgres-DB schreiben
- Leistungsoptimierung ausgleichen/begrenzen
- Wenn die PostgreSQL-Zählung(*) immer langsam ist, wie paginiert man komplexe Abfragen?
- So geben Sie eine Beispielzeile einzeln aus der Datenbank zurück
Ich würde wahrscheinlich eine Hybridlösung in irgendeiner Form implementieren, wie zum Beispiel:
-
Lesen Sie mit einem Cursor den ersten Teil der Daten und senden Sie ihn sofort an den Client.
-
Holen Sie sofort genügend zusätzliche Daten aus dem Cursor, um 99 % der Kundenanforderungen zu erfüllen. Speichern Sie es in einem schnellen, unsicheren Cache wie memcached, Redis, BigMemory, EHCache usw. unter einem Schlüssel, der es mir ermöglicht, es für spätere Anfragen desselben Clients abzurufen. Schließen Sie dann den Cursor, um die DB-Ressourcen freizugeben.
-
Lassen Sie den Cache auf der Basis der am längsten nicht genutzten Daten ablaufen, wenn der Client also nicht schnell genug weiterliest, muss er einen neuen Datensatz aus der DB holen, und die Paginierung ändert sich.
-
Wenn der Client mehr Ergebnisse möchte als die überwiegende Mehrheit seiner Peers, ändert sich die Paginierung irgendwann, wenn Sie zum direkten Lesen aus der DB statt aus dem Cache wechseln oder einen neuen, größeren zwischengespeicherten Datensatz generieren.
Auf diese Weise werden die meisten Clients keine Paginierungsprobleme bemerken und Sie müssen keine großen Datenmengen an die meisten Clients senden, aber Sie werden Ihren DB-Server nicht zum Schmelzen bringen. Sie brauchen jedoch einen großen Boofy-Cache, um damit davonzukommen. Wie praktisch es ist, hängt davon ab, ob Ihre Clients mit dem Unterbrechen der Paginierung umgehen können. Wenn es einfach nicht akzeptabel ist, die Paginierung zu unterbrechen, müssen Sie dies DB-seitig mit Cursorn, temporären Tabellen tun, die gesamte Ergebnismenge auf erste Anfrage kopieren usw. Es hängt auch von der Größe des Datensatzes ab und davon, wie viele Daten jeder Client normalerweise benötigt.
