postgis-workshop/clusterindex — Spanish @ OSGeo Weblate: Spatial data tends to be accessed in spatially correlated windows: …

Translation

English

Spanish

Needs editing

Skip

	English	Spanish	Actions
	Clustering on Indices	Clustering sobre índices
	Databases can only retrieve information as fast as they can get it off of disk. Small databases will float up entirely into RAM cache, and get away from physical disk limitations, but for large databases, access to the physical disk will be a limiting stop in disk access speed.	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.
	Data is written to disk opportunistically, so there is not necessarily any correlation between the order data is stored on the disk and the way it will be accessed or organized by applications.	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.
	Clustering on the R-Tree	Clustering sobre el R-Tree
	Spatial data tends to be accessed in spatially correlated windows: think of the map window in a web or desktop application. All the data in the windows has similar location value (or it wouldn't be in the window!)	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!).
	So, clustering based on a spatial index makes sense for spatial data that is going to be accessed with spatial queries: similar things tend to have similar locations.	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.
	Let's cluster our ``nyc_census_blocks`` based on their spatial index:	Vamos a hacer un cluster con nuestro ``nyc_census_blocks`` basado en su índice espacial:
	The command re-writes the ``nyc_census_blocks`` in the order defined by the spatial index ``nyc_census_blocks_geom_gist``. Can you perceive a speed difference? Maybe not, because the original data may have already had some pre-existing spatial ordering (this is not uncommon in GIS data sets).	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).
	Disk Versus Memory/SSD	Disco vs Memoria/SSD
	Most modern databases are run using SSD storage, which is much faster at random access than old spinning magnetic media. Also, most modern databases are running on top of data which is small enough to fit into the RAM of the database server, and ends up there as the operating system "virtual filesystem" caches it.	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.
	Is clustering still necessary?	¿Es todavía necesario el clustering?
	Surprisingly, yes. Keeping records that are "near each other" in space "near each other" in memory increases the odds that related records will move up the servers "memory cache heirarchy" together, and thus make memory accesses faster.	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.
	System RAM is not the fastest memory on a modern computer. There are several levels of cache between system RAM and the actual CPU, and the underlying operating system and processor will move data up and down the cache heirarchy in blocks. If the block getting moved up happens to include the piece of data the system will need next... that's a big win. Correlating the memory structure with the spatial structure is a way in increase the odds of that win happening.	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.
	Does Index Structure Matter?	¿Importa la Estructura del Índice?
	In theory, yes. In practice, no really. As long as the index is a "pretty good" spatial decomposition of the data, the main determinant of performance will be the order of the actual table tuples.	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.
	The difference between "no index" and "index" is generally huge and highly measurable. The difference between "mediocre index" and "great index" usually takes quite careful measurement to discern, and can be very sensitive to the workload being tested.	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.
	Function List	Lista de funciones
	`CLUSTER <https://www.postgresql.org/docs/current/sql-cluster.html>`_: Re-orders the data in a table to match the ordering in the index.	`CLUSTER <https://www.postgresql.org/docs/current/sql-cluster.html>`_: Reordena los datos en la tabla para que coincida con el orden del índice.