Esto va ha ser muy muy duro.
ammgroup
ammgroup en arrakis.es
Mar Jul 22 00:35:34 CEST 2003
Genial.
Muchas gracias.
Francamente se optimiza el tiempo, casi pillo a access.
Miraré lo de las Pytables.
En Sqlite lo tengo casi listo, pero me da un error al declarar el
cursor.
----- Mensaje Original -----
Remitente: "Ernesto Revilla" <aerd en retemail.es>
Fecha: Lunes, Julio 21, 2003 8:39 pm
Asunto: Re: [Python-es] Esto va ha ser muy muy duro.
> Buneas,
>
> >Ya se sabe, es duro empezar de nuevo.
> >Pretendo migrar de Windows + Visual Basic + Access a Todo +
> Python +
> >Todo
> Que te sea leve. La sensación será del cambio de una jaula de oro
> (falsificado) contra la absoluta libertad, que es inicialmente
> algo más
> trabajoso, pero de da posibilidades prácticamente ilimitadas,
> especialmenteen el ámbito de Internet.
>
> ...DAO vs. mxODBC
>
> >He realizado el mismo ejemplo en Visual Basic y aquí pasa algo.
> >Si tratamos los insert mediante comandos SQL mx supera a VB "Genial",
> >pero en el apartado DAO mientras con Python he tardado en meter 1000
> >registros 9 segundos en VB sólo he tardado 0.5 segundos.
> Sí, esto se debe a que la maquinaria de Python.Com realiza una
> serie de
> validaciones.
> Vemos algunos ejemplos:
>
> Ejemplo 1:
>
> from win32com.client import Dispatch
> e=Dispatch("DAO.DBEngine.35")
> db=e.OpenDatabase("c:/kk.mdb")
> rs=db.OpenRecordset("SELECT * FROM kk")
> from time import time
> t=time()
> for i in range(100000):
> rs.AddNew()
> rs.Fields("Id").Value=i
> rs.Fields("Nombre").Value="kkkkkk"
> rs.Update()
> print "tiempo: %s" % (time()-t)
> db.Close()
>
> 100.000 registros: aprox. 46s
> El acceso a rs.Fields es muy costoso. También desde VisualBasic
> (rs.Fields("NombreCampo")). Con rs!NombreCampo se realiza un
> "EarlyBinding",por lo que se optimiza el acceso.
>
> Ejemplo2: Optimizamos el acceso a rs.Fields:
>
> from win32com.client import Dispatch
> e=Dispatch("DAO.DBEngine.35")
> db=e.OpenDatabase("c:/kk.mdb")
> rs=db.OpenRecordset("SELECT * FROM kk")
> from time import time
> flds=rs.Fields # atencion a esto
> t=time()
> for i in range(100000):
> rs.AddNew()
> flds("Id").Value=i # acceso ahora mediante flds
> flds("Nombre").Value="kkkkkk"
> rs.Update()
> print "tiempo: %s" % (time()-t)
> db.Close()
>
> 100.000 registros, aprox. 30s: No está mal, nos ahoramos 16 segundos.
>
> Sin embargo podemos ligar directamente los campos a una variable,
> como lo
> hace Access / VisualBasic internamente:
>
> from win32com.client import Dispatch
> e=Dispatch("DAO.DBEngine.35")
> db=e.OpenDatabase("c:/kk.mdb")
> rs=db.OpenRecordset("SELECT * FROM kk")
> from time import time
> flds=rs.Fields
> id,nombre=flds("Id"),flds("Nombre") # ligamos directamente
> t=time()
> for i in range(100000):
> rs.AddNew()
> id.Value,nombre.Value=i,"kkkkkk" # acceso directo a los campos
> rs.Update()
> print "tiempo: %s" % (time()-t)
> db.Close()
>
> 100.000 registros: aprox: 12s. No está nada mal, hemos reducido
> de los 46
> iniciales a 12, casi una cuarta parte.
>
> Optimizando el acceso a los métodos (rs.AddNew y rs.Update), se
> obtiene una
> ligera mejora de medio segundo. Creo que no merece la pena.
>
> He probado esto también con transacción pero no mejora. Python.Com
> realizadetrás de los escenarios conversiones y validaciones y
> quizá no se pueda
> mejorar estos tiempos sustancialmente. El mismo ejemplo me tarda desde
> Access unos 6 segundos.
>
> >Bajo estas condiciones no puedo sustituir mis sistemas en VB + access
> >por otro más lento. Necesito que al menos sea igual de eficiente.
> Ahora bien, no creo que sea muy habitual que tengas que insertar
> 100.000registros. Más bien, tienes que leer. Si son aplicaciones
> de gestión, puede
> haber menos del 5% de sentencias de actualización. Se realizan
> constamentebúsquedas.Existe una función GetRows que es
> increíblemente rápida en obtener
> datos, pero devuelve el resultado un array[columna][fila] (justo
> al revés de
> lo convencional) y que tienes que dimensionar si los resultados
> son grandes.
>
> Si utilizas Postgres, que es más lento porque es más completo,
> existe un
> método para realizar una inserción rápida (sin comprobación de
> datos) que es
> sustancialmente más rápido que muchos INSERTs, pero sigue siendo
> aprox 3
> veces más lento que Access. (Access es realmente muy rápida,
> especialmentecon pocos clientes. Con unos cuantos clientes en red
> (10), se empieza a
> ralentizar considerablemente.)
>
> >Si alguien tiene programas de test de rendimiento de bases de datos,
> >pede echarme una mano ?. Con qué otra base de datos puedo mejorar
> estos>rendimientos. Sobre todo teniendo en cuenta que puede que
> tenga de ser
> >instalada en Windows 98 de forma local, es decir; nada de
> servidores de
> >datos.
>
> Estos rendimientos son normalmente suficientes para hacer
> aplicaciones de
> gestión, a excepción de aplicaciones OLAP donde necesitas bastante
> rendimiento para el análisis de datos. En este caso, quizá sea
> mejor usar
> PyTables (como propone Francesc). Puedes probar SQLite, que yo
> todavía no he
> probado.
>
> >Mis aplicaciones necesitan un acceso a base de datos muy, pero
> que muy
> >rápido y poder trabajar con millones de registros.
>
> ¿Sin servidor de base de datos? ¿Mono-puesto? ¿A qué se van a
> dedicar estas
> aplicaciones?
>
> Erny
>
>
> _______________________________________________
> Python-es mailing list
> Python-es en aditel.org
> http://listas.aditel.org/listinfo/python-es
>
Más información sobre la lista de distribución Python-es