Manejar cien millones de registros

[Casimiro Notevi]

Bueno, si lo actualizan en la central, copiando la BD en cada terminal, entonces no hay nada que hablar, ni cobertura, ni actualizaciones, ni nada de nada.

[roman]

¿Por qué no actualizaciones? Me parece que lo que plantea juanelo es adecuado. Digo, si se pueden evitar copiar toda la base cada día pues es un buen ahorro.

// Saludos

[Casimiro Notevi]

Empezado por roman

¿Por qué no actualizaciones? Me parece que lo que plantea juanelo es adecuado. Digo, si se pueden evitar copiar toda la base cada día pues es un buen ahorro.
// Saludos

Porque no tienen cobertura, creo haber entendido que ese es el problema.

[balapro]

Hola, te voy a dar un punto de vista a nivel telecomunicación y no programación, que ocupa gran parte de tu proyecto.

Hoy en día se le complica mas a un programador que a los clientes / vendedores en tu caso que usen el sistema, lo cual por lógica siempre se tiene que buscar algo estable y funcional.

Si desarrollas un softwares, donde tengas esa cantidad de información y una cantidad X de personas, lo mas sencillo y fácil es desarrollar una aplicación web 100% ejecutada, con una buena optimización en los algoritmos de querys especialmente, donde seas puntual en la búsqueda y no tenga que consultar toda la tabla completa para traer la información, para así evitar sobrecargar el teléfono y realizar una operación mas rápida.

Imagínate estar actualizando a cada rato una base de datos en cada equipos, en 500 clientes, tenes un margen muy grande de que si el cliente, le funciona mal el equipo tanto sea telefono/notebook/netbook/table o de CPU de escritorio, la función estaría en optimizar.

Como te contaba te recomiendo trabajar todo a nivel web, ya que te tenes que preocupar solamente por el servidor y la estabilidad web, el resto, si el teléfono no funciona, la notebook/netbook/tables o equipo tiene un virus o no deja ejecutar algo, es problema del cliente no tuyo (un problemilla meno).

Cosas a tener cuenta, toda base de datos SQL y especialmente para poder optimizar una base de datos, no voy a dar 100% detalle técnicos para no hacer largo el post, pero para funcionar óptimamente tenes que tener en cuenta que gran parte de la funcionalidad te lo hace el mecanismo del disco, mas en tu caso, por mi experiencia, tengo servidores de juego en los cuales, la base de datos esta actualmente almacenando y leyendo pequeñas cantidad de bytes aproximadamente entre 8 a 16 bytes = 64 bits a 128 bits (el consumo de red), lo cual el softwares hace muchas consultas por segundos, y en cual me fueron eficaces los disco duros SAS 15K RPM.

La pregunta que muchos se harán.

Porque un disco SAS 15k RPM es mas rápido que un disco solido(SSD)???, cuando los disco sólidos son los mas rápido en transferir información.

Correctamente, los disco sólidos(SSD), transfieren a una taza increíbles, siempre cuando hablemos de archivos grandes, tiene la ventaja de poder transferir hasta 120 Mb/s de lecturar y 90 Mb/s de escritura en el, pero tiene una desventaja cuando se trata de escribir y leer archivos pequeños, su lentitud es increíble, demora hasta 3 veces mas que un disco duro SAS de 15k RPM, esto me ocasionaba un dolor de cabeza, ya que la mitad de las veces se me caían las aplicaciones porque no podían procesar bien la lectura y almacenamiento de información, Espero que en el futuro arreglen eso en los SSD, porque seria genial.

Unas de las ventajas del disco SAS.

Al fusionar el rendimiento y la fiabilidad de la interfaz serie con los entornos SCSI existentes, SAS aporta mayor libertad a las soluciones de almacenamiento sin perder la base tradicional sobre la que se construyó el almacenamiento para empresas, otorgando las siguientes características:
Acelera el rendimiento del almacenamiento en comparación con la tecnología SCSI paralela
Garantiza la integridad de los datos
Protege las inversiones en TI

Los discos duros cuentan con características que son comunes y que a continuación se detallan:

RPM SAS: Significa "Revolutions per Minute" ó vueltas por minuto. Este valor determina la velocidad a la que los discos internos giran cada minuto. Su unidad de medida es: revoluciones por minuto (RPM). Este dato puede ser 7,200 RPM, 10,000 RPM hasta 15,000 RPM.

