¿Tabla que se usa mucho debería clonarse?

[mariscos_recio]

Como he estado mirando, el motor InnoDB con respecto a MyISAM solo hace un bloqueo de la fila y no de toda la tabla, lo que mejora el rendimiento para hacer más consultas simultáneamente. El problema surge cuando tienes una tabla InnoDB que es la "central", es decir, que otras tablas usan foreign key a la columna id de esa tabla central, como en esta imagen:



Es entonces cuando pienso que si afecta al rendimiento general de la base de datos(un cuello de botella producido por esperar a que la fila no este bloqueada) el tener que pedir información siempre a esa tabla central o que, especialmente, muchas consultas de la aplicación tengan que hacer muchas comparaciones con el campo id de dicha tabla central.
Es mejor duplicar esa tabla central y hacer unas consultas de comparación(por ejemplo, inicio de sesiones y todo eso)a la original y otras consultas de comparación a la otra tabla(la duplicada) para obtener el nombre del usuario cuando se requiera u otra información?(repartir en dos la carga de las consultas)

Se que si se duplica una tabla ocuparía más espacio en el disco duro pero a la hora de hacer consultas sobre mismas filas no tendría que esperar mucho(por el tema del bloqueo de fila) porque se repartiría la carga entre dos tablas...también es verdad que consumiría más CPU por lo del tema de los triggers, etc.
¿Aliviaría la carga o mejoraría el rendimiento de las consultas al hacer una duplicación con un trigger a otra tabla?

[gnzsoloyo]

Duplicar una tabla es un despropósito. Cuando tienes problemas de concurrencia, la solución no es duplicar problemas, y además agregar defectos de consistencia de datos. Ya existen soluciones para eso...
No necesitas destruir el sistema con cosas inventadas, sino mejorar los procesos y administrar esa concurrencia, para lo cual existen técnicas.
Además, el acceso no es el problema, sino el volumen de acceso, cosa que se debe analizar en el mundo real, y no en teorizaciones no fundamentadas con documentación.
Cuando hablas del impacto de concurrencia, primero debes especificar a cuánta concurrencia te refieres, y en qué sistema, con tablas de qué volumen de datos. Sin esa información, el planteo sólo se puede responder a nivel teórico, como ya mencioné.
Por lo pronto, una tabla de enormes dimensiones, para un sistema que se maneja a nivel comercial de un país, se puede simplemente particionar, sin que eso implique duplicación de tablas o datos. Y eso no genera complicaciones ni en el diseño ni en el sistema que lo usa, porque se administra a otros niveles.

[mariscos_recio]

Gracias.He estado mirando ya todo el tema de particionado y me he aclarado solo que necesitaría un programa para generar filas/registros automáticamente porque con pequeñas cantidades de registros es muy difícil evaluar el rendimiento.¿Conoces de algún programa que haga algo similar?

[gnzsoloyo]

¿Te refieres a crear datos aleatorios?
No. cada uno hace ese tipo de procedimientos para las bases que diseña, porque cada base es diferente.
Puede que haya programas que te sirvan parcialmente, pero no conozco personalmente ninguno que me haya dado resultados útiles.
Además, en realidad no es necesario demasiada "evaluación de rendimiento", porque el mayor impacto no está en la cantidad de registros, sino en el uso en el mundo real.
Cuando estableces un plan de implementación, una de sus etapas precisamente tiene que ver con el uso esperado de la aplicación, y eso no depende de que algo tenga capacidad ed almacenamiento, sino en la inserción en el mercado, que te permite estimar los requerimientos de los usuarios al sistema. Es allí donde se ve cuáles son las verdaderas necesidades tanto del diseño de la aplicación, como de hardware necesario.
A mi entender, si lo tuyo está en etapa de proyecto, estás preocupándote innecesariamente por cosas que puede que no ocurran nunca.

Una observación que sí puedo hacerte de entrada, es que si tu duda es referente a la tabla que muestras en el diagrama, estás completamente desencaminado...
La tabla de Productos jamás es una tabla problemática, porque es una tabla que recibe poco impacto, ya que sólo se actualiza en modo batch, y eso está fuera del efecto de la concurrencia.
Por otro lado, si tu duda es por el hecho que sea muy consultada en otras partes del proceso, te aclaro que eso sucede en todos los sistemas, y raramente genera inconvenientes, porque el acceso a la misma no ocurre en un único buffer, ni en una única conexión, ni nada que se le parezca.
Para darte una somera idea, en los sistemas que trabajo, existe una sola tabla de productos a nivel país (hay bases distribuidas por país), que contiene (y no exagero) más de 500.000 registros, que se consultan mas o menos unas 1200 veces/segundo, todo el día (con picos mayores o menores), y no fue esa la razón por la que se necesitó particionarla, ya que eso se maneja a nivel servidores de bases de datos, y además con muy potente hardware. Se particionó para descargar los registros obsoletos a segmentos que no estorbasen en las transacciones diarias.
Pero en contexto así, en realidad, son las tablas transaccionales, es decir aquellas donde se asientan las operaciones comerciales, las que realmente representan problemas de concurrencia. Y es a esas tablas (tal vez con pocas relaciones), donde tu análisis debe apuntar. No a una tabla de Productos, por más que esté vinculada a otras 100 tablas.

¿Se entiende a lo que me refiero?

Si estás en etapa de proyecto, no pierdas tiempo evaluando un problema que no existe aún. Evalúa el sistema y lo que puede requerir el usuario, y estudia como gestionar el problema sin tener que sacrificar diseño, consistencia o procesos innecesarios.
La contingencia de un exceso de concurrencia puede simplemente resolverse con mejor hardware, o mejores configuraciones, o servicios, y no necesariamente con lo que estás suponiendo.

A nosotros, ciertos procesos nos bloqueaban ciertas tablas hace un tiempo (no viene al caso cuáles). ¿Y cuál fue la solución?
Cambiar el orden de las tablas del JOIN en tres consultas... porque eso redujo el tiempo de esas consultas a menos de 1/1000.
En otro caso, un proceso que debía realizarse en cinco días (y no miento), se redujo a 12 minutos, simplemente cambiando dos parámetros en un WHERE.

Con esto quiero destacarte que muchas veces no es el tamaño de la tabla el problema, sino lo óptimo de la consulta, porque una consulta puede meterte en un deadlock que no se ve en el diseño de datos. Y eso sí arruina la performance del sistema.

[mariscos_recio]

gnzsoloyo, se puede decir más alto pero no más claro.Me has sacado de mi duda.Soy primerizo en esto y entre leer manuales y dudas que me surgen por el camino del aprendizaje me desvío a veces a temas de este tipo, pero con lo curioso que soy no puedo impedir preguntarme esas cosas...una última pregunta con respecto a las particiones. Una vez que he creado las particiones, en cuanto hago una consulta a la tabla(por ejemplo: select campo from tabla where fecha between '2013-01-01 00:00:00' and '2013-06-30 12:43:00')¿hace por omisión una búsqueda por las particiones o tiene una sintaxis diferente la consulta para buscar por las particiones y no en la tabla entera? Intuyo que con ese ejemplo de consulta que te he puesto ya hace directamente una búsqueda por las particiones donde se encuentran dichos datos y no por la tabla entera...pero no lo se seguro.