amazon redshift - example - ¿Qué significa tener múltiples columnas sortkey?

create table redshift example

Question

Redshift permite designar varias columnas como columnas SORTKEY , pero la mayoría de la documentación de las mejores prácticas se escribe como si solo hubiera un SORTKEY.

Si creo una tabla con SORTKEY (COL1, COL2) , ¿significa que todas las columnas están almacenadas ordenadas por COL1, luego COL2? O tal vez, ya que es una tienda de columnas, ¿cada columna se almacena en un orden diferente? Es decir, COL1 en el orden COL1, COL2 en el orden COL2 y las otras columnas desordenadas?

Mi situación es que tengo una tabla con (entre otros) un type_id y una columna de marca de tiempo. Los datos llegan aproximadamente en orden de fecha y hora. La mayoría de las consultas se unen contra / restringidas por type_id y timestamp. Por lo general, las cláusulas type_id son más específicas, lo que significa que se puede excluir un porcentaje mucho mayor de filas mirando la cláusula type_id que mirando la cláusula de marca de tiempo. type_id es el DISTKEY por este motivo. Estoy tratando de entender los pros y los contras de SORTKEY (type_id) , SORTKEY (stamp) , SORTKEY (type_id,stamp) , SORTKEY (stamp,type_id) .

Gracias.

Answer 1

Diré que el orden para sort_key debe ser

1. Considerar aquellos en dist, filtrar y unirse primero
2. considerar aquellos en el filtro, unirse
3. considera a los que están en el filtro
4. considera a los que están unidos
5. considerar aquellos en grupo por, ordenar por (incluyendo función de ventana)

La regla general: menor cardinalidad puesta primero si mismo nivel.

Answer 2

Si declara SORTKEY(COL1, COL2) , todas las columnas se ordenarán por COL1 , luego COL2 como si se hubiera hecho ORDER BY (COL1, COL2) .

Si está utilizando SORTKEY para acelerar una ÚNETE, AFAIU no importa siempre y cuando use la misma SORTKEY en las tablas que se unirán porque lo que sucede es una combinación de combinación.

Si COL1 es altamente selectivo como su type_id , significa que solo hay un pequeño número de filas que tienen el mismo type_id . Por lo tanto, aunque puede agregar otra columna a SORTKEY, su utilidad es limitada porque ya ha ocurrido la mayor parte de la eliminación de filas.

Si COL1 no es altamente selectivo como su stamp (lo cual es un poco extraño, por cierto; hubiera esperado que fuera más selectivo que type_id ? De todos modos ...), significa que filtrar por stamp no eliminará tantas filas. Así que tiene más sentido declarar una segunda clave de clasificación. Sin embargo, esto es menos eficiente que al revés ya que eliminar filas antes sería más barato. Si a veces filtra por stamp pero no por type_id , puede tener sentido hacer esto.

Answer 3

También estamos usando Redshift y tenemos alrededor de 2 mil millones de registros (+20 millones cada día) y tengo que decir que cuanto menos selectiva es la sort_key, más adelante debería estar en la lista sort_key.

En nuestro caso (y le aconsejamos que analice cómo utiliza / consulta sus propios datos) utilizamos la marca de tiempo como primera orden_clase. El problema con esto es que, incluso dentro de 1 segundo, registramos alrededor de 200 filas, lo que da como resultado que nuestros bloques de 1 MB contienen solo unos pocos segundos, y cada tipo de datos en ese solo bloque. Esto significa que, aunque la marca de tiempo es altamente selectiva, no podemos seguir filtrando, ya que tenemos todo tipo de datos en cada bloque.

Recientemente hemos invertido el orden de las sort_keys. El primero tiene aproximadamente 15 valores diferentes, el segundo tiene aproximadamente 30, etc ... y la marca de tiempo es el último ahora, pero aún así, un bloque aún se mide en segundos.

Esto da como resultado, (ya que usamos las dos primeras sort_keys como filtros con mucha frecuencia) lo siguiente: Solución anterior: un año de datos, seleccione un mes, elimina el 91% de los bloques, pero después tiene que abrirlos todos, incluso aunque queremos seguir filtrando.

La nueva solución elimina aproximadamente 14/15 de los bloques en el primer paso, independientemente del rango de fechas, luego aproximadamente el 95% de los restantes, y la marca de tiempo aún cae el 91% de los restantes.

Lo hemos probado exhaustivamente con dos tablas de 800 millones de registros, que eran iguales, excepto el orden de las claves de clasificación. Cuanto mayor sea el período de tiempo en la cláusula "dónde", mejores resultados obtendremos. Se hizo aún más significativo en caso de uniones, obviamente.

Así que mi sugerencia es que conozca su base de datos y qué tipo de consultas realiza con frecuencia, ya que la columna más selectiva podría no ser la mejor primera clave de clasificación. Tal como dijo Enno Shioji, todo depende de lo que filtres.