Schemadesign für Cassandra

Question

Ich arbeite an einem Projekt des Forums, das einem Benutzer erlaubt, Fragen zu bestimmten Themen aus seinem Netzwerk zu folgen.

Die Nachrichten-Feed-Wand eines Benutzers enthält nur die Fragen, die von seinen Verbindungen gepostet und auf die folgenden Themen getaggt wurden. Ich bin verwirrt, welches Datamodell der Datenbank für solch eine Anwendung am passendsten wäre. Ich habe mich ab sofort mit Cassandra- und MySQL-Lösungen beschäftigt.

Nach meiner Studie von Cassandra erkannte ich, dass Einfache News-Feed-Design, das alle Beiträge aus dem Netzwerk anzeigen würde einfach mit Cassandra Design durch Ausführen schneller Schreibvorgänge an alle Anhänger eines Benutzers über den Beitrag von Benutzer. Aber für meine Art der Anwendung, wo es einen zusätzlichen Filter von 'Folgthemen' gibt, konnte ich mich in Cassandra nicht mit einem guten Schemadesign überzeugen. Ich hoffe, wenn ich etwas verpasse wegen meines kurzen Verständnisses von Cassandra, vielleicht, können Sie mir bitte mit Ihren Vorschlägen helfen, wie dieser Nachrichten-Feed in Cassandra implementiert werden könnte?

Answer 1

Ich gehe davon aus, dass Sie bereits die Twissandra-Beispielanwendung studiert haben. Es ist sehr nah an dem, was du beschreibst. Hier sind ein paar nützliche Links:

• Twissandra github project page
• Riptano documentation on Twissandra

Der primäre Unterschied mit Ihrer Anwendung ist die Einführung von Themen. Wie Sie die Daten speichern, hängt davon ab, wie genau Sie sie abfragen können. Beispielsweise könnten Sie mit allen Themen, die in der gleichen Timeline präsentiert werden, zufrieden sein, oder Sie möchten möglicherweise nur eine Timeline für ein bestimmtes Thema anzeigen (z. B. SO-Tags).

Wenn Sie keine separaten Zeitrahmen brauchen, empfehle ich die folgende, die Twissandra Datenmodell als Basis verwenden:

Anstelle der normalen FOLLOWERS Spalte Familie, für für jeden Benutzer eine Reihe von Anhängern halten jeder Thema. Natürlich verursacht dies ein wenig mehr Arbeit beim Erstellen/Ändern/Löschen von Benutzern, aber es spart Ihnen Arbeit, wenn neue Beiträge erstellt werden, was der Hauptteil der Operationen ist, die Sie behandeln müssen.

Wenn ein Beitrag von Benutzer Joe zu Themen gemacht A, B und C, Sie werden in der Lage sein, wie alle interessierten Nutzer mit einer Abfrage zu erhalten:

multiget(FOLLOWERS, ['Joe::A', 'Joe::B', 'Joe::C']) 

wo ‚Joe :: A ',' Joe :: B 'und' Joe :: C 'sind Zeilenschlüssel. Für jeden der Nachfolger, den Sie zurückbekommen, können Sie einfach die UUID des Posts als Spaltennamen in die Zeitleiste eines jeden Follower einfügen (und Sie müssen sich keine Gedanken über Duplikate in der Timeline machen, da Sie dieselbe UUID für die Spalte verwenden) Name).

Wenn Sie Zeitleisten für einzelne Themen pro Thema unterstützen möchten, sollten Sie für jedes Thema, für das sich ein Benutzer interessiert, eine Zeile und für die Timeline für alle Themen eine Zeile verwenden. Da Sie bereits Follower nach Thema abrufen, ist es einfach zu wissen, für welche Themen der Post die Follower interessieren. Sie können den Post an die richtigen Timelines pro Thema anhängen.