Manejar cien millones de registros

[darkerbyte]

Hola amigos del foro:

Sucede que necesito desarollar un proyecto movil para manejar solo una tabla con cuantro campos

 id (string:10)  activo (booleano)   reporte (booleano)   adeudo (booleano)

Pero esta tabla debe manejar cien millones de registros. La verdadera complejidad es que lo necesitan para una solución movil (ya sea tablet, smartphone o computadora movil) sin depender de internet. Es decir, los trabajadores (como 500) cada mañana puedan descargar la BD actualizada para salir a recorrer las rutas.

He pensado hacerlo en SQlite, tambien veo que Delphi XE5 ha sacado una base de datos para moviles (creo que es InterBase).

Si alguno de ustedes ha manejado bases de datos grandes, tal vez pueda darme un consejo o alguna alternativa. Hice un cáculo muy somero y nada mas por el campo id en cien millones de registros con 10 bytes * 100,000,000 = 954mb! Es una base de datos enorme, considerando que se tiene que estar descargando cada día.

El problema no es el servidor, la empresa tiene los recursos para montar el servidor y el acceso a internet con las características necesarias. La situación son los empleados que estan regados en el pais y necesitan por internet estar descargando la BD cada dia.

Lo que he propuesto a la empresa es discriminar algunos registros en base a ciertos criterios para reducir el tamaño de la tabla. Y pues esta idea se consideró adecuada y la bajariamos a la mitad de registros tal vez. Pero bueno, ellos me piden que si es posible manejar toda la tabla, mejor.

Como ven? estan pidiendo un imposible?

[Casimiro Notevi]

¿Todos los días cambian todos los registros de esa tabla?
¿Cuántos registros cambian?
Desde luego, descargar un giga diario por 500 personas, como que parece un poco bruto.

[mamcx]

Sqlite con seguridad da la talla. Pero sigo sin ver porque hay que tener toda esa info instalada. No se podria filtrar por ruta o persona?

[Neftali [Germán.Estévez]]

Empezado por darkerbyte

(1)* Sucede que necesito desarollar un proyecto movil para manejar solo una tabla con cuantro campos
(1)* Pero esta tabla debe manejar cien millones de registros.
(1)* Lo necesitan para una solución movil (ya sea tablet, smartphone o computadora movil) sin depender de internet.

(2)* Los trabajadores (como 500) cada mañana puedan descargar la BD actualizada para salir a recorrer las rutas.

Como ven?
¿Estan pidiendo un imposible?

Aquí veo dos cuestiones, los requerimientos y la solución.
Hay que decir que no conozco exactamente el problema, pero yo día que ambos son poco "realistas". Sinceramente no se quien los ha "pensado" pero no los veo muy lógicos.

(1)En cuanto a los puntos de "necesidades" de verdad que los veo orreales, por no decir rayando lo absurdo. Una aplicación móvil (pienso en tablet o smartphones -diferente es un ordenador móvil-) está pensada para ser un "cliente", pero no para contener una Base de Datos de 1 millón de registros; No me he equivocado, he dicho 1 millón, ya no te digo si hablamos de 100 millones.
No se si te va a caber, si la va a poder cargar, si la va a poder mover o si la va a poder consultar,... De todas ellas tengo grandes dudas.
Y aun así, si pudiera hacerlo (todas las operaciones) dudo más que sea correcto.

La única solución que le veo es la base de datos en el servidor y acceder a ella desde los dispositivos móviles (que para eso son dispositivos móviles) y consultarla. Pero resulta que son dispositivos móviles "sin movilidad" (= sin conexión). Otro despropósito.

Vuelvo a decir que no conozco el problema y tal vez esto sea la única solución, pero me cuesta mucho creerlo.

(2) Luego viene la solución... (agárrate los gallumbos!!)
=> Que los 500 trabajadores cada mañana se descarguen a los dispositivos móviles la Base de Datos de 100 millones de registros.
Al "lumbreras" que se le haya ocurrido esto (lo siento por si ha sido a tí -espero que no-) tenéis que hacerle empleado del mes. ¡Qué digo! del mes, ¡Empleado del año! Subirle el sueldo y ponerle coche de empresa!
¿De verdad que váis a copiar en los 500 dispositivos la BD? ¿Cuanto espacio es eso? ¿Cuanto tardaríais en hacer la copia? ¿Tendréis que parar el servidor? ¿Posibilidad de que se copie con errores? Sin hablar de que durante el día seguiría desactualizada...
¿Copiarís los 500 uno detrás de otro (el primero empieza a las 4 de la mañana y el último acaba a las 12 la copia)?
¿Los 500 a la vez?
¿Alguna de estas cosas la ha pensado el "lumbreras"?

