Pensando en App Engine

Question

Estoy buscando recursos para ayudar a migrar mis habilidades de diseño del almacén de datos RDBMS tradicional a AppEngine DataStore (es decir, al estilo 'Esquema flexible'). He visto varias presentaciones y toco todos los temas principales y algunas técnicas específicas.

Me pregunto si hay un lugar en el que podamos poner en común el conocimiento de la experiencia ("desde las trincheras") en enfoques del mundo real para repensar cómo se estructuran los datos, especialmente portar aplicaciones existentes. Estamos fuertemente basados ​​en Hibernate y probablemente hemos viajado un poco por el camino equivocado con nuestro modelo de datos ya, generando algunas consultas complicadas con las que nuestro DB está luchando.

favor responder si:

1. Usted ha portado una aplicación no trivial a AppEngine
2. Usted ha creado un tipo común de aplicación desde cero en AppEngine
3. Usted ha hecho ni 1 o 2, pero lo están considerando y quieren compartir sus propios hallazgos hasta el momento.

Answer 1

Me pregunto si hay un lugar en el que fue posible combinar el conocimiento de la experiencia

Varios grupos de Google son buenos para eso, aunque no sé si los hay son directamente aplicables a Java-GAE todavía - mi experiencia GAE hasta ahora es todo-Python (estoy un poco orgulloso de decir que Guido van Rossum, inventor de Python y ahora trabajando en Google en App Engine, me dijo que le había enseñado algunas cosas sobre cómo su idea original funcionó - su recomendación menciona que ahora es el que más me enorgullece, entre todos los que están en mi perfil de linkedin ;-). [Trabajo en Google pero mi impacto en App Engine fue muy periférico: trabajé en "crear la nube", clúster y gestión de redes SW, y App Engine trata de hacer que esa infraestructura sea útil para desarrolladores de terceros].

De hecho, hay muchas presentaciones de ensayos & sobre la mejor forma de desnormalizar y fragmentar sus datos para una escala GAE y un rendimiento óptimos; sin embargo, son de calidad variable. Los libros que están fuera hasta ahora son regulares; en los próximos meses vendrán muchos más, ojalá mejores (tuve un proyecto para escribir uno de esos, con dos amigos muy hábiles, pero todos estamos tan ocupados que terminamos cayéndolo). En general, recomendaría los videos de Google I/O y los ensayos que Google bendijo en su sitio de motores de aplicaciones y blogs, ADEMÁS de cada fragmento de contenido de appenginefan's blog - lo que Guido me recomendó por enseñarle sobre GAE, yo a su vez principalmente aprendí de appenginefan (en parte a través del maravilloso app engine meetup en Palo Alto, pero su blog también es genial ;-).

Answer 2

He jugado un poco con Google App Engine para Java y encontró que tenía muchos defectos:

Esto no es de uso general de aplicaciones Java de alojamiento. En particular, no tiene acceso a un JRE completo (por ejemplo, no puede crear subprocesos, etc.) Dado este hecho, tiene que crear su aplicación desde cero con el Google App Engine JRE en mente. Portar cualquier aplicación no trival sería imposible.

Más pertinente a sus preguntas del almacén de datos ...

El almacén de datos de rendimiento es abismal. Intentaba escribir 5000 observaciones meteorológicas por hora, nada demasiado masivo, pero no pude hacerlo porque seguí corriendo hacia la excepción de tiempo de espera tanto con el almacén de datos como con la solicitud HTTP. El uso de la API de almacenamiento de datos de "bajo nivel" ayudó algo, pero no lo suficiente.

Quería eliminar la observación meteorológica después de 24 horas para no completar mi cuota. Nuevamente, no pude hacerlo porque la operación de eliminación tomó demasiado tiempo. Este problema a su vez llevó a que mi cuota de almacén de datos se llene. Insanamente, no puedes eliminar fácilmente grandes franjas de datos en el almacén de datos de GAE.

Hay algunas características que me gustaron. La integración de Eclipse es elegante. La IU del servidor de aplicaciones de appspot es un millón de veces mejor que trabajar con Tomcat (por ejemplo, buenas vistas de los registros). Pero las desventajas superan con creces esos beneficios para mí.

En resumen, constantemente me encontré teniendo que shave the yak, con el fin de hacer algo que habría sido bastante trivial en cualquier entorno de alojamiento Java/aplicación normal.

Answer 3

Los tiempos de espera son ajustados y el rendimiento fue bueno pero no excelente, así que me encontré usando más espacio para ahorrar tiempo; por ejemplo, tuve una relación de muchos a muchos entre cartas intercambiables y jugadores, así que dupliqué la información de quién posee qué: los objetos de la Carta tienen una lista de jugadores y los objetos del jugador tienen una lista de cartas.

Normalmente, almacenar toda su información dos veces habría sido una tontería (y propenso a perder la sincronización) pero funcionó muy bien.

En Python lanzaron recientemente una API remota para que pueda obtener un shell interactivo en el almacén de datos para que pueda jugar con su almacén de datos sin tiempos de espera ni límites (por ejemplo, puede eliminar grandes cantidades de datos o refactorizar sus modelos); esto es fantásticamente útil ya que, de lo contrario, como mencionó Julien, fue muy difícil realizar operaciones a granel.

Answer 4

El diseño de base de datos no relacional esencialmente implica la desnormalización siempre que sea posible.

Ejemplo: Dado que BigTable no proporciona suficientes características de agregación, la opción de suma (efectivo) que estaría en el mundo de RDBMS no está disponible. En cambio, debería almacenarse en el modelo y el método de guardar el modelo debe anularse para calcular la suma de campo desnormalizada.

El diseño básico esencial que se le viene a la mente es que cada plantilla tiene su propio modelo donde todos los campos obligatorios a ser poblados están presentes desnormalizados en el modelo correspondiente; y tiene una completa complejidad de bots de actualización de señales en los modelos.