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 Diagramm der Entitätsbeziehungen (Entity Relationship Diagram, ERD), das wir für das Schemadesign 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 NoSQL-Datenbank. Daher können Sie keine Verknüpfung – eine Operation, bei der Daten aus mehreren Datenbanken kombiniert werden – durchführen. Kunden, die nicht mit DynamoDB vertraut sind, könnten Philosophien der Gestaltung von relationalen Datenbankmanagementsystemen (RDBMS) auf DynamoDB anwenden (z. B. das Erstellen einer Tabelle für jede Entität), obwohl dies nicht notwendig ist. 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. Hierbei ist es wichtig, zu beachten, dass die postIDs eines Benutzers inkrementell sein müssen: Der zweite postID-Wert muss größer als der erste postID-Wert sein (da die Benutzer ihre Beiträge in der richtigen Reihenfolge sehen möchten). Zu diesem Zweck können Sie postIDs auf der Grundlage eines Zeitwerts wie einem Universally Unique Lexicographically Sortable Identifier (ULID) generieren.

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. eine prominente Persönlichkeit) einen Beitrag verfasst, da es zu einer Drosselung kommt, wenn der Durchsatz einer Partition 1 000 WCU pro Sekunde überschreitet. 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 nicht mit einem API-Aufruf lesen, doch diese Lösung ist kostengünstiger, 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 zum Löschen der Beiträge WCU zu verwenden, können Sie dies über das TTL-Feature von DynamoDB kostenlos tun.

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

Zugriffsmuster	Basistabelle/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:

Verwendung von NoSQL Workbench mit diesem Schemadesign

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

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

2. Laden Sie die oben aufgeführte JSON-Schemadatei herunter, die bereits das NoSQL-Workbench-Modellformat aufweist.

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

4. Nach dem Import in NOSQL Workbench können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.

5. Verwenden Sie das Feature Data Visualizer von NoSQL Workbench, um Ihr Datenmodell zu visualisieren, Beispieldaten hinzuzufügen oder Beispieldaten aus einer CSV-Datei zu importieren.