Perdona que me lo tome un poco a cachondeo (no te ofendas), pero es que me recuerda a esas decisiones que a veces toman gente que NO TIENEN NI IDEA DE UN TEMA (sin pensar nada más y convencidos de que es la idea del siglo), en lugar de dejárselas a quien realmente sabe del tema.
Y sobre eso luego está alguien como tú, que tiene que pensar en una solución, que dado que la base es errónea va a fracasar en el 98% de los casos, y que se va a llevar las culpas por no saber hacer las cosas. Cosas "tan fáciles" como las que ha propuesto el "lumbreras".

Hablando en serio, le veo muchas "lagunas" a este plan y realmente creo que deberíais replantearoslo; O al menos si tienes algo de voz y voto, avisar de que se paren un momento a pensar antes de hacer determinadas cosas.

Un saludo.

[Neftali [Germán.Estévez]]

Empezado por mamcx

Sqlite con seguridad da la talla. Pero sigo sin ver porque hay que tener toda esa info instalada. No se podria filtrar por ruta o persona?

¿De verdad que SQLite en un Smartphone lo ves moviendo 100 millones de registros?
No quiero saber qué pasará si mientras haces la consulta te llaman...

[Casimiro Notevi]

Empezado por Neftali

No quiero saber qué pasará si mientras haces la consulta te llaman...

[[newtron]]

Yo creo que después de tu discurso el amigo darkerbyte ha dejado la informática y se está planteando dedicarse a otra cosa.

Y ya fuera de coñas yo estoy totalmente de acuerdo en que es un proyecto inviable y que tendrían que buscar otra solución.

[ecfisa]

Empezado por Neftali

¿De verdad que SQLite en un Smartphone lo ves moviendo 100 millones de registros?
No quiero saber qué pasará si mientras haces la consulta te llaman...

Claramente expuesto.

Saludos

[roman]

Bueno, la base medirá 1.2 GB aproximadamente. Será como transferir una peli al móvil cada día; tampoco es tanto tiempo

// Saludos

[Neeruu]

Y no seria mejor acceder a la base de datos por Internet?, directamente con una consulta que te traiga los datos que se necesitan el el momento....


Con esto se soluciona el tener que descargar los datos al teléfono todos los días y el gran volumen de datos en el teléfono...
También se optimizaría la velocidad de respuesta, porque si se realiza una consulta sobre la db que esta en el dispositivo móvil, con semejante cantidad de datos, dudo que el tiempo de respuesta sea aceptable...

Saluda Atte Neeruu!!!

[[AzidRain]]

Definitivamente el requerimiento es una locura y la forma de implementarlo no tiene abuela de tan mala. Hacer eso es como regresarse a la época donde no había internet. Hoy con un simple celular que tenga wifi o hasta con la lenta red 3G que tenemos en México, hace la chamba sin problema siempre y cuando la aplicación cliente este bien diseñada porque si al "lumbreras" que lo programe se le ocurre hacer un "select * from clientes" solo para presentar una interminable rejilla de registros se gana el Nobel.

La tabla es muy sencilla aunque tenga millones de registros cualquier consulta medianamente echa ocupará una fracción de segundos.

[webmasterplc]

Tambien puedes idearte que cuando este sin conexion trabaje con los datos en diferido y a penas te conectes a internet haga los cambios al servidor.

[darkerbyte]

Empezado por newtron

Yo creo que después de tu discurso el amigo darkerbyte ha dejado la informática y se está planteando dedicarse a otra cosa...

Pues por poco y me orillan al suicidio

Por supuesto que el planteamiento del problema me pareció una barbaridad. Por eso acudo a ustedes, para que con su experiencia me puedan dar alguna idea de como atacar el problema de la empresa. Voy a ser mas claro en relación el problema.

La oficina de tránsito vehicular nacional quiere implementar una solución para dar a todos los policias de tránsito vehicular que andan en patrullas, en carretera.

Hace uno o dos años implementaron un sistema y les dieron a los oficiales unas tablets con un sistema que se conecta via internet a una base de datos donde el agente, utilizando el numero de placa podia:
1. Ver si el vehiculo tiene estado de robo
2. Ver si el vehiculo tiene alguna infracción
3. Ver si el vehiculo esta al corriente con sus pagos.

Pero la solución nunca funcionó y la inversión fue un total desperdicio porque en nuestro país generalmente no hay cobertura de red en la mayoria de las carreteras. Que decir de conexión 3G o LTE!

Despues del fracaso de este proyecto la oficina regresó a operar "a la antigua" El policia tiene que comunicarse por radio a la oficina y esperar a que algun agente de oficina conteste, haga la investigación del vehiculo y le confirme el estado del vehiculo. Esto significa mucha perdida de tiempo para los oficiales y para los conductores que generalmente se molestan por el tiempo que tardan en verificar el estado de su vehiculo.

Lo que me pidieron es si hay la manera de que cada oficial lleve una copia del sistema para que la consulta de la información la puedan hacer en el momento sin depender de la red ni de algun servicio remoto. (de hecho tambien me piden si se puede dotar al oficial con algun sistema de reconocimiento de placas para que no necesite estar capturando manualmente el numero de placa)

