Der Google App-Engine-Datenspeicher ist extrem langsam

9

Ich brauche Hilfe, um zu verstehen, warum der folgende Code 3 bis 4 Sekunden dauert.

UPDATE: Anwendungsfall für meine Anwendung ist es, den Aktivitätsfeed einer Person seit der letzten Anmeldung zu erhalten. Dieser Feed könnte Updates von Freunden oder einige neue Elemente außerhalb seines Netzwerks enthalten, die er interessant finden könnte. In der Aktivitätstabelle werden alle diese Aktivitäten gespeichert. Wenn sich ein Benutzer anmeldet, führe ich eine Abfrage im GAE-DataStore aus, um die obigen Aktivitäten zurückzugeben. Meine Anwendung unterstützt auch endloses Scrollen, daher brauche ich die Cursor-Funktion von GAE. Zu einer gegebenen Zeit bekomme ich ungefähr 32 Elemente, aber die Aktivitätstabelle könnte Millionen von Zeilen haben (da sie Daten von allen Benutzern enthält).

Gegenwärtig ist die Aktivitätstabelle klein und enthält nur 25 Datensätze und der folgende Java-Code liest nur 3 Datensätze aus derselben Tabelle.

Jeder Datensatz in der Aktivitätstabelle hat 4 UUID-Felder.

Ich kann mir nicht vorstellen, wie sich die Abfrage verhalten würde, wenn die Tabelle Millionen von Zeilen und das Ergebnis 100 Zeilen enthält.

Stimmt etwas nicht mit dem unten stehenden Code?

(Ich verwende Objectify und App-Engine-Cursor)

%Vor%

Ich habe die App Google App Engine extrem langsam durchforstet und dies überprüft Die Reaktionszeit verbessert sich, wenn ich meine Seite ständig aktualisiere (was den obigen Code aufruft). Die Verbesserung ist jedoch nur ~ 30%

Vergleichen Sie dies mit jeder anderen Datenbank und die Antwortzeit für solch winzige Daten liegt in Millisekunden, nicht einmal in 100 Millisekunden.

Bin ich falsch, wenn ich vom GAE DataStore eine normale Art von Datenbankleistung erwarte?

Ich möchte Memcache noch nicht aktivieren, da ich diese Ebene verbessern möchte, ohne zuerst zu cachen.

    
user2250246 04.05.2015, 05:01
quelle

1 Antwort

1

Sie wissen nicht genau, was Ihre Abfrage tun soll, aber es sieht nicht so aus, als würde eine Cursor-Abfrage erforderlich sein. Meiner Meinung nach ist der einzige gültige Anwendungsfall für Cursor-Abfragen eine paginierte Abfrage für Daten mit einer begrenzten Anzahl von Ergebniszeilen. Da Ihre Abfrage kein Limit hat, sehe ich nicht, warum Sie überhaupt einen Cursor verwenden möchten.

Wenn Sie Millionen von Ergebnissen benötigen, führen Sie wahrscheinlich eine Ad-hoc-Analyse von Daten durch (da kein Mensch jemals Millionen von Rohdatenzeilen interpretieren könnte), wäre es besser, wenn Sie BigQuery anstelle des zugehörigen Datenspeichers verwenden. Ich rate nur hier, aber für normale Front-End-Apps benötigen Sie selten Millionen von Zeilen in einem Ergebnis, aber nur ein paar (vielleicht Hunderte), die Sie aus den gesamten verfügbaren Zeilen filtern.

Eine andere Sache:

Sind Sie sicher, dass die Abfrage lange dauert? Es könnte auch der Wrapper um die Abfrage sein. Da Sie Cursor verwenden, müssen Sie die Abfrage aufrufen, bis keine Ergebnisse mehr angezeigt werden. Der Umgang damit könnte teuer werden.

Zuletzt:

Testen Sie auf appengine selbst oder auf dem lokalen Entwicklungsserver? Der Devserver kann offensichtlich keine Wolke simulieren und könnte daher manchmal langsamer (oder schneller) als das reale Ding sein. Der devserver kennt keine Aufwärmzeiten, wenn Ihre Abfrage neue Instanzen erzeugt.

Apropos Cloud: Die Sache mit Cloud-Datenbanken ist nicht, dass sie die beste Leistung für sehr wenig Daten bieten, sondern dass sie skalieren und konsistent mit einigen hundert und einigen Milliarden Zeilen arbeiten.

Bearbeiten:

  

Nach dem Ausführen eines Abrufvorgangs kann die Anwendung a   Cursor, eine undurchsichtige Base64-codierte Zeichenfolge, die den Index markiert   Position des letzten abgerufenen Ergebnisses.

     

[...]

     

Die Position des Cursors wird als Position in der Ergebnisliste definiert   nachdem das letzte Ergebnis zurückgegeben wurde. Ein Cursor ist keine relative Position in   die Liste (es ist kein Offset); Es ist ein Marker für den Datastore   kann springen, wenn eine Indexsuche nach Ergebnissen gestartet wird. Wenn die Ergebnisse für a   Abfragewechsel zwischen Benutzungen eines Cursors, die Abfrage bemerkt nur Änderungen   die in den Ergebnissen nach dem Cursor auftreten. Wenn zuvor ein neues Ergebnis angezeigt wird   die Position des Cursors für die Abfrage, wird nicht zurückgegeben, wenn der   Ergebnisse nach dem Cursor abgerufen werden.   ( Datenspeicherabfragen )

Diese beiden Aussagen lassen vermuten, dass die Abfrageleistung konsistent mit oder ohne Cursorabfragen sein sollte.

Hier sind einige weitere Dinge, die Sie überprüfen sollten:

  • Wie registrieren Sie Ihre Entity-Klassen mit objectify?
  • Wie sieht Ihr tatsächlicher Testcode aus? Ich würde gerne sehen, wie und wo Sie messen.
  • Können Sie einen Vergleich zwischen Cursor-Abfrage und Abfrage ohne Cursor durchführen?
  • Die Verbesserung mit mehreren Anfragen könnte das Ergebnis des integrierten Objectify-Caching sein. Möglicherweise möchten Sie das Caching für Datenspeicherleistungstests deaktivieren
konqi 04.05.2015 09:02
quelle