django - run - ndb put
Consultas complejas utilizando el almacén de datos GAE (4)
Estoy en las primeras etapas de desarrollo de un sitio web de estadísticas deportivas (ultimate frisbee) y me gustaría conocer sus opiniones si Google App Engine es adecuado para mí.
Lo escribo en Python usando Django y me he sentido cómodo con RDBMS estándar durante años, pero este sitio es un proyecto a largo plazo y espero grandes cantidades de datos, por lo que me gustaría la escala "infinita" que ofrece el almacén de datos GAE. Una gran mayoría de las consultas a la base de datos devolverá resultados muy estándar que harían que el almacén de datos parezca una opción lógica. Sin embargo, me gustaría poder realizar consultas extremadamente complejas en el futuro para obtener nuevas métricas estadísticas o simplemente obtener resultados interesantes. Planeo hacer mucho de esto en el futuro, pero no sabré qué son estas consultas hasta que los datos ya estén recopilados.
Por ejemplo, a menudo los analistas de estadísticas de béisbol crean estadísticas ridículas como "Esta es solo la primera vez en los últimos 50 años que dos lanzadores zurdos cuyos apellidos comienzan con ''Z'' han lanzado blanqueadas de un solo golpe atrás. dias". Me gustaría tener la flexibilidad de hacer cualquier tipo de consulta en el futuro. :)
Sin embargo, tengo la impresión de que una base de datos no relacional como bigtable requiere que se te ocurran modelos que contengan datos redundantes de antemano y que todo el trabajo tenga lugar en las inserciones en lugar de las extracciones. Ya he creado modelos django que contienen prácticamente todos los datos que necesitaría consultar, pero no tengo idea de qué modelos desnormalizados querré tener dentro de uno o dos años. Por lo tanto, tengo la sensación de que hacer consultas complejas en el futuro sería extremadamente difícil en el almacén de datos de GAE y me exigiría extraer una tonelada de información del servidor antes de procesarla en python.
¿El almacén de datos del motor de la aplicación de Google simplemente está mal para lo que quiero hacer? O simplemente me estoy perdiendo algo. Muchas gracias de antemano!
Actualización: Gracias por las respuestas hasta ahora. Me doy cuenta de que también debo mencionar que muchas de estas consultas complejas son consultas que me gustaría que los usuarios pudieran hacer, lo que hace que una base de datos fuera de línea no sea realmente una opción. Por ejemplo, los usuarios deberían poder ver varias estadísticas de cuán bien juegan dos jugadores en particular cuando están en el campo al mismo tiempo durante juegos o temporadas específicos. Si bien estas consultas no son tan frecuentes como las estadísticas agregadas estándar, seguirán ocurriendo con regularidad.
Tener una base de datos relacional, así como el almacén de datos de GAE sería genial, pero django no es compatible con múltiples bases de datos de forma predeterminada y emparejar una solución en conjunto suena difícil y complicado. Eric Florenzano tiene una buena solución para dos bases de datos que usan los modelos django, pero si tuviera que usar el almacén de datos GAE, tendría que usar el modelo db del motor de la aplicación. Y llegar a una buena solución como lo hizo para este problema complejo es un poco más allá de mi nivel de habilidad en este momento.
En este momento, mis dos opciones favoritas son utilizar GAE Task Queue para hacer las consultas difíciles o ir a un servidor web más estándar como webfaction y luego simplemente desnormalizar mis tablas más adelante una vez que mis datos crezcan y necesito aumentar el rendimiento.
GAE data-store es un animal completamente diferente de un RDBMS. En una base de datos relacional es fácil escribir algo como:
SELECT STDEV(player_score)
FROM Table
WHERE player_id = 1234
AND game_date BETWEEN ''2007-01-01'' AND ''2009-11-10''
AND city <> ''London''
La consulta GAE tiene muchas restricciones, mira aquí , así que no es fácil traducir esto. Para las funciones agregadas (suma, stdev, etc.), debe extraer todos los datos en la capa de aplicación y calcular o mantener entidades agregadas que se actualicen en cada inserción / actualización de datos.
Actualizar
Puede considerar usar GAE para la IU y la lógica de negocios, pero tener una base de datos relacional separada en otra parte en la nube como: Microsoft SQL, DB2 en Amazon, MySQL en cualquier otro lugar y usar los datos de GAE, almacenar agregados y estadísticas precalculados. Por lo tanto, las estadísticas todavía se calculan en RDBMS, pero almacena los resultados (estadísticas parciales, precalculadas) en el almacenamiento de GAE; similar al almacenamiento dimensional en cubos analíticos.
Yo diría que el almacenamiento de tipo bigtable es menos adecuado para aplicaciones estadísticas, por las mismas razones que usted menciona. Pero este es un intercambio clásico que tienes que hacer. Rara vez me he encontrado usando la flexibilidad de las consultas realmente complejas, pero muchas veces me he visto obligado a buscar soluciones más especializadas para cosas que no deberían haber estado en el DB en primer lugar.
Si se apega a un RDBMS, puede hacer particiones lógicas y desnormalización bastante fácil, por ejemplo, a través de las estrategias de persistencia de Hibernates e Hibernate Shards . Si puede vivir con el procesamiento algo más lento, también puede hacer consultas SQL en almacenamiento de tipo bigtable (consulte, por ejemplo, hadoop pig latin ).
Lo que está describiendo es esencialmente OLAP - Procesamiento analítico en línea. OLAP es una cosa en la que los RDBMS ''tradicionales'' son muy buenos, en parte debido a la flexibilidad y la potencia de SQL, y las bases de datos no relacionales, como el almacén de datos de App Engine, no lo son. Parece que sus consultas de tipo OLAP serán relativamente poco frecuentes en comparación con el acceso normal, así que sugeriría uno de dos enfoques:
- Refleje todos sus datos desde su almacén de datos de App Engine a una base de datos relacional a intervalos, y realice las consultas analíticas en la base de datos relacional. El tráfico de datos del usuario sigue siendo atendido por el almacén de datos, por lo que obtienes todas las ventajas de eso, pero tienes una copia fuera de línea con la que puedes hacer consultas complejas.
- Utilice la compatibilidad Task Task de App Engine para ejecutar consultas que examinen grandes conjuntos de datos. Puede escribir su consulta en Python o Java, luego usar la cola de tareas para ejecutarla en un conjunto de datos muy grande, y recoger los resultados de manera asincrónica, cuando hayan terminado. Obviamente, se requiere un poco de trabajo de infraestructura para hacerlo más fácil (aunque esté atento a mi blog para un futuro proyecto que involucre esto;).
Quiero apoyar la referencia de MindWire sobre el uso de CloudSQL de Google.
Mi proyecto actual en realidad funciona desde el almacén de datos principalmente con más tareas orientadas a SQL realizadas en Cloud SQL.