Schema strutturale per un uso non convenzionale di un database

Question

Schema strutturale per un uso non convenzionale di un database

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

2

Sto scrivendo un client di gioco come un progetto personale e utilizzandolo come veicolo per conoscere l'accesso al database Java, in particolare Neo4j e probabilmente Spring Data Neo4j se decido che sia appropriato. Sono ben consapevole che la mia applicazione è un po 'non convenzionale, e questo ha sollevato questioni che sono strettamente ristrette. Spero che questa domanda sia appropriata per questo sito.

Forse il modo migliore per chiedere questo è spiegare prima cosa sto pensando di fare e perché. Il motivo principale per cui incorporo un database è la persistenza, non la queryabilità. Poiché i tempi di reazione sono critici, il mio piano è che il modello primario dello stato del gioco sia un grafico POJO in memoria. Voglio aggiornare il database persistente in modo asincrono, alla fine coerente. Se capisco correttamente, questo è il contrario della maggior parte delle applicazioni di database, in cui il database è autorevole e i dati in memoria sono solo una copia istantanea.

C'è un nome per questo modello? Se hai scritto qualcosa del genere, quali sono alcune delle insidie che potrei incontrare? È ingenuo persino provarlo?

database design-patterns persistence

posta Kevin Krumwiede 11.08.2014 - 00:40

fonte

3 risposte

Leggi altre domande sui tag database design-patterns persistence

Qual è l'algoritmo di hash a senso unico più corto? WCF è propriamente una piattaforma di comunicazione asincrona?

score 1 · Answer 1

Una trappola è che se c'è un'interruzione di corrente perderai i valori che non sono ancora stati mantenuti.

L'architettura che descrivi è simile a quella utilizzata dai database commerciali in memoria (SAP Hana, Microsoft "Hekaton" ecc.). Questi risolvono questo problema utilizzando l'efficiente registrazione write-ahead. Potresti essere in grado di implementarne una versione se la perdita di dati non è accettabile nel tuo caso d'uso.

score 1 · Answer 2

Questo è un pattern di programmazione asincrono abbastanza standard - non so se ha un nome, ma è certamente il modo in cui si potrebbe lavorare con molte soluzioni cloud dove si lavora con i database NoSQL e la maggior parte tempo di caduta dei dati in una coda dall'applicazione mentre viene aggiornata e quindi si aspetta che venga mantenuta nell'archivio quando l'applicazione è pronta. La maggior parte delle volte i dati vengono recuperati dall'archivio quando inizia una nuova richiesta o al riavvio dell'applicazione, quindi il modello in memoria è quello definitivo.

La cosa che ti aiuterà in questo è sapere che probabilmente vorrai usare una specie di coda di messaggistica per trasferire i tuoi dati nel database, che dovrebbe assicurare che tutti gli aggiornamenti arrivino e che arrivino nell'ordine corretto , ma la tua applicazione front-end può effettivamente far cadere le cose in coda e dimenticarle. L'archivio dati viene quindi eseguito nel proprio processo, preleva gli elementi in coda e li esegue quando è possibile. Questo è anche uno schema molto utile da tenere presente se si inizia a guardare allo spostamento in ambienti distribuiti.

score 0 · Answer 3

 >  what are some of the pitfalls ?

la tua app non è scalabile. in altre parole: non è possibile utilizzare un cloud / cluster per migliorare le prestazioni aggiungendo più server, se si dispone di molti (migliaia di) utenti simultanei.

Finché il numero di utenti è limitato in modo che il "grafico in memoria" possa essere gestito con un server, è ok.