Google App Engine – Datastore Container – Performance Serialisierung mit pickle versus marshal

Da die Google App Engine pro Tag nur 50k Operationen auf den Datastore spendiert, kann man als Workaround einen Container mit mehreren Datensätzen im Datastore abspeichern. Ist z.B. ein Datensatz 500 Byte groß, dann können in einem Datastore-Container bis zu 2.000 Datensätze gespeichert werden.

Als Container eignet sich eine Hash-Liste, die als Key die ID oder den NAME des Datensatzes enthält. Die Liste wird dann serialisiert in einem BlobProperty gespeichert und der Spacebedarf kann zusätzlich mittels ZIP-Kompression reduziert werden.

Frage: Was ist schneller Marshal oder Pickle?
Antwort: Marshal ist 10 mal schneller als Pickle. 

Beim der Realisierung des Datastore-Container musste ich unbedingt die Vorgaben von Google beachten, dass ein Skript nicht langsamer als eine Sekunden sein darf. App Engines, bei denen Skripte länger als 1.000 ms laufen werden von Google in eine spezielle Sandbox ausgesondert.

Meine Implementierung vom Datastore-Container basiert auf Python. In dieser Sprache gibt es mehrere Möglichkeiten der Serialisierung und Deserialisierung eines Objektes, um dieses in einer Datei oder als Blob in der Datenbank zu speichern. Zunächst habe ich auf Pickle gesetzt, aber die Performance war in Python 2.5.4 sehr schlecht – 250 ms je Operation (Get, Put, Delete) bei einer Hash-Liste mit 300 Zeilen und 100 KB Space.

Mehr von diesem Beitrag lesen

Advertisements

Datastore optimieren auf 50k Ops Google AppEngine Quota Limit

Maximal 50.000 Zugriffe auf die API des Datastore gestattet Google täglich in der Free-Version der AppEngine. Ab November 2011 wird mit Google Cloud Service ein neues Preismodell eingeführt, wodurch die Nutzung der Datenbank „BigTable“ durch das 50k-Limit sehr stark beschnitten bzw. verteuert wird.

„Datastore API quota per app per day … 50k free read/write/small“ [AppEngine Pricing

There are 3 categories of Datastore operations [Pricing FAQ]:

  • Write operations (Entity Put, Entity Delete, Index Write) Each of these operations will cost $0.10 per 100k operations.
  • Read operations (Query, Entity Fetch) Each of these operations will cost $0.07 per 100k operations.
  • Small operations (Key Fetch, Id Allocation) Each of these operations will cost $0.01 per 100k operations.

In der GAE-Betaphase waren noch CPU-Zeit, Trafic und Requests die limitierenden Faktoren. Künftig muss die Optimierung (insbesondere auch in der Payed-Version) auf ein Minimum an Datastorezugriffe abzielen, besonders bei Webseiten mit dynamischen Inhalten. Waren früher bis zu 5 Mio dynamische Request pro Monat möglich, sind es jetzt höchstens 1,5 Mio.

Bei den Operations / Zugriffen werden künftig „small ops“ künstiger berechnet. Small Operationen greifen nur auf / über Keys zu. Der Indexzugriff selbst wird extra zum Fetch der Entities abgerechnet. Werden Datensätze nicht gleichzeitig im Bulk eingelesen, dann zählt sogar jeder Fetch einzeln! Die Größe des Fetches ist nicht relevant.

Die 50k Ops sind u.U. schnell weg! Ein paar Cronjobs im Hintergrund erzeugen leicht tausende Zugriffe auf den Datastore pro Tag. Auch Tracking der User kostet ein paar Ops pro HTTP-Request. Teuer wird es für Seiten mit dynamischen Inhalten (z.B. Blogs) und fast unkalkulierbar für asyncrone Kommunikation für Realtime-Apps (z.B. Chats).

Dynamische Seite > 50.000 Hits / Tag?

Wenn die Limits für die anderen APIs bleiben, dann sind imho verschiedene Workarounds für das 50k-Problem denkbar.

Mehr von diesem Beitrag lesen

Sichere WebApp (Proof of Concept)

Konzept für eine sichere Web-Anwendung

Wir haben gerade den Test von Yammer abgebrochen, weil diese Enterprise Microblogging Plattform aktuell einige z.T. schwere Sicherheitslücken (u.a. Cross-Site-Scripting, Phishing) hat. Grund genug sich mal konzeptionell Gedanken darüber zu machen, ob und wie man ein Web-Frontend für’s Business wirklich sicher machen kann.

Mehr von diesem Beitrag lesen