Schemadesign für soziale Netzwerke in DynamoDB

Geschäftlicher Anwendungsfall für soziale Netzwerke

In diesem Anwendungsfall geht es um die Verwendung von DynamoDB als soziales Netzwerk. Ein soziales Netzwerk ist ein Online-Service, über den verschiedene Benutzer miteinander interagieren können. In dem sozialen Netzwerk, das wir gestalten werden, wird den Benutzern eine Timeline mit ihren Beiträgen, ihren Followern, den Personen, denen sie folgen, und deren Beiträgen angezeigt. Die Zugriffsmuster für dieses Schemadesign sind folgende:

• Abrufen von Benutzerinformationen für eine bestimmte userID

• Abrufen der Follower-Liste für eine bestimmte userID

• Abrufen der Liste der gefolgten Personen für eine bestimmte userID

• Abrufen der Beitragsliste für eine bestimmte userID

• Abrufen der Liste der Benutzer, denen der Beitrag gefällt, für eine bestimmte postID

• Abrufen der Anzahl der Likes für eine bestimmte postID

• Abrufen der Timeline für eine bestimmte userID

Diagramm der Entitätsbeziehungen in sozialen Netzwerken

Dies ist das Entitätsbeziehungsdiagramm (ERD), das wir für das Design des Schemas für soziale Netzwerke verwenden werden.

Zugriffsmuster für soziale Netzwerke

Dies sind die Zugriffsmuster, die wir für das Schemadesign für soziale Netzwerke berücksichtigen werden.

• getUserInfoByUserID

• getFollowerListByUserID

• getFollowingListByUserID

• getPostListByUserID

• getUserLikesByPostID

• getLikeCountByPostID

• getTimelineByUserID

Entwicklung des Schemadesigns für soziale Netzwerke

DynamoDB ist eine SQL Nein-Datenbank und ermöglicht Ihnen daher nicht, einen Join durchzuführen — eine Operation, die Daten aus mehreren Datenbanken kombiniert. Kunden, die mit DynamoDB nicht vertraut sind, wenden möglicherweise Entwurfsphilosophien des relationalen Datenbankmanagementsystems (RDBMS) (z. B. das Erstellen einer Tabelle für jede Entität) auf DynamoDB an, wenn sie dies nicht benötigen. Der Zweck des Einzeltabellendesigns von DynamoDB besteht darin, Daten gemäß dem Zugriffsmuster der Anwendung in einer vorverknüpften Form zu schreiben und dann ohne weitere Berechnungen sofort zu verwenden. Weitere Informationen finden Sie unter Single-table vs. multi-table design in DynamoDB.

Gehen wir nun Schritt für Schritt die Entwicklung unseres Schemadesigns durch, um alle Zugriffsmuster zu berücksichtigen.

Schritt 1: Zugriffsmuster 1 (getUserInfoByUserID) angehen

Um bestimmte Benutzerinformationen abzurufen, müssen wir eine Query für die Basistabelle mit der Schlüsselbedingung PK=<userID> durchführen. Mit der Abfrageoperation können Sie die Ergebnisse paginieren, was nützlich sein kann, wenn ein Benutzer viele Follower hat. Weitere Informationen zu Query finden Sie unter Abfragen von Tabellen in DynamoDB.

In unserem Beispiel verfolgen wir zwei Arten von Daten für unseren Benutzer: „count“ und „info“. „count“ gibt an, wie viele Follower ein Benutzer hat, wie vielen Benutzern er folgt und wie viele Beiträge er erstellt hat. „info“ spiegelt die persönlichen Daten eines Benutzers wie z. B. seinen Namen wider.

