Ist GAE eine Infrastruktur, die eine App hosten kann, die von Millionen aktiver Benutzer verwendet wird?

Ich würde gerne wissen, ob es mit den unten aufgeführten Einschränkungen von GAE überhaupt möglich ist, eine großartige soziale App (wie Facebook) zu erstellen, indem diese App auf GAE gehostet wird.

Mit anderen Worten, ist GAE eine Infrastruktur, die eine App hosten kann, die von 600 Millionen aktiven Benutzern verwendet wird?

Einschränkungen, die ich in einigen Foren / Blogs ausgegraben habe (Sie können sie gerne zur Liste hinzufügen, wenn Sie etwas vermissen):

1. HTTP-Anfrage / Antwort

   • Maximale Anforderungsgröße: 32 MB
   • Maximale Antwortgröße: 32 MB
   • Alle Anfragen müssen innerhalb von 30 Sekunden beantwortet werden, andernfalls löst GAE eine DeadlineExceededException aus
   • Jeder Cron-Job muss innerhalb von 10 Minuten ausgeführt werden
   • Cron-Jobs können Map Reduce nicht verwenden
   • Jedes GET oder POST an eine andere Site wird nach 5 Sekunden abgebrochen. Sie können es so konfigurieren, dass es maximal 10 Sekunden wartet. (Zwischenserver wären notwendig, um viele Male mit Twitter und Facebook zu arbeiten)
   • Der Client kann keine Verbindung zu GAE über FTP herstellen (nur HTTP und HTTPS).
   • Kein https für benutzerdefinierte Domains. Nur für Ihre-app-id.appspot.com-Domains.
   • Wenn Sie einen Zustrom von Benutzern erhalten, wird der Fehler "Über Kontingent" angezeigt

2. Datenbank

   • Das Datenbankverhalten ist in der lokalen Entwicklung nicht dasselbe wie auf den tatsächlichen Servern.
   • GQL. Nichts anderes.
   • Keine Abfrage kann mehr als 1000 Datensätze abrufen.
   • Wenn Sie linearen Zugriff auf eine große Anzahl von Datensätzen benötigen, um eine Operation auszuführen, haben Sie kein Glück (Googles Systeme sind massiv geclustert).
   • Die maximale Größe der Memcache-Werte beträgt 1 MB.
   • Einfache Textsuche nicht möglich
   • Sie können nicht 2 Tabellen verbinden.
   • Langsam (Sie müssen lesen, wie Sie Tabellen mithilfe der Vererbung trennen, damit Sie in einer Tabelle suchen, den Schlüssel abrufen und dann das übergeordnete Element abrufen können, um eine Deserialisierungsleistung zu vermeiden.)
   • Laufzeitausnahme "Zu viele Indizes"
   • Eine Entität kann höchstens 5000 Eigenschaftswerte in einem Index haben
   • Schlüsselnamen des Formulars * (Anfang und Ende mit zwei Unterstrichen) sind reserviert und sollten von der Anwendung nicht verwendet werden.
   • Schlüsselnamen sind auf 500 Byte begrenzt (UTF-8-codiert, denke ich)

3. Sprache

   • Python oder Java oder Go (oder Sprachen, die die JVM verwenden, wie Groovy, Scala und andere)

4. Serverprobleme

   • Keine statische IP (möglicherweise Drosselungs- und Kontingentprobleme beim Aufrufen von APIs von Drittanbietern)
   • Jede Anwendung ist auf 3000 Dateien beschränkt
   • Keine Kontrolle über das Betriebssystem oder die Hardware, auf der die Web-App ausgeführt wird

Ich denke, was mich an dieser Frage ärgert, ist, dass Sie sie formuliert und mit "Fakten" geladen haben, um ein endgültiges Nein zu erhalten.

Die Wahrheit ist, dass Sie eine App Engine-App entwickeln können, die die Funktionen von Facebook, Twitter oder Tumblr repliziert. Vorausgesetzt, die App ist gut geschrieben, kann sie Hunderte Millionen Benutzer unterstützen. Der Hauptgrund, warum Sie dies nicht möchten (was für Sie keine Überlegung zu sein scheint), sind die Kosten für die Ausführung eines Dienstes dieser Größe in App Engine.

Außerdem sehe ich nicht, wie eine der von Ihnen aufgeführten Einschränkungen Sie daran hindern würde, eine solche App zu entwickeln.

