Principiante8 min de lectura

Cómo borrar varios items en DynamoDB

No hay DELETE FROM table WHERE … en DynamoDB. Cada delete apunta a un item por su clave primaria completa — la API no tiene operación de borrado masivo, no tiene truncate, y el DELETE de quita exactamente un item por statement. Así que "borrar varios items" es siempre un trabajo de dos pasos: encontrar las claves, luego emitir un delete por clave, en lote para el throughput.

Esta guía cubre las opciones de batching, la variante transaccional todo-o-nada, el caso de borrar-todo, y cómo hacer lo mismo con una selección y dos teclas en una GUI.

¿Cómo borro varios items en DynamoDB?

Recoge las claves primarias de los items que quieres quitar (vía Query o Scan), luego bórralos en lotes: BatchWriteItem admite hasta 25 DeleteRequests por llamada, TransactWriteItems borra hasta 100 items de forma atómica, y los statements PartiQL DELETE se pueden agrupar de 25 en 25 con BatchExecuteStatement. En DynoTable seleccionas las filas y pulsas ⌘⌫ para stagear los deletes, luego revisas y confirmas.

Paso 0: recoge las claves

Un delete necesita la clave primaria entera — en una tabla eso es la clave de partición y la clave de ordenación (AWS: "For each primary key, you must provide all of the key attributes"). No puedes borrar por un atributo arbitrario, así que "borrar cada item donde status = 'archived'" empieza con una lectura:

  • Si la condición vive en una clave (o una clave de GSI), un Query dirigido recoge las claves barato.
  • Si no, es un Scan con filtro — que lee (y factura) toda la tabla, con o sin filtro; mira query vs scan.

Usa una ProjectionExpression que solo devuelva los atributos de clave, y sigue LastEvaluatedKey hasta el final (paginación) o borrarás en silencio solo la primera página de 1 MB.

Método 1: BatchWriteItem (hasta 25 deletes por llamada)

BatchWriteItem empaqueta hasta 25 put/delete requests o 16 MB por llamada (referencia de la API AWS: "Una sola llamada a BatchWriteItem puede transmitir hasta 16 MB de datos por la red, formados por hasta 25 operaciones de escritura o eliminación de elementos").

aws dynamodb batch-write-item --request-items '{
  "Orders": [
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1001"}, "SK": {"S": "META"}}}},
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1002"}, "SK": {"S": "META"}}}},
    {"DeleteRequest": {"Key": {"PK": {"S": "ORDER#1003"}, "SK": {"S": "META"}}}}
  ]
}'

Tres propiedades del lote tropiezan a la gente — todas sacadas de la referencia de la API:

  • No es atómico: "Las operaciones individuales PutItem y DeleteItem especificadas en BatchWriteItem son atómicas; sin embargo, BatchWriteItem en su conjunto no lo es." Algunos deletes pueden aterrizar mientras otros no.
  • Debes reintentar UnprocessedItems. Las peticiones con throttle vuelven en el mapa de respuesta UnprocessedItems, con la misma forma que la petición — "Typically, you would call BatchWriteItem in a loop", y AWS "strongly recommend[s] that you use an exponential backoff algorithm" entre reintentos.
  • Sin condiciones. "You cannot specify conditions on individual put and delete requests" — un delete condicional tiene que ir por DeleteItem o una transacción. Un lote también rechaza dos operaciones sobre la misma clave en una llamada.

La forma del loop — trocea de 25, envía, reencola lo que queda con backoff — es la misma cubierta en operaciones por lotes.

Método 2: TransactWriteItems (deletes atómicos)

Cuando un conjunto de deletes debe tener éxito o fallar juntos — quitar un item padre y los hijos de su , por ejemplo — usa TransactWriteItems: hasta 100 acciones (deletes, puts, updates, condition checks) aplicadas de forma atómica, con por item permitidas. El trade: una escritura transaccional cuesta el doble de write capacity de una escritura simple. La mecánica completa (idempotency tokens, TransactionCanceledException, cálculo de coste) está en transacciones DynamoDB.

Método 3: PartiQL DELETE, en lote

PartiQL no levanta la regla "una clave a la vez" — solo la reescribe de otra forma. El developer guide es explícito (PartiQL DELETE): "You can delete only one item at a time. You cannot issue a single DynamoDB PartiQL statement that deletes multiple items", y la condición WHERE "must resolve to a single primary key value".

Para borrar varios items, agrupas statements de un solo item — BatchExecuteStatement ejecuta hasta 25 statements por lote (todos de lectura o todos de escritura, nunca mezclados):

