2015-08-18 14 views
6

TL; DR: Welche der folgenden drei Optionen ist die effizienteste für die Paginierung mit Redis?Vorteile/Nachteile von Redis-Paginierungsstrategien

Ich implementiere eine Website mit mehreren nutzergenerierten Beiträgen, die in einer relationalen DB gespeichert werden, und kopiert dann in Redis in Form von Hashes mit Schlüsseln wie site:{site_id}:post:{post_id}.

Ich möchte einfache Paginierungsabfragen gegen Redis durchführen, um Lazy-Load-Paginierung zu implementieren (dh Benutzer scrollt nach unten, wir senden eine Ajax-Anfrage an den Server und fragen nach dem nächsten Bündel von Beiträgen) im Pinterest-Stil Schnittstelle.

Dann habe ich eine Set erstellt, um veröffentlichte Posts IDs mit Schlüsseln wie site:{site_id}:posts zu verfolgen. Ich habe Sätze gewählt, weil ich keine doppelten IDs in der Sammlung haben möchte, und ich kann es schnell mit einem einfachen SADD (keine Notwendigkeit zu überprüfen, ob die ID existiert) bei jedem DB-Update machen.

Nun, wie Sets nicht bestellt werden, ich bin wheighting die Vor- und Nachteile der Optionen Paginieren Ich muss:

1) Mit SSCAN Befehl meine bereits implementiertes Sätze Paginieren

in diesem Fall konnte ich den zurückgegebenen Scan Cursor in der Sitzung des Benutzers bestehen bleiben, es dann an den Server auf die nächste Anfrage senden zurück (es ist nicht zuverlässig scheint mit mehreren Benutzern den Zugriff auf und die Aktualisierung der Datenbank: bei einige Zeit der Cursor wäre ungültig und seltsame Ergebnisse zurückgeben - , es sei denn, es gibt eine Einschränkung, die ich vermisse).

2) Umgestalten meinen Sets Lists oder Sorted Sets stattdessen konnte ich mit LRANGE oder ZRANGE

Dann verwenden Paginieren. Liste scheint die performanteste und natürlichste Option für meinen Anwendungsfall zu sein. Es ist perfekt für Seitenumbruch und Bestellung nach Datum, aber ich kann einfach nicht überprüfen, für ein einzelnes Element Existenz ohne alle Liste Schleifen. Sortierte Sets scheint die Vorteile von beiden Sets und Listen beizutreten, verbraucht aber mehr Serverressourcen.

3) Halten Sie regelmäßige Sets mit und speichern Sie die Seitenzahl als Teil des Schlüssels

es so etwas wie site:{site_id}:{page_number}:posts wäre. Es war war die recommended way, bevor Scan-Befehle implementiert wurden.

Also, die Frage ist: Welches ist der effizienteste/einfachste Ansatz? Gibt es eine andere empfohlene Option, die hier nicht aufgeführt ist?

+2

"Beste" ist völlig subjektiv. Was für mich das Beste ist, ist nicht unbedingt gut für dich. –

+2

+1 re "best". Die Verwendung einer Liste ist keine gute Wahl, da LRANGE O (N) ist. Gehen Sie mit sortierten Sets - am einfachsten und saubersten. –

+0

@SergioTulentsev Ja, vielleicht ist "das Beste" nicht das ... beste Wort. Ich werde etwas weniger subjektiv denken und die Frage bearbeiten. Danke –

Antwort

4

„Best“ ist am besten gedient subjektive :)

Ich empfehle Ihnen mit dem zweiten Ansatz gehen, aber auf jeden Fall verwenden Sortiert über Listen-Sets.Dies ist nicht nur sinnvoll für diese Art von Job (siehe ZRANGE), sie sind auch effizienter in Bezug auf die Komplexität im Vergleich zu LRANGE -ing eine Liste.

+0

Ihr Kommentar (und Ihre Antwort) veranlasste mich, den Unterschied zwischen LRANGE [O (S + N)] und ZRANGE [O (log (N) + M)] genauer zu untersuchen und herauszufinden, dass er riesig sein kann! Außerdem hat es mich zu diesem [alten aber goldenen Post von Reddit] geführt (https://www.reddit.com/r/programming/comments/1f2ml3/what_does_olog_n_mean_exactly/), der O (log n) in einem sehr klaren erklärt Weg. Die Kommentare dort sind verdammt witzig !! Nun, die Antwort wurde akzeptiert. Prost. –