1. HTTP-Anfrage / Antwort

   • Maximale Anforderungsgröße: 10 MB - falsch, auf 32 MB erhöht.
   • Maximale Antwortgröße: 10 MB - falsch, auf 32 MB erhöht.

   - Wenn Sie eine soziale App entwickeln, die häufig Seiten mit mehr als 10 MB bereitstellen muss, machen Sie es wahrscheinlich falsch. Wenn Sie Inhalte mit mehr als 32 MB bereitstellen müssen, können Sie den Blobstore auch für Dateien mit bis zu 2 GB verwenden.

   • Sie können nicht auf das Dateisystem zugreifen. (Vergessen Sie das Speichern von Uploads im Dateisystem) - falsch. Sie können aus dem lokalen Dateisystem lesen und Dateien in den Blobstore hochladen und lesen / schreiben.

   - Facebook, Twitter oder Tumblr nehmen auf keinen Fall nur Benutzer-Uploads entgegen und kopieren sie in einen Ordner. Kein Problem.

   • Alle Anfragen müssen innerhalb von 10 Minuten beantwortet werden, andernfalls löst GAE DeadlineExceededException aus - falsch. Eigentlich sind es 30 Sekunden.

   - Wenn Sie länger als 30 Sekunden benötigen, um Ergebnisse auf die Anfrage eines Benutzers zu liefern, machen Sie es wahrscheinlich falsch.

   • Jeder Cron-Job muss innerhalb von 30 Sekunden ausgeführt werden - falsch, es sind 10 Minuten.

   - Wenn Sie eine lange Aufgabe nicht in 10-Minuten-Abschnitte unterteilen können, A: Sie machen es wahrscheinlich falsch und B: Sie können diese Aufgabe jetzt in eine Backend-Instanz verschieben, für die es keine zeitliche Begrenzung für Anforderungen gibt.

   • Cron-Jobs können keine Kartenreduzierung verwenden - nie verwendete Kartenreduzierung, aber ich denke, dies erfordert ein Zitat.

   • Jedes GET oder POST an eine andere Site wird nach 5 Sekunden abgebrochen. Sie können es so konfigurieren, dass es maximal 10 Sekunden wartet. (Zwischenserver wären erforderlich, um viele Male mit Twitter und Facebook zu arbeiten) - Richtig.

   - Wenn eine benutzerbezogene Anforderung an eine externe API länger als 10 Sekunden dauert, ist es wahrscheinlich eine gute Idee, den Benutzer anzuweisen, es trotzdem erneut zu versuchen. Wenn es sich nicht um eine benutzerbezogene Anforderung handelt, können Sie die Aufgabe automatisch wiederholen, bis die API antwortet.

   • Der Client kann keine Verbindung zu GAE über FTP herstellen (nur HTTP und HTTPS). - Wahr

   - Warum ist das ein Problem? Denken Sie, dass ein großes Unternehmen Änderungen über FTP bereitstellt?

   • Kein https für benutzerdefinierte Domains. Nur für Ihre-app-id.appspot.com-Domains. - Wahr.

   - Es steht aber auf der Roadmap.

   • Wenn Sie einen Zustrom von Benutzern erhalten, erhalten Sie den Fehler "Über Kontingent" - halb wahr.

   - Wenn Sie Ihre App richtig budgetieren, wird nie ein Überkontingentfehler angezeigt. Die Royal Wedding-Website wurde auf App Engine gehostet und erhielt 32.000 Anfragen pro Sekunde. Keine Überkontingentfehler. Haben Sie jemals den Fail-Wal auf Twitter oder den Überkapazitätsfehler bei Tumblr gesehen? Das ist im Wesentlichen ihr Überquotenfehler.

