¿Por qué NO particionar?

¿Cuándo NO se querría particionar una base de datos? (pensando en particionar MySQL )

En mi caso

Comenzaré con un par de millones de filas, debería crecer a partir de ahí.
Clave principal en un campo de caracteres que sirve como la restricción de consulta más frecuente (y las búsquedas son frecuentes, al menos algunas por segundo).
La clave primaria se codificará para servir como clave de partición
Se realizarán actualizaciones en cada fila que se extrae en las consultas frecuentes mencionadas anteriormente
Las búsquedas menos frecuentes (contra columnas de fechas u otras) deberán llegar a todas las particiones

Incluso para el último punto, ¿la búsqueda no se ejecuta en paralelo, así que en todos los casos, es una victoria ? ¿Cuáles son las desventajas de la partición? ¿Por qué no es algo que TODOS usan por defecto, al menos cuando estás viendo más de un millón de registros?

ACTUALIZACIÓN: seleccioné la respuesta de zgguy, pero tenga en cuenta que agregué mi propia respuesta con los resultados de mi propia investigación, incluido un enlace a una respuesta realmente buena sobre una pregunta similar que me fue muy útil.

mysql database-design partitioning

— chell
fuente

Respuestas:

No hay una bala de plata para los problemas de rendimiento, y la partición tampoco es una.

Cada partición es esencialmente una tabla en sí misma. Por lo tanto, las consultas que se escriben de una manera que permite que la base de datos busque filas en una sola partición se vuelven más rápidas. La diferencia puede ser enorme para las consultas que tendrían que escanear toda la tabla grande, pero pueden limitarse a escanear solo una partición en la tabla particionada. Para búsquedas de teclas únicas, la diferencia es mucho menor.

Sin embargo, las consultas que usan búsquedas de índice de una manera que requiere que la base de datos visite todas o la mayoría de las particiones de tabla (índice) se ejecutarán considerablemente más lentamente.

La ejecución paralela es un tema en sí mismo. Si ejecuta grandes lotes durante la noche y tiene toda la máquina para hacer ese único trabajo, entonces su paralelización es algo bueno. Sin embargo, en un sistema OLTP donde la base de datos atiende constantemente consultas de muchos usuarios concurrentes, no desea que un usuario tome todos los recursos.

— zgguy
fuente

Entonces, ¿las búsquedas de clave principal / única en realidad no verán mucha mejora (¿alguna?) Porque el índice PK es más rápido? ¿Es esto general? ¿Hay momentos en que un índice PK es más lento? ¿Qué pasa si las búsquedas están sesgadas a las PK agregadas más recientemente? ¿Sería útil una partición basada en la PK (creo que algo de la clave de partición debería ser módulo o similar y NO hash, ¿verdad?) Que hace que la mayor parte de la actividad golpee solo una partición?

— chell

Las búsquedas de claves principales / únicas verán, en el mejor de los casos, una mejora de rendimiento menor. Por otro lado, si su objetivo es reducir la contención de las declaraciones DML, debe realizar una partición de manera que DML se distribuya por igual en todas las particiones en lugar de centrarse en algunas de ellas.

— zgguy

lamento volver 10 días después, pero plantea un punto clave: proporcionó una buena razón para ver la partición como posiblemente no necesaria, sin embargo , mi escenario incluye la actualización de cada registro después de leerlo (varios por segundo). ¿La necesidad de tantas escrituras es un caso más convincente para las particiones (con distribución uniforme) para que la carga de escritura se extienda?

— chell

También estoy tratando de entender tu comentario sobre las consultas que llegan a muchas particiones (que son más lentas). Si las consultas están en contra de la PK, que también se usa (hash) como clave de partición, ¿no sabe el DB de inmediato a qué partición ir en función del hash de la búsqueda? ¡Gracias por la ayuda!

— chell

Lo sentimos, no pude visitar el intercambio de fichas últimamente. La respuesta a la que se vinculó es excelente. Creo que responde a sus dos preguntas.

— zgguy

La respuesta aquí está bien escrita y presenta argumentos similares a la respuesta de zgguy , que la partición no le ofrece mucho beneficio, si lo hay, a un escenario de una sola máquina donde las búsquedas más frecuentes se basan en la clave principal o algo similar (porque las búsquedas indexadas deberían ser igual de rápidas).

De hecho, un hilo común de consejos parece ser que la razón principal para la partición es tangencial y principalmente relacionada con la administración: por ejemplo, segregue sus datos según la fecha si necesita purgar registros antiguos de vez en cuando. Aunque se observó que esto también puede beneficiar su rendimiento de búsqueda si sus datos son tales que la mayoría de las consultas solo alcanzarán los registros agregados recientemente.

También vi mencionar que MySQL nunca hace nada en paralelo (sería bueno ver algunos enlaces o más explicaciones al respecto).

No he visto a nadie hablar sobre si la actividad de escritura agrega o no consideraciones diferentes.

— chell
fuente

No creo que las escrituras cambien tu respuesta. Usted mencionó 2 de los 4 casos de uso que he encontrado. Todavía no hay paralelismo, incluso en 8.0.

— Rick James

Lo primero que viene a la mente es la poda de partición ; si eso no es algo que tus consultas puedan usar.

¿Necesitará purgar una gran cantidad de datos de la tabla ya que la partición lo ayudaría? Aunque antiguo, pero esta publicación de Peter tiene pocos puntos a considerar.

y otra cosa que uno puede pensar es la facilidad de uso para tablas simples ... el particionamiento necesita trabajo y mantenimiento adicionales.

— mysql_user
fuente

Las versiones más nuevas tienen una sintaxis para limitar explícitamente la consulta a una partición. No puedo pensar en una razón válida para usarlos.

— Rick James