Manejar cien millones de registros

[darkerbyte]

Empezado por mamcx

10 millones es algo mas viable.

Hice un BD de prueba (no identico a lo que dices) con 100 millones y me dio mas de 8 GB (con indices y demas).

Con 10 millones 880 MB. Eso es mas viable.

Gracias amigo Mamcx. Has sido demasiado amable en hacer la prueba con los 100 millones de registros. Aunque el tamaño me pareció muy alejado de lo que calcule originalmente. Con que tipo de datos probaste? De hecho los datos serian:

Código SQL [-]placa : char(10) multas : tinyInt(1) robo : tinyInt(1) pagos : tinInt(1)


¿Crees que la BD llegue a ese tamañao (880mb) con esos 4 campos y 10 millones de registros? Gracias de antemano por tu invaluable tiempo!

Empezado por juanelo

Que tal darkerbyte,
El proyecto puede ser viable, pero afinando los procesos de actualizacion de la base de datos, tanto la del servidor como las de los dispositivos mobiles, me explico.
1.- Solo vale la pena hacer la carga "completa" de toda la base de datos la primera vez, al dispositivo mobil.
2.- Las subsecuentes actualizaciones se deber de hacer por medio de un proceso de "sincronizacion", es decir solo actualizar los registros que hayan cambiado en los campos criticos para la aplicacion o bien los nuevos registros.
3.- La implementacion de la sincronizacion es la piedra angular: yo he resuelto esto por medio del manejor de versiones de los registros, de manera que aquellos registros cuyas versiones entre el dispositivo movil y la base de datos "real" difieran deben de ser actualizados.
4.- En mi caso nunca se hace un recorrido de la base en el dispositivo, siempre se tiene la ultima base de datos que se subió al dispositivo (algo asi como bd en dispositivo XYZ, en un disco duro local), la cual obviamente en tu caso va a ser una porcion de la BD "viva", lo cual alijera mucho actualizar las versiones de los registros modificados. De esta manera se sabe despues de haber hecho esta sincronizacion "local", cuales son los registros modificados o nuevos (que son muchisimo menos que el total) y son estos los que se "actualizan" ahora si en el dispositivo.
5.- En todo momento debes de guardar el estado de "ultima sincronizacion", tanto en la bd local (la bd reducida espejo del dispositivo en disco local) y la BD movil.

A grandes pasos eso es lo que en mi caso hemos implementado (me basé en la forma de operar de itunes por ejemplo, aunque no se si asi lo hace en realidad) y creeme que es muy confiable.

Saludos y mucha suerte.

Gracias amigo Juanelo, creo que me has dado una excelente idea.

Lo que estoy pensando es que tal vez podriamos crear un script para actualizar solo los campos que cambiaron. Y la aplicacion estará encagada, segun la idea de guardar el numero de versión actual (supongamos la 103) cuando se conecte para actualizar entonces el sistema le indicaría cuantas actualizaciones hay (supongamos vamos en al 106) entonces el sistema movil descargaria del servidor y ejecturaría los scripts correspoondientes (un ejemplo) 104.sq, 105.sql y 106.sql.
Ademas la ventaja es que estas actualizaciones se harian diario en el destacamento de transito. De manera que no seria problema el internet.
Y toda la chamba caeria en el servidor que será el que tenga que estar generando estas actualizaciones cada día.
Incluso hasta podriamos almacenar unos cuantos campos mas.

En nuestro caso el problema no seria la actualización pues la base de datos movil es exclusivamente para consulta. Podriamos utlizar un modulo aparte para guardar infracciones y que ese si se sincronice con el servidor hasta que esten el el destacamento. Pero el procedimiento ya se iria por otro lado, enviando los datos al servidor, el sevidor guardando en las tablas correspondientes y luego el servidor generar la actualización para la "tabla para consulta rapida"

Y si se compra algun equipo portatil que sea lo suficientemente potente (tal vez un android con quadcore y una tarjeta de 32GB y utilizando Delphi XE5 y Firedac) ya solución no se ve tan imposible ¿Que opinan?