Wie entwerfe ich eine Datenbank zum Speichern einer sortierten Liste?

Ich möchte eine sortierte Liste in einer Datenbank speichern. Ich möchte die folgenden Vorgänge effizient ausführen.

1. Einfügen (x) - Fügen Sie den Datensatz x in die Tabelle ein
2. Löschen (x) - Löscht den Datensatz x aus der Tabelle
3. Vorher (x, n) - Die 'n' Datensätze vor dem Datensatz x in der sortierten Liste zurückgeben.
4. Nach (x, n) - Die 'n' Datensätze zurückgeben, die dem Datensatz x in der sortierten Liste folgen.
5. First (n) - Gibt die ersten n Datensätze aus der sortierten Liste zurück.
6. Last (n) - Gibt die letzten n Datensätze aus der sortierten Liste zurück.
7. Compare (x, y) - Wenn zwei Datensätze x und y aus der Tabelle gegeben sind, finde, ob x> y ist.

Die einfache Methode, die ich mir vorstellen könnte, besteht darin, eine Art "Rang" -Attribut in der Tabelle zu speichern und durch Sortieren nach diesem Attribut abzufragen. Bei dieser Methode wird das Einfügen / Ändern eines Datensatzes mit Rang jedoch zu einer kostspieligen Operation. Gibt es eine bessere Methode?

Insbesondere möchte ich die Tabelle mit Amazon SimpleDB implementieren. Eine allgemeine Antwort für eine relationale Datenbank sollte jedoch ebenfalls hilfreich sein.

Update beim Ladeprofil:

Da ich dies für eine Webanwendung plane, hängt es von der Anzahl der Benutzer ab, die die App verwenden.

Wenn es 100.000 aktive Benutzer gibt (Superoptimismus: P), dann wäre meine sehr ungefähre Schätzung pro Tag

500.000 Auswahlen, 100.000 Einfügen und Löschen, 500.000 Aktualisierungen

Ich würde erwarten, dass der Tisch insgesamt auf 500.000 wächst.

Ich bin auf der Suche nach Updates, Insert und Compare-Operationen zu optimieren. Der Rang der Gegenstände wird sich ständig ändern und ich muss die Tabelle auf dem neuesten Stand halten.

Wenn der Rang nicht völlig willkürlich ist, sondern von einer anderen Eigenschaft abgeleitet werden kann (z. B. Name, Punktzahl des Spielers usw.), schauen Sie sich Joels Antwort genau an .

Wenn es sich um eine willkürliche Eigenschaft Ihrer Daten handelt, sollte diese als Spalte in Ihrer Datensatztabelle gespeichert werden. Angenommen, Amazon SimpleDB ähnelt dem typischen RDBMS, können Sie diese Spalte indizieren und alle oben genannten Abfragen schnell mit der entsprechenden Indizierungsstrategie beantworten. Dies ist normal für ein RDBMS.

Da Sie eine hohe Einfüge- und Aktualisierungsaktivität, aber auch eine relativ hohe Leseaktivität erwarten, empfehle ich Folgendes:

• Gruppieren Sie die Tabelle nach dem Rang, insbesondere wenn die meisten Ihrer Abfragen gegen den Rang sind. Wenn dies nicht der Fall ist oder wenn die Auswahl eines Clustering-Schlüssels in SimpleDB nicht verfügbar ist, erstellen Sie einfach einen Index mit Rang als führende Spalte. Dies würde die Fragen 3-6 erfüllen.
• Ein Index, der zuerst den Datensatz und dann den Rang enthält (oder in der SQL Server-Welt nur den INCLUDERang " Aufzeichnen und -en" oder nur, wenn Sie nach Rang gruppiert haben), würde die Abfrage 7 erfüllen.
• Die Vorgänge 1 und 2 können optimiert werden, indem Sie die Daten entsprechend verteilen (z. B. FILLFACTORin SQL Server festlegen). Dies ist besonders wichtig, wenn Sie sich nach Rang gruppieren.
• Behalten Sie beim Einfügen oder Aktualisieren von Rängen so viel Abstand wie möglich zwischen den Rangnummern bei, um die Möglichkeit zu minimieren, dass Sie einen vorhandenen Datensatz neu einstufen müssen, um ein Einfügen oder Aktualisieren von Rängen zu ermöglichen. Wenn Sie beispielsweise Ihre Datensätze in 1000er-Schritten klassifizieren, bleibt genügend Platz für etwa die Hälfte der Änderungen und Einfügungen mit minimaler Wahrscheinlichkeit, und Sie müssen einen Datensatz, der nicht direkt an diesen Änderungen beteiligt ist, neu klassifizieren.
• Jede Nacht werden alle Datensätze neu geordnet, um die Ranglücken zwischen ihnen zurückzusetzen.
• Sie können die Häufigkeit der Massen-Neueinstufungen sowie die Ranglückengröße so einstellen, dass die erwartete Anzahl von Einfügungen oder Aktualisierungen im Verhältnis zur Anzahl der vorhandenen Datensätze berücksichtigt wird. Wenn Sie also über 100.000 Datensätze verfügen und davon ausgehen, dass Ihre Einfügungen und Aktualisierungen 10% davon ausmachen, lassen Sie genügend Platz für 10.000 neue Ränge und ordnen Sie sie jede Nacht neu.
• Das erneute Einordnen von 500.000 Datensätzen ist eine kostspielige Operation, aber eine tägliche oder wöchentliche Unterbrechung der Arbeitszeit sollte für eine solche Datenbank in Ordnung sein. Diese Massen-Neueinstufung außerhalb der Geschäftszeiten, um die Ranglücken beizubehalten, erspart Ihnen die Neueinstufung vieler Datensätze für jede Rangaktualisierung oder -einfügung während Ihrer normalen Geschäftszeiten und Spitzenzeiten.