Wie wir sehen, werden diese beiden Arten von Daten durch die beiden unten aufgeführten Elemente dargestellt. Das Element, dessen Sortierschlüssel „count“ enthält, wird sich eher ändern als das Element mit „info“. DynamoDB berücksichtigt die Größe des Elements vor und nach der Aktualisierung und der verbrauchte bereitgestellte Durchsatz spiegelt die größere dieser Elementgrößen wider. Auch wenn Sie nur eine Teilmenge der Attribute des Elements aktualisieren, verbraucht UpdateItem weiterhin den gesamten bereitgestellten Durchsatz (die größere der Elementgrößen vor und nach der Aktualisierung). Sie können die Elemente mit einer einzigen Query-Operation abrufen und UpdateItem verwenden, um vorhandene numerische Attribute hinzuzufügen oder davon zu subtrahieren.

Schritt 2: Zugriffsmuster 2 (getFollowerListByUserID) angehen

Um eine Liste der Benutzer abzurufen, die einem bestimmten Benutzer folgen, müssen wir eine Query für die Basistabelle mit der Schlüsselbedingung PK=<userID>#follower durchführen.

Schritt 3: Zugriffsmuster 3 (getFollowingListByUserID) angehen

Um eine Liste der Benutzer abzurufen, denen ein bestimmter Benutzer folgt, müssen wir eine Query für die Basistabelle mit der Schlüsselbedingung PK=<userID>#following durchführen. Sie können dann eine TransactWriteItemsOperation verwenden, um mehrere Anfragen zu gruppieren und wie folgt vorzugehen:

• Fügen Sie Benutzer A zur Follower-Liste von Benutzer B hinzu und erhöhen Sie dann die Anzahl der Follower von Benutzer B um eins.

• Fügen Sie Benutzer B zur Follower-Liste von Benutzer A hinzu und erhöhen Sie dann die Anzahl der Follower von Benutzer A um eins.

Schritt 4: Zugriffsmuster 4 (getPostListByUserID) angehen

Um eine Liste der Beiträge abzurufen, die von einem bestimmten Benutzer erstellt wurden, müssen wir eine Query für die Basistabelle mit der Schlüsselbedingung PK=<userID>#post durchführen. Dabei ist zu beachten, dass der Wert eines Benutzers inkrementell sein postIDs muss: Der zweite PostID-Wert muss größer als der erste PostID-Wert sein (da Benutzer ihre Beiträge sortiert sehen möchten). Sie können dies tun, indem Sie auf der postIDs Grundlage eines Zeitwerts wie einem Universally Unique Lexicographically Sortable Identifier () generieren. ULID

Schritt 5: Zugriffsmuster 5 (getUserLikesByPostID) angehen

Um eine Liste der Benutzer abzurufen, denen der Beitrag eines bestimmten Benutzers gefallen hat, müssen wir eine Query für die Basistabelle mit der Schlüsselbedingung PK=<postID>#likelist durchführen. Dies ist dasselbe Muster, das wir zum Abrufen der Listen der Follower und der Personen, denen ein Benutzer folgt, in Zugriffsmuster 2 (getFollowerListByUserID) und Zugriffsmuster 3 (getFollowingListByUserID) verwendet haben.

Schritt 6: Zugriffsmuster 6 (getLikeCountByPostID) angehen

Um die Anzahl der Likes für einen bestimmten Beitrag abzurufen, müssen wir eine GetItem-Operation für die Basistabelle mit der Schlüsselbedingung PK=<postID>#likecount ausführen. Dieses Zugriffsmuster kann zu Drosselungsproblemen führen, wenn ein Benutzer mit vielen Followern (z. B. ein Star) einen Beitrag erstellt, da eine Drosselung auftritt, wenn der Durchsatz einer Partition 1000 pro Sekunde überschreitet. WCU Dieses Problem ist nicht auf DynamoDB zurückzuführen, es tritt nur in DynamoDB auf, da sich DynamoDB am Ende des Software-Stacks befindet.