2. Datenbank

   • Das Datenbankverhalten ist in der lokalen Entwicklung nicht dasselbe wie auf den tatsächlichen Servern. - Falsch

   - Wenn Sie meinen, dass das Ausführen des Datenspeichers auf Ihrem Laptop langsamer ist als das Ausführen im App Engine-Cluster, dann true, ansonsten überhaupt nicht true.

   • GQL. Nichts anderes. - Falsch

   - Die meisten Entwickler verwenden Datenbankfilter, um den Datenspeicher abzufragen. Außerdem könnte man genauso sagen, dass MySQL "SQL erlaubt. Sonst nichts."

   • Keine Abfrage kann mehr als 1000 Datensätze abrufen (ist zum Kotzen, wenn Sie Ihrem Client die Möglichkeit geben möchten, jetzt mit einem Klick offline zu gehen) - False.

   - Das 1000-Rekord-Limit wurde vor langer Zeit aufgehoben. Zeigen Sie mir außerdem jede benutzerseitige Seite auf Facebook, Twitter oder Tumblr, für deren Rendern mehr als 1000 Datensätze erforderlich sind.

   • Wenn Sie linearen Zugriff auf eine große Anzahl von Datensätzen benötigen, um eine Operation auszuführen, haben Sie kein Glück (Googles Systeme sind massiv geclustert).

   - Ich bin mir nicht mal sicher, was du hier vorhast. Die meisten Leute betrachten die Geschwindigkeit von Googles massivem Cluster als einen großen Vorteil des Systems.

   • Die maximale Größe der Memcache-Werte beträgt 10 MB. - Tatsächlich sind es 1 MB pro Memcache-Eintrag, genau wie bei jeder anderen Memcache-Implementierung.

   • Einfache Textsuche nicht möglich - Richtig.

   - Es ist eine Funktion, die an Deck ist. Die meisten großen Websites führen keine eigene Indizierung der Textsuche durch.

   • Sie können nicht 2 Tabellen verbinden. - Wahr.

   - App Engine-Entwickler müssen ihr Denken von einer einzelnen massiven SQL-Abfrage mit mehreren Verknüpfungen an mehrere kleinere Einzelabfragen anpassen oder Daten denormalisieren, damit keine Verknüpfungen erforderlich sind.

   • Langsam (Sie müssen lesen, wie Sie Tabellen mithilfe der Vererbung trennen, damit Sie in einer Tabelle suchen, den Schlüssel abrufen und dann das übergeordnete Element abrufen können, um eine Deserialisierungsleistung zu vermeiden.) - ???

   - Übersetzung / Zitieren erforderlich.

   • Laufzeitausnahme "Zu viele Indizes" - True

   - Die Anzahl der Indizes in einer einzelnen App ist begrenzt. Ich habe jedoch nur akademische Forschungsanwendungen gesehen.

   • Eine Entität kann höchstens 5000 Eigenschaftswerte in einem Index haben - True

   - Wenn jemand mehr als 5000 Freunde hat, benötigt er zwei Entitäten in der Freundesgruppe.

   • Schlüsselnamen des Formulars __*__(Anfang und Ende mit zwei Unterstrichen) sind reserviert und sollten von der Anwendung nicht verwendet werden. - Wahr

   -- Na und?

   • Schlüsselnamen sind auf 500 Byte begrenzt (UTF-8-codiert, denke ich) - True

   - Schon wieder was? Schlüsselnamen dienen nicht zum Speichern von Novellen, sondern zum eindeutigen Identifizieren einer Entität.

3. Sprache

   • Python oder Java oder Go (alles andere müsste in diese Sprachen übersetzt werden) - Halb wahr

   - Tatsächlich können Sie auch jede Sprache ausführen, die auf der JVM ausgeführt wird, einschließlich PHP und JRuby. Python und Java sind zwei leistungsstarke Sprachen mit vielen verfügbaren Tools, Tutorials und erfahrenen Programmierern.

4. Serverprobleme

   • Keine statische IP (Drosselung und Kontingentprobleme beim Aufrufen von APIs von Drittanbietern) - Halb wahr

   - Die meisten APIs von Drittanbietern kennen App Engine und / oder haben eine Beziehung zu Google. Einige Male hat Twitter die App Engine versehentlich blockiert und sie wird innerhalb weniger Stunden behoben.

   • Jede Anwendung ist auf 3000 Dateien beschränkt - halb wahr

   - Wenn Sie wirklich mehr als 3000 Codedateien für Ihre Webanwendung benötigen, können Sie Zip-Importe verwenden (möglicherweise machen Sie es auch falsch).

   • Keine Kontrolle über Betriebssystem oder Hardware, auf der die Web-App ausgeführt wird - True

   - App Engine ist eine Plattform als Service . Die Leute bezahlen dafür, dass sie sich nicht um die Wartung des Betriebssystems oder der Hardware kümmern müssen. Dies ist der Hauptvorteil von App Engine, keine Einschränkung.

