mysql - supermasivo - ¿Es malvada una mesa de ''agujero negro''?
el agujero negro libro (8)
Cada vez que inserte una fila en una tabla, lo más probable es que esté escribiendo en la misma área del disco duro o en la misma página (en el mundo de MS-SQL, no sé acerca de postgresql), por lo que esta técnica probablemente conduzca a la contención y el bloqueo, ya que todas las transacciones compiten para escribir en la misma tabla.
También esto reducirá a la mitad el rendimiento de las inserciones ya que las inserciones requieren dos inserciones en lugar de una.
Y esto es desnormalización ya que ahora hay dos copias de los datos en lugar de una.
Leyendo esta pregunta, acabo de enterarme de la existencia del truco de la tabla de blackhole : básicamente consiste en usar una sola tabla para insertar datos y luego un desencadenante que divide los datos en muchas otras tablas.
Me pregunto si esto podría causar problemas, una vez que los desarrolladores que trabajan en el proyecto lo saben.
¿Cuáles son las ventajas y desventajas de esta técnica ?
Edit : El parpadeo que tuve en mente cuando vi el ejemplo es sobre transacciones: si por alguna razón falla la transacción, encontrará la fila de blackhole con los datos originales, para propósitos históricos y tal vez una ayuda con la depuración, pero esto Parece ser el único +1 que puedo ver con los agujeros negros. Ideas?
Curiosamente, también me enteré de la existencia de hoyos negros.
Podría decirse que la pregunta aquí es en realidad una más amplia, es decir, si la lógica de negocios debe estar incorporada o no en los activadores de base de datos. En este caso, la tabla de agujero negro se usa esencialmente como un almacén de datos transitorios que el activador de la tabla de agujero negro puede utilizar. ¿Debería usarse el gatillo en primer lugar? Para mí esa es la verdadera carne de la cuestión.
Personalmente, creo que el uso de activadores debe estar restringido solo al registro y las tareas específicas de DBA y no debe contener lógica de negocios (o cualquier lógica) que debe pertenecer firmemente en la capa de aplicación. Parece que ha habido bastantes opiniones expresadas sobre si los activadores de la base de datos son malos o no . Creo que tu pregunta también cae dentro de esa categoría.
Incrustar la lógica de la capa de aplicación en los disparadores de la base de datos puede ser riesgoso.
Es probable que termine dividiendo la lógica empresarial entre el código de la aplicación y la base de datos. Esto puede ser muy confuso para alguien que intenta apoyar y meterse en una base de código.
Si termina con demasiada lógica en los desencadenantes y, de hecho, en los procedimientos almacenados, puede terminar fácilmente con problemas de rendimiento en su servidor de base de datos que, de hecho, deberían haberse solucionado mediante la distribución de tareas de procesamiento de alto rendimiento, es decir, lógica empresarial compleja entre las aplicaciones. Servidores y dejar el servidor de base de datos libre para su propósito principal, es decir, servir datos.
Sólo el valor de mis dos bits, por supuesto!
Esto no parece una buena idea. Si está intentando mantener el código del extremo frontal simple, ¿por qué no usar un procedimiento almacenado? Si no es para mantener el código del extremo delantero simple, no entiendo el punto en absoluto.
La pregunta original que incitó la suya no llega al corazón de los "agujeros negros" de MySQL.
¿Qué es un agujero negro?
En MySQL, BLACKHOLE es un motor de almacenamiento que simplemente descarta toda la información insertada en él, de manera análoga a un dispositivo nulo. Hay varias razones para usar este backend, pero tienden a ser un poco abstruso:
- Un esclavo de filtrado de binlog de "solo relé"
Ver los documentos , y here y here . - Benchmarking
Por ejemplo, medir la sobrecarga del registro binario sin preocuparse por la sobrecarga del motor de almacenamiento - Varios trucos computacionales
Ver here
Si no sabe por qué necesita un sumidero de datos enmascarado como una tabla, no lo use.
¿Cuál es la técnica que estás preguntando?
El uso en consideración parece ser:
- redirigir los datos insertados a otras tablas
- registro de auditoría de la acción original de INSERTion
- descartar los datos originales INSERT
Por lo tanto, la respuesta a la pregunta de "maldad" o ventajas y desventajas es la misma que la respuesta a las preguntas para VIEWs que se pueden insertar / actualizar (la forma común de implementar el # 1), el registro de auditoría basado en activadores (cómo la mayoría de la gente hace el # 2 ) y las anulaciones / contraacciones de comportamiento en general (hay varias formas de lograr el # 3).
¿Entonces, cuál es la respuesta?
La respuesta es, por supuesto, "a veces estas técnicas son apropiadas y otras no". :) ¿Sabes por qué lo estás haciendo? ¿Es la aplicación un lugar mejor para esta funcionalidad? ¿Es la abstracción demasiado frágil, demasiado permeable, demasiado rígida, etc.?
No creo que el agujero negro tenga ventajas reales.
Escribir el código de activación para mover los datos probablemente no sea un trabajo notablemente menor que escribir el código para insertar los datos en el lugar correcto en primer lugar.
Como escribe Christian Oudard, no reduce la complejidad, solo la mueve a un lugar donde es realmente difícil de depurar.
A la baja:
Los "efectos secundarios" suelen ser una mala idea en el desarrollo de software. Los desencadenantes son efectos secundarios: tengo la intención de hacer una cosa (insertar datos en una tabla), y en realidad hace muchas otras cosas. Ahora, cuando estoy depurando mi código, tengo que mantener todos los efectos secundarios en mi cabeza también, y los efectos secundarios podrían tener efectos secundarios.
la mayoría de los programas dedican mucho más tiempo al mantenimiento que al desarrollo. Es probable que la incorporación de nuevos desarrolladores al equipo y la explicación del truco del agujero negro aumente la curva de aprendizaje, por un beneficio insignificante (en mi opinión).
Debido a que los desencadenantes son efectos secundarios, y es relativamente fácil desencadenar una enorme cascada de desencadenantes si no tiene cuidado, siempre he tratado de diseñar mis bases de datos sin depender de los desencadenantes; donde los activadores son claramente el camino correcto, solo he dejado que mis desarrolladores más experimentados los creen. El truco del agujero negro hace que los disparadores se conviertan en una forma normal y normal de trabajar. Este es un punto de vista personal, por supuesto.
No hagas esto El hecho de que se llame truco y no una forma estándar de hacer algo me dice lo suficiente.
Esto mata totalmente el patrón de uso normal del modelo relacional. No estoy seguro de que realmente mate la forma normal, ya que todavía puedes tener todo eso en su lugar. Simplemente se mete con la manera en que los datos llegan a las tablas de destino. Parece una pesadilla de rendimiento encima de una pesadilla de mantenimiento. Imagine que una tabla tiene un disparador que debe activarse para más de 1,800 inserciones de tabla, por ejemplo. Eso me hace sentir mal.
Este es un truco de salón interesante nada más.
Por favor no hagas esto. Esto no reduce la complejidad, solo lo mueve. Este tipo de lógica pertenece a la capa de aplicación, donde puedes usar un lenguaje más agradable como PHP, Python o Ruby para implementarlo.
Supongo que esto sería bastante lento, ya que no se pueden utilizar las ventajas de los "inserciones masivas".