Me gustaría saber con las restricciones de GAE enumeradas a continuación, ¿es posible incluso construir una gran aplicación social (como Facebook) al alojar esa aplicación en GAE?
En otras palabras, ¿GAE es una infraestructura capaz de alojar una aplicación utilizada por 600 millones de usuarios activos?
Restricciones que eliminé de un par de foros / blogs (siéntase libre de agregar a la lista si encuentra algo que falta):
Solicitud / respuesta HTTP
- Tamaño máximo de solicitud: 32 MB
- Tamaño máximo de respuesta: 32 MB
- Todas las solicitudes deben responder dentro de los 30 segundos; de lo contrario, GAE lanzará DeadlineExceededException
- Cada trabajo cron debe ejecutarse en 10 minutos
- Los trabajos de Cron no pueden utilizar la reducción de mapas
- Cada GET o POST a otro sitio se cancela después de 5 segundos. Puede configurarlo para esperar hasta 10 segundos como máximo. (los servidores intermedios serían necesarios para trabajar con Twitter y Facebook muchas veces)
- El cliente no puede conectarse a GAE a través de FTP (solo HTTP y HTTPS).
- No hay https para dominios personalizados. Solo para tus dominios-app-id.appspot.com.
- Si recibe una afluencia de usuarios, recibirá un error de "exceso de cuota"
Base de datos
- El comportamiento de la base de datos no es el mismo en el desarrollo local que en los servidores reales.
- GQL Nada más.
- Ninguna consulta puede recuperar más de 1000 registros (apesta seriamente si desea permitir que su cliente tenga un botón de un clic para desconectarse ahora)
- Si necesita acceso lineal a una gran cantidad de registros para realizar una operación, no tiene suerte (los sistemas de Google están agrupados masivamente)
- El tamaño máximo de los valores de Memcache es de 1 MB.
- No puedo hacer una búsqueda de texto simple
- No puedes unirte a 2 mesas.
- Lento (debe leer sobre cómo separar las tablas usando la herencia para poder buscar en una tabla, obtener la clave y luego obtener su padre para evitar el rendimiento de deserialización)
- Excepción de tiempo de ejecución de "demasiados índices"
- Una entidad puede tener como máximo 5000 valores de propiedad en un índice
- Los nombres clave del formulario * (comienzan y terminan con dos guiones bajos) están reservados y la aplicación no debe usarlos.
- Los nombres de clave están limitados a 500 bytes (UTF-8 codificado, supongo)
Idioma
- Python o Java o Go (o lenguajes que utilizan la JVM como Groovy, Scala y otros)
Problemas del servidor
- Sin IP estática (puede haber problemas de aceleración y de cuotas al llamar a API de terceros)
- Cada aplicación está limitada a 3000 archivos
- Sin control del sistema operativo o hardware que ejecuta la aplicación web
Respuestas:
Creo que lo que me molesta de esta pregunta es que la has formulado y cargado con "hechos" en un intento de obtener un no definitivo.
La verdad es que podría desarrollar una aplicación App Engine que replica las características de Facebook, Twitter o Tumblr. Y suponiendo que la aplicación esté bien escrita, se adaptaría a cientos de millones de usuarios. La razón principal por la que no querrías (lo que no parece ser una consideración para ti) es el costo de ejecutar un servicio de ese tamaño en App Engine.
Además, no veo cómo alguna de las restricciones que ha enumerado le impediría desarrollar una aplicación de este tipo.
Solicitud / respuesta HTTP
- si está desarrollando una aplicación social que con frecuencia necesita entregar páginas de más de 10 MB, probablemente lo esté haciendo mal. Además, si necesita entregar contenido de más de 32 MB, puede usar el blobstore para archivos de hasta 2 GB.
- No hay forma de que Facebook, Twitter o Tumblr solo estén cargando usuarios y los copien en una carpeta. No es un problema.
- Si necesita más de 30 segundos para entregar resultados a la solicitud de un usuario, probablemente lo esté haciendo mal.
- Si no puede dividir una tarea larga en fragmentos de 10 minutos, A: probablemente lo esté haciendo mal y B: ahora puede mover esa tarea a una instancia de Backend, que no tiene un límite de tiempo para las solicitudes.
Los trabajos de Cron no pueden utilizar la reducción de mapas: nunca se utilizó la reducción de mapas, pero creo que esto requiere una cita.
Cada GET o POST a otro sitio se cancela después de 5 segundos. Puede configurarlo para esperar hasta 10 segundos como máximo. (los servidores intermedios serían necesarios para trabajar con Twitter y Facebook muchas veces) - Verdadero.
- Si una solicitud dirigida a un usuario a una API externa tarda más de 10 segundos, probablemente sea una buena idea decirle al usuario que vuelva a intentarlo de todos modos. Si no se trata de una solicitud orientada al usuario, puede volver a intentar la tarea automáticamente hasta que la API responda.
-- ¿Por qué es esto un problema? ¿Crees que alguna empresa a gran escala implementa cambios a través de FTP?
- Sin embargo, está en la hoja de ruta.
- Si presupuesta adecuadamente su aplicación, nunca verá un error de exceso de cuota. El sitio de Royal Wedding fue alojado en App Engine y recibió 32,000 solicitudes por segundo. No hay errores de exceso de cuota. Además, ¿alguna vez has visto la ballena fallada en Twitter o el error de exceso de capacidad en Tumblr? Eso es esencialmente su error de exceso de cuota.
Base de datos
- Si quiere decir que ejecutar el almacén de datos en su computadora portátil es más lento que ejecutarlo en el clúster de App Engine, entonces es cierto, de lo contrario no es cierto en absoluto.
- La mayoría de los desarrolladores usan filtros db para consultar el almacén de datos. Además, también podría decir que MySQL permite "SQL. Nada más".
- El límite de 1000 registros se levantó hace mucho tiempo. Además, muéstrame cualquier página orientada al usuario en Facebook, Twitter o Tumblr que requiera más de 1000 registros para renderizarse.
- Ni siquiera estoy seguro de lo que estás haciendo aquí. La mayoría de la gente considera que la velocidad del clúster masivo de Google es una gran ventaja del sistema.
El tamaño máximo de los valores de Memcache es de 10 MB. - En realidad, es 1 MB por entrada de memcache, igual que cualquier otra implementación de memcache.
No se puede realizar una búsqueda de texto simple: verdadero.
- Es una característica que está en cubierta. La mayoría de los sitios grandes no realizan su propia indexación de búsqueda de texto.
- Los desarrolladores de App Engine necesitan ajustar su pensamiento desde una sola consulta SQL masiva de múltiples uniones a varias consultas individuales más pequeñas, o desnormalizar datos para que no se necesiten uniones.
- Se requiere traducción / cita.
- Hay un límite para la cantidad de índices en una sola aplicación. Sin embargo, solo he visto solicitudes de investigación académica.
- Entonces, si alguien tiene más de 5000 amigos, necesitaría dos entidades en el grupo de amigos.
__*__(comienzan y terminan con dos guiones bajos) están reservados y la aplicación no debe usarlos. - Cierto-- ¿Y qué?
- De nuevo, ¿y qué? Los nombres clave no son para almacenar novelas, son para identificar de forma única una entidad.
Idioma
- En realidad, también puede ejecutar cualquier lenguaje que se ejecute en la JVM, incluidos PHP y JRuby. Sin embargo, no estoy seguro de por qué es un problema, Python y Java son dos lenguajes poderosos con muchas herramientas disponibles, tutoriales y programadores experimentados.
Problemas del servidor
- La mayoría de las API de terceros conocen App Engine y / o tienen una relación con Google. Algunas veces Twitter ha bloqueado accidentalmente App Engine y se soluciona en unas pocas horas.
- Si realmente necesita más de 3000 archivos de código para su aplicación web, puede usar las importaciones zip (también, podría estar haciéndolo mal).
- App Engine es una plataforma como servicio . No tener que preocuparse por el mantenimiento del sistema operativo o el hardware es lo que la gente paga. Esta es la ventaja clave de App Engine, no una limitación.
fuente
No, App Engine no es apropiado para una aplicación con 600 millones de usuarios activos.
Siendo realistas, las aplicaciones de este tamaño se ejecutan en una infraestructura altamente personalizada desde sus propios centros de datos. Probablemente sea posible alojar una aplicación de este tipo con Google, pero trabajaría directamente con su equipo de ventas para diseñar una solución; las restricciones de sandbox que ha enumerado anteriormente serían irrelevantes desde hace mucho tiempo.
Si recién estás comenzando, es una tontería diseñar alrededor de la suposición de que te volverás tan popular como Facebook. Cualquier aplicación que se vuelva tan grande lo hace de forma incremental y con refactorización constante. Primero, preocúpese por diseñar características que atraerán a 600 millones de usuarios. Rediseñar la implementación para soportar una creciente base de usuarios es un problema trivial en comparación.
fuente
Creo que los puntos en las preguntas frecuentes se encuentran en un par de áreas principales.
En primer lugar, están los puntos que en realidad son beneficiosos para la escalabilidad, en lugar de perjudicarlos. En una aplicación altamente escalable, una de las cosas por las que se esfuerza es asegurarse de que cada solicitud sea en gran medida independiente de las demás y también de que todas tengan el mismo "tamaño" (en términos de uso de CPU, memoria, red, etc.).
De esa forma, las solicitudes se pueden distribuir fácilmente entre los nodos de su clúster sin preocuparse por un grupo de solicitudes "grandes" que eliminan las solicitudes más pequeñas en el mismo nodo. Esto mantiene su infraestructura simple en términos de mantenimiento, rendimiento y confiabilidad.
Entonces eso cubre cosas como:
La segunda categoría son cosas que simplemente están desactualizadas:
Ahora, sería bueno que Google abriera su infraestructura para permitir que los trabajos cron utilizaran Map Reduce y le permitieran ejecutar consultas sobre todo su conjunto de datos. Pero para cuando sea una fracción significativa de 600 millones de usuarios, ya será un gran cliente de Google y, de todos modos, tendrá más opciones que las que están disponibles en App Engine.
fuente
Si se le ocurre una idea que atraerá incluso a 100, y mucho menos a 600 millones de usuarios, tendrá capital de riesgo y cualquier equipo tecnológico para desarrollarlo y ejecutarlo en cualquier infraestructura. Y también querrá proteger su propiedad intelectual en ese caso, que GAE no proporcionará porque Google quiere tener acceso al código fuente de cada aplicación GAE (de todos modos, no puede proteger el código Python y Java).
GAE es adecuado para empresas que desean deshacerse de sus costos de infraestructura de TI y no tienen la necesidad de proteger el código IP sino solo sus datos.
fuente