- Se incorporó
- 15 Enero 2004
- Mensajes
- 11.872
Estos temas los puedo desclasificar ahora que ya no trabajo ahí...
En los locos años 2006, para una de las patas de la solución del Transantiago se contrató a una empresa de desarrollo brasileña que había hecho un sistema de posicionamiento de buses en su ciudad.
El software trabajaba más o menos así: cada x minutos el bus transmitía a un servidor central su código de bus, la hora y la posición (pónganle que son dos coordenada numérica, para el caso da lo mismo) y una aplicación central lee esos registros y te va "dibujando" la ruta del bus en una pantalla.
Estos tipos habían desarrollado el sistema en su ciudad basados en MySql (si, un mysql 4 del año de la corneta) y las bases pedían que lo hicieran en Oracle. Tenían el know how y a pesar de que nunca habían trabajado con bases de datos Oracle, el sql ansi permitía que las mismas instrucciones sql les sirvieran en MySql y en Oracle.
Como yo tuve que ir a instalarles Oracle en los servidores de prueba y desarrollo estuve en las reuniones de coordinación y acá viene lo interesante: como los registros eran TAAAAANTOS, para hacer las lecturas más rápidas estos tipos habían partido la tabla de posiciones en ¡¡¡365 TABLAS!!!
No recuerdo el nombre de la tabla de posiciones así que supongamos que se llama POSICIONAMIENTO. Ya, estos tipos habían creado 365 tablas
POSICIONAMIENTO0101
POSICIONAMIENTO0102
POSICIONAMIENTO0103
..
..
POSICIONAMIENTO1229
POSICIONAMIENTO1230
POSICIONAMIENTO1231
(si amigos, la mansa paja)
¿Por qué eso? Porque como los datos eran tantos, aún cuando estuviera todo bien indexado la consulta se demoraba mucho si era una tabla única, así que estos tipos crearon 365 tablas y el código de la aplicación decidía en qué tabla guardar el registro. Si amigo desarrollador o amigo DBA, era una solución muy sconf.
En una de las reuniones de coordinación uno de los DBA Oracle se entera de eso y les dice
"Compadrito, esa huea en Oracle se soluciona con PARTICIONAMIENTO de la tabla POSICIONAMIENTO"
y los brasileños onda
y los DBAs les explicaron en qué consistía el particionamiento:
A grosso modo. divides físicamente una tabla en varios segmentos por algún criterio: día, mes, un número, etc.
- La idea es que los segmentos tengan más o menos la misma cantidad de registros para que la división tenga sentido.
- El otro dato a considerar es que el criterio para partir la tabla deba ser fijo, onda que no lo cambies. Una vez que un registro se insertó quedó para siempre en esa partición (creo que Oracle en sus últimas versiones permite mover registros entre particiones).
- Esto es transparente para la aplicación.
- Cuando haces una consulta, el motor de base de datos solito sabe a qué partición tiene que ir a buscar el registro solicitado.
A los desarrolladores brasileños se les explicó que al momento de crear la tabla se particionaba por día y en su código no tenían que hacer nada raro, simplemente llamar a la tabla POSICIONAMIENTO a secas para insertar y seleccionar.
"Pero la tabla tiene chillones de registros, los selects van a tardar mucho"
"Usted calmao compadrito, que si usted hace un select con where dia = 26 de enero, el motor de Oracle internamente va a buscar los registros solamente en el segmento físico correspondiente a la partición del 26 de enero"
También el @galansinchance me pidió una vez que le de una mano con reportería de un sistema basado en MySql así que saqué la vieja confiable del particionamiento y paff, mejora de rendimiento al toque.
En los locos años 2006, para una de las patas de la solución del Transantiago se contrató a una empresa de desarrollo brasileña que había hecho un sistema de posicionamiento de buses en su ciudad.
El software trabajaba más o menos así: cada x minutos el bus transmitía a un servidor central su código de bus, la hora y la posición (pónganle que son dos coordenada numérica, para el caso da lo mismo) y una aplicación central lee esos registros y te va "dibujando" la ruta del bus en una pantalla.
Estos tipos habían desarrollado el sistema en su ciudad basados en MySql (si, un mysql 4 del año de la corneta) y las bases pedían que lo hicieran en Oracle. Tenían el know how y a pesar de que nunca habían trabajado con bases de datos Oracle, el sql ansi permitía que las mismas instrucciones sql les sirvieran en MySql y en Oracle.
Como yo tuve que ir a instalarles Oracle en los servidores de prueba y desarrollo estuve en las reuniones de coordinación y acá viene lo interesante: como los registros eran TAAAAANTOS, para hacer las lecturas más rápidas estos tipos habían partido la tabla de posiciones en ¡¡¡365 TABLAS!!!
No recuerdo el nombre de la tabla de posiciones así que supongamos que se llama POSICIONAMIENTO. Ya, estos tipos habían creado 365 tablas
POSICIONAMIENTO0101
POSICIONAMIENTO0102
POSICIONAMIENTO0103
..
..
POSICIONAMIENTO1229
POSICIONAMIENTO1230
POSICIONAMIENTO1231
(si amigos, la mansa paja)
¿Por qué eso? Porque como los datos eran tantos, aún cuando estuviera todo bien indexado la consulta se demoraba mucho si era una tabla única, así que estos tipos crearon 365 tablas y el código de la aplicación decidía en qué tabla guardar el registro. Si amigo desarrollador o amigo DBA, era una solución muy sconf.
En una de las reuniones de coordinación uno de los DBA Oracle se entera de eso y les dice
"Compadrito, esa huea en Oracle se soluciona con PARTICIONAMIENTO de la tabla POSICIONAMIENTO"
y los brasileños onda
y los DBAs les explicaron en qué consistía el particionamiento:
A grosso modo. divides físicamente una tabla en varios segmentos por algún criterio: día, mes, un número, etc.
- La idea es que los segmentos tengan más o menos la misma cantidad de registros para que la división tenga sentido.
- El otro dato a considerar es que el criterio para partir la tabla deba ser fijo, onda que no lo cambies. Una vez que un registro se insertó quedó para siempre en esa partición (creo que Oracle en sus últimas versiones permite mover registros entre particiones).
- Esto es transparente para la aplicación.
- Cuando haces una consulta, el motor de base de datos solito sabe a qué partición tiene que ir a buscar el registro solicitado.
A los desarrolladores brasileños se les explicó que al momento de crear la tabla se particionaba por día y en su código no tenían que hacer nada raro, simplemente llamar a la tabla POSICIONAMIENTO a secas para insertar y seleccionar.
"Pero la tabla tiene chillones de registros, los selects van a tardar mucho"
"Usted calmao compadrito, que si usted hace un select con where dia = 26 de enero, el motor de Oracle internamente va a buscar los registros solamente en el segmento físico correspondiente a la partición del 26 de enero"
También el @galansinchance me pidió una vez que le de una mano con reportería de un sistema basado en MySql así que saqué la vieja confiable del particionamiento y paff, mejora de rendimiento al toque.
