SQL para DynamoDB y los límites de PartiQL

DynamoDB es un almacén de valores-clave NoSQL, pero responde preguntas con forma SQL más de lo que la gente espera, y mucho menos de lo que esperan. Este es el mapa honesto: ¿qué SQL-on-DynamoDB en realidad sales de la caja, dónde se detiene y las pocas formas para ejecutar las consultas JOIN / GROUP BY / agregadas que la superficie nativa no puede expresar.

¿Puedes query DynamoDB con SQL?

En parte. DynamoDB envía PartiQL, un idioma compatible con SQL para SELECT/INSERT/UPDATE/DELETE por clave, por lo que SELECT * FROM "Orders" WHERE OrderID = 100 funciona. Pero es una superficie compatible con SQL sobre DynamoDB API, no es un motor SQL: AWS admite solo un subconjunto, por lo que JOIN, GROUP BY, y COUNT(*) están fuera. Para aquellos que necesitan un motor en capas en la parte superior.

AWS describes PartiQL como "un idioma SQL compatible con query, para seleccionar, insertar, actualizar y eliminar datos en Amazonas DynamoDB", pero es igualmente explícito que "Amazon DynamoDB admite un subconjunto del PartiQL query idioma." En el momento en que alcanzas un JOIN, un GROUP BY o COUNT(*), estás fuera de lo que PartiQL puede hacer - ver PartiQL vs SQL para la función completa por función comparación.

PartiQL: una superficie compatible con SQL, no un motor SQL

PartiQL asigna SQL declaraciones de aspecto en las mismas operaciones de plano de datos que SDK expone. Un SELECT con una igualdad partition-key se compila en un Query; un SELECT sin uno se compila en un Scan. Según el AWS SELECT referencia:

El uso de la declaración SELECT puede dar como resultado una tabla completa scan si se cumple una igualdad o La condición IN con una clave de partición no se proporciona en la cláusula WHERE.

Entonces, se siguen aplicando las mismas reglas de patrón de acceso que govern Query y Scan. PartiQL simplemente los oculta detrás de una sintaxis familiar. No agrega ningún planificador query, ni uniones y sin agregación basada en conjuntos. Cada declaración se reduce a un nativo. operación:

Un SELECT sin igualdad de clave de partición se compila en una tabla completa Scan. en us-east-1 bajo demanda que factura 0,5 RCU por 4 KB eventualmente consistente para cada elemento examinado: una tabla de 500 MB de filas de 2 KB equivale aproximadamente a 125 000 RCU antes de cualquier filtro WHERE reduce el conjunto de resultados. Velocidad de línea en forma de PartiQL lee en la calculadora de precios.

Si una operación no se reduce a un solo Obtener/Query/Scan/Put/Update/Delete, PartiQL simplemente no puede expresarlo. Todo lo que aparece a continuación es consecuencia de aquello. hecho.

Qué cubre PartiQL

DynamoDB PartiQL admite cuatro declaraciones DML/query:

• SELECCIONAR — leer elementos (se compila en Query o Scan)
• INSERT — agrega un elemento (PutItem)
• ACTUALIZAR — modificar un elemento (UpdateItem)
• BORRAR — eliminar un elemento (DeleteItem)

