Wie würden Sie einen AppEngine-Datenspeicher für eine soziale Website wie Twitter entwerfen?

Question

Ich frage mich, was wäre der beste Weg, um eine soziale Anwendung zu gestalten, bei der Mitglieder mit Google AppEngine Aktivitäten ausführen und den Aktivitäten anderer Mitglieder folgen.

Um genauer sein lässt vermuten wir diese Entitäten haben:

• Benutzer, die Freunde haben
• Aktivitäten welche Aktionen gemacht werden von den Benutzern darstellen (können sagen, die jeweils eine Zeichenfolge Nachricht und eine Reference an seinen Besitzer Benutzer, oder es kann Elternvereinigung über appengine Schlüssel verwenden)

Der schwierige Teil folgt den Aktivitäten Ihres Freundes, Das bedeutet, dass Sie die neuesten Aktivitäten von all Ihren Freunden zusammenfassen. Normalerweise wäre das ein Join zwischen der Activities-Tabelle und Ihrer Freundesliste, aber das ist kein praktikabler Entwurf für appengine, da es keinen simulierenden Join gibt, der N-Abfragen auslösen muss (wobei N die Anzahl der Freunde ist) und dann im Speicher zusammengeführt werden - sehr teuer und wird wahrscheinlich Anfragetermin überschreiten ...)

Ich denke derzeit über die Implementierung dieser Posteingangswarteschlangen, wo Erstellung einer neuen Aktivität einen Hintergrundprozess ausgelöst wird, die den Schlüssel der neuen Aktivität in den "Posteingang "jeder folgenden Benutzer:

• bekommen‚Alle Nutzer, die X folgen‘ist eine mögliche appengine Abfrage
• Keine sehr teure Stapeleingabe in eine neue "Posteingang" -Entität, die grundsätzlich Tupel (Benutzer-, Aktivitätsschlüssel) speichert.

Ich werde gehört Gedanken auf diesem Entwurf oder alternative Vorschläge usw. glücklich sein

Answer 1

bei Building Scalable, Complex Apps on App Engine Werfen Sie einen Blick (pdf), eine faszinierende Rede gegeben bei Google I/O von Brett Slatkin. Er spricht das Problem an, einen skalierbaren Messaging-Dienst wie Twitter aufzubauen.

Hier ist seine Lösung eine Liste Eigenschaft mit:

class Message(db.Model): 
    sender = db.StringProperty() 
    body = db.TextProperty() 

class MessageIndex(db.Model): 
    #parent = a message 
    receivers = db.StringListProperty() 

indexes = MessageIndex.all(keys_only = True).filter('receivers = ', user_id) 
keys = [k.parent() for k in indexes) 
messages = db.get(keys) 

Dieser Schlüssel nur Abfrage findet die Nachrichten Indizes mit einem Empfänger gleich dem Sie ohne Deserialisieren angegeben und die Liste der Empfänger der Serialisierung. Dann verwenden Sie diese Indizes, um nur die gewünschten Nachrichten zu erfassen.

Hier der falsche Weg, es zu tun:

class Message(db.Model): 
    sender = db.StringProperty() 
    receivers = db.StringListProperty() 
    body = db.TextProperty() 

messages = Message.all().filter('receivers =', user_id) 

Dies ist ineffizient, da Abfragen alle Ergebnisse durch Ihre Frage zurück auszupacken haben. Wenn Sie also in jeder Empfängerliste 100 Nachrichten mit 1.000 Benutzern zurückgegeben haben, müssen Sie 100.000 (100 x 1000) Listeneigenschaftswerte deserialisieren. Viel zu teuer in Datenspeicher-Latenz und CPU.

Ich war ziemlich verwirrt von all dem zuerst, so schrieb ich eine short tutorial about using the list property.Viel Spaß :)

Answer 2

Ich weiß nicht, ob es das ist beste Entwurf für eine soziale Anwendung, aber jaiku war ported to App Engine von seinem ursprünglichen Schöpfer, als das Unternehmen von Google übernommen wurde, so sollte es sinnvoll sein.

Siehe den Abschnitt Schauspieler und Tiger und Bären, Oh My! in design_funument.txt. Die Entitäten sind in common/models.py definiert und die Abfragen sind in common/api.py.

Answer 3

Ich denke, das kann jetzt mit den neuen Projection Queries in NDB gelöst werden.

class Message(ndb.Model): 
    sender = ndb.StringProperty() 
    receivers = ndb.StringProperty(repeated=True) 
    body = ndb.TextProperty() 

messages = Message.query(Message.receivers == user_id).fetch(projection=[Message.body]) 

Jetzt müssen Sie sich nicht mit dem teuer Kosten beschäftigen, die Liste Eigenschaft deserialisiert.

Answer 4

Robert, über Ihre vorgeschlagene Lösung:

messages = Message.query(Message.receivers == user_id).fetch(projection=[Message.body]) 

ich denke, der ndb.TextProperty „Körper“ kann nicht mit Projektionen verwendet werden, da nicht indiziert. Projektionen unterstützen nur indexierte Eigenschaften. Die gültige Lösung wäre, die 2 Tabellen zu pflegen: Message und MessageIndex.