compartir una base de datos entre el trenzado y Django

Question

Estoy desarrollando un servidor de juegos multijugador que utiliza Django para el servidor web (interfaz HTML, autenticación de usuarios, los juegos disponibles, clasificación, etc.) y Twisted para manejar las conexiones entre los jugadores y los juegos y para interactuar con los juegos en sí mismos. El servidor de juegos, el servidor web y la base de datos pueden ejecutarse en diferentes máquinas.

¿Cuál es la "mejor" al arquitecto la base de datos compartida, de una manera que es compatible con cambios en el esquema de base de datos en el futuro. ¿Debería intentar incorporar el ORM de Django en el marco de Twisted y usar diferidos para que no sea bloqueante? ¿Debería estar atascado creando y manteniendo dos esquemas/interfaces de bases de datos separadas, uno en el modelo de Django y el otro usando twisted.enterprise.row?

Del mismo modo, la autenticación de usuarios, debería utilizan la funcionalidad de autenticación de usuario torcido, o tratar de incluir módulos de Django en el servidor de juego para manejar la autenticación de usuario en el lado de juego?

Answer 1

En primer lugar me gustaría identificar qué necesita tanto Django y trenzado. Asumir que te sientes cómodo con Twisted usando twisted.web y auth será suficiente y podrás reutilizar la capa de tu base de datos para las aplicaciones frontend y back-end.

Alternativamente, usted podría mirar a la otra manera, lo que está haciendo Twisted mejor como un servidor de juegos? ¿Estás esperando apoyar a más jugadores (más conexiones simultáneas) o algo más? Considere que si debe usar el subproceso dentro de retorcido para bloquear el acceso a la base de datos, es muy probable que no sea capaz de soportar de manera eficiente/confiable cientos de subprocesos simultáneos. Recuerde que Python tiene un bloqueo de intérprete global, por lo que los hilos no son necesariamente la mejor forma de escalar.

También debe considerar por qué usted está mirando para utilizar una base de datos SQL y un ORM. ¿Su juego tiene datos que son los más adecuados para ser almacenados en una base de datos relacional? Quizás valga la pena examinar algo como MongoDB u otra base de datos clave o de objetos clave para almacenar el estado del juego. Muchas de estas tiendas NoSQL tienen controladores de bloqueo para su uso en controladores Django y no bloqueantes para su uso en Twisted (txmongo, por ejemplo).

Dicho esto, si usted está empeñado en usar tanto Django y Twisted hay algunas técnicas para incrustar el bloqueo del acceso DB en un servidor de Twisted no bloqueante.

1. adbapi (utiliza agrupación de hebras en espiral)
2. El uso directo de la agrupación de hebras trenzado utilizando reactor.deferToThread
3. La tormenta ORM tiene una rama proporcionar apoyo Twisted (Maneja deferToThread llama internamente)
4. SAsync es una biblioteca que trata de hacer el trabajo SQLAlchemy de forma asíncrona
5. han torcido interactuar a través de RPC con un proceso que administra la base de datos bloqueo

por lo que debe ser capaz de gestionar objetos del ORM de Django a sí mismo mediante la importación de ellos en torcido y ser llamadas para preparar muy cuidadoso para reactor.deferToThread. Hay muchos problemas posibles al trabajar con estos objetos dentro de que algunos objetos ORM pueden emitir SQL al acceder/establecer una propiedad, etc.

Me doy cuenta de que esta no es necesariamente la respuesta que esperabas, pero tal vez lo que espera lograr y por qué está eligiendo estas tecnologías específicas permitirá a la gente obtener mejores respuestas.

Answer 2

Solo evitaría el ORM de Django, no es todo eso y sería un dolor acceder fuera del contexto de Django (testigo del trabajo que se requería para hacer que Django admitiera múltiples bases de datos). El acceso torcido a la base de datos siempre requiere hilos (incluso con twisted.adbapi), y los hilos le dan acceso a cualquier ORM que elija. SQLalchemy sería una buena opción.