También apoya transacciones y operaciones por lotes. Objetivos de lectura bien formados la clave de partición con una igualdad o IN:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY` está permitido, pero la referencia AWS restringe la clave de pedido a "un clave hash o una clave de clasificación": la partición o clave de clasificación, no columnas arbitrarias. Ese es el límite máximo de lo que PartiQL acepta. Para copiar y pegar declaraciones, consulte PartiQL ejemplos.

Lo que PartiQL no puede hacer

Estas son las cosas que los desarrolladores suelen esperar de "SQL" y PartiQL. admite ninguno de ellos:

• No JOIN. El PartiQL SELECT sintaxis es un solo FROM {{table}}[.{{index}}]: una tabla o un índice, nunca dos tablas relacionadas en una clave. Este es el diseño de tabla única compensación: usted modela para sus patrones de acceso desde el principio porque la capa query no puede remodelar los datos después.
• No GROUP BY. No está en la gramática; no hay ninguna cláusula para agrupar filas.
• Sin funciones agregadas. El PartiQL referencia de funciones enumera exactamente una función en "Funciones agregadas": SIZE, que devuelve el tamaño de un atributo en bytes para un único elemento. No hay COUNT, SUM, AVG, MIN o MAX en filas. AWS dice claramente: "Cualquier SQL Las funciones que no están incluidas en esta lista no son compatibles actualmente con DynamoDB."
• Sin LIKE, sin subconsultas, sin UNION, sin funciones de ventana. Coincidencia de patrones utiliza contains / begins_with; el resto no tiene equivalente alguno.

Entonces, "ingresos totales por cliente el mes pasado": una línea GROUP BY en cualquier base de datos relacional: no se puede expresar en PartiQL. scan los datos y agregarlo en el código de la aplicación.

La única forma de obtener JOIN / GROUP BY / comportamiento agregado real durante DynamoDB Los datos son una herramienta que ejecuta un motor SQL real encima. Para interactivo, consultas ad-hoc hay dos: el conector federado de Amazon Athena y DynoTable es SQL Workbench. (Para análisis programados, el ETL cero de DynamoDB La integración con Amazon Redshift también ejecuta SQL uniones y agregados).

Cómo query DynamoDB con SQL reales a través de Amazon Athena

La propia respuesta de AWS a "real SQL sobre DynamoDB" es la Amazon Athena DynamoDB conector, que "permite a Amazon Athena comunicarse con DynamoDB para que usted pueda query tus tablas con SQL." Debido a que Athena es un motor SQL completo, esto te permite JOIN y agregados: el tutorial de AWS se titula "Acceda, query y únase a tablas de Amazon DynamoDB usando Athena."

El problema es la configuración y el costo:

• Es un conector federado basado en Lambda que implementas en tu cuenta. (a través de la consola Athena o el repositorio de aplicaciones sin servidor), cableado a través de AWS Glue para schema y derramando los resultados en un bucket de S3 (documentos del conector).
• Debajo del capó todavía usa las operaciones Query y Scan de la API de DynamoDB. AWS warn es que "las consultas que utilizan scan pueden consumir una gran cantidad de lecturas unidades de capacidad (RCUs)", así se lee en un query analítico sobre una tabla grande, y metros - muchos artículos (el conector cuesta). Utilice el calculadora del tamaño del artículo para medir qué scan-pesado query costará.
• Las operaciones de escritura como INSERT INTO no se admiten a través del conector.

Athena es la herramienta adecuada para análisis programados y paneles de BIrds. es pesado para el caso cotidiano "Solo necesito unir dos tablas y observar el resultado" - ese es el vacío que llena la siguiente sección.

DynoTable SQL Workbench: SQL dentro de las reglas de patrón de acceso de DynamoDB

DynoTable SQL Workbench corre real SQL — JOIN, GROUP BY, COUNT/SUM/AVG — contra tus tablas DynamoDB en vivo desde un escritorio client, sin Lambda, Glue o S3 para sostenerse. Materializa las hileras mediante DynamoDB es el tiempo de ejecución real de Query/Scan, luego ejecuta un único SELECT sobre ellos. localmente en su escritorio:

-- Runs in the DynoTable Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

La parte "dentro de las reglas de patrón de acceso de DynamoDB" es importante. El Workbench no finja que DynamoDB es Postgres; todavía se lee Query/Scan debajo del capó, de modo que usted esté al tanto de lo que cuesta cada query y haga cumplir las DynamoDB. modelo de acceso en lugar de ocultarlo:

• INNER JOIN y LEFT JOIN únicamente: el atributo objetivo ON debe ser un clave de partición o GSI clave de partición. No RIGHT / FULL / CROSS / unión por coma.
• Aún no hay autouniones, ni subconsultas, ni tablas derivadas, ni funciones de ventana.
• Las uniones y proyecciones operan sobre atributos escalares.

Si solo necesita redactar las condiciones y expresiones clave para el API sin procesar — no es una declaración SQL completa: DynamoDB Generador de expresiones genera el correcto FilterExpression / KeyConditionExpression sin la superficie PartiQL en absoluto.

Si su goal es un DynamoDB SQL client para explorar, depurar y analizar tablas, el Workbench llena ese vacío, y el resto de DynoTable es un completo DynamoDB GUI a su alrededor.

Pruebe DynoTable para ejecutar SQL real en sus propias tablas.

FAQ

¿Puedes ejecutar SQL en DynamoDB? Puede ejecutar PartiQL, un subconjunto compatible con SQL (SELECCIONAR/INSERTAR/ACTUALIZAR/BORRAR mediante clave). Para JOIN, GROUP BY y agregados necesita un motor SQL en la parte superior: Amazon Athena DynamoDB conector, o DynoTable SQL Workbench: un único dialecto SELECT con INNER/LEFT JOIN, sin CTE, uniones ni subconsultas.

¿DynamoDB PartiQL admite UNIRSE? No. La sintaxis PartiQL SELECT tiene una única tabla o índice FROM y no tiene combinación gramática. Las uniones requieren un motor en capas sobre DynamoDB.

¿PartiQL admite GROUP BY o agregados como COUNT y SUM? No. No hay ninguna cláusula GROUP BY y la única función "agregada" es SIZE (el tamaño de bytes de un atributo para un elemento). COUNT, SUM, AVG, MIN y MAX. entre filas no son compatibles.

¿Es DynamoDB SQL o NoSQL? NoSQL: un almacén de documentos y valores clave. PartiQL agrega un SQL compatible con query lenguaje en la parte superior, pero DynamoDB no tiene motor relacional, uniones ni agregados.

¿Es PartiQL good para consultas ad-hoc? Para búsquedas basadas en claves, sí. Para consultas analíticas ad hoc (recuentos, resúmenes, se une), no, PartiQL no puede expresarlos y SELECT sin restricciones está en silencio. convertirse en la tabla completa scans.

¿Existe un DynamoDB SQL client que maneje UNIRSE y AGRUPAR POR? Sí, DynoTable SQL Workbench corre JOIN/GROUP BY/agregados contra vivos. tablas desde el escritorio, y Amazon Athena lo hace a través de un conector federado que implementar en su cuenta AWS.