[
  {"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1001' AND SK = 'META'"},
  {"Statement": "DELETE FROM \"Orders\" WHERE PK = 'ORDER#1002' AND SK = 'META'"}
]
aws dynamodb batch-execute-statement --statements file://statements.json

Un WHERE que no fija la clave completa falla — no hay DELETE FROM Orders WHERE status = 'archived'. Más patrones PartiQL (y los límites detrás) en ejemplos PartiQL y PartiQL vs SQL.

Borrar TODOS los items (truncate)

DynamoDB no tiene truncate. Tus opciones, por orden de preferencia:

  1. Borrar y recrear la tabla. El delete item a item de una tabla entera factura una escritura por item; DeleteTable + CreateTable evita toda la factura de escritura. El pie: los settings de tabla — índices, TTL, , capacity mode, tags — no vuelven solos; los redesclaras al crear (la infrastructure-as-code lo convierte en un no-evento).
  2. Caducar items con . Si "borrar todo lo más viejo que X" es de verdad lo que quieres, el TTL borra los items caducados en background sin consumir write capacity — un borrado masivo a cámara lenta que no cuesta.
  3. Scan + delete por lotes (Método 1) cuando la tabla debe seguir en servicio y solo se va un subset — pagas una lectura por item escaneado más una escritura por item borrado.

Borrar varios items en DynoTable

El flujo seleccionar-luego-borrar de arriba — query, recoger claves, trocear, reintentar — es exactamente la faena que una GUI debería llevarse. En DynoTable, es una selección en la grid:

  1. Ejecuta o filtra una query para que las filas a borrar estén en pantalla.
  2. Selecciónalas y pulsa ⌘⌫ — cada fila seleccionada se convierte en un delete stageado. Nada ha tocado DynamoDB aún: las filas se tiñen de rojo en la grid y aparecen como tarjetas revisables en el panel de staging.
  3. Revisa, luego confirma. Los commits salen como lotes TransactWriteItems con condiciones de optimistic locking — un delete stageado solo pasa si el item sigue existiendo — y los lotes grandes se trocean automáticamente para quedarse dentro de los límites de transacción de DynamoDB. ⌘⇧⌫ se salta la review y borra-y-confirma la selección en un solo atajo.
Deletes stageados en DynoTable: las filas seleccionadas teñidas de rojo en la grid, cada una una tarjeta revisable en el panel de staging antes de confirmar.
Deletes stageados en DynoTable: las filas seleccionadas teñidas de rojo en la grid, cada una una tarjeta revisable en el panel de staging antes de confirmar.

El alcance es honesto: borras las filas que seleccionaste — una operación revisada, recuperable hasta el commit — no un truncate ciego de toda la tabla. Para vaciar una tabla entera, bórrala y recréala (arriba).

Si un delete necesita una condición escrita a mano (attribute_exists, un check de versión), construye la ConditionExpression exacta + los mapas de placeholders en el DynamoDB Expression Builder y engánchala a un DeleteItem o a una transacción.

FAQ

¿Puedo borrar varios items en una sola llamada DynamoDB? Sí — hasta 25 con BatchWriteItem (best-effort, reintenta los UnprocessedItems) o hasta 100 de forma atómica con TransactWriteItems. Ambos exigen una clave primaria completa por item; ninguno acepta una condición "where" para seleccionar los items.

¿Hay un DELETE WHERE en DynamoDB? No. Ni la API de bajo nivel ni PartiQL pueden borrar por condición — el DELETE de PartiQL exige un WHERE que "se resuelva a un solo valor de clave primaria". Primero haces query o scan por las claves, luego borras cada una.

¿Cómo borro todos los items de una tabla DynamoDB? Para una limpieza completa, borra y recrea la tabla — evita pagar una escritura por item. Para una limpieza por edad, usa TTL, que borra items caducados sin consumir write capacity. Scan + delete por lotes es el plan B cuando la tabla debe seguir en servicio.

¿Por qué reaparecen items tras mi delete por lotes? Casi siempre UnprocessedItems no reintentados: un BatchWriteItem con throttle devuelve en silencio los deletes fallidos en la respuesta, y un código que no loopea sobre ellos "termina" con items todavía en la tabla. Reintenta con exponential backoff hasta que el mapa vuelva vacío.

¿Cuánto cuesta borrar items? Cada delete es una escritura estándar (una WCU por tramo de 1 KB, duplicada en una transacción), y encontrar las claves también cuesta lecturas. Estima el daño con la calculadora de pricing.

¿Prefieres ver lo que borras primero? Descarga DynoTable — selecciona las filas, stagea los deletes con ⌘⌫, revisa los diffs y confirma cuando estés seguro.

Actualizado