GAE-GEO-DB ~ Umkreissuche mit Google App Engine DataStore

Datenmodell für eine Umkreissuche mit der Google App Engine: Ziel ist ein skalierbares Design für den DataStore, um weltweit beliebig viele Geo-Positionen zu speichern.
Mehr von diesem Beitrag lesen

Advertisements

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

Architektur des Google App Engine Cloud Service Framework macht Webseiten für Startups skalierbar

Die Architektur des Google App Engine Cloud Service (GAE) ist ein Framework bzw. Server Stack, der es ermöglicht eine Webseite skalierbar mit hoher Performance zu betreiben ohne als Startup bei der Unternehmensgründung selbst eine Infrastruktur aus Clustern aufbauen und betreiben zu müssen. Das Hosting einer Webapp ist in der Free Version sogar kostenlos, sodass eine Homepage gratis für Googles Plattform in Python, Java oder Go entwickelt werden kann. Steigt die Serverlast später an, kann der eigene Cluster mitwachsen ohne dafür die Software anpassen zu müssen.

Der Vorteil der Cloud ist, dass bei einer Plattform als Service nur variable Kosten anfallen. Um die Skalierbarkeit kümmern sich andere und man selbst hat keine Fixkosten von mehrere tausende Euro pro Monat für IT-Spezialisten. Dieser Artikel beschreibt Aufbau und Funktionsweise der App Engine, über die täglich Millionen von Besuchern möglich sind.

Startup / skalierbarer Webserver

Besonders für Startups eignet sich die App Engine, da die Infrastruktur mitwächst und zu Beginn kostenlos ist.

Die traditionelle IT-Architektur im Client-/Serverumfeld bzw. von Webservern ist meist statisch und zentralisiert. Das bedeutet die Anwendung besteht aus einem oder mehreren fest konfigurierten Servern in einem Rechenzentrum und nutzt ein relationales Datenbanksystem. Die Kapazität dieser Ressourcen und damit die maximal mögliche Serverlast ist begrenzt. Übersteigt die Besucherzahl dann zunehmend die Kapazitäten des eigenen Systems ist guter Rat teuer, denn nicht jeder IT’ler beherrscht Skalierung.

Die Infrastruktur der App Engine wird als Platform as a Service (PaaS) genutzt. Bei dieser Plattform sind die Webserver, der Cache, die Datenbank und die Dateiserver weltweit in einer public Cloud verteilte, sodass jeder Request von anderen Servern beantwortet werden kann. Die Anzahl der benötigten Server wird dynamisch an die aktuelle Last angepasst. Ideal für Startups und neue Projekte, in denen sich die IT auf die Umsetzung der Anwendung konzentriert und nicht zusätzlich mit der Infrastruktur sowie deren Betrieb belastet wird.

Komponenten / Server Stack

Mit der Google App Engine kann sofort mit der Umsetzung der Webseite begonnen werden, da sie alle nötigen Komponenten für Entwicklung, Test, Deployment und Betrieb enthält.

Die Komponenten der Google App Engine Cloud können auch für den Aufbau einer eigenen skalierbaren Infrastrukturen adaptiert werden. Für Teile existieren Open Source Lösungen oder Amazon Services, die im eigenen Stack integrierbar sind. Im Vergleich zu einer Apache MySQL PHP Installation unter Linux (LAMP) oder Windows (WAMP) ähnelt die App Engine von der Laufzeitumgebung eher einem Java EE Application Server (JBoss, Websphere, Tomcat), da Programme z.B. auch bei Python im Hauptspeicher gecached werden.

Bestandteile des App Engine Cloud Service sind:

  • Webspace (Application)
  • Webserver (Instanz)
  • Load-Balancer (Scheduler)
  • Laufzeitumgebung (Python, Java, Go)
  • Cache (Memcache)
  • hierarchische Datenbank (Datastore)
  • relationale Datenbank (SQL-DB)
  • Fileserver (Blobstore)
  • Scheduler (Cron)
  • Webhook (Task)
  • Batchserver (Backend)
  • HTTP-Push (Channel)
  • Emailserver (API)
  • Bibliotheken (API’s)
  • Entwicklungsumgebung (Eclipse)
  • Testumgebung (SDK)
  • Deploymentverfahren (SDK)
  • Versionsverwaltung (GAE)
  • Benutzerverwaltung (GAE)
  • Logging (GAE)
  • Monitoring (GAE)
  • Domainverwaltung (Apps)
  • Dokumentation (Web)

Jede Komponente der App Engine Architektur ist skalierbar! Um die Kapazität der Cloud insgesamt zu erweitern müssen nur weitere Server hinzugefügt werden. Zudem kann ein Server seine Aufgabe ändern indem er mit einem anderen Image ausgeführt wird. Das gesamte System ist weniger anfällig gegen Ausfälle einzelner Server. Um das Management der Cloud kümmert sich Google, zu jeder Uhrzeit und auch am Wochenende.

Mehr von diesem Beitrag lesen

Memcache Quota Limit – 212 MB, 48 Stunden – Google Appengine

Der Google Appengine Memcache hat aktuell folgende Limits: maximal 212 MB Space, maximal 48 Stunden und 1 MB je Datensatz sowie maximal 10 K Datensätze. Langfristig können 500 KB zwischengespeichert werden.

Von Google selbst wird keine Quota für den Memcache veröffentlicht, sodass man die Werte nur durch eigene Tests ermitteln kann. Über die google.appengine.api kann mit memcache.get_stats()[‚bytes‘] die aktuelle Größe und mit memcache.get_stats()[‚oldest_item_age‘] der älteste Datensatz ermittelt werden.

Im Memcache können kurzfristig maximal 222.003.552 Byte und langfristig nur 500.269 Byte gespeichert werden, die maximale Dauer beträgt 172.800 Sekunden und maximale Größe 1.000.000 Byte für einen Datensatz. Bei mehr als 10.000 Datensätzen wirft die Appengine eine Exception und steigt mit einem 500 Server Error aus.

Mehr von diesem Beitrag lesen

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

SimpleHomePage für Google AppEngine released

SimpleHomePage für Google AppEngine erlaubt es eine Webseite direkt im Browser ohne SDK zu ändern. Neben statische Dateien (Bilder & Co) können auch dynamische Skripte mit Python online hochgeladen werden.

Download SimpleHomePage – Release 20110921

Im folgenden beschreiben ich, was man tun muss, um SHP4GAE nutzen zu können. Nachdem SimpleHomePage heruntergeladen und bei Google als AppEngine installiert wurde, ist man schon fast fertig.

Schritt 1 – Setup


Setup – Adminpasswort festlegen

Nach der Installation muss zunächst das Passwort für den Administrator definiert werden. Das Passwort wird verschlüsselt in der Datenbank der AppEngine abgespeichert.

Domain Check mit GAE urlfetch

Kleiner Workaround für die Google App Engine, um die Existenz einer Domain zu überprüfen. Statt der Library socket wird urlfetch aus der google.appengine.api verwendet.

Mehr von diesem Beitrag lesen