- Ejemplo: Disco duro SAS tiene dentro de sus características lo siguiente: Marca HP®, 600 GB, 2.5 Inch, Hot Plug, 6G, SAS, 10K RPM*. * Este dato indica que el su eje de giro permite hasta 10,000 vueltas por minuto.

Pulgadas SAS: se refiere al formato de tamaño de la unidad, esta puede ser de 3.5" (LFF) ó de 2.5" (SFF).

- Ejemplo: Disco duro SAS tiene dentro de sus características lo siguiente: Marca HP®, 600 GB, SFF 2.5 Inch*, Hot Plug, 6G, SAS, 10K RPM. * Este dato indica que el tamaño de disco es de 2.5 pulgadas (2.5")

Capacidades de almacenamiento SAS: Es el total de Bytes ó símbolos que es capaz de almacenar un disco duro. Su unidad de medida es el Byte, pero actualmente se utilizan medidas como el GigaByte (GB) y el TeraByte (TB). Para discos duros SAS este dato puede estar entre 72 GigaBytes (GB) hasta 2 TeraBytes (TB).

- Ejemplo: Un disco duro SAS tiene dentro de sus características lo siguiente: Marca HP®, 600 GB*, SFF 2.5 Inch, Hot Plug, 6G, SAS, 10K RPM. * Este dato indica puede almacenar hasta 18 GigaBytes de datos.

Usos específicos del disco duro SAS
1.- Se utilizan principalmente para el almacenamiento de los sistemas operativos de red (Microsoft Server 2009, plataforma Linux Apache) y para servidores de grandes empresas.

2.- También un uso muy frecuente es el de guardar la información de usuarios en grandes empresas, en el ambiente doméstico no se utilizan.

Y obviamente..... acompáñalo por un buen servidor Intel XEON(Dedicado DELL o HP), si es por seguridad y backups algún RAID de tu gusto como RAID-1 RAID-10, etc.

Comunicación del servidor con el cliente.

Ahora, ya que logramos comprendes las estabilidad y funcionalidad de la bases de datos, ya que tu programa va a ser transferido vía internet, necesitas saber tu posición geográfica, saber el consumo y gran parte el tracert(ruta donde viaja la información), para poder elegir un servidor estable y sin delay, revisar bien el peering de la conexión) no es lo mismo que tu información valla a EEUU con un Ping de 150 ms, pasando por 5 nodos centrales, a que lo tengas locamente con 25/40 ms y pasando por 1 a 2 nodos de tu país.

El cliente, con simplemente Internet, sea tanto GPRS/3G/4G, no debería tener ningún tipo de problema, ya que aclaraste que tenes problema con esto, diste a entender que los sistema de telefonía son inestable, pero si optimizas que sea pequeño el consumo del Internet al realizar la operación, esto te puede ayudar mucho.

Bueno, este fue mi opinión a conocimiento previos y experiencias sucedidas.

Saludos

[Casimiro Notevi]

Empezado por balapro

...

Bienvenido a clubdelphi, ¿ya leiste nuestra guía de estilo?, gracias por tu colaboración

[balapro]

No, a leer se ha dicho.

Gracias.

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

Empezado por darkerbyte

Mi estimado Neftali, el equipo sera destinado exclusivamente 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

Gracias por la explicación Darkerbyte. Bueno así se aclaran un poco más ñas cosas, y algunas cosas que antes parecían no tener sentido, ahora al menos tienen una razón de ser (como el tema de la cobertura).
Ahora conociendo el problema es cuestión de "afinar" la solución.

[ASAPLTDA]

1. Descargar la base de datos 1 sola vez o por demanda conectado a internet en coneccion rapida
1.1 programar grupo de usuarios en un periodo de tiempo determinado
2. Descargar unicamente los cambios a la base de datos que realicen despues de la hora 0 (cargar Inicial)
2.1 De que numero de registros hablamos ?
3. trabajar offline

[mamcx]

Empezado por darkerbyte

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)

Mira un test (en python)

http://repl.it/Py1

De hecho mi tabla era:

Código SQL [-]
CREATE TABLE test
    (
        Id integer PRIMARY KEY AUTOINCREMENT,
        name TEXT,
        Value INTEGER
    );

Que es menos campos. Ten en cuenta que sqlite solo tiene 2 tipos de datos: INT/VARCHAR.

----