Sie sollten prüfen, ob es wirklich wichtig ist, dass alle Benutzer die Anzahl der Likes gleichzeitig sehen, oder ob dies schrittweise im Laufe der Zeit geschehen kann. Im Allgemeinen muss die Anzahl der Likes für einen Beitrag nicht sofort zu 100 % korrekt sein. Sie können diese Strategie einführen, indem Sie eine Warteschlange zwischen Ihrer Anwendung und DynamoDB einrichten, damit die Aktualisierungen in regelmäßigen Abständen erfolgen.

Schritt 7: Zugriffsmuster 7 (getTimelineByUserID) angehen

Um die Timeline für einen bestimmten Benutzer abzurufen, müssen wir eine Query-Operation für die Basistabelle mit der Schlüsselbedingung PK=<userID>#timeline ausführen. Betrachten wir ein Szenario, in dem die Follower eines Benutzers ihren Beitrag synchron sehen müssen. Jedes Mal, wenn ein Benutzer einen Beitrag schreibt, wird seine Follower-Liste gelesen und seine userID und postID werden langsam in den Timeline-Schlüssel aller seiner Follower eingegeben. Wenn Ihre Anwendung nun gestartet wird, können Sie den Timeline-Schlüssel mit der Query-Operation lesen und den Timeline-Bildschirm mit einer Kombination aus userID und postID füllen, indem Sie die BatchGetItem-Operation für alle neuen Elemente verwenden. Sie können die Timeline bei einem API Anruf nicht lesen, aber dies ist eine kostengünstigere Lösung, wenn die Beiträge häufig bearbeitet werden könnten.

Auf der Timeline werden die neuesten Beiträge angezeigt, daher benötigen wir eine Möglichkeit, die alten Beiträge zu bereinigen. Anstatt sie WCU zu löschen, können Sie die TTLFunktion von DynamoDB verwenden, um dies kostenlos zu tun.

Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:

Zugriffsmuster	Basis-table/GSI/LSI	Operation	Partitionsschlüsselwert	Sortierschlüsselwert	Sonstige Bedingungen/Filter
getUserInfoByUserID	Basistabelle	Query	PK= <userID>
getFollowerListByUserAUSWEIS	Basistabelle	Query	PK=<userID>#follower
getFollowingListByUserAUSWEIS	Basistabelle	Query	PK=<userID>#following
getPostListByUserAUSWEIS	Basistabelle	Query	PK=<userID>#post
getUserLikesByPostAUSWEIS	Basistabelle	Query	PK=<postID>#likelist
getLikeCountByPostAUSWEIS	Basistabelle	GetItem	PK=<postID>#likecount
getTimelineByUserID	Basistabelle	Query	PK=<userID>#timeline

Endgültiges Schema für soziale Netzwerke

Dies ist das endgültige Schemadesign. Informationen zum Herunterladen dieses Schemadesign als JSON Datei finden Sie unter DynamoDB-Beispiele auf. GitHub

Basistabelle:

No SQL Workbench mit diesem Schemadesign verwenden

Sie können dieses endgültige Schema in No SQL Workbench importieren, ein visuelles Tool, das Funktionen für Datenmodellierung, Datenvisualisierung und Abfrageentwicklung für DynamoDB bereitstellt, um Ihr neues Projekt weiter zu untersuchen und zu bearbeiten. Gehen Sie folgendermaßen vor, um zu beginnen:

1. Laden Sie No Workbench herunter. SQL Weitere Informationen finden Sie unter No SQL Workbench für DynamoDB herunterladen.

2. Laden Sie die oben aufgeführte JSON Schemadatei herunter, die bereits im No SQL Workbench-Modellformat vorliegt.

3. Importieren Sie die JSON Schemadatei in No SQL Workbench. Weitere Informationen finden Sie unter Importieren eines vorhandenen Datenmodells.

4. Sobald Sie in NOSQL Workbench importiert haben, können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.

5. Verwenden Sie die Data Visualizer-Funktion von No SQL Workbench, um Ihr Datenmodell zu visualisieren, Beispieldaten hinzuzufügen oder Beispieldaten aus einer CSV Datei zu importieren.