Nein, App Engine ist nicht für eine App mit 600 Millionen aktiven Benutzern geeignet.

Realistisch gesehen laufen Apps dieser Größe auf einer hochgradig angepassten Infrastruktur aus ihren eigenen Rechenzentren heraus. Es ist wahrscheinlich möglich, eine solche App bei Google zu hosten, aber Sie würden direkt mit dem Verkaufsteam zusammenarbeiten, um eine Lösung zu entwickeln. Die oben aufgeführten Sandbox-Einschränkungen wären längst irrelevant.

Wenn Sie gerade erst anfangen, ist es albern, von der Annahme auszugehen, dass Sie genauso beliebt werden wie Facebook. Jede App, die so groß wird, tut dies schrittweise und mit ständigem Re-Factoring. Sorgen Sie sich zunächst um das Entwerfen von Funktionen, die 600 Millionen Benutzer anziehen werden. Die Neugestaltung der Implementierung zur Unterstützung einer wachsenden Benutzerbasis ist im Vergleich dazu ein triviales Problem.

Ich denke, die Punkte in dieser FAQ fallen in einige Hauptbereiche.

Zuallererst gibt es die Punkte, die eher der Skalierbarkeit als dem Nachteil zugute kommen . In einer hoch skalierbaren Anwendung ist eines der Dinge, die Sie anstreben, sicherzustellen, dass jede Anforderung weitgehend unabhängig von den anderen ist und dass sie alle ungefähr dieselbe "Größe" haben (in Bezug auf CPU-Auslastung, Speicher, Netzwerk usw.).

Auf diese Weise können Anforderungen einfach auf Knoten in Ihrem Cluster verteilt werden, ohne sich Gedanken über eine Gruppe "großer" Anforderungen machen zu müssen, bei denen kleinere Anforderungen auf demselben Knoten ausgehungert sind. Dies hält Ihre Infrastruktur in Bezug auf Wartung, Leistung und Zuverlässigkeit einfach.

Das umfasst also Dinge wie:

• Maximale Anforderungs- / Antwortgröße
• Antwortzeiten anfordern
• Antwortzeitlimits für externe Anforderungen
• Maximale Größe des Memcaches (in der Standardversion von Memcache beträgt die maximale Wertgröße 1 MB, sodass Google offensichtlich eine benutzerdefinierte Binärdatei ausführt, die diese Grenze um das Zehnfache erhöht).
• Maximale Datenbankantwortgröße (dh das Limit von 1.000 Zeilen)
• etc

Die zweite Kategorie sind Dinge, die einfach veraltet sind:

• Google Go ist jetzt als Sprache in App Engine verfügbar . In Bezug auf Hochleistungssprachen werden Sie nicht viel besser als Go. Ich mag diesen wirklich sehr
• Datenspeicher kann fehlschlagen - nicht wahr mit dem Datenspeicher mit hoher Replikation (offensichtlich kann Memcache fehlschlagen, aber es ist nur ein Cache)
• Die Anzahl der Dateien ist auf 3.000 und nicht auf 1.000 begrenzt

Nun wäre es schön, wenn Google seine Infrastruktur öffnen würde, damit Cron-Jobs Map Reduce verwenden können, und Sie Abfragen über Ihren gesamten Datensatz ausführen können. Aber wenn Sie sogar einen bedeutenden Bruchteil von 600 Millionen Nutzern ausmachen, werden Sie bereits ein sehr großer Kunde von Google sein und hätten ohnehin mehr Optionen als in App Engine verfügbar.

Wenn Sie eine Idee haben, die sogar 100, geschweige denn 600 Millionen Benutzer anzieht, haben Sie jedes Risikokapital und jedes Tech-Team, um sie auf jeder Infrastruktur zu entwickeln und zu betreiben. In diesem Fall möchten Sie auch Ihr geistiges Eigentum schützen, das GAE nicht bereitstellt, da Google Zugriff auf den Quellcode jeder GAE-App haben möchte (Sie können Python- und Java-Code ohnehin nicht wirklich schützen).
GAE eignet sich für Unternehmen, die ihre IT-Infrastrukturkosten senken möchten und nicht nur die IP-Adresse, sondern nur ihre Daten schützen müssen.