SQL para DynamoDB e os limites do PartiQL

DynamoDB é um armazenamento de valor-chave NoSQL, mas responde mais às perguntas do formato SQL do que as pessoas esperam – e muito menos do que esperam. Este é o mapa honesto: o que SQL-on-DynamoDB você realmente sai da caixa, onde ele para e as poucas maneiras para executar as consultas JOIN/GROUP BY/agregadas que a superfície nativa não pode expresso.

Você pode consultar DynamoDB com SQL?

Parcialmente. O DynamoDB vem com PartiQL, uma linguagem compatível com SQL para SELECT/INSERT/UPDATE/DELETE por tecla, então SELECT * FROM "Pedidos" ONDE OrderID = 100 funciona. Mas é uma superfície compatível com SQL em relação ao DynamoDB API, não é um mecanismo SQL - AWS suporta apenas um subconjunto, então JOIN, GROUP BY e COUNT(*) foi lançado. Para aqueles, você precisa de um motor em camadas.

AWS descreve PartiQL como "uma linguagem de consulta compatível com SQL, para selecionar, inserir, atualizar e excluir dados em AmazonDynamoDB", mas é igualmente explícito que "o Amazon DynamoDB suporta um subconjunto do PartiQL linguagem de consulta." No momento em que você pega um JOIN, GROUP BY ou COUNT(*), você está fora do que o PartiQL pode fazer - veja PartiQL vs SQL para ver todos os recursos, recurso por recurso comparação.

PartiQL: uma superfície compatível com SQL, não um motor SQL

PartiQL mapeia declarações com aparência de SQL nas mesmas operações de data-plane do SDK expõe. Um SELECT com igualdade partition-key compila para um Query; um SELECT sem um compila para um Scan. De acordo com Referência AWS SELECT:

Usar a instrução SELECT pode resultar em uma varredura completa da tabela se uma igualdade ou A condição IN com uma chave de partição não é fornecida na cláusula WHERE.

Portanto, as mesmas regras de padrão de acesso que regem o Query e o Scan ainda se aplicam – O PartiQL apenas os esconde atrás de uma sintaxe familiar. Não adiciona nenhum planejador de consulta, não junções e nenhuma agregação baseada em conjunto. Cada instrução se reduz a um nativo operação:

Um SELECT sem igualdade de chave de partição é compilado em um Scan de tabela completa. Em us-east-1 on-demand que cobra 0,5 RCU por 4 KB eventualmente consistente para cada item examinado — uma tabela de 500 MB com linhas de 2 KB equivale a aproximadamente 125.000 RCU antes de qualquer filtro WHERE restringir o conjunto de resultados. Taxa de linha em formato PartiQL lê na calculadora de preços.

Se uma operação não se reduzir a um único Get/Query/Scan/Put/Update/Delete, PartiQL simplesmente não consegue expressar isso. Tudo abaixo é consequência disso fato.

O que o PartiQL cobre

O PartiQL do DynamoDB suporta quatro instruções DML/query:

• SELECT — lê itens (compila para Query ou Scan)
• INSERIR — adicione um item (PutItem)
• ATUALIZAÇÃO — modificar um item (UpdateItem)
• DELETE — remove um item (DeleteItem)

Também suporta transações e operações em lote. Alvos de leitura bem formados a chave de partição com igualdade ou IN:

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

ORDER BY é permitido, mas a referência AWS restringe a chave de pedido a "a chave hash ou uma chave de classificação" — a partição ou sort key, não colunas arbitrárias. Esse é o limite máximo que o SELECT do PartiQL aceita. Para copiar e colar pronto instruções, consulte exemplos PartiQL.

O que o PartiQL não pode fazer

Estas são as coisas que os desenvolvedores mais esperam do “SQL” e do PartiQL não suporta nenhum deles:

• Não JOIN. O Sintaxe PartiQL SELECT é um único FROM XTK0X[.XTK1X] — uma tabela ou um índice, nunca dois tabelas relacionadas em uma chave. Este é o design de mesa única compensação: você modela para seus padrões de acesso antecipadamente porque a camada de consulta não pode remodelar os dados depois.
• Não GROUP BY. Não está na gramática; não há cláusula para agrupar linhas.
• Sem funções agregadas. O Referência de funções PartiQL lista exatamente uma função em "Funções agregadas": SIZE, que retorna o tamanho de um atributo em bytes para um único item. Não há COUNT, SUM, AVG, MIN ou MAX nas linhas. AWS afirma claramente: "Qualquer SQL funções que não estão incluídas nesta lista não são atualmente suportadas em DynamoDB."
• Sem LIKE, sem subconsultas, sem UNION, sem funções de janela. Correspondência de padrões usa contains/begins_with; o resto não tem equivalente algum.

Portanto, "receita total por cliente no mês passado" - um GROUP BY de uma linha em qualquer banco de dados relacional — não pode ser expresso em PartiQL. Você escanearia os dados e agregue-o no código do aplicativo.

