Condivisione di un database tra Twisted e Django

Question

Sto sviluppando un server di gioco multiplayer che utilizza Django per il server Web (frontend HTML, autenticazione utente, giochi disponibili, classifica, ecc.) E Twisted per gestire le connessioni tra i giocatori e i giochi e interfacciarsi con i giochi stessi. Il server dei giochi, il server web e il database possono essere eseguiti su macchine diverse.

Qual è il modo "migliore" per progettare il database condiviso, in modo da supportare le modifiche allo schema del database in futuro. Dovrei provare ad incorporare l'ORM di Django nel framework Twisted e usare i differiti per renderlo non-blocking? Devo essere bloccato a creare e mantenere due schemi/interfacce database separati, uno nel modello di Django e l'altro con twisted.enterprise.row?

Analogamente, con l'autenticazione utente, dovrei utilizzare la funzionalità di autenticazione utente di twisted o provare ad includere i moduli Django nel server di giochi per gestire l'autenticazione dell'utente sul lato gioco?

Answer 1

Prima di tutto, identificherei il motivo per cui hai bisogno sia di Django che di Twisted. Supponendo che tu stia bene con Twisted usando twisted.web e auth sarà sufficiente e potrai riutilizzare il tuo livello di database sia per le app di frontend che per quelle di backend.

In alternativa si potrebbe guardare in un altro modo, cosa fa Twisted facendo meglio come server di gioco? Speri di supportare più giocatori (più connessioni simultanee) o qualcos'altro? Considera che se è necessario utilizzare il threading con twisted to do per bloccare l'accesso al database, è probabile che tu non sia in grado di supportare efficacemente/in modo affidabile centinaia di thread simultanei. Ricorda che Python ha un Global Interpreter Lock, quindi i thread non sono necessariamente il modo migliore per scalare.

Si dovrebbe anche considerare il motivo per cui si sta cercando di utilizzare un database SQL e un ORM. Il tuo gioco ha dati che sono davvero i più adatti per essere memorizzati in un database relazionale? Forse vale la pena esaminare qualcosa come MongoDB o un altro database di valori-chiave o oggetto per memorizzare lo stato del gioco. Molti di questi negozi NoSQL hanno entrambi i driver di blocco da utilizzare nei driver Django e non bloccanti per l'uso in Twisted (per esempio txmongo).

Detto questo, se sei morto impostato sull'utilizzo di entrambi Django e Twisted ci sono alcune tecniche per incorporare l'accesso al DB di blocco in un server Twisted non bloccante.

1. adbapi (utilizza piscina filo ritorto)
2. uso diretto della piscina filo ritorto usando reactor.deferToThread
3. La tempesta ORM ha un ramo sostegno ritorto (che gestisce deferToThread chiama internamente)
4. SAsync è una libreria che cerca di rendere il lavoro SQLAlchemy in maniera asincrona
5. Avete contorto interagire tramite RPC con un processo che gestisce il blocco DB

Quindi dovresti essere in grado di gestire tu stesso gli oggetti ORG Django importandoli in modo distorto e facendo molta attenzione alle chiamate a reactor.deferToThread. Ci sono molti possibili problemi quando si lavora con questi oggetti all'interno del fatto che alcuni oggetti ORM possono emettere SQL quando si accede/imposta una proprietà, ecc.

Mi rendo conto che questa non è necessariamente la risposta che ci si aspettava ma forse più dettagli su quello che speri di realizzare e il motivo per cui scegli queste tecnologie specifiche permetteranno alla gente di ottenere risposte migliori.

Answer 2

Eviterei semplicemente l'ORM di Django, non è tutto ciò e sarebbe un problema accedere al di fuori di un contesto Django (testimonia il lavoro che è stato necessario per fare in modo che Django supporti più database). L'accesso al database contorto richiede sempre thread (anche con twisted.adbapi) e thread ti danno accesso a qualsiasi ORM che scegli. SQLalchemy sarebbe una buona scelta.