Ich mag die Einfachheit, Skalierbarkeit und Benutzerfreundlichkeit des Datenspeichers; und die Verbesserungen in der neuen ndb Bibliothek sind fabelhaft.
Wenn ich die Best Practices für Datenspeicher verstehe, sollte man keinen Code schreiben, um Item- und / oder Seitenzahlen übereinstimmender Abfrageergebnisse bereitzustellen, wenn die Anzahl der Elemente, die einer Abfrage entsprechen, groß ist. weil der einzige Weg, dies zu tun ist, alle Ergebnisse zu erhalten, die ressourcenintensiv ist.
In vielen Anwendungen, einschließlich unserer, besteht jedoch häufig der Wunsch, eine Anzahl übereinstimmender Elemente zu sehen und dem Benutzer die Möglichkeit zu geben, zu einer bestimmten Seite dieser Ergebnisse zu navigieren. Das Problem mit dem Datenspeicher-Paging wird durch die Einschränkung von fetch (limit, offset = X) wie im Artikel Durch große Datensätze blättern . Um den empfohlenen Ansatz zu unterstützen, müssen die Daten eine eindeutig bewertete Spalte enthalten, die so angeordnet werden kann, wie die Ergebnisse angezeigt werden. Diese Spalte definiert einen Startwert für jede Ergebnisseite. Wenn wir es speichern, können wir die entsprechende Seite effizient abrufen und die Navigation zu einer bestimmten oder nächsten Seite wie gewünscht ermöglichen. Wenn Sie die Ergebnisse auf mehrere Arten anzeigen möchten, müssen daher möglicherweise mehrere solcher Spalten gepflegt werden.
Es sollte beachtet werden, dass ab SDK v1.3.1 Abfragecursors verfügbar sind sind die empfohlene Methode für das Auslagern von Datenspeichern. Sie haben einige Einschränkungen, einschließlich fehlender Unterstützung für IN- und! = Filteroperatoren. Derzeit verwenden einige unserer wichtigen Abfragen IN , aber wir versuchen, sie mit OR zur Verwendung mit Abfragecursorn zu schreiben.
Gemäß den vorgeschlagenen Richtlinien könnten einem Benutzer die Navigationstasten (Weiter) und (Zurück) sowie bestimmte Seitenschaltflächen bei der Navigation angezeigt werden. Wenn der Benutzer zum Beispiel dreimal (Weiter) dreimal gedrückt hat, kann die App die folgenden Schaltflächen anzeigen, wobei die eindeutige Startaufzeichnung oder der jeweilige Cursor für die Navigation beibehalten wird: (Zurück) (Page -1) (Seite-2) (Seite-3) (Seite-4) (Weiter) .
Einige haben vorgeschlagen, Zählungen separat zu verfolgen, aber diese Vorgehensweise ist nicht praktikabel, wenn Benutzer eine Reihe von Feldern abfragen können, die die zurückgegebenen Ergebnisse variieren.
Ich suche nach Einsichten zu diesen Themen im Allgemeinen und den folgenden Fragen speziell:
Welche Navigationsoptionen für Abfrageergebnisse bieten Sie in Ihren Datenspeicher-Apps an, um diese Einschränkungen zu umgehen?
Wenn die Benutzer eine effiziente Ergebniszählung und Seitennavigation erhalten sollen der gesamten Abfrageergebnismenge eine Priorität hat, sollte der Datenspeicher verwendet werden zugunsten der GAE MySql-Lösung , die jetzt angeboten wird.
Gibt es anstehende Änderungen in der großen Tabellenarchitektur? Datenspeicherimplementierung, die zusätzliche Funktionen für Ergebnisse einer Abfrage effizient zählen?
Vielen Dank im Voraus für Ihre Hilfe.
Es hängt alles davon ab, wie viele Ergebnisse Sie normalerweise erhalten. Z.B. Durch Übergeben von .count () einem geeigneten Limit können Sie eine genaue Anzahl angeben, wenn die # Elemente z. & lt; = 100 und "viele", wenn es mehr gibt. Es klingt, als könnten Sie nicht alle möglichen Zählungen vorberechnen, aber zumindest könnten Sie sie zwischenspeichern und dadurch viele Datenspeicheroperationen speichern.
Bei der Verwendung von NDB kann es am effizientesten sein, die erste Seite von Entitäten mit fetch_page () anzufordern und dann den resultierenden Cursor als Startpunkt für einen count () - Aufruf zu verwenden. Alternativ können Sie die Funktionen fetch () der ersten Seite und count () gleichzeitig mit den asynchronen Funktionen ausführen. Die zweite Option ist möglicherweise die einzige Möglichkeit, wenn Ihre Abfrage keine Cursors unterstützt. Die meisten IN / OR-Abfragen unterstützen derzeit keine Cursors, aber sie tun dies, wenn Sie nach __key__ sortieren.
Was die UI-Optionen anbelangt, reicht es aus, die Optionen für die nächste und die vorherige Seite anzubieten. Die "Gooooooogle" -UI, die mehrere Seiten überspringen lässt, ist niedlich, aber ich benutze sie fast nie selbst. (Um "vorherige Seite" zu implementieren, kehren Sie die Reihenfolge der Abfrage um und verwenden Sie denselben Cursor, den Sie für die aktuelle Seite verwendet haben. Ich bin mir ziemlich sicher, dass dies garantiert funktioniert.)
Vielleicht nur für diese Art von Paging zielen:
(erste) (Vorherige) ( Page1 ) (Page2) (Page3) .... (Letzte) (nächste)
Auf diese Weise wird die Gesamtanzahl nicht benötigt - Sie brauchen nur Ihren Code, um zu wissen, dass es genug Ergebnisse für weitere 3+ Seiten gibt. Bei einer Seitengröße von 10 Elementen pro Seite müssen Sie nur wissen, dass es 30+ Elemente gibt.
Wenn Sie 60 Elemente haben (genug für 6 Seiten), wenn Sie bereits auf Seite 4 sind, würde Ihr Code nach vorne schauen und erkennen, dass nur noch 20 Datensätze vorhanden sind. Sie könnten dann die letzte Seitenzahl anzeigen:
(erste) (Vorherige) ( Page4 ) (Seite 5) (Seite 6) (nächste) (letzte)
Grundsätzlich holen Sie für jeden Abruf für die aktuelle Seite nur Datensätze für weitere drei Seiten Daten, zählen Sie sie, um zu sehen, wie viele Seiten Sie tatsächlich haben, und zeigen Sie Ihren Pager entsprechend an.
Auch wenn Sie nur die Schlüssel holen, ist es effizienter als zusätzliche Gegenstände zu holen. hoffe das macht doch einen Sinn !! ?? :)
Da die Frage "Suche nach Ideen / Alternativen zum Bereitstellen einer Seite" war, vielleicht die sehr einfache Alternative, 10 Seiten key_only-Elemente zu holen, dann ist die Handhabung der Navigation innerhalb dieses Sets eine Überlegung wert.
Ich habe dies bei der Beantwortung einer ähnlichen Frage ausführlich erläutert. Dort finden Sie Beispielcode:
Rückwärts-Paginierung mit dem Cursor ist funktioniert aber fehlt ein Gegenstand
Der Beispielcode wäre für diese Frage geeigneter. Hier ist ein Teil davon:
%Vor%Siehe die referenzierte Frage für mehr Code.
Natürlich, wenn die Ergebnismenge potentiell riesig ist, muss noch ein Limit für das Fetch angegeben werden, das harte Limit ist 1000 Punkte, denke ich. Offensichtlich ist das Ergebnis mehr als einige 10 Seiten lang, der Benutzer wird aufgefordert, durch Hinzufügen von Kriterien zu verfeinern.
Der Umgang mit Paging innerhalb einiger hundert keys_only-Items ist wirklich so viel einfacher, dass es definitiv eine Überlegung wert ist. Es macht es recht einfach, eine direkte Seitennavigation bereitzustellen, wie in der Frage erwähnt. Die eigentlichen Entity Items werden nur für die aktuell aktuelle Seite geholt, der Rest sind nur Schlüssel, also ist es nicht so teuer. Und Sie sollten erwägen, das keys_only-Ergebnis für einige Minuten in Memcache zu belassen, damit ein Benutzer, der schnell durch die Seiten blättert, nicht die gleiche Abfrage erneut ausführen muss.
Tags und Links google-app-engine google-cloud-datastore app-engine-ndb