amazon s3 - precios - Desplazamiento al rojo amazónico: inserción masiva vs COPIA desde s3

precio de amazon s3

Question

Tengo un clúster de desplazamiento al rojo que uso para algunas aplicaciones de análisis. Tengo datos entrantes que me gustaría agregar a una tabla de clicks . Digamos que tengo ~ 10 nuevos ''clics'' que deseo almacenar cada segundo. Si es posible, me gustaría que mis datos estén disponibles tan pronto como sea posible en el desplazamiento al rojo.

Por lo que entiendo, debido al almacenamiento en columnas, el rendimiento de inserción es malo, por lo que debe insertar por lotes. Mi flujo de trabajo es para almacenar los clics en redis, y cada minuto, inserto los ~ 600 clics de redis a desplazamiento al rojo como un lote.

Tengo formas de insertar un lote de clics en desplazamiento al rojo:

• Multi-row insert strategy de inserción de varias filas: utilizo una consulta de inserción regular para insertar varias filas. Documentación de inserción de varias filas aquí
• S3 Copy strategy : Copio las filas en s3 como clicks_1408736038.csv . Luego ejecuto una COPY para cargar esto en la tabla de clicks . COPIA documentación aquí

Hice algunas pruebas (esto se hizo en una tabla de clicks con 2 millones de filas):

             | multi-row insert stragegy |       S3 Copy strategy    |
             |---------------------------+---------------------------+
             |       insert query        | upload to s3 | COPY query |
-------------+---------------------------+--------------+------------+
1 record     |           0.25s           |     0.20s    |   0.50s    |
1k records   |           0.30s           |     0.20s    |   0.50s    |
10k records  |           1.90s           |     1.29s    |   0.70s    |
100k records |           9.10s           |     7.70s    |   1.50s    |

Como puede ver, en términos de rendimiento, parece que no gano nada copiando primero los datos en s3. El tiempo de upload + copy es igual al tiempo de insert .

Preguntas:

¿Cuáles son las ventajas y desventajas de cada enfoque? ¿Cuál es la mejor práctica? Yo me perdí algo ?

Y una pregunta complementaria: ¿es posible desplazar al rojo COPY los datos automáticamente desde s3 a través de un manifiesto? Me refiero a COPIAr los datos tan pronto como se agreguen nuevos archivos .csv a s3. Doc here y here . ¿O tengo que crear un trabajador de fondo para activar los comandos COPY?

Mi análisis rápido:

En la documentación sobre consistencia , no se menciona la carga de datos a través de inserciones de varias filas. Parece que la forma preferida es COPY ing desde s3 con claves de objeto únicas (cada .csv en s3 tiene su propio nombre único) ...

• S3 Copy strategy :
  • PROS: parece la buena práctica de los documentos.
  • CONTRAS: Más trabajo (tengo que administrar cubos y manifiestos y un cron que desencadena los comandos COPY ...)
• Multi-row insert strategy
  • PROS: Menos trabajo. Puedo llamar a una consulta de insert desde mi código de aplicación
  • CONTRAS: no se ve como una forma estándar de importar datos. ¿Me estoy perdiendo de algo?

Answer 1

La copia S3 funciona más rápido en caso de cargas de datos más grandes. cuando digas que miles de millones de registros deben cargarse en el desplazamiento al rojo, entonces s3 upload + copy funcionará más rápido que insertar consultas.

La copia S3 funciona en modo paralelo.

Cuando crea una tabla y lo inserta, existe un límite para el tamaño del lote. El tamaño máximo para un solo SQL es de 16 MB. Por lo tanto, debe tener en cuenta el tamaño de SQL Batch (depende del tamaño de cada consulta de inserción)

La copia S3 aplica automáticamente la codificación (compresión) para su tabla. Cuando crea la tabla y muestra la carga utilizando la copia, puede ver la compresión aplicada automáticamente.

Pero si está utilizando el comando de inserción para comenzar, notará que no se aplica compresión, lo que dará lugar a más espacio para la tabla en desplazamiento al rojo y, en algunos casos, a un tiempo de proceso de consulta lento.

Si desea utilizar comandos de inserción, cree una tabla con cada columna que tenga codificaciones aplicadas para ahorrar espacio y un tiempo de respuesta más rápido.

Answer 2

Los resultados de mis pruebas difieren un poco. Estaba cargando el archivo CSV a Redshift desde el escritorio del sistema operativo Windows.

• El inserto de fila fue el más lento.
• La inserción de varias filas fue 5 veces más rápida que la inserción de filas.
• S3 + COPY fue 3 veces más rápido que el inserto de varias filas.

Lo que contribuyó a la inserción masiva de S3 + COPY a granel.

• El hecho de que no es necesario analizar el enunciado de inserción desde la línea CSV.
• Stream se comprimió antes de la carga de varias partes en S3.
• El comando COPY fue extremadamente rápido.

CSV_Loader_For_Redshift todos mis hallazgos en una sola secuencia de comandos de Python CSV_Loader_For_Redshift

Answer 3

Podría valer la pena implementar micro lotes al realizar cargas masivas en Redshift. Puede valer la pena leer este artículo, ya que también contiene otras técnicas que deben seguirse para un mejor rendimiento del comando COPY.

http://blogs.aws.amazon.com/bigdata/post/Tx2ANLN1PGELDJU/Best-Practices-for-Micro-Batch-Loading-on-Amazon-Redshift

Answer 4

Redshift es una base de datos analítica, y está optimizado para permitirle consultar millones y miles de millones de registros. También está optimizado para permitirle ingerir estos registros muy rápidamente en Redshift usando el comando COPY.

El diseño del comando COPY es para trabajar con la carga paralela de múltiples archivos en los múltiples nodos del clúster. Por ejemplo, si tiene un clúster de 5 pequeños nodos (dw2.xl), puede copiar datos 10 veces más rápido si tiene datos múltiples (20, por ejemplo). Existe un equilibrio entre la cantidad de archivos y la cantidad de registros en cada archivo, ya que cada archivo tiene una pequeña sobrecarga.

Esto debería llevarlo al equilibrio entre la frecuencia de la COPIA, por ejemplo, cada 5 o 15 minutos y no cada 30 segundos, y el tamaño y número de los archivos de eventos.

Otro punto a considerar son los 2 tipos de nodos Redshift que tienes, los SSD (dw2.xl y dw2.8xl) y los magnéticos (dx1.xl y dw1.8xl). Los SSD son más rápidos en términos de ingestión también. Como busca datos muy recientes, probablemente prefiera ejecutarlos con los SSD, que generalmente cuestan menos de 500 GB de datos comprimidos. Si con el tiempo tiene más de 500 GB de datos comprimidos, puede considerar ejecutar 2 clústeres diferentes, uno para datos "calientes" en SSD con los datos de la última semana o mes, y uno para datos "fríos" en discos magnéticos con todos tus datos históricos

Por último, no es necesario que cargue los datos en S3, que es la mayor parte de su tiempo de ingestión. Puede copiar los datos directamente desde sus servidores usando la opción COPIA SSH. Ver más información al respecto aquí: http://docs.aws.amazon.com/redshift/latest/dg/loading-data-from-remote-hosts.html

Si puede dividir sus colas Redis en varios servidores o al menos varias colas con diferentes archivos de registro, probablemente pueda obtener muy buenos registros por segundo de velocidad de ingestión.

Otro patrón que puede considerar para permitir análisis casi en tiempo real es el uso de Amazon Kinesis, el servicio de transmisión. Permite ejecutar análisis en datos con demora de segundos y, al mismo tiempo, preparar los datos para copiar en Redshift de una manera más optimizada.