BD o archivos

[Alexpi]

Llevo unos dias dudando en esto a ver si podeis ayudarme.

Imaginad un servidor de un juego, cuando se conecta un jugador necesita cargar en memoria informacion de este jugador y cuando el jugador se desconecta, es necesario volcar la info de memoria al HD.

Mi pregunta es, que es mas rapido? guardar y cargar la informacion en/desde archivo binario o base de datos?

[bnl]

Es más rapido guardarlo en un archivo binario, pero la base de datos te da muchas mas funcionalidades, como busquedas, actualizaciones masivas o siguiendo un criterio, joins, etc. Si las necesitas y utilizas un archivo tendrias que implementarlo tu y seguramente al final fuera mas lento que la BD.
Depende de lo que necesites.

[Alexpi]

yaya, si tubiera que hacer ese tipo de consultas sin duda usaria la BD, pero me refiero solo a guardar datos, osea, el estado del usuario en el servidor cuando se desconectó, para recuperarlo cuando se conecte.

Vamos, toda la info que tenga en la clase Jugador por ejemplo. Si usase una BD necesitaria consultar varias tablas tanto para guardar como para recuperar y en cambio un archivo binario seria todo de golpe, por eso pregunto que es mas rapido.

[senior wapo]

Haz que todas las fichas ocupen lo mismo en bytes y guardalas todas en un único archivo binario que mantengas siempre abierto. Cuando quieras leer la ficha de un jugador te posicionas (número de jugador * tamaño de ficha) y lees.

Mantén en memoria una lista (mismamente una tabla hash) de nombres de jugadores y su correspondiente número de ficha.

La cosa es evitar tener muchos archivos en el directorio.

Si se te complica mucho usa la librería sqlite.

[Alexpi]

si el servidor usa 1 hilo para cada jugador, el acceso al archivo habria que hacerlo en exclusion mutua.

No es mejor usar 1 solo archivo por cliente?

[[EX3]]

si el servidor usa 1 hilo para cada jugador, el acceso al archivo habria que hacerlo en exclusion mutua

En este caso no merece mas la pena usar una base de datos? Con ella tendrias posibilidad de hacer varias conexiones simultaneas y seria rapido, sobre todo si va ser para consultar perfiles de usuario.

Salu2...

[Tei]

si el servidor usa 1 hilo para cada jugador, el acceso al archivo habria que hacerlo en exclusion mutua.

No es mejor usar 1 solo archivo por cliente?

Si de pronto ese hilo usa mucha memoria y quieres tener muchos clientes. Puedes tener ahi una limitacion....

¿Un archivo, muchos archivos?, al sistema operativo le puede costar abrir un fichero, si hay muchos directorios o muchos ficheros, o una combinacion de los dos. El sistema de ficheros no es una base de datos. En una base de datos yo no espero ninguna perdida de rendimiento importante de tener 300 a 30.000 registros. En un sistema de ficheros, pasando ciertos limites si me espero penalitis importantes de rendimiento.

Todo esto, si tienes un fichero donde los registros tienen un tamaño fijo, y su posicion en el fichero es ID * tamaño del registro, es que no se puede construir algo mas rapido.

Quizas puedas tener un hilo lector/guardador con una especie de cache. (Aunque no se las implicaciones de una idea asi)

¿Realmente necesitas velocidad? Quizas una base de datos sea lenta. Pero puede mover grandes volumenes de informacion sin sudar. Y no tienes que programarle tu los caches, y las historias, para que sea optimo. Aparte, no tienes que reconstruir ficheros porque haya cambiado el formato. Las bases de datos son flexibles a la hora de añadir campos.

Otra cosa. Si finalmente guardas informacion en registros. Recuerda el concepto de union de C, para hacer un formato "inteligente".

[senior wapo]

Si tu juego es via web, usa una base de datos.

Yo asumía un juego en tiempo real, y si lo es, no se que hace usando 1 hilo por jugador :P

No hace falta exclusión mútua ya que cada uno solo  accede a un área concreta del fichero (la de su ficha).
Solo por eso, solo necesitarías lock del área de tu ficha en lugar del fichero completo. pero es que además, no hace falta locking de ningún tipo porque tienes garantizado que nadie más va a tocar tu ficha (sólo hay 1 jugador conectado por cada ficha).

En todo caso, si tu diseño requiere preocuparse por esas cosas, entonces el problema contesta a la pregunta por sí solo: tira de BBDD o reinventa la rueda.

[Alexpi]

Si tu juego es via web, usa una base de datos.

Yo asumía un juego en tiempo real, y si lo es, no se que hace usando 1 hilo por jugador :P

No hace falta exclusión mútua ya que cada uno solo  accede a un área concreta del fichero (la de su ficha).
Solo por eso, solo necesitarías lock del área de tu ficha en lugar del fichero completo. pero es que además, no hace falta locking de ningún tipo porque tienes garantizado que nadie más va a tocar tu ficha (sólo hay 1 jugador conectado por cada ficha).

En todo caso, si tu diseño requiere preocuparse por esas cosas, entonces el problema contesta a la pregunta por sí solo: tira de BBDD o reinventa la rueda.

No es un juego web.

No queria decirlo pero bueno, estoy suponeindo un servidor de un masivo (solo teoricamente no me lapideis xD).

Que tiene de malo usar 1 hilo por jugador? pensaba que era la forma mas optima. Hacer un servidor secuencial para procesar a los jugadores conectados seria injusto, en cuanto a que, los que esten en el extremo del array tendran una latencia muy mala debido a que deben esperar a que se procesen todos los jugadores que hay delante.

Con un sistema concurrente se garantiza que todos los jugadores sean tratados de la misma forma en cuanto a tiempo de procesador.

En cuanto a lo que dices de que no necesitan exclusion muta, yo creo que si. Recuerda que si todos comparten el mismo descriptor de fichero, este solo puede apuntar a 1 posicion del archivo en un momento dado y si 2 hilos intentan acceder a la vez a posiciones distintas, acabaran accediendo ambos a la misma posicion pues el 1º mueve el puntero de posicion y luego el 2º vuelve a moverlo antes de que el 1º lea lo que le interesa.

[shephiroth]

Depende como lo hagas puede que solo necesites tener 1 descriptor de archivo. Yo por lo que estoy leyendo lees mucho y escribes pocas veces, te podría venir bien que te creases un singleton hijo de thread, con los siguientes metodos:

Código [Seleccionar] Expand

#define UserRawBytes 200
public static FileManager* getFileManager();
public char[UserRawBytes] readUserRawBytes(int IdUser);
public void writeUserRawBytes(char[UserRawBytes], int IdUser);


[Tei]

Que tiene de malo usar 1 hilo por jugador? pensaba que era la forma mas optima.

Solo me preocupa desde un punto de vista de consumo de ram. Si cada hilo come 1 MB, y quieres tener al menos 2000 usuarios, necesitaras 2 GB.
Quizas deberia preocuparme por otras cosas (coste de cambio de contexto?), pero mis conocimientos no llegan mas lejos.
De todos modos esto que comento solo es importante si numeroDeUsuarios * RAMproceso = numero muy gordo.