Tal vez es hora de pensar en algo diferente a una BD normal.

Me acorde de los bitarray:
http://stackoverflow.com/questions/1...rray-in-python

Usando un test rapido en python:

Código PHP:

>>> from bitarray import bitarray
>>> a = bitarray(1000*1000*1000)
>>> with open('somefile.bin', 'wb') as fh:
...     a.tofile(fh)
... 
>>> exit() 


El archivo queda pesando 125 MB. Esto es porque un BITMAP/BITARRAY almacena BITS, no BYTES.


Ahora, como carajos se usa eso? Un ejemplo completo (esto es usando REDIS, pero el concepto es general):

http://amix.dk/blog/post/19714
http://blog.getspool.com/2011/11/29/...redis-bitmaps/

[Casimiro Notevi]

[off topic]
Hubo una época en la que para ahorrar memoria los campos si/no (1/0) los manejábamos en bits, así que con un solo byte teníamos 8 campos.
Eso sí que era afinar y ahorrar
[/off topic]

[mamcx]

Que rayos, me pico la curiosidad como resolver esto, y creo que le pegue (NOTA advierto que para algoritmos raros no soy como seoane).

El truco es dejar de pensar en una BD relacional y usar mejor una BD LLave=Valor (NOSQL).

Al usar un BITARRAY, lo que se indica es que el BIT en la posicion X es 1 o 0. Ahora la trampa: Para indicar la posicion hasheo una cadena tipo "IDENTIFICADOR-CATEGORIA" en el caso de que sea True (porque si es falso es redundante setear la posicion!).

Asi que si para buscar el valor, se vuelve a hashear y se mira si en esa posicion esta True. Fin.

Código PHP:

# -*- coding: utf-8 -*-
import random
import string
import os

import mmh3
from bitarray import bitarray

#Las posiciones son hash int32. Crear un bitarray del max de INT32
db = bitarray(2147483647)


# Generar un hash int32. Esta sera la posicion en la BD
def asInt32(key, value):
    return mmh3.hash("%s-%s" % (key, value))


# Solo importa si hay problemas.
def saveRecord(key, tieneMulta, tienePago, tieneRobo):
    if tieneMulta:
        db[asInt32(key, 'M')] = True
    if tienePago:
        db[asInt32(key, 'P')] = True
    if tieneRobo:
        db[asInt32(key, 'R')] = True


def rand_string(size=10, chars=string.ascii_uppercase + string.digits):
    return ''.join(random.choice(chars) for _ in range(size))


# Boolean aleatorio
def ranB():
    return bool(random.getrandbits(1))


# Una fila de la BD aleatoria
def _buildDataRow():
    return dict(key=rand_string(), tieneMulta=ranB(), tienePago=ranB(), tieneRobo=ranB())


# Genera filas mediante un generador, sin cargar todo en memoria!...
def getData():
    count = 1
    for i in xrange(1, 1000 * 1000 * 10):
        count += 1

        if count >= (100 * 10000):
            count = 1
            print "%d records.." % i

        yield _buildDataRow()


if os.path.exists('somefile.bin'):
    print "Cargando archivo de datos.."
    with open('somefile.bin', 'wb') as fh:
        db.fromfile(fh)
else:
    # Llenar la BD de datos...
    print "Generando datos.."
    for row in getData():
        saveRecord(**row)
    print "Listo"


#Para encontrar el valor, solo necesito saber si en la posicion del  hash
#de la cadena esta en True
def find(key, value):
    return db[asInt32(key, value)]


# Una valor fijo pa probar
testRow = getData().next()

saveRecord(**testRow)


def searchForRow(row):
    print "Buscar un valor en la BD. Original:", row
    key = row['key']

    print "Tiene Pago?", find(key, 'P')
    print "Tiene Robo?", find(key, 'R')
    print "Tiene Multa?", find(key, 'M')

searchForRow(testRow)

#Guardemos el archivo
with open('somefile.bin', 'wb') as fh:
    db.tofile(fh) 


P.D: El archivo que esto genera es aprox 200 MB, dependiendo de cuantos valor TRUE se generen..

Junto a usar dropbox, esta el tema resuelto:

https://www.dropbox.com/developers

[darkerbyte]

Empezado por roman

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.

