Filisofía en Bases de datos, peticiones, multiples tareas y la vida... PSOE y elecciones en España.
Esto serà un post sobre "Filosofía" sobre un problema real de motores SQL y relacionado con que este domingo estaré como Interventor y Votante en las elecciones de España...
Intentaré poner unas pocas ideas claras, porque lo relacionado con filosofía da para escribir biblias..............
En la última semana estamos hablando con un colego sobre los tiempos de respuesta de un motor SQL en determinados querys.
* A veces menos de un segundo, a veces 80 segundos o más.
* Un cliente pide que "garanticemos" el tiempo de respuesta, garantías? como? cuando? en que condiciones ?
* un motor SQL recibe 30.000 peticiones (querys) por segundo, cuanto demorará en resolver cada una ? puedo garantiazar que "todas" serán resueltas en menos de un segundo?
* no, porque nadie lo sabe... ni siquiera quien programó el propio motor...
* porqué ? porque un motor SQL, es una caja negra, donde llegan (en nuestro caso) 30.000 peticiones por segundo, que el motor intenta resolver de la "mejor manera que cree", aprovechando los recursos con que cuenta (ram, disco, red, cpu, caches), sin cometer errores, manteniendo una coherencia e integridad en los datos y además de todo, ¿ en menos de un segundo ?
* además tenemos varios factores que alteran el ecosistema: simultáneidad, peticiones largas/raras/mal hechas, agentes externos Y ADEMAS "lo desconocido".
***** Una cosa es suponer cuanto tiempo demorará un motor en resolver algo y otra cosa diferente es poder "garantizarlo".
PARA ver un caso real de la vida real, supongamos que alguien pregunta un expediente en un Ayuntamiento para "algo" (como ejemplo), el ente indica una fecha "tentativa" para resolver su petición, basada en estadísticas de años anteriores, basada en ojo de la mesa de entradas, en el ojo de "Informes"... pero garantías no dan.
* Porque ? porque en un trámite donde intervienen varias personas, procedimientos, métodos, verificaciones, ordenadores y otros factores, alguna parte puede tener vacaciones, otra puede tener un accidente (ojalá no pase), otra puede recibir un llamado urgente del colegio de su hijo/a, otra parte tiene un virus, hay una inundación, cortes de energía....
* Ocurre que en situaciones de unos pocos segundos (lo que demora un SQL) pueden pasar tantas cosas como en varios dias en la vida real.
* Mientras que para un motor SQL, una petición debe resolverse rápidamente en menos de un segundo (sin errores), en un Ayuntamiento la petición debe resolverse en unos dias/semanas y se aceptan errores. Que luego se arreglarán pidiendo cita nuevamente.
RESÚMEN, es bastante complicado garantizar el tiempo de resolución de una petición a un SQL, aunque tengamos estadísticas, aunque tengamos un DBA experto, aunque "normalmente" demora NN segundos, porque los agentes externos pueden alterar los tiempos. Y sobretodo porque un SQL busca el bien común de una manera socialista...
SOCIALISMO
"basado en la administración de los sistemas de producción" (los de desarrollo y Pre también cuentan)
"control social por parte del Estado" (nuestro SQL central)
"reducir las diferencias económicas entre clases" (en nuestro caso, prioridades de peticiones)
"construir una sociedad sin clases" (excepto en C++ que las tienen)
"servir a la amplia población en vez de a unos cuantos" (todos los querys son iguales ante el amo SQL)
Si no me equivoco el Logo del SQL era rojo no?
Porqué en una empresa tan capitalista, se produce y anda tan bien un producto socialista ?
Intentaré poner unas pocas ideas claras, porque lo relacionado con filosofía da para escribir biblias..............
En la última semana estamos hablando con un colego sobre los tiempos de respuesta de un motor SQL en determinados querys.
* A veces menos de un segundo, a veces 80 segundos o más.
* Un cliente pide que "garanticemos" el tiempo de respuesta, garantías? como? cuando? en que condiciones ?
* un motor SQL recibe 30.000 peticiones (querys) por segundo, cuanto demorará en resolver cada una ? puedo garantiazar que "todas" serán resueltas en menos de un segundo?
* no, porque nadie lo sabe... ni siquiera quien programó el propio motor...
* porqué ? porque un motor SQL, es una caja negra, donde llegan (en nuestro caso) 30.000 peticiones por segundo, que el motor intenta resolver de la "mejor manera que cree", aprovechando los recursos con que cuenta (ram, disco, red, cpu, caches), sin cometer errores, manteniendo una coherencia e integridad en los datos y además de todo, ¿ en menos de un segundo ?
* además tenemos varios factores que alteran el ecosistema: simultáneidad, peticiones largas/raras/mal hechas, agentes externos Y ADEMAS "lo desconocido".
***** Una cosa es suponer cuanto tiempo demorará un motor en resolver algo y otra cosa diferente es poder "garantizarlo".
PARA ver un caso real de la vida real, supongamos que alguien pregunta un expediente en un Ayuntamiento para "algo" (como ejemplo), el ente indica una fecha "tentativa" para resolver su petición, basada en estadísticas de años anteriores, basada en ojo de la mesa de entradas, en el ojo de "Informes"... pero garantías no dan.
* Porque ? porque en un trámite donde intervienen varias personas, procedimientos, métodos, verificaciones, ordenadores y otros factores, alguna parte puede tener vacaciones, otra puede tener un accidente (ojalá no pase), otra puede recibir un llamado urgente del colegio de su hijo/a, otra parte tiene un virus, hay una inundación, cortes de energía....
* Ocurre que en situaciones de unos pocos segundos (lo que demora un SQL) pueden pasar tantas cosas como en varios dias en la vida real.
* Mientras que para un motor SQL, una petición debe resolverse rápidamente en menos de un segundo (sin errores), en un Ayuntamiento la petición debe resolverse en unos dias/semanas y se aceptan errores. Que luego se arreglarán pidiendo cita nuevamente.
RESÚMEN, es bastante complicado garantizar el tiempo de resolución de una petición a un SQL, aunque tengamos estadísticas, aunque tengamos un DBA experto, aunque "normalmente" demora NN segundos, porque los agentes externos pueden alterar los tiempos. Y sobretodo porque un SQL busca el bien común de una manera socialista...
SOCIALISMO
"basado en la administración de los sistemas de producción" (los de desarrollo y Pre también cuentan)
"control social por parte del Estado" (nuestro SQL central)
"reducir las diferencias económicas entre clases" (en nuestro caso, prioridades de peticiones)
"construir una sociedad sin clases" (excepto en C++ que las tienen)
"servir a la amplia población en vez de a unos cuantos" (todos los querys son iguales ante el amo SQL)
Si no me equivoco el Logo del SQL era rojo no?
Porqué en una empresa tan capitalista, se produce y anda tan bien un producto socialista ?
Comentarios