¿Cómo ayuda la partición de tablas?

Tengo dificultades para captar la idea de los pros y los contras de la partición de tablas. Estoy a punto de comenzar a trabajar en un proyecto que tendría 8 tablas y una de ellas será la tabla de datos principal que tendrá 180-260 millones de registros. Como será una tabla indexada correctamente, estoy pensando en limitar los registros de la tabla a 20 millones de esta manera, tendría que crear 9-13 tablas.

Pero no estoy muy seguro de cómo mejorará el rendimiento porque estarán sentados en la misma máquina (32 GB de RAM).

Estoy usando MySQL y las tablas serían MyISAM y la tabla grande tendría un índice en el campo de identificación y no hay más complejidades como la búsqueda de texto completo, etc.

También arroje luz sobre el particionamiento de tablas frente al particionamiento de bases de datos.

Lo siguiente es simplemente una locura despotricando ...

Si deja todos los datos en una tabla (sin particiones), tendrá tiempos de búsqueda O (log n) usando una clave. Tomemos el peor índice del mundo, el árbol binario. Cada nodo de árbol tiene exactamente una clave. Un árbol binario perfectamente equilibrado con 268,435,455 (2 ^ 28 - 1) nodos de árbol tendría una altura de 28. Si divide este árbol binario en 16 árboles separados, obtendrá 16 árboles binarios cada uno con 16,777,215 (2 ^ 24 - 1) nodos de árbol para una altura de 24. La ruta de búsqueda se reduce en 4 nodos, un 14,2857% de reducción de altura. Si el tiempo de búsqueda es en microsegundos, una reducción del 14.2857% en el tiempo de búsqueda es nula a insignificante.

Ahora en el mundo real, un índice BTREE tendría treenodes con múltiples claves. Cada búsqueda BTREE realizaría una búsqueda binaria dentro de la página con un posible descenso a otra página. Por ejemplo, si cada página BTREE contenía 1024 claves, una altura de árbol de 3 o 4 sería la norma, una altura de árbol corta de hecho.

Observe que una partición de una tabla no reduce la altura del BTREE, que ya es pequeña. Dada una partición de 260 millones de filas, incluso existe la gran probabilidad de tener múltiples BTREE con la misma altura. La búsqueda de una clave puede pasar por todas las páginas raíz de BTREE cada vez. Solo uno cumplirá el camino del rango de búsqueda necesario.

Ahora amplíe esto. Todas las particiones existen en la misma máquina. Si no tiene discos separados para cada partición, tendrá E / S de disco y rotaciones de husillo como un cuello de botella automático fuera del rendimiento de búsqueda de la partición.

En este caso, el particionamiento por base de datos tampoco le compra nada si id es la única clave de búsqueda que se está utilizando.

El particionamiento de datos debe servir para agrupar datos que están de manera lógica y coherente en la misma clase. El rendimiento de la búsqueda en cada partición no necesita ser la consideración principal siempre que los datos estén agrupados correctamente. Una vez que haya logrado la partición lógica, concéntrese en el tiempo de búsqueda. Si solo está separando datos por ID solamente, es posible que nunca se pueda acceder a muchas filas de datos para lecturas o escrituras. Ahora, eso debería ser una consideración importante: ubique todos los identificadores a los que se accede con mayor frecuencia y particione con ellos . Todos los ID a los que se accede con menos frecuencia deben residir en una gran tabla de archivo a la que todavía se pueda acceder mediante la búsqueda de índice para esa consulta 'una vez en una luna azul'.

El impacto general debería ser tener al menos dos particiones: una para los identificadores de acceso frecuente y la otra paritiion para el resto de los identificadores. Si los ID a los que se accede con frecuencia son bastante grandes, opcionalmente podría particionarlos.

200 millones de filas están ciertamente en el rango en el que podría beneficiarse de la partición de tablas. Dependiendo de su aplicación, podría apostar algunos de los beneficios enumerados a continuación:

• Facilidad para purgar datos antiguos Si necesita borrar registros de más de (digamos) 6 meses, puede dividir la tabla en la fecha y luego intercambiar particiones más antiguas. Esto es mucho más rápido que eliminar datos de una tabla y, a menudo, se puede hacer en un sistema en vivo. En el caso del OP, esto podría ser útil para el mantenimiento del sistema.

• Múltiples volúmenes de disco La partición le permite dividir datos para distribuir el tráfico del disco en múltiples volúmenes de disco para mayor velocidad. Con un controlador RAID moderno, es probable que esto no sea un problema para el OP.

• Escaneos de tablas y rangos más rápidos Realmente, un sistema operativo no debería estar haciendo este tipo de cosas, pero un almacén de datos o un sistema similar hará este tipo de consulta en cantidad. Los escaneos de tablas utilizan principalmente tráfico de disco secuencial, por lo que suelen ser la forma más eficiente de procesar una consulta que devuelve más del pequeño porcentaje de las filas de una tabla.
  
  El particionamiento mediante un filtro común (generalmente basado en tiempo o período) permite eliminar grandes fragmentos de la tabla de tales consultas si el predicado se puede resolver con la clave de partición. También permite que la tabla se divida en múltiples volúmenes, lo que puede proporcionar ganancias de rendimiento significativas para grandes conjuntos de datos. Normalmente, esto no es un problema para los sistemas operativos.

Para los fines del OP, no es probable que la partición logre muchos beneficios de rendimiento para las consultas operativas, pero puede ser útil para la administración del sistema. Si hay algún requisito significativo para informar agregados en grandes volúmenes de datos, un esquema de partición apropiado puede ayudar con eso.

El particionamiento permite reorganizaciones concurrentes por partición, si todos sus índices están particionados. Si no, las particiones son aún mucho más pequeñas y usan menos espacio de trabajo para reorganizar. Y, internamente, cualquier DBMS "bueno" puede hacer cosas en paralelo con tablas particionadas. Eso probablemente NO incluye MySQL o MyISAM, aunque ...