Wenn Sie mehr als 100.000 Lesevorgänge für eine Tabelle mit einer Größe von mehr als 100.000 erwarten, empfehle ich nicht, den Ansatz der verknüpften Liste zu verwenden. Es wird nicht gut auf diese Größen skaliert.

Ich verwende im Allgemeinen die von Ihnen beschriebene "Rang" -Methode. Anstatt mit dem Aktualisieren von Zeilen herumzuspielen, wenn Elemente neu angeordnet werden mussten, konnte ich häufig alle Datensätze in der Liste löschen und neue Elemente in der richtigen Reihenfolge einfügen. Diese Methode ist eindeutig für den Abruf optimiert.

Ein alternativer Ansatz wäre, die Datensätze als verknüpfte Liste zu modellieren, indem eine reflexive "Vorgänger" -Fremdschlüsselspalte in der Tabelle verwendet wird:

ID   setID   item       predecessor
---  ------  ------     ------------
1    1       Apple      null
2    1       Orange     1
3    2       Cucumber   null
4    1       Pear       2
5    1       Grape      4
6    2       Carrot     3

Sie können problemlos eine Liste abrufen und Elemente mit geringem Aufwand hinzufügen und entfernen. Es ist jedoch schwierig, die Datensätze in der richtigen Reihenfolge zu veröffentlichen. Vielleicht gibt es eine clevere Möglichkeit, dies in einer einzigen Abfrage zu tun, wahrscheinlich mit vielen Alias-Table-Joins.

Ich benutze diesen letzteren Ansatz oft, wenn ich eine baumartige Beziehung modelliere (Kategorien, Ordner, Mengen und Teilmengen). Im Allgemeinen hatte ich eine Art rekursive Funktion, um den gesamten Baum in meiner Anwendung zu rekonstruieren.

Ich würde denken, dass die Sache zu tun ist, die Eigenschaft oder Eigenschaften zu speichern, die verwendet werden, um den Rang zu berechnen, und dann einen Index über sie zu erstellen. Anstatt zu versuchen, die Datenbank zu zwingen, die Daten physisch in einer Rangfolge zu speichern oder eine manuell verwaltete verknüpfte Liste zu verwenden, sollten Sie das Datenbankmodul das tun lassen, wofür es entwickelt wurde.

Dies sind die Einschränkungen eines Nicht-RDBMS wie simpleDB. Die Funktionen, die Sie benötigen, können nicht auf der DB-Seite in simpleDB implementiert werden, sondern müssen von der Programmierseite / -anwendung aus implementiert werden.

Für ein RDBMS wie dieses SQL serversind die Funktionen, die Sie benötigen, für den Clustered-Index rudimentär.

• Einfügen (x) - Datensatz x in die Tabelle einfügen> Einfaches Einfügen.
• Löschen (x) - Datensatz x aus der Tabelle löschen> Einfaches Löschen.

• Vorher (x, n) - Die 'n' Datensätze vor dem Datensatz x in der sortierten Liste zurückgeben. > Wählen Sie Top-n-Ergebnisse aus, bei denen x kleiner als der Wert ist, und sortieren Sie nach Klausel.

• Nach (x, n) - Die 'n' Datensätze zurückgeben, die dem Datensatz x in der sortierten Liste folgen. > Wählen Sie Top-n-Ergebnisse aus, bei denen x größer als value ist, und sortieren Sie nach Klausel.

• First (n) - Gibt die ersten n Datensätze aus der sortierten Liste zurück. > Wählen Sie die besten n Ergebnisse aus.

• Last (n) - Gibt die letzten n Datensätze aus der sortierten Liste zurück. > Top n Ergebnisse nach Reihenfolge auswählen von absteigend.

• Compare (x, y) - Wenn zwei Datensätze x und y aus der Tabelle gegeben sind, finde, ob x> y ist. > TSQL IF-Anweisung.

Folgendes habe ich verwendet, um meine Postgres-Tabelle nach jeder Einfügung neu zu ordnen:

CREATE OR REPLACE FUNCTION re_rank_list() RETURNS trigger AS $re_rank_list$
DECLARE
    temprow record;
    row_idx integer := 1;    
BEGIN
    FOR temprow IN
    SELECT * FROM your_schema.your_list WHERE list_id = NEW.list_id ORDER BY rank ASC
    LOOP
        UPDATE your_schema.your_list SET rank = row_idx * 100 WHERE id = temprow.id;
        row_idx := row_idx + 1;
    END LOOP;
    RETURN NEW;
END;
$re_rank_list$ LANGUAGE plpgsql;


CREATE TRIGGER re_rank_list AFTER UPDATE ON your_schema.your_list_value
    FOR EACH ROW 
    WHEN (pg_trigger_depth() = 0)
    EXECUTE PROCEDURE re_rank_list();

Für meinen Anwendungsfall ist die Leistung kein Problem, aber die Gewissheit, dass sie niemals kaputt geht oder sich merkwürdig verhält, ist wichtig.