La idea para hacer mas liviano el sistema es solo indicar en la tabla el estado del vehiculo "reporte de robo, infracciones, pagos al corriente" en caso de que el vehiculo este "limpio" dejar marchar al ciudadano sin hacer perder mas tiempo. Si el vehiulo presenta alguna situacion de estas entonces ya se hace la llamada a oficina para solicitar todos los datos del vehiculo y hacer una inspeccion mas detallada, pero ya con causa justificada.

Lo que yo pense es que tal vez podriamos generar una base de datos de solo los vehiculos que si tienen alguna situación, de esta manera pienso yo que se rediciría el numero de registros a la cuarta parte. Y ya en oficina el servidor cada noche podría esta generarndo en modo bacth la base de datos a ser distribuida.

He echo mas investigación y en total serian unos 25 millones de registros (bueno antes eran 100) de ahi supongamos que la BD llegue a tener unos 10 millones de registros por vehiculos con alguna situación. Creen que 10 millones pueda ser posible??? Ademas no necesariamente seria una smarthphone

Empezado por Neftali

¿De verdad que SQLite en un Smartphone lo ves moviendo 100 millones de registros?
No quiero saber qué pasará si mientras haces la consulta te llaman...

Mi estimado Neftali, el equipo sera destinado exclsivamente para el sistema. De echo el problema es precisamente que no hay cobertura, asi que no creo que le entren llamadas
Otra vez, el problema es que la infraestructura de comunicaciones en mi país aun no esta bien desarollada.

Lo que quiero es poder decir a la oficina "Definitivamente es inviable" pero hasta agotar todos los recursos

[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.

[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.

[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?

[Casimiro Notevi]

Empezado por darkerbyte

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?

No tiene nada que ver.

[Casimiro Notevi]

Me explico:

Sería muy simple hacer un simple sql: "select campo1,campo2,campo3,campo4 from tabla where matricula=?"
Para ello sobra cualquier tablet o smartphone, por muy malo que sea, ya que el esfuerzo del servidor es mínimo y el ancho de banda de la red también es minúscula.

El problema es querer pasar la base de datos completa a cada terminal (tablet o smartphone), es lo mismo mil megas que ochocientos megas, es la misma burrada. No es la solución.
Otra cosa que puedes hacer es guardar en una tabla aparte cada cambio en la principal, ahí irían las altas, bajas, modificaciones. Y serían solamente esos registros los que se pasaran a los terminales. Comprimidos en un zip, mediante FTP, por ejemplo, quedarían en poco cosa.
Peeeeero.... si el problema es que hay mala cobertura para hacer lo primero, ¿acaso hay buena cobertura para actualizar la base de datos todos los días, de todos los terminales?

La solución es ampliar decentemente la cobertura de telefonía, nada más. Todo lo demás es una chapuza que no soluciona realmente el problema, solamente lo desvía, da rodeos para intentar solucionarlo, pero lo único que consigue es crear nuevos problemas.

[Casimiro Notevi]

Por cierto, me ha recordado la historia del sultán de algún lugar de África que visitó USA y quedó impresionado por la silla eléctrica para ejecutar a reos condenados a morir.
Encargó una silla eléctrica de esas para llevársela a su país, una vez allí, los técnicos la instalaron y se encontraron con un problema: olvidaron que en ese país todavía no tenían electricidad.

[roman]

Empezado por Casimiro Notevi

El problema es querer pasar la base de datos completa a cada terminal (tablet o smartphone), es lo mismo mil megas que ochocientos megas, es la misma burrada. No es la solución.
Otra cosa que puedes hacer es guardar en una tabla aparte cada cambio en la principal, ahí irían las altas, bajas, modificaciones. Y serían solamente esos registros los que se pasaran a los terminales. Comprimidos en un zip, mediante FTP, por ejemplo, quedarían en poco cosa.
Peeeeero.... si el problema es que hay mala cobertura para hacer lo primero, ¿acaso hay buena cobertura para actualizar la base de datos todos los días, de todos los terminales?

La solución es ampliar decentemente la cobertura de telefonía, nada más. Todo lo demás es una chapuza que no soluciona realmente el problema, solamente lo desvía, da rodeos para intentar solucionarlo, pero lo único que consigue es crear nuevos problemas.

En mi opinión están satanizando en forma algo desmedida. Ya se explicó con claridad cuál es la limitación y a mi me suena bastante razonable: no hay cobertura en el camino y extenderla, no depende, desde luego, de ellos. Por las mañanas, en la central, sí hay cobertura y se carga la base o las actualizaciones.

Vamos, que para el problema planteado no me parece descabellada la solución.

Por otra parte, no sé cómo funciona el Delphi para programación de móviles pero, ¿no se supone que los ClientDataSets cubrían precisamente estas necesidades de trabajar sin conexión y actualizarse a demanda? ¿No hay algo similar para móviles?

// Saludos