Utilizando Navicat para grandes volumenes de datos

Utilizo navicat para diferentes aplicaciones. Por ejemplo, un sistema de replicacion para alta disponibilidad de bd’s en mysql, que llega a manejar hasta 100000 registros por tabla, y se sincroniza cada hora mediante la sincronizacion de datos de navicat. Sin embargo, unos días atrás, intente hacer un sincronizador de dos tablas diferentes mediante navicat, las tablas en cuestion llegarían a tener unos 2 millones de tuplas. Supongo que me hizo falta pensar un poco al respecto… El resultado? Navicat no logra manejar esas cantidades de datos en tiempos razonables, el proceso de carga funciono bien hasta tener aproximadamente 1 millon de tuplas, en adelante los tiempos eran excesivos, puesto que tenia que traer los datos de ambos servidores, y sincronizar los datos de las dos fuentes, lo cual generalmente acababa consumiendo todos los recursos del servidor. En conclusión, ni navicat ni herramientas que repliquen mediante el método de navicat (barridos de tablas y posterior comparación) serán útiles para sincronizar grandes volúmenes de datos.

Categorías:Uncategorized

Auto_increment en Mysql. Como se comportan?

febrero 8, 2012 3 comentarios

Hace unos dias, me percate de que en una BD con varias columnas marcadas como auto_increment, los valores de estos contadores eventualmente se reiniciaban. El proceso es mas o menos asi:

 

Durante el dia, se alimenta y opera sobre una base de datos, terminando con un esquema:

Tabla A:

id               texto

1                uno

2                dos

3                tres

4                cuatro

5                 cinco

 

Al termino del dia, los datos de esta bd se copian a otra y se eliminan. El caso es que, esperabamos que en el dia dos los insert quedaran de la siguiente forma

 

6             seis

7            siete

8            ocho

 

Y lo hacían. Sin embargo, eventualmente el contador se reiniciaba a 1. Siendo un caso random, no tenia mucha explicación lógica. Hasta hoy, que consultando con el soporte de MYSQL, me explican que pasa lo siguiente con el comportamiento de los auto_increment:

 

El valor es almacenado en memoria y no en disco, por tanto, si se reinicia el servidor, regenera el valor del campo auto_increment basandose en una query de la siguiente forma:

Select max(campoincremental) from tabla

Entonces, es de suponer que si se vacian datos de la tabla, y luego se reinicia el servidor, los campos marcados como auto_increment serán reiniciados a 1.

 

Otra forma en que estos campos pueden reiniciarse es al ejecutar sentencias como

  • Alter Table.   (para versiones anteriores a 5.1.55)
  • Optimize table.  (para versiones anteriores a 5.1.55)
Debo decir también que MySQL garantiza que los campos auto_increment no se repetirán en una tabla nunca. Pero esto quiere decir que no se repetirán para dos tuplas que existan, excluyendo el caso en que la primera de ellas ha sido borrada.

En fin, esto puede afectar sistemas historicos (mi caso),  los cuales deberán ser tratados con cuidado cuando se tenga como fuente tablas con auto_increment. Incluso, muchos recomiendan no usar la funcionalidad pura de mysql, si no implementar la propia mediante tablas de secuencia. Pero eso conllevaría probablemente problemas de rendimiento, que habría que solventar en cada caso.

 

 

Categorías:Uncategorized

Conviviendo con el motor Federated de MYSQL

Para quien no conozca el motor federated de Mysql, es mas o menos lo siguiente:

Se tiene una tabla T1 en el servidor S1. En el servidor S2, se necesita “ver” los datos de la tabla T1. Si se trabaja con Mysql, se tienen dos opciones:

1. Unirlas mediante programacion

2. Crear una tabla federada en S2, apuntando hacia S1.

La tabla federada en S2, actua exactamente como si estuviese almacenada en S2, aun cuando los datos están almacenados en S1. Desde la bd en S2, es posible realizar inserts, updates y deletes con normalidad.

Por lo que he leído en otras webs, el motor Federated no es al 100% fiable, aun así, tengo que decir que tengo algunas aplicaciones utilizando este tipo de tablas, con consultas y actualizaciones realizadas varias veces por ida, y no he tenido ni un solo problema. De allí, puedo decir que quizás no sean una buena opción para aplicaciones mayores, pero en sistemas pequeños, suelen ser muy funcionales, y pueden ahorrarnos varias lineas de código en las aplicaciones.

Mas informacion sobre tablas federadas en

http://dev.mysql.com/doc/refman/5.0/es/federated-use.html

Categorías:Uncategorized Etiquetas:

Sebastian Thrun – University 2.0 – Udacity

http://new.livestream.com/channels/556/videos/112950

En el enlace, se encuentra el discurso de Sebastian Thrun en el cual reflexiona sobre los metodos utilizados por las universidades en la actualidad. En resumen, habla de sus experiencias durante el curso impartido en 2011 a través  de http://www.ai-class.com en compañía de Peter Norvig. Durante el discurso, la conclusión central es que Sebastian no encuentra como volver a dar clases para 15 o 20 personas en un salon de clases, cuando puede compartir sus conocimientos con miles y miles alrededor del mundo. Es por ello que lanza el proyecto Udacity, sitio en el cual se ofrecen de momento 2 cursos en linea:

 

Computer Science 373: Programming a Robotic Car

Computer Science 101: Building a Search Engine

 

Ambos cursos inician el 20 de febrero próximo.

Es muy interesante la propuesta. El sitio de udacity ofrece que en 7 semanas, enseñaran como programar un motor de búsqueda como google o yahoo y por el otro lado, en las mismas 7 semanas, podria aprenderse a programar todos los sistemas de un auto-robot.

Oportunidades para no dejar pasar.

Categorías:Uncategorized Etiquetas:

Lentitud en lecturas de SISS 2008

Hace algunos días, trabajando con SISS 2008, experimentaba una extrema lentitud al ejecutar un paquete de migración de datos, exactamente cuando se esta pre-ejecutando el paquete. La razón?: Los indices utilizados por el dbms al ejecutar la consulta sobre el origen de datos. Es curioso, pues la consulta ejecutada sobre la base de datos en si, devuelve resultados rápidamente, pero al ejecutar se desde siss, se toma mucho tiempo (20 o 30 minutos, mientras que ejecutada directamente son 2 minutos a lo sumo).

Conclusion: Al trabajar con siss (al menos el 2008), es completamente necesario que las consultas utilicen indices en la base de datos origen.

Categorías:Uncategorized Etiquetas: