+3
Planned

Hotlap history | Historial de hotlaps

Rodrigo Zarza 12 years ago updated by David Anes 12 years ago 5

Keep all hotlaps in the system and allow users to get this information on demand.


Estaría bien que se quedasen almacenadas las hotlaps de circuitos anteriores. Aunque entiendo que si algún día hay muchas comunidades puede llegar a colapsar un poco la base de datos. De ser así se podría quedar almacenadas sólo las dos últimas por ejemplo.

Answer

Answer
Planned

De hecho, actualmente yo ya tengo el historial de todas las vueltas que se han dado, es cuestión de implementarlo en el frontend.


Por el tema de que fueran demasiadas, eso ya está pensado y, en principio, no será necesario borrar nunca vueltas, ya que el sistema está preparado para almacenar hasta 2^122 hotlaps... o lo que viene a ser lo mismo:


5316911983139663491615228241121400000 vueltas rápidas.


La verdad es que no creo que nunca lleguemos a semejante barbaridad, antes se acabará el espacio en disco duro xDDD

Answer
Planned

De hecho, actualmente yo ya tengo el historial de todas las vueltas que se han dado, es cuestión de implementarlo en el frontend.


Por el tema de que fueran demasiadas, eso ya está pensado y, en principio, no será necesario borrar nunca vueltas, ya que el sistema está preparado para almacenar hasta 2^122 hotlaps... o lo que viene a ser lo mismo:


5316911983139663491615228241121400000 vueltas rápidas.


La verdad es que no creo que nunca lleguemos a semejante barbaridad, antes se acabará el espacio en disco duro xDDD

La verdad que son demasiadas jaja Ya te garantizo que aunque borres la mitad de esos números no llegarías a ellos. Ya el día que lleguemos al millón lo celebraremos, y mira si queda para llegar a eso.


Si tienes todo en el backend, pues no hay más de qué hablar. A la espera de la implementación.

Joder David, si es que está todo pensado.

David, el historial de hotlaps antiguas guardado en otra tabla hará al sistema ir más rápido cuando los indices crezcan un poco..

Tenemos un sistema de cache/proxy transparente con una BBDD distribuida no relacional en memoria que consigue eso sin necesidad de andar moviendo datos de una tabla a otra que en la próxima actualización estará funcionando, ya que estamos haciendo la migración. Ahora estamos haciendo pruebas de carga del nuevo sistema, evaluando Mongo y REDIS. Más en la próximas semanas...

Actualmente, una query cuesta del orden de 50 a 60ms, con lo que aún tenemso margen, pero por si acaso lanzaremos el sistema de caching en la próxima actualización.