A única maneira de obter comportamento real do JOIN / GROUP BY / agregado em relação ao DynamoDB data é uma ferramenta que executa um mecanismo SQL real em cima dele. Para interativo, Para consultas ad-hoc, há duas: o conector federado do Amazon Athena e Bancada de trabalho SQL do DynoTable. (Para análises programadas, o ETL zero do DynamoDB a integração com o Amazon Redshift também executa junções e agregações SQL.)

Como consultar DynamoDB com SQL real via Amazon Athena

A própria resposta do AWS para "SQL real sobre DynamoDB" é a Conector Amazon Athena DynamoDB, que "permite que o Amazon Athena se comunique com o DynamoDB para que você possa consultar suas mesas com SQL." Como Athena é um motor SQL completo, isso faz você JOIN e agregados – o passo a passo do AWS é intitulado "Acesse, consulte e junte tabelas do Amazon DynamoDB usando Athena."

O problema é a configuração e o custo:

• É um conector federado baseado em Lambda que você implanta em sua conta (por meio do console Athena ou do Serverless Application Repository), com fio por meio do AWS Glue para esquema e distribuição de resultados em um balde S3 (documentos do conector).
• Sob o capô, ele ainda usa as operações Query e Scan API do DynamoDB. AWS alerta que “consultas que utilizam varreduras podem consumir um grande número de leituras unidades de capacidade (RCUs)", assim se lê uma consulta analítica em uma grande tabela - e metros — muitos itens (custos do conector). Use o calculadora de tamanho de item para avaliar o que é consulta pesada de digitalização custará.
• Operações de gravação como INSERT INTO não são suportadas pelo conector.

Athena é a ferramenta certa para análises programadas e painéis de BI. É pesado para o caso diário "Eu só preciso juntar duas tabelas e observar o resultado" - essa é a lacuna que a próxima seção preenche.

DynoTable SQL Workbench: SQL dentro das regras de padrão de acesso do DynamoDB

O SQL Workbench do DynoTable executa SQL real - JOIN, GROUP BY, COUNT/SUM/AVG — em suas tabelas DynamoDB ativas de um cliente de desktop, sem Lambda, cola ou S3 para se levantar. Ele materializa as linhas através O tempo de execução real do Query / Scan do DynamoDB e, em seguida, executa um único SELECT sobre eles localmente em sua área de trabalho:

-- 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

A parte "dentro das regras de padrão de acesso do DynamoDB" é importante. A bancada não finja que DynamoDB é Postgres - ele ainda lê Query/Scan sob o capa, para que você fique ciente de quanto custa cada consulta e aplica os requisitos do DynamoDB modelo de acesso em vez de ocultá-lo:

• Somente INNER JOIN e LEFT JOIN — o atributo de destino ON deve ser um chave de partição ou chave de partição GSI. Sem RIGHT / FULL / CROSS / junção de vírgula.
• Ainda não há auto-junções, nem subconsultas, nem tabelas derivadas, nem funções de janela.
• Junções e projeções operam em atributos escalares.

Se você precisar apenas compor as condições e expressões-chave para o API bruto - não é uma declaração SQL completa – o DynamoDB Expression Builder gera o corrija FilterExpression / KeyConditionExpression sem a superfície PartiQL de jeito nenhum.

Se seu objetivo é um cliente DynamoDB SQL para explorar, depurar e analisar tabelas, o Workbench preenche essa lacuna - e o resto do DynoTable é um completo GUI DynamoDB ao redor dele.

Experimente DynoTable para executar SQL real em suas próprias mesas.

FAQ

Você pode executar SQL em DynamoDB? Você pode executar PartiQL, um subconjunto compatível com SQL (SELECT/INSERT/UPDATE/DELETE por chave). Para JOIN, GROUP BY e agregados você precisa de um motor SQL no topo: o Amazon Conector Athena DynamoDB ou SQL Workbench do DynoTable - um único dialeto SELECT com INNER/LEFT JOIN, sem CTEs, uniões ou subconsultas.

O DynamoDB PartiQL suporta JOIN? Não. A sintaxe PartiQL SELECT possui uma única tabela ou índice FROM e nenhuma junção gramática. As junções requerem um mecanismo em camadas sobre o DynamoDB.

O PartiQL suporta GROUP BY ou agregados como COUNT e SUM? Não. Não há cláusula GROUP BY e a única função "agregada" é SIZE (o tamanho em bytes de um atributo para um item). COUNT, SUM, AVG, MIN e MAX entre linhas não são suportadas.

É DynamoDB SQL ou NoSQL? NoSQL — um armazenamento de valores-chave e documentos. PartiQL adiciona uma consulta compatível com SQL linguagem no topo, mas o DynamoDB não possui mecanismo relacional, junções ou agregações.

O PartiQL é bom para consultas ad hoc? Para pesquisas baseadas em chave, sim. Para consultas analíticas ad hoc (contagens, rollups, junções), não - PartiQL não pode expressá-los, e SELECTs irrestritos silenciosamente tornam-se varreduras completas da tabela.

Existe um cliente DynamoDB SQL que lida com JOIN e GROUP BY? Sim - o SQL Workbench do DynoTable executa JOIN/GROUP BY/aggregates contra live tabelas do desktop, e o Amazon Athena faz isso por meio de um conector federado que você implantar em sua conta AWS.