Roman has entendido perfectametne la situación. Los policias/oficiales o como le llamen en vuestro país tienen una oficina base donde ellos se reportan cada día. En estas oficinas si tenemos internet de banda ancha (unos 10mbps). Una vez que ellos sincronicen sus dispositivos, ellos podran salir a carretera donde no hay cobertura telefónica y por lo mismo no hay internet.

Bueno gracias al amigo mamcx ahora hay dos posibilidades para resolver el problema.

Idea #1: Cuando se compren todos los equipos cargarlos con la base de datos inicial. De ahi en lo sucesivo cada día solo ir actualizando los registros que cambiaron en la base de datos. Algo así como hacen los antivirus los cuales solo descargan y aplican las actualizaciones necesarias para las nuevas vacunas y no descargan todo el diccionario.

Claro que para esto se diseñara un sistema que este trabajando en el servidor que genere cada día las actualizaciones. Para el armado del servidor voy a solicitar tus consejos amigo balapro

Idea #2: Mamcx nos ha sugerido la idea de usar bitmaps. Aunque entiendo muy poco de eso Si me quedan claro tres cosas:

1. La base de datos reduce enormemente su tamaño, y segun las pruebas de el amigo Mamcx, a unos 200mb. Que descargandolos a una velocidad de 450kbs (en una red de 5mpbs) tardaria unos 8 minutos. Suena bastante accesible. Considerando que nuestra velocidad de banda ancha es de 10mpbs

2. Las busquedas son bastante rápidas (segun el ejemplo que nos dejo sobre REDIS y la comparación en 128 millones de usuarios)

3. Se necestaria descargar toda la base de datos para cada actualización.

La verdad es que nunca he trabajado en Phyton. ¿Phyton se puede utilizar para crear aplicaciones moviles?

Y la pregunta del millon. Ahora pensando en el servidor. ¿Que sera mas facil/rapido generar el archivo para python ó el script para actualizar la BD? Considerando que en el servidor si tendremos una BD relacional. Tal vez Oracle o algun otro monstruo.

[Casimiro Notevi]

[mamcx]

Empezado por darkerbyte

Idea #2: Mamcx nos ha sugerido la idea de usar bitmaps. Aunque entiendo muy poco de eso Si me quedan claro tres cosas:

Haz de cuenta que funciona igual que un Array, solo que unicamente acepta valores True/False:

Código Delphi [-]
datos[0]:=True;
datos[1]:=False;
datos[2]:=False;
datos[3]:=True;

Y que internamente se almacenas BITS, no BYTES, lo que hace que sea super compacto.

Lee bien los links, hay estan explicados y con graficas

Empezado por darkerbyte

3. Se necestaria descargar toda la base de datos para cada actualización.

No. Como vez en el script, es posible cargar el archivo, asignar datos y volverlo a salvar. Osea que se puede hacer los mismo que con una BD: Preguntar por los cambios desde la version X o desde la fecha X, actualizar el BITMAP y salvarlo.

Sin embargo, es posible ademas reutilizar un servicio como dropbox (que tiene SDK para usarse como libreria interna en mobiles y funciona identico), asi que si haces el archivo en el servidor, lo pones en dropbox, este lo sincronizaria entre las maquinas.

Esa es otra opcion. Probablemente para evitar lios de corrupcion, hay que chequear el SDK para recibir la notificacion de cuando termina el proceso, y mover el archivo a una ubicacion fija cuando termine

Empezado por darkerbyte

La verdad es que nunca he trabajado en Phyton. ¿Phyton se puede utilizar para crear aplicaciones moviles?

Si: http://kivy.org

Pero si vas a hacer una app por la que te pagan, es mejor usar malo conocido

