27. Clustering sobre índices¶
La velocidad máxima a la que las bases de datos pueden recuperar información depende de la velocidad a la que puedan leerla del disco. Las bases de datos pequeñas pueden cargar toda su información en el cache RAM y evitar las limitaciones físicas de los discos, pero para bases de datos grandes el acceso al disco físico será un tope en cuanto a la velocidad de acceso a disco.
Los datos se escriben a disco de forma oportunista, de forma que no hay necesariamente ninguna correlación entre el orden en que se almacenan en disco y la forma en que las aplicaciones accederán a ellos o los organizarán.
One way to speed up access to data is to ensure that records which is likely to be retrieved together in the same result set are located in similar physical locations on the hard disk platters. This is called «clustering».
The right clustering scheme to use can be tricky, but a general rule applies: indexes define a natural ordering scheme for data which is similar to the access pattern that will be used in retrieving the data.
Because of this, ordering the data on the disk in the same order as the index can provide a speed advantage in some cases.
27.1. Clustering sobre el R-Tree¶
Se suele acceder a los datos espaciales en ventanas correladas espacialmente: piensemos en la ventana de mapa de una aplicación web o de escritorio. Todos los datos en la ventana tienen un valor de localización similar (¡o no estarían dentro de la ventana!).
Así, el clustering basado en un índice espacial tiene sentido para datos espaciales a los que se va a acceder mediante queries espaciales: cosas similares tienden a tener localizaciones similares.
Vamos a hacer un cluster con nuestro nyc_census_blocks basado en su índice espacial:
-- Cluster the blocks based on their spatial index
CLUSTER nyc_census_blocks USING nyc_census_blocks_geom_idx;
El comando re-escribe nyc_census_blocks en el orden definido por el índice espacial nyc_census_blocks_geom_gist. ¿Se percibe una diferencia de velocidad? Quizás no, porque los datos originales puede que tenga ya algún orden espacial preexistente (esto no es raro en los juegos de datos de SIG).
27.2. Disco vs Memoria/SSD¶
La mayoría de las bases de datos modernas funcionan sobre almacenamiento SSD, que es mucho más rápido para accesos aleatorios que los viejos medios discos magnéticos girantes. Además, la mayoría de las bases de datos modernas funcionan sobre datos que son los bastante pequeños para caber en la RAM del servidor de la base de datos, y terminan allí según el «sistema de archivos virtual» del sistema operativo los va cacheando.
¿Es todavía necesario el clustering?
Sorprendentemente, sí. Mantener registros que están «cerca del otro» en espacios «cerca del otro» en la memoria aumenta las posibilidades de que registros relacionados se muevan en la «jerarquia de memoria caché» juntos haciendo el acceso a la memoria más rápido.
La RAM del sistema no es la memoria más rápida en un ordenador moderno. Hay muchos niveles de caché entre el sistema RAM y la CPU, y el sistema operativo y el procesador moverán datos arriba y abajo en esa jerarquia de caché en bloques. Si resulta que el bloque que se está moviendo incluye el trozo de datos que el sistema necesitará justo después,… es una gran victoria. Correlar la estructura de la memoria con la estructura espacial es un forma de aumentar las posibilidades de que esto suceda.
27.3. ¿Importa la Estructura del Índice?¶
En teoría, sí. En la práctica, realmente no. Ya que el índice es una descomposición espacial de los datos «bastante buena», el principal factor que afectará al rendimiento será el orden de las tuplas de la tabla.
La diferencia entre «sin indice» e «índice» normalmente es muy grande y muy medible. La diferencia entre «índice mediocre» y «gran índice» normalmente requiere una medida muy cuidadosa para diferenciar y puede ser muy sensible a la carga de trabajo que se esté testando.