(Python es muy simple en general, pero en cuanto a mobiles, son pocas las opciones maduras: El lenguaje nativo de cada plataforma es la opcion #1, luego siguen MONO, C/C++ plus Lenguaje nativo, ciertas herramientas con Lua, Delphi, etc.)

Empezado por darkerbyte

Y la pregunta del millon. Ahora pensando en el servidor. ¿Que sera mas facil/rapido generar el archivo para python ó el script para actualizar la BD? Considerando que en el servidor si tendremos una BD relacional. Tal vez Oracle o algun otro monstruo.

Usa una BD relacional. El monstruo que quieres se llama Postgres.

No solo tiene los comandos necesarios para manipular bits:

http://www.postgresql.org/docs/9.3/s...bitstring.html

Se pueden programar los procedimientos/funciones en muchos lenguajes (como python!), y por ende, se puede usar el codigo que puse de base para guardar la info en un campo BITSTRING:

http://www.postgresql.org/docs/9.3/s...atype-bit.html

O un campo binario:

http://www.postgresql.org/docs/9.3/s...pe-binary.html

P.D: Mira tambien:

http://dba.stackexchange.com/questio...sql-bit-string

Generar de forma rapida en el servidor el archivo puede requerir algo de gimnasia. Estuve mirando generar los 100 millones y realmente lento de forma sequencial. Explotando que solo importaria los datos True se puede (quizas) reducir un poco pero al final la gracia es crear un codigo que sea multi-proceso * N-Cores * N-Threads, generar (digamos) de a millon de datos en archivos y concatenar los archivos en uno solo.

[darkerbyte]

Gracias amigo mamcx, eres un maestro! Voy a meterme a estudiar bien el asunto de los bitmap.

Bueno, hay muchas cosas que se decían que eran imposibles hasta que alguien inventó la solución. Por ejemplo, todos decian que era imposible Volar.
Creo que de este problema que para muchos esta descabellado e imposible de resolver, podemos inventar una solución

[Casimiro Notevi]

Empezado por darkerbyte

Tal vez Oracle o algun otro monstruo.

No, justo lo contrario, busca algo sencillo, simple, agil, pequeño y rápido. No tiene sentido instalar, mantener y pagar por un oracle para tener una tabla con 4 campos
No se necesita un gran servidor, ni tampoco potentes "clientes", lo que necesitas es un sistema sencillo y bien afinado.... y una buena internet

[ASAPLTDA]

[QUOTE
1. La base de datos reduce enormemente su tamaño,...
2.[/quote]

Segun entiendo el problema en la noche podrias generar un una tabla con solo los cambios la cual seria descargada por todos los usuarios, para asi no no tener que generar una tabla de cambios para cada uno de los usuarios, ya que es comun a todos aquellos.

Podrias tener un log de cambios para cada fecha, ya que pasaria si un usuario no puede descargar los cambios en un par de dias

[[gatosoft]]

Hola darkerbyte,

Pensar en tener bases offline, que se sincornicen y que recidan en un dispositivo movil, no suena muy natural. suena forzado.

Y creo que de tanto enofcarse en la solución propuesta, podrías estar perdiendo de vista el problema general. El problema evidente aqui es la comunicación y deberías revisar soluciones enfocadas en ésta dirección. Aunque supongo que tu y tu patrocinador ya buscaron alternativas en éste sentido, quiero mencionarlo por si acaso:

¿El problema de cobertura en comunicación vía celular/movil se limita solo a datos?, tienes disponible SMS, o Voz Digital? En el caso de voz digital podrias porbar un sistema de audio respuesta (IVR), pos SMS hay alternativas de comunicación masiva (cuyos costos debe asumir tu sponsor).

Existe una opcion un poco mas "sofisticada" y es utilizar la transmisión de datos por radiofrecuencia No conozco bien, pero pueden hacerse adaptaciones a los dispositivos para que emitan y reciban la información transformando analogico a digital.

Han pensado en servicio de internet satelital? (Red BGAN ==> Broadband Global Area Network). Tiene como complicación que el "modem" es del tamaño de una laptop, lo cual sería irónico si lo que se queria era proporcionar una simple tablet.

No soy experto en nada de lo que propongo, solo intento mostrar que la solcuión puede estar en otro foco.

Un saludo,

[darkerbyte]

Claro que si amigo Gatosoft
Estamos buscando opciones de conectividad. Desafortunadamente por GSM/3G ninguna compaña telefonica tiene cobertua del 100% de carreteras. La mayoria de la cobertura solo es en autopistas y carreteras cercanas a la ciudad.

Estamos buscando otras opciones ya que contar con internet sería mucho mas facil que el desarollo de todo el sistema. Dado que aun no encontramos estamos considerando seriamente la opcion via software, por esto estamos estudiando la viabiliadad de este proyecto.

Un enorme agradecimiento a todos por su tiempo y consejos, en cuanto se defina algo los informaré

[kaiserilich]

Empezado por darkerbyte

Pues por poco y me orillan al suicidio...

emplea o bien un web service ó con datasnap en el que solicites la información y te regrese los datos especificos para el "coche/situación" y asi no tendras que descargar sino la información que requieras al dispositibvo movil en tiempo real y ya.