P: ¿Qué es Amazon DynamoDB?

Amazon DynamoDB es un servicio de base de datos NoSQL completamente administrado que proporciona un desempeño rápido, predecible y muy fácil de escalar. Amazon DynamoDB permite a los clientes evitar las cargas administrativas que supone tener que utilizar y escalar bases de datos distribuidas, de lo que pasa a ocuparse AWS, de tal modo que no tengan que preocuparse del aprovisionamiento, la instalación y la configuración del hardware, ni tampoco de la planificación de la capacidad de desempeño, la replicación, los parches del software o el escalado de clústeres.

P: ¿Qué administra Amazon DynamoDB por mí?

Amazon DynamoDB elimina una de las principales dificultades del escalado de bases de datos: administrar el software de la base de datos y el aprovisionamiento del hardware necesario para ejecutarla. De hecho, ahora se puede implementar una base de datos no relacional en cuestión de minutos. DynamoDB escala automáticamente la capacidad de desempeño para satisfacer las demandas de carga de trabajo y crea particiones y subparticiones de los datos a medida que crece el tamaño de la base de datos. Además, Amazon DynamoDB realiza una réplica sincronizada de los datos en tres centros de una misma región de AWS, lo que proporciona un alto nivel de disponibilidad y de durabilidad de los datos.

P: ¿Qué significa coherencia de lectura? ¿Por qué debo preocuparme?

Amazon DynamoDB almacena tres copias geográficamente distribuidas de cada tabla para aumentar la disponibilidad y la durabilidad de los datos. La consistencia de lectura representa la manera y la planificación con la que una grabación o actualización correcta de un elemento de datos queda reflejada en una operación de lectura posterior del mismo elemento. Amazon DynamoDB expone lógica que permite especificar las características de consistencia que desee para cada solicitud de lectura dentro de la aplicación.

P: ¿Cuál es el modelo de coherencia de Amazon DynamoDB?

Al leer datos de Amazon DynamoDB, los usuarios pueden especificar si desean que la lectura tenga coherencia alta o final:

Lecturas de coherencia eventual (opción predeterminada): esta opción aumenta el rendimiento de la lectura. No obstante, es posible que este tipo de lectura no refleje los resultados de una escritura realizada recientemente. La consistencia entre todas las copias de datos suele lograrse en un segundo. Si se repite una lectura tras un breve intervalo de tiempo, se deberían devolver los datos actualizados.

Lecturas de coherencia alta: además de la opción de coherencia eventual de las lecturas, Amazon DynamoDB ofrece la flexibilidad y el control para solicitar una lectura de coherencia alta si así lo requiere su aplicación o algún elemento de la misma. Una lectura de coherencia alta devuelve un resultado que refleja todas las escrituras que han obtenido una respuesta satisfactoria antes de realizar la lectura en cuestión.

P: ¿DynamoDB admite actualizaciones atómicas in situ?

Amazon DynamoDB permite realizar actualizaciones rápidas in situ. Basta con realizar una única llamada a la API para aumentar o disminuir algún atributo numérico de una fila. Del mismo modo, puede agregarlo o eliminarlo de manera atómica en conjuntos, listas o mapas. Consulte nuestra documentación relacionada para obtener información adicional acerca de las actualizaciones atómicas.

P: ¿Por qué Amazon DynamoDB se basa en unidades de estado sólido?

Amazon DynamoDB se ejecuta de forma exclusiva en unidades de estado sólido (SSD). Estas unidades nos ayudan a conseguir nuestros objetivos de diseño, que consisten en ofrecer respuestas predecibles y de baja latencia para almacenar datos y obtener acceso a ellos a cualquier escala. El alto desempeño de E/S de las unidades de estado sólido nos permite cubrir de forma eficaz cargas de trabajo de solicitudes a gran escala, así como ofrecer esta eficacia a los clientes con un bajo costo por solicitud.

P: El costo de almacenamiento de DynamoDB parece alto. ¿Se trata de un servicio rentable para el uso previsto?

Como sucede con cualquier producto, instamos a los clientes potenciales de Amazon DynamoDB a que se fijen en el costo total de una solución, y no exclusivamente en los precios. El costo total que supone realizar el mantenimiento de una base de datos es solo una parte de los requisitos del tráfico de solicitudes y de la cantidad de datos almacenados. La mayoría de las cargas de trabajo de las bases de datos se caracterizan por requerir un alto nivel de E/S (muchas lecturas y escrituras por segundo) por cada GB almacenado. Amazon DynamoDB se basa en unidades de estado sólido, por lo que aumenta el costo por cada GB almacenado en relación con los soportes giratorios, pero también nos permite ofrecer costos de solicitud muy bajos. Por lo que observamos en las cargas de trabajo habituales de las bases de datos, la factura total del servicio DynamoDB basado en SSD suele ser más baja que el costo de utilizar una base de datos normal relacional o no relacional basada en soportes giratorios. Si su caso de uso consiste en almacenar una gran cantidad de datos a los que no suele obtener acceso, el servicio DynamoDB podría no ser el más adecuado. En estas situaciones, le recomendamos que utilice S3.

Cabe destacar también que el costo de almacenamiento refleja el costo que supone almacenar varias copias de cada elemento de datos en diferentes instalaciones de una región de AWS.

P: ¿DynamoDB es una solución indicada exclusivamente para aplicaciones de gran escala?

No. DynamoDB ofrece un escalado sencillo, para que pueda escalar automáticamente a medida que incrementan los requisitos de su aplicación. No obstante, si necesita un desempeño rápido y predecible a cualquier escala, DynamoDB puede ser la solución ideal para satisfacer sus necesidades.

P: ¿Cómo puedo empezar a utilizar Amazon DynamoDB?

Haga clic en “Inscribirse” para comenzar con Amazon DynamoDB hoy mismo. A partir de ahí, puede comenzar a interactuar con Amazon DynamoDB mediante la consola de administración de AWS o las API de Amazon DynamoDB. Si utiliza la consola de administración de AWS, puede crear una tabla con Amazon DynamoDB y comenzar a explorar con tan solo unos clics.

P: ¿Qué tipo de funcionalidad de consulta admite DynamoDB?

Amazon DynamoDB soporta operaciones GET/PUT mediante la utilización de una clave principal definida por el usuario. La clave principal es el único atributo obligatorio para los elementos de la tabla e identifica tales elementos de forma exclusiva. La clave principal se especifica cuando se crea una tabla. Además de ello, DynamoDB ofrece un servicio de consultas flexible, ya que le permite consultar atributos clave no principales con la utilización de índices secundarios globales e índices secundarios locales.

Una clave principal puede ser una clave de partición como atributo exclusivo o una clave compuesta partición-clase. Una clave principal de partición como atributo exclusivo podría ser, por ejemplo, "UserID". Esto podría permitir leer y escribir datos rápidamente para un elemento asociado con un ID de usuario determinado.

Una clave compuesta partición-clase se indiza como un elemento de clave de partición y como un elemento de clave de clase. Esta clave de varias partes mantiene una jerarquía entre los valores primero y segundo del elemento. Por ejemplo, una clave compuesta partición-clase podría ser una combinación de "UserID" (partición) y "Timestamp" (clase). Si mantiene la clave de partición de forma constante, puede buscar en el elemento de clave de clase para recuperar elementos. Esto le permitiría utilizar la API Query para, por ejemplo, recuperar todos los elementos para una clave UserID exclusiva en un intervalo de marcas temporales.

Para obtener más información sobre la indexación secundaria global y sus capacidades de consulta, consulte la sección Índices secundarios de las preguntas frecuentes.

 

P: ¿Cómo puedo actualizar y consultar elementos de datos con Amazon DynamoDB?

Después de crear una tabla con la consola de administración de AWS o la API CreateTable, puede utilizar las API PutItem o BatchWriteItem para insertar elementos. A continuación, puede utilizar las API GetItem, BatchGetItem o, si las claves principales compuestas están habilitadas y se utilizan en la tabla, la API de consulta Query para recuperar los elementos que haya añadido a la tabla.

P: ¿Amazon DynamoDB admite las operaciones condicionales?

Sí, puede especificar una condición que debe cumplirse para que se complete una operación Put, Update o Delete en un elemento. Para realizar una operación condicional, puede definir una ConditionExpression construida a partir de lo siguiente:

  • Funciones booleanas: ATTRIBUTE_EXIST, CONTAINS y BEGINS_WITH.
  • Operadores de comparación: =, <>, <, >, <=, >=, BETWEEN e IN
  • Operadores lógicos: NOT, AND y OR.  

Puede construir una expresión condicional de forma libre que combine varias cláusulas condicionales, incluidas cláusulas anidadas. Las operaciones condicionales permiten a los usuarios aplicar sistemas de control de concurrencia optimista en DynamoDB. Para obtener más información sobre las operaciones condicionales, consulte nuestra documentación relacionada.

P: ¿Se soportan las expresiones para las condiciones de clave?

Sí, puede especificar una expresión como parte de la llamada al API de consulta para que se filtren los resultados de acuerdo con los valores de las claves principales de una tabla mediante el parámetro KeyConditionExpression.

P: ¿Se soportan las expresiones para las claves de partición y compuestas partición-clase?

Sí, puede utilizar expresiones tanto para claves de partición como para las claves compuestas partición-clase. Consulte la página de documentación para obtener más información sobre las expresiones compatibles con las claves de partición y compuestas partición-clase.

P: ¿Amazon DynamoDB admite operaciones de incremento o decremento?

Sí, Amazon DynamoDB permite realizar operaciones atómicas de aumento y disminución sobre valores escalares.

P: ¿Cuándo debo utilizar Amazon DynamoDB en lugar de un motor de base de datos relacional en Amazon RDS o Amazon EC2?

Las aplicaciones web de hoy en día generan y consumen grandes volúmenes de datos. Por ejemplo, un juego online podría comenzar con solo unos miles de usuarios y poca carga de trabajo en la base de datos, 10 escrituras y 50 lecturas por segundo. Si el juego tiene éxito, podría pasar a tener millones de usuarios y generar decenas (o incluso centenares) de miles de escrituras y lecturas por segundo. Además, podría llegar a generar terabytes de datos o más al día. Desarrollar sus aplicaciones con Amazon DynamoDB permite comenzar por lo básico y pedir más capacidad de solicitud para una tabla a medida que aumentan sus necesidades, sin tiempos de inactividad. Las tarifas por la capacidad de solicitud aprovisionada son muy rentables, y además Amazon DynamoDB se encarga de dividir los datos y el tráfico entre la capacidad de servidor suficiente para satisfacer sus necesidades. Amazon DynamoDB se ocupa de la administración de la base de datos y usted solo tiene que almacenar y solicitar sus datos. La replicación automática y la conmutación por error ofrecen una tolerancia a errores integrada, alta disponibilidad y durabilidad de los datos. Amazon DynamoDB le aporta la tranquilidad de saber que su base de datos está totalmente administrada y puede crecer según las necesidades de su aplicación.

Aunque Amazon DynamoDB aborda los problemas principales relacionados con la escalabilidad, la administración, el desempeño y la fiabilidad de la base de datos, no ofrece toda la funcionalidad de una base de datos relacional. No admite consultas relacionales (como, por ejemplo, uniones) ni transacciones complejas. Por tanto, si su carga de trabajo precisa de esta funcionalidad o si busca compatibilidad con un motor relacional existente, es mejor que ejecute un motor relacional en Amazon RDS o Amazon EC2. Aunque los motores de base de datos relacionales ofrecen características y una funcionalidad potente, escalar una carga de trabajo más allá de una única instancia es una tarea bastante compleja y exige mucho tiempo y experiencia. Por tanto, si prevé que necesitará aumentar el aprovisionamiento de recursos en su nueva aplicación y no precisa de características relacionales, Amazon DynamoDB será la mejor opción.

P: ¿En qué se diferencia Amazon DynamoDB de Amazon SimpleDB?

¿Cuál de estos servicios debo utilizar? Ambos servicios son bases de datos no relacionales que le ahorran el trabajo que conlleva su administración. Amazon DynamoDB se centra en ofrecer una escalabilidad sencilla y un desempeño rápido y predecible. Se ejecuta en discos de estado sólido (SSD) para ofrecer baja latencia y no impone límites a la capacidad de solicitud ni al tamaño de almacenamiento para una tabla determinada. Esto se debe a que Amazon DynamoDB realiza las particiones de los datos y de la carga de trabajo de forma automática entre un número suficiente de servidores para cubrir las necesidades de ajuste de escala. En cambio, una tabla en Amazon SimpleDB tiene un límite de almacenamiento estricto de 10 GB y está limitada en la capacidad de solicitud que puede alcanzar (normalmente, 25 escrituras/segundo). En caso de que necesite escalas adicionales, usted deberá encargarse de administrar las particiones y las nuevas particiones de los datos a través de tablas de SimpleDB adicionales. Aunque SimpleDB tiene límites de escalado, puede ser una buena solución para cargas de trabajo más reducidas que precisen de flexibilidad en las consultas. Amazon SimpleDB indiza automáticamente todos los atributos de los elementos y, además, ofrece flexibilidad en las consultas costa del desempeño y la escala.

En la entrada del blog de DynamoDB escrita por el director de tecnología de Amazon, Werner Vogels, se ofrece información adicional acerca de la evolución de la tecnología de las bases de datos no relacionales en Amazon.

P: ¿Cuándo debo utilizar Amazon DynamoDB en lugar de Amazon S3?

Amazon DynamoDB almacena datos estructurados, indexados por clave principal, y permite obtener un acceso de lectura y escritura de baja latencia a los elementos cuyo volumen oscila entre 1 byte y 400 KB. Amazon S3 almacena objetos binarios no estructurados y adecuados para almacenar objetos de hasta 5 TB. A fin de optimizar los costos de los servicios de AWS, los objetos de gran tamaño y los conjuntos de datos a los que no obtenga acceso con frecuencia se deberían almacenar en Amazon S3, mientras que los elementos de datos de menor tamaño y los punteros a archivos (posiblemente a objetos de Amazon S3) se deberían guardar en Amazon DynamoDB.

P: ¿Se puede usar DynamoDB en aplicaciones que se ejecuten en cualquier sistema operativo?

Sí. DynamoDB es un servicio administrado en la nube al que se obtiene acceso a través del API. DynamoDB se puede usar en aplicaciones que se ejecuten en cualquier sistema operativo (por ejemplo: Linux, Windows, iOS, Android, Solaris, AIX, HP-UX, etc.). Recomendamos utilizar los kits de desarrollo de software (SDK) de AWS para comenzar a utilizar DynamoDB. Puede encontrar una lista de AWS SDK en la página Recursos para desarrolladores. Si tiene problemas a la hora de instalar o usar uno de nuestros SDK, infórmenos de ello en el foro de AWS correspondiente.


P: ¿Qué es el modelo de datos?

El modelo de datos de Amazon DynamoDB es el siguiente:

Tabla: una tabla es una recopilación de elementos de datos, al igual que una tabla de una base de datos relacional consiste en una recopilación de filas. Cada tabla puede contener un número infinito de elementos de datos. Amazon DynamoDB no sigue ningún esquema, ya que los elementos de datos de una tabla no necesitan tener los mismos atributos ni el mismo número de atributos. Cada tabla debe tener una clave principal. Esta puede ser una clave de atributo única o una clave de atributo "compuesta" que combine dos atributos. Los atributos que designe como clave principal deben encontrarse en todos los elementos, ya que las claves principales identifican de forma exclusiva cada uno de los elementos dentro de la tabla.

Elemento: un elemento se compone de una clave principal o compuesta y de un número flexible de atributos. No existe ningún límite explícito sobre el número de atributos asociados a un elemento individual, pero el tamaño agregado de un elemento, incluidos todos los nombres y los valores de los atributos, no puede exceder400 KB.

Atributo: cada atributo asociado a un elemento de datos se compone de un nombre de atributo (por ejemplo, “Color”) y de un valor o de un conjunto de valores (por ejemplo, “Rojo” o “Rojo, Amarillo, Verde”). Los atributos individuales no tienen ningún límite de tamaño explícito, pero el valor total de un elemento (incluidos todos los nombres y los valores de los atributos) no puede superar 400 KB.

P: ¿Existe algún límite respecto al tamaño de un elemento?

El tamaño total de un elemento, incluidos los nombres y los valores de los atributos, no puede superar los 400 KB.

P: ¿Hay algún límite con respecto al número de atributos que puede tener un elemento?

No existe ningún límite en cuanto al número de atributos que un elemento puede tener. No obstante, el tamaño total de un elemento, incluidos los nombres y los valores de los atributos, no puede superar 400 KB.

P: ¿Cuáles son las API?

  • CreateTable – Crea una tabla y especifica el índice principal utilizado para acceder a los datos.
  • UpdateTable – Actualiza los valores de rendimiento aprovisionados para una tabla determinada.
  • DeleteTable – Elimina una tabla.
  • DescribeTable – Devuelve el tamaño, el estado y la información del índice de la tabla.
  • ListTables – Muestra una lista de todas las tablas asociadas con la cuenta y el punto de enlace actuales.
  • PutItem – Crea un nuevo elemento o reemplaza un elemento anterior por otro nuevo (incluidos todos los atributos). Si en la tabla especificada ya existe un elemento con la misma clave principal, el nuevo elemento reemplazará totalmente al existente. También puede utilizar operadores condicionales para reemplazar un elemento solo si los valores de los atributos cumplen determinadas condiciones, o bien para insertar un nuevo elemento solo en caso de que este no exista todavía.
  • BatchWriteItem – Inserta, sustituye y elimina varios elementos de diversas tablas en una única solicitud, pero no como una transacción única. Admite lotes de hasta 25 elementos para Put o Delete, con un tamaño de solicitud máximo de 16 MB.
  • UpdateItem – Edita los atributos de un elemento existente. También puede utilizar operadores condicionales para realizar una actualización solo si los valores de los atributos del elemento cumplen determinadas condiciones.
  • DeleteItem – Elimina un único elemento de una tabla mediante la clave principal. También puede utilizar operadores condicionales para realizar una eliminación solo si los valores de los atributos del elemento cumplen determinadas condiciones.
  • GetItem – La operación GetItem devuelve un conjunto de atributos de un elemento que coincide con la clave principal. La operación GetItem, de forma predeterminada, ofrece una lectura consistente final. Si las lecturas consistentes finales no son aceptables para su aplicación, utilice ConsistentRead.
  • BatchGetItem – La operación BatchGetItem devuelve los atributos de varios elementos de varias tablas mediante la utilización de sus claves principales. Una única respuesta tiene un límite de tamaño de 16 MB y devuelve un máximo de 100 elementos. Admite tanto la consistencia firme como la final.
  • Query –  Obtiene uno o varios elementos mediante la clave principal de la tabla, o de un índice secundario mediante la clave del índice. Puede reducir el alcance de la consulta realizada en una tabla mediante expresiones u operadores comparativos. También puede filtrar los resultados de las consultas mediante la utilización de filtros en los atributos que no son clave. Admite tanto la coherencia firme como la final. Una única respuesta tiene un límite de tamaño de 1 MB.
  • Scan – Obtiene todos los elementos y atributos al realizar un análisis completo de la tabla o de un índice secundario. Puede limitar el resultado mediante la definición de filtros para uno o varios atributos.

P: ¿Cuál es el modelo de consistencia de la operación de análisis?

La operación de análisis soporta lecturas de consistencia alta o final. De forma predeterminada, la operación de análisis es de consistencia final. Sin embargo, puede modificar el modelo de consistencia mediante el parámetro ConsistentRead en la llamada al API Scan. Si configura el parámetro ConsistentRead en modo verdadero, se realizarán lecturas consistentes de la operación de análisis. Para obtener más información, lea la documentación sobre la operación de análisis.

P: ¿Cómo funciona la operación de análisis?

Puede considerar la operación de análisis Scan como un iterador. Si el tamaño agregado de los elementos analizados para una solicitud del API Scan determinada supera el límite de 1 MB, la solicitud terminará y los resultados encontrados se devolverán junto con un API LastEvaluatedKey (para continuar el análisis en una operación posterior).

P: ¿Hay alguna limitación para una operación de análisis?

Una operación de análisis en una tabla o en un índice secundario tiene un límite de 1 MB de datos por operación. Tras alcanzar el límite de 1 MB, detiene la operación y devuelve los valores coincidentes hasta dicho punto y un valor LastEvaluatedKey para aplicarlo en una operación ulterior, para que pueda reanudar la operación desde donde la dejó.

P: ¿Cuántas unidades de capacidad de lectura consume una operación de análisis?

Las unidades de lectura necesarias representan el número de bytes consumidos por la operación de análisis, redondeado a los 4 KB más próximos, dividido entre 4 KB. El análisis de una tabla con lecturas consistentes alta consume el doble de capacidad de lectura que un análisis con lecturas consistentes finales.

P: ¿Qué tipos de datos soporta DynamoDB?

DynamoDB soporta cuatro tipos de datos escalares: números, cadenas, binarios y booleanos. Además, DynamoDB soporta los tipos de datos de recopilación: Conjunto de números, conjunto de binarios, lista heterogénea y mapa heterogéneo. DynamoDB también soporta valores NULL.

P: ¿Qué tipos de estructuras de datos soporta DynamoDB?

DynamoDB soporta las estructuras de datos de valor de clave y de documentos.

P: ¿Qué es el almacén de valor clave?

El almacenamiento de valor de clave es un servicio de base de datos que proporciona soporte para el almacenamiento, la realización de consultas y la actualización de conjuntos de objetos que se identifican mediante una clave y valores que incluyen el contenido almacenado.

P: ¿Qué es el almacén de documentos?

El almacenamiento en documentos proporciona soporte para el almacenamiento, la realización de consultas y la actualización de elementos en un formato de documento, como JSON, XML y HTML.

P: ¿Dispone DynamoDB del tipo de datos JSON?

No, pero puede utilizar el documento SDK para transferir los datos JSON directamente a DynamoDB. Los tipos de datos de DynamoDB son un superconjunto de los tipos de datos compatibles con JSON. El Documento SDK transformará automáticamente los documentos JSON en tipos de datos nativos de DynamoDB.

P: ¿Puedo utilizar la consola de administración de AWS para ver y editar documentos JSON?

Sí. La consola de administración de AWS proporciona una interfaz de usuario sencilla que permite explorar y editar los datos almacenados en sus tablas de DynamoDB, incluidos documentos JSON. Para ver o editar datos en su tabla, inicie sesión en la consola de administración de AWS, elija DynamoDB, seleccione la tabla que desea ver y haga clic en el botón "Explorar tabla".

P: ¿La consulta de datos JSON es diferente en DynamoDB?

No. Puede crear un índice secundario global o local en cualquier elemento JSON de nivel superior. Por ejemplo, suponga que ha almacenado un documento JSON que contiene la siguiente información sobre alguien: nombre, apellidos, código postal y una lista de todos sus amigos. El nombre, los apellidos y el código postal son elementos JSON de nivel superior. Podría crear un índice que le permita realizar una consulta a partir del nombre, apellido o código postal. Sin embargo, la lista de amigos no es un elemento de nivel superior, por lo que no se puede indexar. Para obtener más información sobre la indexación secundaria global y sus capacidades de consulta, consulte la sección Índices secundarios de estas preguntas frecuentes.

P: Si tengo datos JSON anidados en DynamoDB, ¿solamente puedo recuperar un elemento específico de los mismos?

Sí. Al utilizar las API GetItem, BatchGetItem, Query o Scan, puede definir una ProjectionExpression que determine qué atributos deberán recuperarse de la tabla. Estos atributos pueden incluir escalares, conjuntos o elementos de un documento JSON.

P: Si tengo datos JSON anidados en DynamoDB, ¿solamente puedo actualizar un elemento específico de los mismos?

Sí. Al actualizar un elemento de DynamoDB, puede especificar el subelemento del documento JSON que desea actualizar.

P: ¿Qué es el Documento SDK?

El Documento SDK es un contenedor de tipos de datos para JavaScript que facilita la interoperabilidad entre los tipos de datos de DynamoDB y JS. Mediante este SDK, se efectuará automáticamente la encapsulación de las solicitudes. En el caso de las respuestas, se desencapsularán los tipos de datos. Para obtener más información y descargar el SDK, consulte el repositorio de GitHub aquí.

 


P: ¿Hay un límite con respecto al volumen de datos que puedo almacenar en Amazon DynamoDB?

No. No existe ningún límite en cuanto a la cantidad de datos que se pueden almacenar en una tabla de Amazon DynamoDB. A medida que aumente el conjunto de datos, Amazon DynamoDB los distribuirá automáticamente entre los recursos de máquina suficientes para satisfacer sus necesidades de almacenamiento.

P: ¿Hay un límite con respecto al nivel de rendimiento que puedo obtener de una única tabla?

No, puede incrementar el ajuste del límite de capacidad máxima de Auto Scaling o incrementar el desempeño que ha aprovisionado manualmente para su tabla con la API o la consola de administración de AWS. DynamoDB puede operar a escala masiva y no existe ningún límite teórico para el desempeño máximo que puede conseguir. El servicio divide automáticamente la tabla en varias particiones, cada una de ellas una unidad de computación paralela independiente. DynamoDB puede conseguir tasas de desempeño cada vez más altas añadiendo particiones.

Si quiere superar desempeños de 10 000 escrituras/segundo o 10 000 lecturas/segundo, primero debe contactar con Amazon a través de este formulario online.

P: ¿Amazon DynamoDB sigue disponible cuando Auto Scaling activa el escalado o cuando solicito que aumente o disminuya el rendimiento previsto haciendo el cambio correspondiente para ello?

Sí. Amazon DynamoDB está diseñado para aumentar o reducir su desempeño aprovisionado al tiempo que permanece disponible, ya sea administrado por Auto Scaling o manualmente.

P: ¿Necesito gestionar particiones cliente sobre Amazon DynamoDB?

No. Amazon DynamoDB elimina la necesidad de realizar particiones en las tablas de las bases de datos para aumentar o reducir el desempeño.

P: ¿Qué alto nivel de disponibilidad tiene Amazon DynamoDB?

El servicio se ejecuta en centros de datos probados y de alta disponibilidad de Amazon. El servicio replica datos en tres instalaciones de una región de AWS a fin de ofrecer tolerancia a errores en caso de que falle el servidor o de que se produzcan interrupciones en la zona de disponibilidad.

P: ¿Cómo consigue Amazon DynamoDB un alto nivel de tiempo de actividad y durabilidad?

Para conseguir altos niveles de tiempos de actividad y durabilidad, Amazon DynamoDB replica los datos de forma sincronizada entre las tres instalaciones de una región de AWS.


P: ¿Qué es DynamoDB Auto Scaling?

DynamoDB Auto Scaling es una característica totalmente administrada que incrementa o reduce automáticamente la capacidad de lectura y escritura aprovisionada de una tabla de DynamoDB o un índice secundario global, a medida que aumentan o disminuyen las solicitudes de una aplicación.

P: ¿Por qué debo utilizar Auto Scaling?

Auto Scaling elimina las conjeturas a la hora de aprovisionar capacidad adecuada al crear tablas nuevas y reduce la carga operativa de la monitorización constante del desempeño consumido y el ajuste manual de la capacidad aprovisionada. Auto Scaling ayuda a garantizar la disponibilidad de la aplicación y reduce los costos de la capacidad aprovisionada no utilizada.

P: Qué patrones de solicitud y carga de trabajo de aplicaciones son aptos para Auto Scaling?

Auto Scaling es ideal para patrones de solicitudes uniformes, predecibles y con un uso elevado y reducido del desempeño sostenido que dura entre varios minutos y horas.

P: ¿Cómo puedo habilitar Auto Scaling para una tabla de DynamoDB o índice secundario global?

Desde la consola de DynamoDB, cuando cree una nueva tabla, deje la opción "Usar ajustes predeterminados" marcada para habilitar Auto Scaling y aplique los mismos ajustes de índices secundarios globales para la tabla. Si desactiva "Usar ajustes predeterminados", puede determinar la capacidad aprovisionada manualmente o habilitar Auto Scaling con valores personalizados para el uso objetivo y la capacidad mínima y máxima. Para tablas existentes, puede habilitar Auto Scaling o cambiar ajustes de Auto Scaling existentes dirigiéndose a la pestaña "Capacidad". Para los índices, puede habilitar Auto Scaling desde la pestaña "Índices". Auto Scaling también se puede administrar de manera programática con la CLI o el SDK de AWS. Para obtener más información, consulte la Guía para desarrolladores de DynamoDB.

P: ¿Qué ajustes puedo configurar para Auto Scaling?

Hay tres ajustes configurables para Auto Scaling: el uso objetivo, el porcentaje del desempeño consumido real en relación con el desempeño aprovisionado total en un momento determinado, y la capacidad mínima y la capacidad máxima a la que Auto Scaling puede escalarse. El valor por defecto del uso objetivo es 70% (el espectro admitido es 20%-80% en incrementos del 1%), la capacidad mínima es 1 unidad y la capacidad máxima es el límite de la tabla para su cuenta en la región. Consulte la página Límites en DynamoDB para informarse de los límites por defecto de las tablas a nivel de región.

P: ¿Puedo cambiar los ajustes de una política de Auto Scaling existente?

Sí, puede cambiar los ajustes de una política de Auto Scaling existente en cualquier momento dirigiéndose a la pestaña "Capacidad" en la consola de administración o de manera programática desde la CLI o el SDK con las API de AutoScaling.

P: ¿Cómo funciona Auto Scaling?

Cuando crea una nueva política de Auto Scaling para su tabla de DynamoDB, se crean alarmas de Amazon CloudWatch con los umbrales de uso objetivo que especifico, calculados en función de las métricas de capacidad consumida y aprovisionada publicadas en CloudWatch. Si el uso real de la tabla varía del uso objetivo durante un tiempo determinado, las alarmas de CloudWatch activan Auto Scaling, que evalúa su política y realiza una solicitud de la API UpdateTable a DynamoDB para que incremente (o reduzca) dinámicamente la capacidad de desempeño aprovisionada de la tabla para acercar el uso real al uso objetivo.

P: ¿Puedo habilitar una sola política de Auto Scaling en varias tablas de varias regiones?

No, una política de Auto Scaling solo puede configurarse para una sola tabla o índice secundario global dentro de una sola región.

P: ¿Puedo obligar una política de Auto Scaling a escalarse a la capacidad máxima o mínima al instante?


No, no se admite el escalado instantáneo a la capacidad mínima o máxima. En vez, puede deshabilitar temporalmente Auto Scaling, configurar la capacidad que necesite manualmente para la duración requerida, y volver a habilitar Auto Scaling más adelante.

P: ¿Dónde puedo monitorizar las acciones de escalado activadas por Auto Scaling?

Puede monitorizar el estado de las acciones de escalado activadas por Auto Scaling en la pestaña "Capacidad" de la consola de administración y desde los gráficos de CloudWatch en la pestaña "Métricas".

P: ¿Cómo puedo saber si una tabla tiene una política activa de Auto Scaling?

Desde la consola de DynamoDB, haga clic en Tablas en el menú izquierdo para abrir la vista de lista de todas las tablas de DynamoDB de su cuenta. En el caso de tablas con una política de Auto Scaling, la columna "Auto Scaling" mostrará READ_CAPACITY, WRITE_CAPACITY o READ_AND_WRITE dependiendo de si Auto Scaling está habilitado para lectura, escritura o ambas. Además, en la sección "Detalles de la tabla" de la pestaña "Vista general" de una tabla, la etiqueta de capacidad aprovisionada muestra si Auto Scaling está habilitado para lectura, escritura o ambas.

P: ¿Qué ocurre con la política de Auto Scaling cuando elimino una tabla o índice secundario global con una política activa?

Cuando elimina una tabla o índice secundario global de la consola, su política de Auto Scaling y las alarmas de CloudWatch correspondientes también se eliminan.

P: ¿Conlleva el uso de Auto Scaling algún costo adicional?

No, el uso de Auto Scaling no conlleva ningún costo adicional, aparte de lo que ya paga por DynamoDB y las alarmas de CloudWatch. Si desea más información sobre los precios de DynamoDB, visite la página de precios de DynamoDB.

P: ¿Cómo funciona la capacidad de desempeño administrada por Auto Scaling con la capacidad reservada que tengo?

Auto Scaling funciona con la capacidad reservada del mismo modo que la capacidad de desempeño aprovisionada manualmente lo hace en la actualidad. La capacidad reservada se aplica a la capacidad aprovisionada total para la región en la que la ha comprado. La capacidad aprovisionada por Auto Scaling consumirá la capacidad reservada primero, facturada de acuerdo con las tarifas con descuento, mientras que cualquier capacidad en exceso se cobrará de acuerdo con las tarifas estándar. Para limitar el consumo total a la capacidad reservada que ha comprado, distribuya el límite de capacidad máximo entre todas las tablas con Auto Scaling habilitado, de manera que el total acumulado sea inferior a la cantidad de capacidad reservada total que ha adquirido.


P: ¿Qué son los índices secundarios globales?

Los índices secundarios globales son índices que contienen una partición o claves de partición y clase que pueden ser diferentes de la clave principal de la tabla.

Para que el acceso a los datos de una tabla resulte eficaz, Amazon DynamoDB crea y mantiene los índices para los atributos de clave principal. Esto permite a las aplicaciones recuperar datos con rapidez mediante la especificación de los valores de clave principal. No obstante, muchas aplicaciones pueden beneficiarse de contar con una o varias claves secundarias (o alternativas) disponibles para permitir un acceso eficaz a los datos con atributos distintos de la clave principal. Para ello, puede crear uno o varios índices secundarios en una tabla y realizar solicitudes de consulta a estos índices.

Amazon DynamoDB soporta dos tipos de índices secundarios:

  • Índice secundario local – Un índice que tiene la misma clave de partición que la tabla, pero una clave de clase distinta. Un índice secundario local es “local” porque cada partición de un índice secundario local se basa en una partición de tabla que tiene la misma clave de partición.
  • Índice secundario global – Un índice con una clave de partición o una clave de partición y clase que puede diferir de las claves de la tabla. Un índice secundario global se considera “global” porque las consultas del índice pueden abarcar todos los elementos de una tabla en todas las particiones. 

Amazon DynamoDB mantiene los índices secundarios automáticamente como objetos poco poblados. Los elementos solo aparecerán en un índice si se encuentran en la tabla en la que se ha definido el índice. Esto hace que las consultas a un índice sean muy eficaces, ya que el número de elementos del índice a menudo será muy inferior al número de elementos de la tabla.

Los índices secundarios globales soportan atributos no exclusivos, lo que aumenta la flexibilidad de las consultas por el hecho de admitir consultas de atributos de la tabla que no son claves.

Consideremos una aplicación de juegos que almacena información de sus jugadores en una tabla de DynamoDB, cuya clave principal se compone de UserId (partición) y GameTitle (clase). Los elementos tienen atributos denominados TopScore, Timestamp, ZipCode y otros. Al crear la tabla, DynamoDB ofrece un índice implícito (índice principal) sobre la clave principal que puede soportar consultas eficaces que devuelven las puntuaciones máximas de un usuario específico en todos los juegos.

No obstante, si la aplicación necesita las puntuaciones máximas de los usuarios para un juego en concreto, utilizar este índice principal resultaría ineficaz, ya que habría que analizar toda la tabla. En su lugar, un índice secundario global con GameTitle como el elemento de clave de partición y TopScore como el elemento de clave de clase permitiría a la aplicación recuperar rápidamente las puntuaciones máximas de un juego.

Un índice secundario global no precisa de un elemento de clave de clase. Por ejemplo, podría disponer de un índice secundario global con una clave que solo tenga un elemento de partición GameTitle. En el ejemplo siguiente, el índice secundario global no tiene atributos proyectados, por lo que solo devolverá todos los elementos (identificados por la clave principal) que tengan un atributo que coincida con el atributo GameTitle que se está consultando.

P: ¿Cuándo debo utilizar los índices secundarios globales?

Los índices secundarios globales resultan particularmente útiles para realizar un seguimiento de las relaciones entre los atributos que tienen muchos valores diferentes. Por ejemplo, podría crear una tabla de DynamoDB con CustomerID como la clave de partición principal para la tabla y ZipCode como la clave de partición para un índice secundario global, ya que hay muchos códigos postales y porque posiblemente tendrá muchos clientes. Con la utilización de la clave principal, podría obtener rápidamente el registro de cualquier cliente. Con el índice secundario global, podría consultar con eficacia todos los clientes con un código postal determinado.

Para asegurarse de que aprovecha la máxima capacidad del índice secundario global, consulte nuestra documentación de prácticas recomendadas sobre cargas de trabajo uniformes.

P: ¿Cómo puedo crear un índice secundario global para una tabla de DynamoDB?

El GSI (índice secundario global) asociado a una tabla puede especificarse en cualquier momento. Para obtener pasos detallados sobre cómo crear una tabla y sus índices, haga clic aquí. Puede crear un máximo de 5 índices secundarios globales por cada tabla.

P: ¿Es compatible la versión local de DynamoDB con los índices secundarios globales?

Sí. La versión local de DynamoDB resulta útil para el desarrollo y la prueba de aplicaciones con DynamoDB. Puede descargar la versión más actualizada de DynamoDB aquí.

P: ¿Qué son los atributos proyectados?

Los datos de un índice secundario se componen de atributos proyectados o copiados, en el índice desde la tabla. Al crear un índice secundario, defina una clave alternativa para el índice, junto con otros atributos que desee proyectar en el índice. Amazon DynamoDB copia estos atributos en el índice, junto con los atributos de la clave principal, desde la tabla. Posteriormente, puede consultar el índice exactamente de la misma forma en que consultaría una tabla.

P: ¿Una clave de índice secundario global se puede definir para atributos no exclusivos?

Sí. A diferencia de la clave principal de una tabla, un índice secundario global no requiere que los atributos indizados sean exclusivos. Por ejemplo, un índice secundario global en GameTitle podría indizar todos los elementos que realizan un seguimiento de las puntuaciones de los usuarios para cada juego. En este ejemplo, este índice secundario global puede consultarse para obtener todos los usuarios que han jugado al juego “TicTacToe”.

P: ¿En qué difieren los índices secundarios globales de los locales?

Los índices secundarios globales y locales mejoran la flexibilidad de las consultas. Un índice secundario local está vinculado a un valor de clave de partición específico, mientras que un índice secundario global abarca todos los valores de clave de partición. Dado que los elementos que tienen el mismo valor de clave de partición comparten la misma partición en DynamoDB, el índice secundario “local” solo abarca los elementos que están almacenados juntos (en la misma partición). Por tanto, el propósito del índice secundario local es consultar elementos que tienen el mismo valor de clavede partición, pero distintos valores de clave de clase. Por ejemplo, consideremos una tabla de DynamoDB que realiza un seguimiento de los pedidos de los clientes, donde CustomerId es la clave de partición.

Un índice secundario local OrderTime permite realizar consultas eficaces para recuperar los últimos elementos solicitados de un cliente particular.

En cambio, un índice secundario global no está restringido a los elementos con un valor de clave de partición común. En lugar, el índice secundario global abarca todos los elementos de la tabla, al igual que la clave principal. Para la tabla anterior, se puede utilizar un índice secundario global para ProductId para encontrar con eficacia todos los pedidos de un producto concreto. Tenga en cuenta que, en este caso, no se especifica ninguna clave de clase de índice secundario global y, aunque puede haber muchos pedidos con el mismo atributo ProductId, se almacenarán como elementos independientes en el índice secundario global.

A fin de garantizar que los datos de la tabla y del índice se colocan en la misma partición, los índices secundarios locales limitan [] el tamaño total de todos los elementos (tablas e índices) a 10 GB por valor de clave de partición. Los índices secundarios locales no fuerzan la co-location de los datos y no tienen dicha restricción.

Al escribir en una tabla, DynamoDB actualiza atómicamente todos los índices secundarios locales afectados. En cambio, las actualizaciones de los índices secundarios globales definidos en la tabla son finalmente coherentes.

Los índices secundarios locales permiten que el API de consulta recupere los atributos que no forman parte de la lista de proyección. Los índices secundarios globales no soportan este comportamiento.

P: ¿Cómo funcionan los índices secundarios globales?

De muchas formas, el comportamiento del índice secundario global es similar al de una tabla de DynamoDB. Puede consultar un índice secundario global a través de su elemento de clave de partición mediante el uso de filtros condicionales en el elemento de clave de clase del índice secundario global. No obstante, a diferencia de la clave principal de la tabla de DynamoDB, que debe ser exclusiva, la clave de índice secundario global puede ser la misma para varios elementos. Si existen varios elementos con la misma clave de índice secundario global, se hace un seguimiento de los mismos como elementos de índice secundario global independientes, y una consulta del índice secundario global los recuperará todos como elementos individuales. Internamente, DynamoDB garantizará que los contenidos del índice secundario global se actualicen correctamente a medida que los elementos se añaden, eliminan o actualizan.

DynamoDB almacena atributos proyectados de un índice secundario global en la estructura de datos del índice secundario global, junto con la clave de índice secundario global y las claves principales de los elementos coincidentes. Los índices secundarios globales consumen almacenamiento de los elementos proyectados que existen en la tabla de origen. Esto permite realizar consultas del índice secundario global en lugar de la tabla, lo que aumenta la flexibilidad de las consultas y mejora la distribución de la carga de trabajo. Los atributos que forman parte de algún elemento de una tabla, pero no de la clave del índice secundario global, de la clave principal de la tabla o de los atributos proyectados no se devuelven al consultar el índice secundario global. Las aplicaciones que necesitan datos adicionales de la tabla después de consultar el índice secundario global pueden recuperar la clave principal del índice secundario global y usar las API GetItem o BatchGetItem para recuperar los atributos deseados de la tabla. Puesto que al final los índices secundarios globales son coherentes, las aplicaciones que utilizan este patrón tienen que admitir la eliminación de elementos (desde la tabla) entre las llamadas al índice secundario global y GetItem/BatchItem.

DynamoDB administra automáticamente las adiciones, actualizaciones y eliminaciones de elementos en un índice secundario global cuando se realizan los cambios correspondientes en la tabla. Cuando se añade un elemento (con atributos de clave de índice secundario global) a la tabla, DynamoDB actualiza el índice secundario global de forma asincrónica para añadir el nuevo elemento. De forma similar, cuando se elimina un elemento de la tabla, DynamoDB también lo elimina del índice secundario global afectado.

P: ¿Puedo crear índices secundarios globales para tablas basadas en particiones y tablas de esquema partición-clase?

Sí, puede crear un índice secundario global con independencia del tipo de clave principal que la tabla DynamoDB tiene. La clave principal de la tabla puede incluir una clave de partición, o una clave de partición y una clave de clase.

P: ¿Qué es el modelo de consistencia de los índices secundarios globales?

Los índices secundarios globales soportan la consistencia final. Cuando se insertan o actualizan elementos en una tabla, los índices secundarios globales no se actualizan de forma sincrónica. En condiciones de funcionamiento normales, escribir en un índice secundario global propagará el cambio en una fracción de un segundo. En escenarios de errores poco probables, pueden producirse retrasos más largos. Debido a ello, la lógica de la aplicación debe ser capaz de administrar los resultados de la consulta de índice secundario global que están potencialmente desfasados. Tenga en cuenta que se trata del mismo comportamiento que muestran otras API de DynamoDB que soportan las lecturas finalmente consistentes.

Consideremos una tabla en la que se hace un seguimiento de las puntuaciones máximas, donde cada elemento tiene los atributos UserId, GameTitle y TopScore. La clave de partición principal es UserId y la clave de clase principal es GameTitle. Si la aplicación añade un elemento que denota una nueva puntuación máxima para GameTitle "TicTacToe" y UserId "GAMER123" y posteriormente se consulta el índice secundario global, es posible que la nueva puntuación no aparezca en el resultado de la consulta. No obstante, cuando se ha completado la propagación del índice secundario global, el nuevo elemento comenzará a aparecer en las consultas del índice secundario global.

P: ¿Puedo aprovisionar el desempeño por separado para la tabla y para cada índice secundario global?

Sí. Los índices secundarios globales administran el desempeño de forma independiente de la tabla en la que se basan. Cuando habilita Auto Scaling para una tabla nueva o existente desde la consola, puede elegir si lo desea aplicar los mismos ajustes a GSI. También puede aprovisionar distintos desempeños para las tablas y los índices secundarios globales manualmente.

En función de la aplicación, la carga de trabajo solicitada en un índice secundario local puede variar significativamente con respecto a la de la tabla o a otros índices secundarios globales. A continuación se detallan algunas situaciones de este tipo:

  • Un índice secundario global que contiene una pequeña fracción de los elementos de la tabla necesita un desempeño de escritura mucho más bajo con respecto al de la tabla.
  • Un índice secundario global utilizado para búsquedas de elementos poco frecuentes necesita un desempeño de lectura mucho más bajo con respecto al de la tabla.
  • Un índice secundario global utilizado por una tarea básica con uso intensivo de lecturas puede necesitar un desempeño de lectura alto durante algunas horas al día.

A medida que aumentan las necesidades, puede cambiar el desempeño aprovisionado del índice secundario global, con independencia del desempeño aprovisionado de la tabla.

Consideremos una tabla de DynamoDB con un índice secundario global que proyecta todos los atributos y tiene la clave de índice secundario global en el 50% de los elementos. En este caso, las unidades de capacidad de escritura aprovisionada del índice secundario global deben definirse en un 50% de las unidades de capacidad de escritura aprovisionada de la tabla. Con un planteamiento similar, puede estimarse el rendimiento de lectura del índice secundario global. Consulte la documentación sobre el índice secundario global de DynamoDB para obtener más detalles.

P: ¿En qué repercute añadir un índice secundario global en el desempeño y el almacenamiento aprovisionados para una tabla?

De forma similar a una tabla de DynamoDB, un índice secundario global consume desempeño aprovisionado cuando se hacen lecturas o escrituras en él. Una escritura que añade o actualiza un elemento de índice secundario global consumirá unidades de capacidad de escritura en función del tamaño de la actualización. La capacidad consumida por la escritura del índice secundario global es adicional a la que se necesita para actualizar el elemento en la tabla.

Tenga en cuenta que si añade, elimina o actualiza un elemento de una tabla de DynamoDB y esto no produce ningún cambio en un índice secundario global, este índice no consumirá ninguna unidad de capacidad de escritura. Esto ocurre cuando se añade un elemento sin ningún atributo de clave de índice secundario global a la tabla de DynamoDB, o bien cuando se actualiza un elemento sin cambiar ninguna clave de índice secundario global ni ningún atributo proyectado.

Una consulta de un índice secundario global consume unidades de capacidad de lectura, en función del tamaño de los elementos examinados por la consulta.

Los costos de almacenamiento de un índice secundario global se basan en el número total de bytes almacenados en dicho índice secundario global. Esto incluye la clave de índice secundario global y los valores y atributos proyectados y una sobrecarga de 100 bytes para fines de indexación.

P: ¿DynamoDB puede limitar las escrituras de mi aplicación en una tabla por el desempeño aprovisionado de un índice secundario global?

Habida cuenta de que algunas o todas las escrituras realizadas en una tabla de DynamoDB resultan en escrituras en índices secundarios globales relacionados, es posible que pueda agotarse el desempeño aprovisionado de un índice secundario global. En tal caso, se limitarán las escrituras posteriores en la tabla. Esto puede producirse incluso si la tabla tiene unidades de capacidad de escritura disponibles.

P: ¿Con qué frecuencia puedo cambiar el desempeño aprovisionado del índice?

Las tablas con índices secundarios globales tienen los mismos límites diarios en cuanto al número de operaciones de cambios de desempeño que las tablas normales.

P: ¿Cómo se me cobra la utilización del índice secundario global de DynamoDB?

El rendimiento aprovisionado agregado de una tabla y sus índices secundarios globales se cobran por hora. Aunque no es necesario, cuando aprovisiona manualmente, se le cobra por el desempeño aprovisionado acumulado de una tabla y sus GSI por hora. Además, se factura el almacenamiento de datos consumido por el índice secundario global, además de tarifas (externas) de transferencia de datos estándar. Si desea cambiar la capacidad de desempeño aprovisionada para los GSI, puede hacerlo en la consola de DynamoDB, o la API UpdateTable o la API PutScalingPolicy para actualizar los ajustes de la política de Auto Scaling.

P: ¿Puedo especificar qué índice secundario global debe utilizarse para una consulta?

Sí. Además de los parámetros de consulta comunes, un comando Query del índice secundario global incluye explícitamente el nombre del índice secundario global que cabe utilizar. Tenga en cuenta que una consulta solo puede utilizar un índice secundario global.

P: ¿Qué llamadas de API soportan un índice secundario global?

Las llamadas a las API soportadas por un índice secundario global son Query y Scan. Una operación Query solo busca los valores de atributos de clave de índice y soporta un subconjunto de operadores comparativos. Dado que los índices secundarios globales se actualizan de forma asincrónica, no puede utilizar el parámetro ConsistentRead con la consulta. Haga clic aquí para consultar los detalles sobre la utilización de los índices secundarios globales con consultas y análisis.

P: ¿En qué orden se presentan los resultados del análisis de un índice secundario global?

Si se trata de un índice secundario global, con un esquema de una única clave de partición, la ordenación no se lleva cabo. Para índices secundarios globales con esquema partición-clase, la ordenación de los resultados para la misma clave de partición se basa en el atributo por clase.

P: ¿Puedo cambiar los índices secundarios globales después de haberse creado una tabla?

Sí, los índices secundarios globales pueden cambiarse en cualquier momento, incluso después de haberse creado la tabla.

P: ¿Cómo puedo añadir un índice secundario global a una tabla existente?

Puede añadir índices secundarios globales a través de la consola o de una llamada API. En la consola de DynamoDB, primero seleccione la tabla a la que desea añadir un índice secundario global y haga clic en el botón “Create Index” para añadir un nuevo índice. Siga los pasos del asistente para la creación de índices y seleccione “Create” cuando termine. También puede añadir o eliminar un índice secundario global mediante la llamada API UpdateTable con el parámetro GlobalSecondaryIndexes. Para obtener más información, consulte nuestra página de documentación.

P: ¿Cómo puedo eliminar un índice secundario global?

Puede eliminar índices secundarios globales a través de la consola o con una llamada al API. En la consola DynamoDB, seleccione la tabla para la que desea eliminar un índice secundario global. A continuación, seleccione la pestaña "Indexes" en "Table Items" y haga clic en el botón "Delete" para borrar el índice. También puede eliminar un índice secundario global mediante la llamada API UpdateTable. Para obtener más información, consulte nuestra página de documentación.

P: ¿Puedo añadir o eliminar más de un índice en una sola llamada a API en la misma tabla?

Solo puede añadir o eliminar un índice por cada llamada al API.

P: ¿Qué sucede si envío múltiples solicitudes para añadir el mismo índice?

Solo se acepta la primera solicitud para añadir y se producirá un error en todas las posteriores hasta que se complete la primera.

P: ¿Puedo añadir o eliminar varios índices en la misma tabla simultáneamente?

No, en todo momento puede estar activa únicamente la operación de añadir o eliminar índice en una tabla.

P: ¿Debo aprovisionar desempeño adicional para añadir un índice secundario global?

Con Auto Scaling, se recomienda que utilice los mismos ajustes para el índice secundario global que para la tabla. Aunque no es necesario, cuando aprovisiona manualmente, se recomienda encarecidamente aprovisionar desempeño de escritura adicional independiente del desempeño del índice. Si no aprovisiona desempeño de escritura adicional, se consumirá el desempeño de escritura del índice para añadir el nuevo índice. Esto afectará al desempeño de escritura del índice mientras se crea el índice, además de aumentar el tiempo para crear el nuevo índice.

P: ¿Debo reducir el desempeño adicional en un índice secundario global una vez que se ha creado el índice?

Sí, una vez completado el proceso debe cancelar el rendimiento de escritura adicional que ha aprovisionado para añadir un índice.

P: ¿Puedo modificar el desempeño de escritura aprovisionado para añadir un índice secundario global?

Sí, puede incrementar o reducir el rendimiento de escritura aprovisionado para la creación del índice en cualquier momento durante el proceso de creación.

P: ¿Sigue la tabla disponible cuando se añade o elimina un índice secundario global?

Sí, la tabla está disponible cuando se actualiza el índice secundario global.

P: ¿Siguen los índices existentes disponibles cuando se añade o se elimina un índice secundario global?

Sí, los índices existentes están disponibles cuando se actualiza el índice secundario global.

P: ¿Está disponible el nuevo índice cuando se añade o crea un índice secundario global?

No, el nuevo índice solo estará disponible una vez finalizado el proceso de creación del índice.

P: ¿Cuánto tiempo se tarda en añadir un índice secundario global?

La duración de tiempo depende del tamaño de la tabla y la cantidad de desempeño de escritura aprovisionado adicional para la creación del índice secundario global. El proceso de añadir o eliminar un índice puede variar desde unos pocos minutos a varias horas. Por ejemplo, supongamos que tiene una tabla de 1 GB que tiene 500 unidades de capacidad de escritura aprovisionadas y ha aprovisionado 1 000 unidades de capacidad de escritura adicionales para el índice y la nueva creación de índice. Si el nuevo índice incluye todos los atributos de la tabla y la tabla está usando todas las unidades de la capacidad de escritura, calculamos que la creación del índice tardará aproximadamente 30 minutos.

P: ¿Cuánto tiempo se tarda en eliminar un índice secundario global?

Normalmente, la eliminación de un índice tardará pocos minutos. Por ejemplo, eliminar un índice con 1 GB de datos normalmente llevará menos de 1 minuto.

P: ¿Cómo puedo hacer seguimiento del progreso de la operación de añadir o eliminar un índice secundario global?

Puede utilizar la consola de DynamoDB o el API DescribeTable para comprobar el estado de todos los índices asociados a la tabla. En una operación de adición de un índice, el estado del índice será “CREATING” mientras que se está creando el índice. Una vez que haya terminado la creación del índice, el estado del índice cambiará de “CREATING” a “ACTIVE”. En una operación de eliminación de índice, el índice eliminado deja de existir una vez completada la solicitud.

P: ¿Puedo recibir una notificación cuando finalice el proceso de creación de índice para añadir un índice secundario global?

Puede solicitar que se le envíe una notificación a su dirección de email donde se confirme que se ha completado la incorporación del índice. Cuando añade un índice a través de la consola, puede solicitar una notificación en el último paso antes de crear el índice. Cuando se complete la creación del índice, DynamoDB le enviará una notificación de SNS a su email.

P: ¿Qué sucede cuando ya tengo 5 índices secundarios globales e intento añadir más?

Usted tiene un límite actual de 5 índices secundarios globales. La operación “Add” fallará y obtendrá un error.

P: ¿Puedo reutilizar un nombre para un índice secundario global si anteriormente se ha eliminado un índice con el mismo nombre?

Sí, una vez que se ha eliminado un índice secundario global, ese nombre de índice puede volver a utilizarse al añadir un nuevo índice.

P: ¿Puedo cancelar la adición de un índice mientras que se está creando?

No, una vez que se inicie la creación del índice, no se puede cancelar el proceso.

P: ¿Los atributos de clave de índice secundario global son necesarios en todos los elementos de una tabla de DynamoDB?

No. Los índices secundarios globales son índices poco poblados. A diferencia del requisito de disponer de una clave principal, un elemento de una tabla de DynamoDB no tiene que contener ninguna de las claves de índice secundario global. Si una clave de índice secundario global tiene elementos de partición y de clase y el elemento de una tabla los omite, el índice secundario global correspondiente no indizará dicho elemento. En tales casos, un índice secundario global puede resultar muy útil en elementos de localización eficaz que tienen un atributo poco común.

P: ¿Puedo recuperar todos los atributos de una tabla de DynamoDB a partir de un índice secundario global?

Una consulta en un índice secundario global solo puede devolver atributos especificados para incluirlos en el índice secundario global en el momento de la creación. Los atributos incluidos en el índice secundario global son los que están proyectados de forma predeterminada, como los atributos de clave de índice secundario global y los atributos de clave principal de la tabla, y los que el usuario haya especificado para proyectarlos. Por este motivo, una consulta de índice secundario global no devolverá los atributos de los elementos que forman parte de la tabla, pero que no están incluidos en el índice secundario global. Un índice secundario global que especifica todos los atributos como atributos proyectados puede utilizarse para recuperar cualquier atributo de tabla. Haga clic aquí para consultar la documentación sobre la utilización de índices secundarios globales para hacer consultas.

P: ¿Cómo puedo enumerar los índices secundarios globales asociados con una tabla?

El API DescribeTable devuelve información detallada sobre los índices secundarios globales de una tabla.

P: ¿Qué tipos de datos pueden incluirse en los índices?

Es posible utilizar todos los tipos de datos escalares (número, cadena, binario y booleano) para el elemento de clave de clase de la clave de los índices secundarios locales. Los tipos de conjunto, lista y mapa no se pueden indexar.

P: ¿Son posibles los índices de atributos compuestos?

No. Sin embargo, puede concatenar atributos en una cadena y utilizarla como una clave.

P: ¿Qué tipos de datos pueden formar parte de los atributos proyectados para un índice secundario global?

Puede especificar atributos con cualquier tipo de datos (incluidos los tipos Set) para proyectarlos en un índice secundario global.

P: ¿Cuáles son algunas consideraciones de escalabilidad de los índices secundarios globales?

Las consideraciones de desempeño de la clave principal de una tabla de DynamoDB también se aplican a las claves de índice secundario global. Un índice secundario global asume un patrón de acceso relativamente aleatorio en todas las claves principales. Para aprovechar al máximo el desempeño aprovisionado de índice secundario, debe seleccionar un elemento de partición de clave de índice secundario global que tiene un amplio número de valores distintos, y un elemento de clave de clase de índice secundario global que se solicita de forma bastante uniforme, de la forma más aleatoria posible.

P: ¿Qué nuevas métricas estarán disponibles en CloudWatch para los índices secundarios globales?

Las tablas con índices secundarios globales ofrecerán métricas agregadas para la tabla y los índices secundarios globales, así como desgloses de métricas para la tabla y cada índice secundario global.

Los informes de índices secundarios globales individuales soportarán un subconjunto de las métricas de CloudWatch soportadas por una tabla. Entre ellas se incluyen:

  • Capacidad de lectura (capacidad de lectura aprovisionada y capacidad de lectura consumida)
  • Capacidad de escritura (capacidad de escritura aprovisionada y capacidad de escritura consumida)
  • Eventos de lectura limitada
  • Eventos de escritura limitada

Para obtener más detalles sobre las métricas soportadas por las tablas y los índices de DynamoDB, haga clic aquí.

P: ¿Cómo puedo analizar un índice secundario global?

Los índices secundarios globales pueden analizarse a través de la consola o con el API Scan.

Para analizar un índice secundario global, indique explícitamente el índice junto al nombre de la tabla que desea analizar. Debe especificar el nombre y valor del atributo de partición del índice. También puede especificar una condición para el atributo de clave de clase del índice.

P: ¿Un análisis del índice secundario global me permitirá especificar que se devuelvan atributos no proyectados en el conjunto de resultados?

El análisis de índices secundarios globales no soportará la obtención de atributos no proyectados.

P: ¿Se soportará el análisis paralelo de los índices?

Sí, se soportarán los análisis paralelos de los índices, y la semántica es exactamente la misma que para la tabla principal.


P: ¿Qué son los índices secundarios locales?

Los índices secundarios locales permiten ejecutar ciertas consultas comunes de manera más rápida y rentable, cuando, de otro modo, sería necesario obtener un gran número de elementos y después filtrar los resultados. De este modo, las aplicaciones pueden disfrutar de consultas más flexibles basadas en un rango más amplio de atributos.

Antes del lanzamiento de los índices secundarios locales, si deseaba buscar elementos concretos en un bucket de clave de partición (elementos que comparten la misma clave de partición), DynamoDB buscaba todos los objetos con la misma clave de partición y filtraba los resultados acorde a sus necesidades. Por ejemplo, imaginemos una aplicación de eCommerce que almacena datos de pedidos de clientes en una tabla de DynamoDB con un esquema partición-clase de marca de tiempo de pedidos de ID de cliente. Sin los LSI, para responder a la solicitud "Mostrar todos los pedidos realizados por el cliente X con fecha de envío en los últimos 30 días, ordenados por fecha de envío" era necesario usar el API de consulta para obtener todos los objetos con la clave de partición "X", ordenar los resultados por fecha de envío y después descartar los resultados más antiguos.

Con los índices secundarios locales, este proceso resulta mucho más sencillo. Ahora puede crear un índice en el atributo “fecha de envío” y ejecutar esta consulta de manera eficiente obteniendo solo los elementos necesarios. De este modo, se reducen considerablemente la latencia y el costo de las consultas, ya que se obtienen solo los elementos que cumplen sus criterios específicos. Asimismo, se simplifica el modelo de programación de la aplicación, dado que ya no tendrá que escribir lógica de clientes para filtrar los resultados. La razón por la que denominamos a este nuevo índice secundario índice secundario “local” es que se utiliza junto con la clave de partición y, por lo tanto, permite realizar búsquedas locales en un bucket de clave de partición. De este modo, mientras que antes solo se podían realizar búsquedas mediante la clave de partición y la clave de clase, ahora también es posible hacer uso de un índice secundario en lugar de la clave de clase, con lo que se amplía el número de atributos que se pueden utilizar para las consultas y estas se realizan de manera más eficaz.

Las copias redundantes de atributos de datos se copian en los índices secundarios locales que defina. Entre estos atributos se incluyen la clave de partición y la clave de clase de la tabla, además de la clave de clase alternativa que defina. También puede almacenar de forma redundante otros atributos de datos en el índice secundario local para consultarlos sin tener que obtener acceso a la tabla.

Los índices secundarios locales no resultan adecuados para todas las aplicaciones. Establecen ciertas limitaciones sobre el volumen de datos que se pueden almacenar en un único valor de clave de partición. Para obtener más información, consulte las preguntas frecuentes que aparecen a continuación sobre las colecciones de elementos.

P: ¿Qué son las proyecciones?

Se conoce como proyección el conjunto de atributos que se copian en un índice secundario local. La proyección determina los atributos que se obtendrán con la máxima eficacia. Cuando se realiza una consulta en un índice secundario local, Amazon DynamoDB puede obtener acceso a cualquiera de los atributos proyectados, con el mismo desempeño que si dichos atributos se encontrasen en su propia tabla. Si necesita obtener atributos no proyectados, Amazon DynamoDB los extraerá automáticamente de la tabla.

Cuando se define un índice secundario local, es necesario especificar los atributos que se proyectarán en el mismo. Como mínimo, cada entrada de índice consta de: (1) el valor de clave de partición de la tabla, (2) un atributo que funcionará como clave de clase del índice y (3) el valor de clave de clase de la tabla.

Además de estos componentes mínimos, es posible elegir una lista personalizada de otros atributos no de clave para proyectarlos en el índice. Incluso puede proyectar todos los atributos en el índice, en cuyo caso este incluirá los mismos datos que la tabla, pero organizados conforme a la clave de clase alternativa especificada.

P: ¿Cómo puedo crear un LSI?

Los LSI se crean en el momento de crear la tabla. En estos momentos, no es posible añadirlos más tarde. Para crear un LSI, especifique los dos parámetros siguientes:

Clave de clase indizada – El atributo que se incluirá en el índice y que se utilizará para las consultas.

Atributos proyectados: La lista de atributos de la tabla que se copiarán directamente en el índice secundario local para poder encontrarlos más rápidamente sin necesidad de extraer datos del índice principal, que contiene todos los elementos de la tabla. Sin los atributos proyectados, el índice secundario local solo contiene claves de índices principales y secundarios.

P: ¿Cuál es el modelo de coherencia para los LSI?

Los índices secundarios locales se actualizan automáticamente cuando se actualiza el índice principal. De manera similar a las lecturas de los índices principales, los LSI soportan opciones de lectura consistente firme y final.

P: ¿Contienen los índices secundarios locales referencias a todos los elementos de la tabla?

No, no tiene por qué ser así. Los índices secundarios locales solo hacen referencia a los elementos que contienen la clave de clase indizada especificada para ese LSI concreto. Debido al esquema flexible de DynamoDB, no todos los elementos tienen por qué contener todos los atributos.

Esto hace que los índices secundarios locales puedan estar poco poblados, a diferencia del índice principal. Dado que los índices secundarios locales están poco poblados, resultan eficaces para realizar consultas sobre atributos poco comunes.

Por ejemplo, en el ejemplo de los pedidos descrito anteriormente, un cliente puede tener algunos atributos adicionales en un elemento que solo se incluyen si el pedido se cancela (como los atributos de fecha y hora de cancelación o de motivo de la cancelación). Para las consultas relacionadas con los elementos cancelados, resultaría eficaz contar con un índice secundario local con cualquiera de estos atributos, ya que los únicos elementos a los que haría referencia serían los que presentasen dichos atributos.

P: ¿Cómo se pueden realizar consultas en los índices secundarios locales?

Solo es posible realizar consultas en los índices secundarios locales mediante el API Query.

Para realizar una consulta en un índice secundario local, indique explícitamente el índice junto al nombre de la tabla donde desea realizar la consulta. Debe especificar el nombre y valor del atributo de partición del índice. También puede especificar una condición para el atributo de clave de clase del índice.

La consulta puede obtener atributos no proyectados almacenados en el índice principal si se realiza una búsqueda de la tabla, lo que supone un consumo de unidades de capacidad de lectura adicionales.

Las consultas realizadas mediante los índices secundarios locales soportan tanto las lecturas de consistencia firme como de consistencia final.

P: ¿Cómo se crean los índices secundarios locales?

Los índices secundarios locales deben definirse en el momento de crear la tabla. El índice principal de la tabla debe utilizar una clave compuesta partición-clase.

P: ¿Puedo añadir índices secundarios locales a una tabla existente?

No, no es posible añadir índices secundarios locales a una tabla existente por el momento. Sin embargo, estamos trabajando en esta característica y esperamos que esté disponible en el futuro. Cuando se crea una tabla con índices secundarios locales, es posible crear un índice secundario local para utilizarlo en el futuro mediante la definición de un elemento de clave de clase que actualmente no esté en uso. Ya que los índices secundarios locales están poco poblados, este índice no tendrá ningún costo hasta que decida utilizarlo.

P: ¿Cuántos índices secundarios locales puedo crear en una tabla?

Cada tabla puede incluir hasta cinco índices secundarios locales.

P: ¿Cuántos atributos no de clave proyectados puedo crear en una tabla?

Cada tabla puede incluir hasta 20 atributos no clave proyectados en total en todos los índices secundarios locales de esta Cada índice también puede especificar que se proyecten todos los atributos no clave del índice principal.

P: ¿Puedo modificar un índice una vez creado?

No, no es posible modificar un índice una vez creado. Estamos trabajando para añadir esta característica en el futuro.

P: ¿Puedo eliminar los índices secundarios locales?

No, en estos momentos los índices secundarios locales no se pueden suprimir de la tabla una vez creados. Por supuesto, si decide eliminar toda la tabla, los índices que contenga también se eliminarán. Sin embargo, estamos trabajando en esta característica y esperamos que esté disponible en el futuro.

P: ¿Cómo consumen los índices secundarios locales capacidad aprovisionada?

No es necesario aprovisionar capacidad para los índices secundarios locales de forma explícita. Los LSI consumen capacidad provisionada como parte de la tabla con la que están asociados.

Las lecturas de LSI y las escrituras a tablas con LSI consumen capacidad conforme a la fórmula estándar de 1 unidad por 1 KB de datos, con las siguientes diferencias:

Cuando las operaciones de escritura contienen datos que son relevantes para uno o más índices secundarios locales, dichas operaciones se copian en los índices secundarios locales apropiados. En estos casos, la tabla consumirá una determinada capacidad de escritura y cada LSI relevante consumirá capacidad de escritura adicional.

Las actualizaciones que sobrescriben un elemento existente pueden generar dos operaciones, una eliminación y una inserción, y, por lo tanto, consumir unidades extra de capacidad de escritura por cada KB de datos.

Cuando una consulta de lectura solicite atributos no proyectados en el LSI, DynamoDB los obtendrá del índice principal. Esta solicitud implícita GetItem consume una unidad de capacidad de lectura por cada 4 KB de datos de elementos obtenidos.

P: ¿Cuánto almacenamiento consumen los índices secundarios locales?

Los índices secundarios locales consumen almacenamiento para el nombre y valor de atributo de las claves principales y de índice de cada LSI, y para todos los atributos no de clave proyectados, además de 100 bytes por elemento reflejado en el LSI.

P: ¿Qué tipos de datos pueden incluirse en los índices?

Es posible utilizar todos los tipos de datos escalares (número, cadena y binario) para el elemento de clave de clase de la clave de los índices secundarios locales. Los tipos de conjuntos no se pueden utilizar.

P: ¿Qué tipos de datos pueden proyectarse en un índice secundario local?

Es posible proyectar todos los tipos de datos (incluidos los tipos de conjuntos) en los índices secundarios locales.

P: ¿Qué son las colecciones de elementos y qué relación guardan con los LSI?

En Amazon DynamoDB, una colección de elementos es cualquier grupo de elementos que comparten una misma clave de partición en una tabla y en todos los índices secundarios locales de esta. Los sistemas de base de datos relacionales partidos (o fragmentados) tradicionales los denominan fragmentos o particiones y hacen referencia a todos los elementos o filas de base de datos almacenados bajo una clave de partición.

Las colecciones de elementos se crean y mantienen automáticamente en toda tabla que incluya índices secundarios locales. DynamoDB almacena cada colección de elementos en una única partición de disco.

P: ¿Existen límites de tamaño para las colecciones de elementos?

Toda colección de elementos de Amazon DynamoDB está sujeta a un tamaño máximo de 10 gigabytes. Para cualquier valor de clave de partición distintivo, la suma de todos los tamaños de los elementos de la tabla más todos los tamaños de los elementos de los índices secundarios locales de dicha tabla no debe exceder los 10 GB.

El límite de 10 GB de las colecciones de elementos no se aplica a las tablas sin índices secundarios locales, solo se ven afectadas las tablas con al menos un índice secundario local.

Aunque las colecciones de elementos individuales tienen un tamaño limitado, el tamaño del almacenamiento de una tabla con índices secundarios locales completa es ilimitado. El tamaño total de una tabla con índices de Amazon DynamoDB es efectivamente ilimitado siempre que el tamaño de almacenamiento total (tabla e índices) para cualquier valor de clave de partición no supere el umbral de los 10 GB.

P: ¿Cómo se puede supervisar el tamaño de una colección de elementos?

Las API de escritura de DynamoDB (PutItem, UpdateItem, DeleteItem y BatchWriteItem) incluyen una opción para que su respuesta muestre un cálculo estimado del tamaño de la colección de elementos relevante. Este cálculo incluye una estimación del tamaño máximo y mínimo (medido en gigabytes) de los datos de una colección de elementos concreta.

Es recomendable que configure su aplicación para que monitorice los tamaños de las colecciones de elementos. La aplicación debe examinar las respuestas de las API en relación al tamaño de las colecciones de elementos y enviar un mensaje de error cuando una colección supere un límite definido por el usuario (8 GB, por ejemplo). Este sistema de advertencia temprana le informa de que una colección de elementos está aumentando de tamaño y le concede tiempo suficiente para hacer algo al respecto.

P: ¿Qué ocurre si supero el límite de 10 GB en una colección de elementos?

Si una colección de elementos concreta supera el límite de 10 GB, no podrá añadir nuevos elementos ni aumentar el tamaño de los existentes para esa clave de partición en particular. Las operaciones de lectura y escritura que reduzcan el tamaño de la colección de elementos siguen estando permitidas. Las demás colecciones de elementos de la tabla no se ven afectadas.

Para solventar este problema, en la colección que ha superado los 10 GB, puede suprimir elementos o reducir el tamaño de los mismos. También es posible introducir nuevos elementos bajo un nuevo valor de clave de partición para solucionar este problema. Si la tabla incluye datos históricos a los que se obtiene acceso con poca frecuencia, puede considerar la posibilidad de archivar los datos históricos en Amazon S3, Amazon Glacier u otro servicio de almacenamiento de datos.

P: ¿Cómo puedo analizar un índice secundario local?

Para analizar un índice secundario local, indique explícitamente el índice junto al nombre de la tabla que desea analizar. Debe especificar el nombre y valor del atributo de partición del índice. También puede especificar una condición para el atributo de clave de clase del índice.

El análisis puede obtener atributos no proyectados almacenados en el índice principal si se realiza una búsqueda de la tabla, lo que supone un consumo de unidades de capacidad de lectura adicionales.

P: ¿Un análisis del índice secundario local me permitirá especificar que se devuelvan atributos no proyectados en el conjunto de resultados?

El análisis de índices secundarios locales soportará la obtención de ​atributos no proyectados.

P: ¿En qué orden se presentan los resultados del análisis de un índice secundario local?

En el caso de los índices secundarios locales, el orden dentro de un grupo se basará en el orden del atributo indexado.


P: ¿Qué es el control de acceso avanzado de DynamoDB?

El control de acceso minucioso (FGAC, por sus siglas en inglés) proporciona a los propietarios de una tabla de DynamoDB un elevado nivel de control de los datos presentes en la tabla. Específicamente, el propietario de la tabla puede indicar quién (intermediario) puede obtener acceso a determinados elementos o atributos de la tabla y qué acciones puede realizar (capacidades de lectura/escritura). FGAC se utiliza junto con AWS Identity and Access Management (IAM), que administra las credenciales de seguridad y los permisos asociados.

P: ¿Cuáles son los casos de uso comunes para FGAC en DynamoDB?

FGAC puede beneficiar a cualquier aplicación que registre información en una tabla de DynamoDB, en la que el usuario final (o el cliente de aplicación que actúa en nombre de un usuario final) desee leer o modificar la tabla directamente, sin un servicio de nivel intermedio. Por ejemplo, un desarrollador de una aplicación para móviles denominado Acme puede utilizar FGAC para registrar los datos más relevantes de cada usuario de Acme en una tabla de DymanoDB. FGAC permite que el cliente de la aplicación modifique solo los datos más relevantes del usuario que está ejecutando la aplicación actualmente.

P: ¿Puedo utilizar el control de acceso de grano fino con los documentos JSON?

Sí. Puede usar el control de acceso pormenorizado (Fine Grain Access Control, FGAC) para restringir el acceso a sus datos de acuerdo con los atributos de nivel superior de su documento. No puede usar FGAC para restringir el acceso de acuerdo con los atributos anidados. Por ejemplo, suponga que ha almacenado un documento JSON que contiene la siguiente información sobre alguien: ID, nombre, apellidos y una lista de todos sus amigos. Podría hacer uso de FGAC para restringir el acceso mediante su ID, nombre o apellido, pero no mediante su lista de amigos.

P: Sin FGAC, ¿cómo puede lograr un desarrollador control de acceso a nivel de elemento?

Para lograr este nivel de control sin FGAC, el desarrollador debería elegir entre varios procedimientos potencialmente molestos. Algunos de estos procedimientos son:

  1. Proxy: el cliente de aplicación envía una solicitud a un proxy intermediario que realiza las tareas de autenticación y autorización. Esta solución aumenta la complejidad de la arquitectura del sistema y puede derivar en un costo total de propiedad más alto.
  2. Por tabla de cliente: cada cliente de aplicación tiene asignada su propia tabla. Dado que los clientes de aplicación obtienen acceso a tablas diferentes, estarían protegidos los unos de los otros. Esto podría requerir la creación de millones de tablas por parte de un desarrollador, lo que convertiría la administración de bases de datos en algo realmente desagradable.
  3. Por token de cliente incrustado: un token secreto se incrusta en el cliente de aplicación. La desventaja radica en la dificultad para cambiar el token y administrar su impacto en los datos almacenados. Aquí, la clave de los elementos accesibles por parte de este cliente contendría el token secreto.

P: ¿Cómo funciona FGAC con DynamoDB?

Con FGAC, una aplicación solicita un token de seguridad que la autoriza a obtener acceso solo a elementos específicos de una tabla de DynamoDB determinada. Con este token, el agente de la aplicación del usuario final puede realizar solicitudes a DynamoDB directamente. Tras recibir la solicitud, las credenciales de la solicitud recibida son evaluadas en primer lugar por DymanoDB, que utilizará IAM para autenticar la solicitud y determinar las capacidades permitidas al usuario. Si la solicitud del usuario no se permite, FGAC impedirá que se acceda a los datos.

P: ¿Cuánto cuesta FGAC para DymanoDB?

No se aplican cargos adicionales por utilizar FGAC. Como siempre, solo paga por el desempeño aprovisionado y el almacenamiento asociado con la tabla de DynamoDB.

P: ¿Cómo puedo empezar?

Consulte la sección sobre el control de acceso minucioso de la guía para desarrolladores de DynamoDB para obtener información sobre cómo crear una política de acceso, crear una función de IAM para su aplicación (por ejemplo, una función denominada AcmeFacebookUsers para una app_id de 34567 para Facebook), así como asignar su política de acceso a la función. La directiva de confianza de la función determina los proveedores de identidad que se aceptan (por ejemplo, el inicio de sesión con Amazon, Facebook o Google) y la política de acceso describe a qué recursos de AWS se puede obtener acceso (por ejemplo, una tabla de DynamoDB). Mediante el uso de la función, la aplicación ahora puede obtener unas credenciales temporales para DymanoDB al llamar al API AssumeRoleWithIdentityRequest de AWS Security Token Service (STS).

P: ¿Cómo puedo permitir que los usuarios consulten un índice secundario local, pero impedirles que una búsqueda de la tabla recupere atributos no proyectados?

Algunas operaciones de consulta en un índice secundario local pueden ser más caras que otras si solicitan atributos que no estén proyectados en un índice. Puede restringir estas operaciones "de búsqueda" que pueden resultar muy caras limitando los permisos a solamente atributos proyectados, para lo que debe usar la clave de contexto "dynamodb:Attributes".

P: ¿Cómo puedo evitar que los usuarios accedan a atributos específicos?

El procedimiento recomendado para impedir el acceso a atributos específicos es seguir los principios de privilegios mínimos, así como permitir el acceso solo a atributos específicos.

Otra opción es utilizar una política Deny para especificar atributos no permitidos. Sin embargo, esto no se recomienda por las razones siguientes:

  1. Con una política Deny, el usuario puede descubrir los nombres de los atributos ocultos. Para ello, debe realizar varias solicitudes para cada nombre de atributo posible, hasta que finalmente se deniega el acceso al usuario.
  2. Las políticas Deny son más frágiles, dado que DynamoDB podría introducir una nueva funcionalidad de API en el futuro que podría permitir un patrón de acceso que ya había intentado bloquear anteriormente.

P: ¿Cómo puedo impedir que los usuarios añadan datos no válidos a la tabla?

Los controles de FGAC disponibles pueden determinar qué elementos modificados o leídos y qué atributos se pueden modificar o leer. Los usuarios pueden añadir nuevos elementos sin dichos atributos bloqueados y cambiar cualquier valor de cualquier atributo que sea modificable.

P: ¿Puedo conceder acceso a varios atributos sin mostrarlos todos?

Sí, el lenguaje de políticas IAM admite una amplia variedad de operaciones de comparación, incluidas StringLike y StringNotLike entre otras. Para obtener más información, consulte la referencia de la política IAM.

P: ¿Cómo puedo crear una política adecuada?

Le recomendamos que utilice el generador de políticas de DynamoDB desde la consola de DynamoDB. También puede comparar su política con las que se muestran en la Guía para desarrolladores de Amazon DynamoDB para asegurarse de que está siguiendo un patrón recomendado. Puede publicar políticas en los foros de AWS para ver opiniones de la comunidad de DynamoDB.

P: ¿Puedo conceder acceso de acuerdo con un ID de usuario canónico en lugar de usar ID independientes para el usuario de acuerdo con el proveedor de identidad con el que inicia sesión?

No, si no se utiliza una “máquina expendedora de tokens”. Si un usuario recupera el acceso federado a su función de IAM usando directamente credenciales de Facebook sin STS, estas credenciales temporales solo tendrán información sobre el inicio de sesión en Facebook del usuario, y no su información de inicio de sesión de Amazon o Google. Si desea almacenar de forma interna un mapeo de cada uno de estos inicios de sesión para sus propios identificadores invariables, puede ejecutar un servicio con el que el usuario se contactará para iniciar sesión y después llamar a STS y proporcionarles las credenciales asignadas a cualquier valor de clave de partición con el que se encuentre como su ID de usuario canónica.

P: ¿Qué información no puede ocultarse a los intermediarios que usan FGAC?

Existe información determinada sobre los elementos en la tabla que no puede bloquearse actualmente para el intermediario:

  • Métricas de colecciones de elementos. El intermediario puede solicitar el número de elementos estimado y el tamaño en bytes de la colección de elementos.
  • Desempeño consumido: el intermediario puede solicitar un resumen o desglose detallado del desempeño aprovisionado consumido por las operaciones.
  • Casos de validación. En determinados casos, el intermediario puede obtener más información sobre la existencia y el esquema clave de una tabla cuando no estaba previsto concederle acceso. Para evitar esto, siga los principios de seguridad de otorgar privilegios mínimos y conceda acceso solo a las tablas y acciones a las que pretendía conceder acceso.
  • Si deniega el acceso a atributos específicos en lugar de aprobar el acceso a atributos específicos, el intermediario teóricamente puede determinar los nombres de los atributos ocultos de acuerdo con la lógica "permitir todos excepto". Es más seguro aprobar nombres de atributos específicos en su lugar.

P: ¿Amazon DynamoDB es compatible con los permisos de IAM?

Sí, DynamoDB admite los permisos en el nivel de API a través de la integración del servicio AWS Identity and Access Management (IAM).

Para obtener más información sobre IAM, vaya a:

P: Quiero realizar análisis de seguridad o solucionar problemas operativos en las tablas de DynamoDB. ¿Puedo obtener el historial de todas las llamadas al API de DynamoDB realizadas en mi cuenta?

Sí. AWS CloudTrail es un servicio web que registra las llamadas a la API de AWS de la cuenta y entrega archivos de log. El historial de llamadas a las API de AWS creado por AWS CloudTrail permite realizar análisis de seguridad, un seguimiento de los cambios en los recursos y auditorías sobre la conformidad. Puede obtener información sobre el soporte de DynamoDB para CloudTrail aquí. Obtenga más información sobre CloudTrail en la página de detalles de AWS CloudTrail y habilítelo a través de la página de inicio de la Consola de administración de AWS en CloudTrail.


P: ¿Cómo se me cobrará por el uso que haga de Amazon DynamoDB?

Cada tabla de DynamoDB tiene un rendimiento de escritura y de escritura previsto asociado con ella. Si excede el límite de la capa gratuita, se le facturará cada hora de esa capacidad de desempeño.

Tenga en cuenta que se le cobrará por hora de capacidad de desempeño, independientemente de que envíe o no solicitudes a dicha tabla. Si desea cambiar la capacidad de desempeño aprovisionada de la tabla, puede hacerlo a través de la consola de administración de AWS, la API UpdateTable o la API PutScalingPolicy para Auto Scaling.

Además, DynamoDB cobra el almacenamiento de datos indizados, así como la tarifa de transferencia de datos estándar de Internet.

Si desea más información sobre los precios de Amazon DynamoDB, visite la página de precios de DynamoDB.

P: ¿Puedo ver algunos ejemplos de precios?

A continuación se incluye un ejemplo de cómo calcular sus costos de desempeño según los precios de la región de EE.UU. Este (Norte de Virginia). Para ver los precios aplicables a otras regiones, consulte nuestra página de precios.

Si crea una tabla y solicita 10 unidades de capacidad de escritura y 200 unidades de capacidad de lectura para el desempeño provisionado, se le cobrarán las siguientes cantidades:

0,01 USD + (4 x 0,01 USD) = 0,05 USD por hora

Si sus necesidades cambian y aumenta su reserva de desempeño a 10 000 unidades de capacidad de escritura y a 50 000 unidades de capacidad de lectura, se le cobrará lo siguiente:

(1 000 x 0,01 USD) + (1 000 x 0,01 USD) = 20 USD/hora

Si desea más información sobre los precios de Amazon DynamoDB, visite la página de precios de DynamoDB.

P: ¿Los precios incluyen impuestos?

Para obtener más información sobre impuestos, consulte la ayuda sobre impuestos de Amazon Web Services.

P: ¿En qué consiste el rendimiento previsto?

Amazon DynamoDB Auto Scaling ajusta la capacidad de desempeño automáticamente a medida que cambian los volúmenes de solicitud, en función de su uso objetivo y los límites mínimo y máximo de capacidad deseados, o le permite especificar manualmente el desempeño de solicitud que desea que su tabla pueda alcanzar. Entre bambalinas, el servicio administra el aprovisionamiento de recursos para conseguir la tasa de desempeño solicitada. En lugar de pedirle que piense en instancias, hardware, memoria y otros factores que podrían influir en el desempeño, simplemente le pedimos que aprovisione el nivel de desempeño que desea alcanzar. En esto consiste el modelo de servicio basado en el desempeño provisionado.

Durante la creación de una tabla o índice secundario global nuevos, Auto Scaling está habilitado por defecto con ajustes predeterminados de uso objetivo, capacidad mínima y máxima. De forma alternativa, pude especificar sus necesidades de capacidad de lectura y escritura manualmente. Amazon DynamoDB realiza particiones automáticamente y reserva la cantidad adecuada de recursos para satisfacer sus requisitos de desempeño.

P: ¿Cómo influye la selección de la clave principal en la escalabilidad que puedo llegar a conseguir?

Al almacenar los datos, Amazon DynamoDB divide la tabla en varias particiones y distribuye los datos entre ellas en función del elemento de clave de partición de la clave principal. Al asignar los recursos de capacidad, Amazon DynamoDB supone un patrón de acceso relativamente aleatorio en todas las claves principales. Debe definir su modelo de datos para que las solicitudes resulten en una distribución equitativa del tráfico entre las claves principales. Si una tabla contiene un número muy reducido de elementos (posiblemente, uno solo) de clave de partición a los que se accede con mucha frecuencia, el tráfico se concentra en un número reducido de particiones; posiblemente en una sola. Si la carga de trabajo está muy desequilibrada, es decir, distribuida de forma desproporcionada en una partición o solo en algunas, las operaciones no conseguirán el desempeño general provisionado. Por tanto, para obtener el máximo desempeño con Amazon DynamoDB, debe crear tablas en las que el elemento de clave de partición tenga muchos valores distintos y donde los valores se soliciten con bastante uniformidad, de la forma más aleatoria posible. Un ejemplo de buena clave principal sería CustomerID, en caso de que la aplicación tenga muchos clientes y las solicitudes realizadas a los diversos registros de clientes sean más o menos uniformes. Un ejemplo de clave principal muy sesgada sería "Nombre de categoría de producto", en caso de que determinadas categorías sean más populares que las otras.

P: ¿Qué es una unidad con capacidad de lectura/escritura?

¿Cómo puedo calcular cuántas unidades de capacidad de lectura y escritura necesito para mi aplicación? Una unidad de capacidad de escritura le permite realizar una escritura por segundo de elementos con un tamaño máximo de 1 KB. Del mismo modo, una unidad de capacidad de lectura le permite realizar una lectura altamente consistente por segundo (o dos lecturas consistentes finales por segundo) de elementos con un tamaño de hasta 4 KB. Los elementos más grandes precisarán de más capacidad. Puede calcular el número de unidades de capacidad de lectura y escritura que necesita estimando el número de escrituras y lecturas que necesita realizar por segundo y, a continuación, multiplicando este número por el tamaño de los elementos (redondeando al KB más próximo).

Unidades de capacidad requerida para escrituras = Número de elementos de escritura por segundo x tamaño de elemento en bloques de 1 KB

Unidades de capacidad requerida para lecturas* = Número de elementos de lectura por segundo x tamaño de elemento en bloques de 4 KB

* Si utiliza lecturas con consistencia final obtendrá el doble del desempeño en términos de lecturas por segundo.

Si los elementos tienen un tamaño inferior a 1 KB, cada unidad de capacidad de lectura le dará 1 lectura consistente/segundo y cada unidad de capacidad de escritura le dará 1 escritura/segundo de capacidad. Por ejemplo, si sus elementos tienen un tamaño de 512 bytes y necesita leer de la tabla 100 elementos por segundo, entonces necesita aprovisionar 100 unidades de capacidad de lectura.

Si los elementos tienen un tamaño superior a 4 KB, debe calcular el número de unidades de capacidad de lectura y de escritura que necesita. Por ejemplo, si los elementos tienen un tamaño de 4,5 KB y desea realizar 100 lecturas/segundo, entonces necesita aprovisionar 100 (lecturas por segundo) x 2 (número de bloques de 4 KB necesarios para almacenar 4,5 KB) = 200 unidades de capacidad de lectura.

Tenga en cuenta que el número necesario de unidades de capacidad de lectura se determina en función del número de elementos que se lean por segundo, no por el número de solicitudes que se realicen al API. Por ejemplo, si necesita leer de la tabla 500 elementos por segundo y los elementos tienen un tamaño de 4 KB o menos, entonces necesita 500 unidades de capacidad de lectura. En este caso, no influye el hecho de que realice 500 solicitudes individuales al API GetIem o 50 solicitudes al API BatchGetItem y que cada una devuelva 10 elementos.

P: ¿Podré conseguir siempre el nivel de desempeño provisionado?

Amazon DynamoDB supone un patrón de acceso relativamente aleatorio en todas las claves principales. Debe definir su modelo de datos para que las solicitudes resulten en una distribución equitativa del tráfico entre las claves principales. Si su modelo de acceso es sesgado o poco uniforme, es posible que no logre alcanzar el nivel de desempeño provisionado.

Al almacenar los datos, Amazon DynamoDB divide la tabla en varias particiones y distribuye los datos entre ellas en función del elemento de clave de partición de la clave principal. El desempeño provisionado asociado a una tabla también se divide entre las particiones; el desempeño de cada partición se administra de forma independiente en función de la cuota que se le haya asignado. Las particiones no comparten el desempeño provisionado. Por tanto, una tabla administrada en Amazon DynamoDB tiene más posibilidades de conseguir los niveles de desempeño provisionado si la carga de trabajo se distribuye con uniformidad entre los valores de clave de partición. Distribuir las solicitudes entre los valores de clave de partición las distribuye también entre las particiones, lo que ayuda a conseguir el nivel máximo de desempeño provisionado.

Si sigue un patrón de carga de trabajo poco uniforme entre las claves principales y no puede conseguir el desempeño provisionado, tal vez pueda satisfacer sus necesidades de desempeño aumentando aún más dicho desempeño, lo que le permitirá obtener un desempeño mayor en cada partición. No obstante, le recomendamos que considere la opción de modificar los modelos de solicitud o de datos, a fin de conseguir un modelo de acceso relativamente aleatorio entre las claves principales.

P: Si recupero un único elemento de un documento JSON, ¿se me cobrará por leer todo el elemento?

Sí. Cuando lee datos de DynamoDB, consume el rendimiento necesario para leer el elemento completo.

P: ¿Cuál es el desempeño máximo que puedo aprovisionar para una única tabla de DynamoDB?

DynamoDB es una solución diseñada para ajustar escalas sin imponer límites. No obstante, si desea superar el índice de rendimiento de 10 000 unidades de capacidad de escritura o de 10 000 unidades de capacidad de lectura para una única tabla, primero debe ponerse en contacto con Amazon a través de este formulario en línea. Si desea aprovisionar más de 20 000 unidades de capacidad de escritura o de 20 000 unidades de capacidad de lectura desde una única cuenta de suscriptor, primero debe ponerse en contacto con nosotros a través del formulario descrito anteriormente.

P: ¿Cuál es el rendimiento mínimo que puedo aprovisionar para una única tabla de DynamoDB?

La menor cantidad de desempeño aprovisionado que puede solicitar es 1 unidad de capacidad de escritura y 1 unidad de capacidad de lectura tanto para Auto Scaling como para el aprovisionamiento de desempeño manual.

Este umbral se encuadra dentro de la capa gratuita, que permite disponer de 25 unidades de capacidad de escritura y de 25 unidades de capacidad de lectura. La capa gratuita se aplica a nivel de cuenta y no de tabla. Dicho de otra manera, si suma la capacidad prevista de todas sus tablas y la capacidad total no es superior a 25 unidades de capacidad de escritura y 25 unidades de capacidad de lectura, la capacidad prevista estará dentro de la capa gratuita.

P: ¿Existe algún límite respecto al cambio del desempeño previsto en una única solicitud?

Puede incrementar la capacidad de desempeño provisionada de su tabla en la cantidad que desee mediante el API UpdateTable. Por ejemplo, puede incrementar la capacidad de escritura aprovisionada de su tabla de 1 unidad de escritura a 10 000 unidades de escritura con una sola llamada al API. Su cuenta sigue estando sujeta a los límites de capacidad por tabla y cuenta, tal como se describe en nuestra página de documentación. Si necesita incrementar sus límites de capacidad prevista, puede visitar nuestro Centro de soporte. Haga clic en “Abrir un caso nuevo” y rellene una solicitud de aumento de límites del servicio.

P: ¿Cuánto se me cobrará por el rendimiento previsto?

Cada tabla de Amazon DynamoDB tiene preaprovisionados los recursos que necesita para conseguir el nivel de desempeño solicitado por el cliente. Se le cobrará una tarifa por hora mientras la tabla conserve estos recursos. Si desea ver una lista de precios en la que también se expongan ejemplos, consulte la página de precios de DynamoDB.

P: ¿Cómo puedo cambiar el rendimiento previsto para una tabla existente de DynamoDB?

El desempeño provisionado de una tabla de Amazon DynamoDB se puede actualizar de dos formas. Puede realizar el cambio en la consola de administración, o mediante una solicitud a la API UpdateTable. En cualquier caso, Amazon DynamoDB seguirá disponible durante el proceso de aumento o disminución del desempeño provisionado.

P: ¿Con qué frecuencia puedo cambiar el desempeño provisionado?

Puede cambiar el rendimiento previsto tantas veces como desee. Puede reducirlo hasta cuatro veces por día, en cualquier momento. El término día se corresponde con la zona horaria GMT. Además, si no se ha producido ninguna reducción en las últimas cuatro horas, se permite una adicional, lo que en la práctica significa que la cantidad máxima de reducciones por día es 9 (4 reducciones en las primeras 4 horas y 1 reducción por cada periodo de 4 horas en un día).

Tenga en cuenta que no puede cambiar el nivel de desempeño provisionado si la tabla de Amazon DynamoDB aún no ha respondido a la última solicitud de cambio de desempeño realizada. Utilice la consola de administración o la API DescribeTables para comprobar el estado de la tabla. Si el estado es "CREATING", "DELETING" o "UPDATING", no podrá ajustar el desempeño de la tabla. Espere a que la tabla se encuentre en estado "ACTIVE" y vuelva a intentarlo.

P: ¿El nivel de consistencia afecta a la tasa de desempeño?

Sí. Para una asignación determinada de recursos, el nivel de lectura que puede conseguir una tabla de DynamoDB difiere entre las lecturas de consistencia alta y final. Si solicita “1 000 unidades de capacidad de lectura”, DynamoDB asignará los recursos suficientes para conseguir 1 000 lecturas altamente consistentes por segundo de elementos de hasta 4 KB. En cambio, si desea conseguir 1 000 lecturas consistentes finales de elementos de hasta 4 KB, tendrá que dividir por dos dicha capacidad, es decir, 500 unidades de capacidad de lectura. Si desea obtener instrucciones adicionales sobre cómo elegir la tasa apropiada de desempeño para la tabla con la que cuenta, consulte nuestra guía sobre el desempeño previsto.

P: ¿El tamaño del elemento afecta a la tasa de desempeño?

Sí. Para una asignación determinada de recursos, el nivel de lectura que puede conseguir una tabla de DynamoDB depende del tamaño de un elemento. Cuando especifique el nivel de desempeño previsto que le gustaría alcanzar, DynamoDB suministra los recursos asumiendo que el tamaño de los elementos será inferior a 4 KB. Cada vez que se produzca un aumento de hasta 4 KB, también aumentarán de forma lineal los recursos que necesita para conseguir el mismo nivel de desempeño. Por ejemplo, si ha aprovisionado una tabla de DynamoDB con 100 unidades de capacidad de lectura, significa que esta puede administrar 100 lecturas por segundo de 4 KB, o 50 lecturas por segundo de 8 KB, o 25 lecturas por segundo de 16 KB, y así sucesivamente.

Asimismo, la velocidad de escritura que puede alcanzar una tabla de DynamoDB depende del tamaño del elemento. Cuando especifique el nivel de desempeño de escritura que le gustaría alcanzar, DynamoDB aprovisionará los recursos asumiendo que el tamaño de los elementos será inferior a 1 KB. Cada vez que se produzca un aumento de hasta 1 KB, también aumentarán de forma lineal los recursos que necesita para conseguir el mismo nivel de desempeño. Por ejemplo, si ha aprovisionado una tabla de DynamoDB con 100 unidades de capacidad de escritura, significa que esta puede administrar 100 lecturas por segundo de 1 KB, o 50 lecturas por segundo de 2 KB, o 25 lecturas por segundo de 4 KB, y así sucesivamente.

Si desea obtener instrucciones adicionales sobre cómo elegir la tasa apropiada de desempeño para la tabla con la que cuenta, consulte nuestra guía sobre el desempeño previsto.

P: ¿Qué sucede si mi aplicación lee o escribe más de lo previsto en términos de capacidad?

Si su aplicación realiza más lecturas o escrituras por segundo de lo que permite la capacidad de desempeño provisionada de la tabla, se rechazarán las solicitudes que superen la capacidad provisionada y recibirá el código de error 400. Por ejemplo, si ha solicitado 1 000 unidades de capacidad de escritura e intenta ejecutar 1 500 escrituras por segundo de elementos de 1 KB, es posible que DynamoDB solo le permita realizar 1 000 escrituras por segundo y que reciba el código de error 400 con las demás solicitudes. Debe utilizar CloudWatch para controlar la tasa de solicitudes y así garantizar que siempre disponga del desempeño suficiente para alcanzarla.

P: ¿Cómo puedo saber si he superado mi capacidad de desempeño provisionada?

DynamoDB publica la capacidad de desempeño consumida como una métrica de CloudWatch. Puede configurar una alarma en esta métrica para que reciba una notificación cuando se acerque a la capacidad provisionada.

P: ¿Cuánto se tarda en cambiar el nivel de desempeño provisionado de una tabla?

En general, las disminuciones de desempeño pueden llevar de unos segundos a unos minutos, mientras que los aumentos pueden tardar de unos minutos a unas horas.

Recomendamos encarecidamente que no intente programar los aumentos de desempeño de modo que se produzcan al tiempo que surge la necesidad. Es aconsejable aprovisionar la capacidad adicional con la suficiente antelación como para garantizar que se encuentre disponible en el momento de necesitarla.

P: ¿Qué es la capacidad reservada?

La capacidad reservada es una característica de facturación que le permite obtener descuentos en la capacidad de desempeño aprovisionada si cumple estas condiciones:

  • Realiza un pago inicial único.
  • Acepta un nivel de uso mensual mínimo durante todo el periodo del acuerdo.

La capacidad reservada se aplica en una única región de AWS y se puede comprar por un período de 1 o 3 años. Cada tabla de DynamoDB tiene capacidad de desempeño aprovisionado asociada, ya esté administrada por Auto Scaling como por aprovisionamiento manual cuando crea o actualiza una tabla. Esta capacidad determina la velocidad de lectura y escritura que puede alcanzar la tabla de DynamoDB. La capacidad reservada es un acuerdo de facturación y no tiene ninguna influencia directa sobre el desempeño o la capacidad de las tablas de DynamoDB. Por ejemplo, si adquiere 100 unidades de capacidad de escritura de capacidad reservada, acepta pagar por dicha capacidad durante el periodo del acuerdo (1 o 3 años) a cambio de una reducción en el precio.

P: ¿Cómo puedo comprar capacidad reservada?

Inicie sesión en la consola de administración de AWS, vaya a la página de la consola de DynamoDB y, a continuación, haga clic en “Reserved Capacity”. De este modo, obtendrá acceso a la página "Reserved Capacity Usage". Haga clic en “Purchase Reserved Capacity” y aparecerá un formulario que, si lo rellena, le permitirá adquirir capacidad reservada. Asegúrese de haber seleccionado la región de AWS en la que se utilizará la capacidad reservada. Una vez que haya adquirido la capacidad reservada, podrá consultar la compra realizada en la página “Reserved Capacity Usage”.

P: ¿Puedo cancelar una compra de capacidad reservada?

No, no puede cancelar la capacidad reservada y el pago por única vez tampoco se reembolsa. Seguirá pagando por cada hora durante el periodo del acuerdo de capacidad reservada independientemente del uso que haga.

P: ¿Cuál es la cantidad mínima de capacidad reservada que puedo comprar?

La cantidad mínima disponible de capacidad reservada es de 100 unidades (de lectura o escritura).

P: ¿Existen API que pueda utilizar para comprar capacidad reservada?

Aún no. Ofreceremos API y añadiremos más opciones a la capacidad reservada en el futuro.

P: ¿Puedo mover la capacidad reservada de una región a otra?

No. La capacidad reservada se asocia a una única región.

P: ¿Puedo aprovisionar una capacidad de rendimiento mayor que la capacidad reservada?

Sí. Al comprar capacidad reservada, acepta un nivel de uso mínimo y paga una tarifa reducida por dicho nivel de uso. Si aprovisiona una capacidad superior a ese nivel mínimo, deberá abonar las tarifas estándar por la capacidad adicional.

P: ¿Cómo se utiliza la capacidad reservada?

La capacidad reservada se aplica automáticamente a la factura. Por ejemplo, si adquiere 100 unidades de capacidad reservada de escritura y ha aprovisionado 300, la compra de capacidad reservada cubrirá automáticamente el costo de 100 unidades de capacidad de escritura y deberá abonar las tasas estándar por las 200 unidades de capacidad de escritura restantes.

P: ¿Qué ocurre si aprovisiono una capacidad de rendimiento menor que la capacidad reservada?

Una compra de capacidad reservada es un acuerdo por el que se compromete a pagar por una cantidad mínima de capacidad de desempeño provisionada durante el periodo del acuerdo, a cambio de una reducción en los precios. Aunque no utilice toda la capacidad reservada, deberá seguir pagando cada mes por esa cantidad mínima de capacidad de desempeño provisionada.

P: ¿Puedo utilizar la capacidad reservada para varias tablas de DynamoDB?

Sí. La capacidad reservada se aplica a la capacidad total aprovisionada en la región en la que compró la capacidad reservada. Por ejemplo, si adquiere 5 000 unidades de capacidad de escritura de capacidad reservada, puede aplicarlas a una tabla con 5 000 unidades de capacidad de escritura, o a 100 tablas con 50 unidades de capacidad de escritura, o a 1 000 tablas con 5 unidades de capacidad de escritura, etc.

P: ¿Se aplica la capacidad reservada al uso de DynamoDB en las cuentas de facturación consolidada?

Sí. Si tiene varias cuentas enlazadas mediante la facturación consolidada, las unidades de capacidad reservada adquiridas en los niveles de cuenta del pagador o cuenta enlazada se comparten con todas las cuentas enlazadas con la cuenta del pagador. La capacidad reservada se aplica primero a la cuenta que la adquirió; cualquier capacidad restante se aplica entonces a las demás cuentas enlazadas.

 

P: ¿Qué es la replicación entre regiones de DynamoDB?

La replicación entre regiones de DynamoDB le permite mantener copias idénticas (llamadas réplicas) de una tabla de DynamoDB (llamada tabla maestra) en una o más regiones de AWS. Cuando habilita la replicación entre regiones para una tabla, se crean copias idénticas de esta en otras regiones de AWS. Cualquier escritura realizada en la tabla se propaga automáticamente a las réplicas.

 

P: ¿Cuándo debo utilizar la replicación entre regiones?

Puede utilizar la replicación entre regiones para beneficiarse de lo siguiente.

  • Recuperación de desastres eficaz: la replicación de las tablas en varios centros de datos le permite, en caso de que se produzca un error en el centro de datos, utilizar las tablas de DynamoDB de otra región.
  • Lecturas más rápidas: Si posee clientes en varias regiones, puede proporcionarles datos con mayor rapidez al leer la tabla de DynamoDB del centro de datos de AWS más cercano.
  • Administración del tráfico más sencilla: puede utilizar réplicas para distribuir la carga de trabajo de lectura entre varias tablas y, por lo tanto, consumir menos capacidad de lectura en la tabla maestra.
  • Migración regional sencilla: al crear una réplica de lectura en una nueva región y, a continuación, convertir la réplica en tabla maestra, puede migrar la aplicación a esa región con más facilidad.
  • Migración de datos en vivo: para mover una tabla de DynamoDB de una región a otra, puede crear una réplica de la tabla de la región de origen en la región de destino. Cuando las tablas estén sincronizadas, puede modificar la aplicación de manera que escriba en la región de destino.

P: ¿Qué modos de replicación entre regiones se soportan?

En la actualidad, la replicación entre regiones soporta el modo de una sola tabla maestra. Este modo dispone de una tabla maestra y una o varias réplicas.

P: ¿Cómo puedo configurar la replicación entre regiones de una sola tabla maestra para una tabla?

Puede crear réplicas interregionales con la biblioteca de replicación entre regiones de DynamoDB.

P: ¿Cómo puedo saber si se ha completado el proceso de arranque?

En la aplicación de administración de la replicación, el estado de la replicación cambia de “proceso de arranque” a “activo”.

P: ¿Puedo disponer de varias réplicas de una sola tabla maestra?

Sí, no existen límites en cuanto a la cantidad de réplicas de una tabla principal que se pueden poseer. Se crea un lector de transmisiones de DynamoDB para cada réplica, que copia datos de la tabla maestra, manteniéndolas sincronizadas.

P: ¿Cuánto cuesta configurar la replicación entre regiones para una tabla?

Para habilitar la replicación entre regiones de DynamoDB, se usa la biblioteca de replicación entre regiones de DynamoDB. Mientras que la biblioteca de replicación entre regiones no conlleva cargos adicionales, deberá abonar los precios convencionales por los recursos especificados a continuación que utilice el proceso. Se le facturará por lo siguiente:

  • Desempeño aprovisionado (lecturas y escrituras) y almacenamiento de las réplicas.
  • Transferencia de datos entre regiones.
  • Lectura de datos de las transmisiones de DynamoDB para mantener las tablas actualizadas.
  • Las instancias EC2 aprovisionadas para hospedar el proceso de replicación. El costo de las instancias dependerá del tipo de instancia que elija y la región que hospede las instancias.

P: ¿En qué región se ejecuta la instancia de Amazon EC2 que hospeda la replicación entre regiones?

La aplicación de replicación entre regiones se hospeda en una instancia de Amazon EC2 en la misma región en la que se ejecutó por primera vez la aplicación de replicación entre regiones. Se le cobrará el precio de la instancia en esta región.

P: ¿Se escala automáticamente la instancia de Amazon EC2 cuando cambia el tamaño y desempeño de la tabla maestra y las réplicas?

En la actualidad, la instancia EC2 no se autoescala. Tendrá que elegir el tamaño de la instancia al configurar la replicación interregional de DynamoDB.

P: ¿Qué sucede si se produce un fallo en la instancia de Amazon EC2 que administra la replicación?

La instancia de Amazon EC2 se ejecuta tras un grupo de escalado automático, lo que significa que la aplicación realizará una conmutación por error automática a otra instancia. La aplicación utiliza la biblioteca de clientes de Kinesis (KCL), que marca puntos de control en la copia. Si falla una instancia, la aplicación puede encontrar el punto de control y continuar desde ahí.

P: ¿Puedo seguir utilizando mi tabla de DynamoDB mientras se crea una réplica de lectura?

Sí. La creación de una réplica es una operación online. La tabla seguirá estando disponible para operaciones de lectura y escritura mientras se crea la réplica. El proceso de arranque utiliza la operación de análisis para copiar desde la tabla de origen. Aconsejamos que aprovisione la tabla con suficientes unidades de capacidad de lectura para soportar la operación de análisis.

 

P: ¿Cuánto tiempo se tarda en crear una réplica?

El tiempo que se tarda en copiar una tabla maestra a la réplica por primera vez depende del tamaño de la tabla maestra, así como de la capacidad aprovisionada de la tabla maestra y la réplica. El tiempo que se tarda en propagar un cambio a nivel de elemento de la tabla maestra a la réplica depende de la capacidad aprovisionada en la tabla maestra y réplica y del tamaño de la instancia de Amazon EC2 que ejecuta la aplicación de replicación.

P: Si cambio la capacidad aprovisionada para la tabla maestra, ¿se actualiza también la capacidad aprovisionada para la réplica?

Una vez que se ha creado la replicación, cualquier cambio en la capacidad aprovisionada para la tabla maestra no actualizará la capacidad de desempeño de la réplica.

 

P: ¿Tendrán las réplicas los mismos índices que la tabla maestra?

Si decide crear la réplica a partir de la aplicación de replicación, los índices secundarios de la tabla maestra NO se crearán automáticamente en la réplica. La aplicación de replicación no propagará los cambios realizados en los índices secundarios de la tabla maestra a las réplicas. Tendrá que agregar/actualizar/eliminar los índices de cada una de las réplicas mediante la consola de administración de AWS, tal como lo haría con las tablas de DynamoDB convencionales.

 

P: ¿Tendrá la réplica la misma capacidad de desempeño provisionada que la tabla maestra?

Cuando cree la réplica, aconsejamos que aprovisione al menos la misma capacidad de escritura que en la tabla principal para asegurarse de disponer de suficiente capacidad para abordar todas las escrituras entrantes. Puede configurar la capacidad de lectura provisionada de la réplica en el nivel que resulte adecuado para su aplicación.

 

P: ¿Cuál es el modelo de consistencia de las réplicas?

Las réplicas se actualizan de manera asíncrona. DynamoDB considerará que una operación de lectura se ha realizado con éxito una vez que la tabla maestra la haya aceptado. A continuación, la escritura se propagará a todas las réplicas. Por lo tanto, se producirá un pequeño retraso al propagar una lectura a todas las réplicas.

P: ¿Existen métricas de CloudWatch para la replicación entre regiones?

Las métricas de CloudWatch están disponibles para todas las configuraciones de replicación. Para ver las métricas, seleccione el grupo de replicación y abra la pestaña de monitorización. Existen métricas disponibles sobre el desempeño y el número de registros procesados, y puede monitorizar cualquier discrepancia entre el desempeño de la tabla maestra y las réplicas.

P: ¿Se puede disponer de una réplica en la misma región que la tabla maestra?

Sí, siempre y cuando la tabla principal y la réplica tengan nombres distintos, ambas pueden existir en la misma región.

P: ¿Puedo agregar o eliminar una réplica después de crear un grupo de replicación?

Sí, puede agregar o eliminar una réplica del grupo de replicación en cualquier momento.

P: ¿Puedo eliminar un grupo de replicación una vez creado?

Sí. Al eliminar el grupo de replicación se eliminará la instancia EC2 del grupo. Sin embargo, tendrá que eliminar la tabla de metadatos de DynamoDB.

P: ¿Qué son los activadores de DynamoDB?

Los activadores de DynamoDB son una característica que le permite ejecutar acciones personalizadas a partir de actualizaciones a nivel de elemento en una tabla de DynamoDB. Puede especificar la acción personalizada mediante código.

P: ¿Qué puedo hacer con los activadores de DynamoDB?

Existen varias situaciones en las que los activadores de DynamoDB pueden resultar útiles. Algunos casos de uso incluyen el envío de notificaciones, la actualización de una tabla agregada y la conexión de tablas de DynamoDB con otras fuentes de datos.

P: ¿Cómo funcionan los activadores de DynamoDB?

La lógica personalizada de un activador de DynamoDB se almacena en una función de AWS Lambda como código. Para crear un activador para una tabla determinada, puede asociar una función de AWS Lambda a la transmisión (mediante DynamoDB Streams) en una tabla de DynamoDB. Cuando se actualice la tabla, las actualizaciones se publicarán en las transmisiones de DynamoDB. Por su parte, AWS Lambda leerá las actualizaciones de la transmisión asociada y ejecutará el código en la función.

P: ¿Cuánto cuesta el uso de los activadores de DynamoDB?

Con los activadores de DynamoDB, solo paga por la cantidad de solicitudes de la función de AWS Lambda y el tiempo que tarda en ejecutarse la función de AWS Lambda. Obtenga más información sobre los precios de AWS Lambda aquí. No se le cobra por las lecturas que la función de AWS Lambda realiza en la transmisión (mediante las transmisiones de DynamoDB) asociada con la tabla.

P: ¿Existen límites en cuanto a la cantidad de activadores que puede tener una tabla?

No existen límites en cuanto al número de activadores de una tabla.

P: ¿Qué lenguajes soportan los activadores de DynamoDB?

En la actualidad, los activadores de DynamoDB admiten JavaScript, Java y Python para las funciones de activación.

P: ¿Hay soporte de API para crear, editar o eliminar activadores de DynamoDB?

No, en la actualidad no existen API nativas que creen, editen o eliminen activadores de DynamoDB. Para crear una función de AWS Lambda y asociarla con una de las transmisiones de DynamoDB, debe utilizar la consola de AWS Lambda. Para obtener más información, consulte la página de preguntas frecuentes sobre AWS Lambda.

P: ¿Cómo creo un activador de DynamoDB?

Para crear un activador, puede crear una función de AWS Lambda y asociar la fuente del evento de la función a una transmisión de DynamoDB. Para obtener más información, consulte la página de preguntas frecuentes sobre AWS Lambda.

P: ¿Cómo puedo eliminar un activador de DynamoDB?

Puede eliminar un activador si elimina la función de AWS Lambda asociada. Puede borrar una función de AWS desde la consola de AWS Lambda o a través de una llamada al API de AWS Lambda. Para obtener más información, consulte la página de preguntas frecuentes sobre AWS Lambda y la página de la documentación.

P: Ya tengo una función de AWS Lambda. ¿Cómo puedo crear un activador de DynamoDB usando esta función?

Puede cambiar la fuente del evento de la función de AWS Lambda de manera que apunte a una de las transmisiones de DynamoDB. Para ello, vaya a la consola de DynamoDB. En la tabla para la que se ha activado la transmisión, elija dicha transmisión, seleccione el botón Associate Lambda Function y, a continuación, elija la función que desea utilizar para el activador de DynamoDB en la lista de funciones de Lambda.

P: ¿En qué regiones están disponibles los activadores de DynamoDB?

Los activadores de DynamoDB están disponibles en todas las regiones de AWS en las que están disponibles AWS Lambda y DynamoDB.

P: ¿Qué es DynamoDB Streams?

DynamoDB Streams proporciona una secuencia en orden cronológico de los cambios a nivel de elemento realizados en los datos de una tabla en las últimas 24 horas. Puede obtener acceso a una transmisión con una sencilla llamada API y utilizarla para mantener al día otros almacenes de datos de forma que reflejen los últimos cambios realizados en DynamoDB o para tomar medidas en función de los cambios realizados en la tabla.

P: ¿Cuáles son los beneficios de DynamoDB Streams?

Con las API de DynamoDB Streams, los desarrolladores pueden recibir actualizaciones y obtener los datos de nivel de elemento antes y después de que se cambien los elementos. Esto sirve para crear extensiones creativas en sus aplicaciones desarrolladas sobre DynamoDB. Por ejemplo: un desarrollador que cree un juego multijugador a nivel mundial con DynamoDB puede usar las API de DynamoDB Streams y crear una topología con varias versiones maestras y mantenerlas sincronizadas consumiendo las transmisiones de DynamoDB de cada versión maestra y reproduciendo las actualizaciones en las versiones maestras remotas. O, por poner otro ejemplo, los desarrolladores pueden utilizar las API de las transmisiones de DynamoDB para crear aplicaciones móviles que avisan automáticamente a los dispositivos móviles de todos los amigos de un grupo en cuanto un usuario suba un selfie nuevo. Los desarrolladores también podrían utilizar las transmisiones de DynamoDB para mantener herramientas de almacenamiento de datos (como Amazon Redshift) sincronizadas con todos los cambios realizados en su tabla de DynamoDB a fin de poder disponer de análisis en tiempo real. DynamoDB también se integra con Elasticsearch mediante el complemento Logstash de Amazon DynamoDB, lo que permite a los desarrolladores agregar la búsqueda de texto sin formato de contenidos de DynamoDB.

Puede obtener más información sobre las transmisiones de DynamoDB en nuestra documentación.

P: Si utilizo las transmisiones de DynamoDB, ¿cuánto tiempo estarán disponibles los cambios que haya realizado en mi tabla de DynamoDB?

DynamoDB Streams mantiene un registro de todos los cambios realizados en la tabla durante 24 horas. Transcurrido ese tiempo, los cambios se borran.

P: ¿Cómo puedo habilitar las transmisiones de DynamoDB?

DynamoDB Streams se debe habilitar tabla a tabla. Para habilitar DynamoDB Streams para una tabla de DynamoDB existente, seleccione la tabla en la consola de administración de AWS, elija la pestaña Overview, haga clic en el botón Manage Stream, seleccione un tipo de vista y haga clic en Enable.

Para obtener más información, consulte nuestra documentación.

P: ¿Cómo puedo verificar que DynamoDB Streams está habilitado?

Cuando haya habilitado DynamoDB Streams, verá la transmisión en la consola de administración de AWS. Seleccione su tabla y, a continuación, elija la pestaña Overview. En los detalles de Streams, verifique que la configuración de "Streams enabled" es "Sí".

P: ¿Cómo puedo obtener acceso a DynamoDB Streams?

Puede obtener acceso a una transmisión de DynamoDB con una sencilla llamada API mediante el SDK de DynamoDB o a través de la biblioteca de clientes de Kinesis (KCL). La KCL le ayuda a utilizar y procesar los datos de la transmisión, así como a administrar tareas como el equilibrio de carga entre varios lectores, la respuesta a fallos de las instancias y la creación de puntos de control en registros procesados.

Para obtener más información sobre el acceso a las transmisiones de DynamoDB, consulte nuestra documentación.

P: ¿Muestra DynamoDB Streams los cambios realizados en mi tabla de DynamoDB en orden?

Los cambios realizados en cada elemento concreto aparecen en el orden correcto. Los cambios realizados en diferentes elementos pueden aparecer en las transmisiones de DynamoDB en un orden diferente al de su recepción.

Por ejemplo: imagine que tiene una tabla de DynamoDB para controlar las mejores puntuaciones obtenidas en un juego y que cada elemento de la tabla representa a un jugador concreto. Imagine que realiza las tres actualizaciones siguientes en este orden:

  • Cambio 1: Cambiar la puntuación máxima del Jugador 1 a 100 puntos
  • Cambio 2: Cambiar la puntuación máxima del Jugador 2 a 50 puntos
  • Cambio 3: Cambiar la puntuación máxima del Jugador 1 a 125 puntos

Las actualizaciones 1 y 3 se refieren al mismo elemento (jugador 1), con lo que las transmisiones de DynamoDB indicarán que la actualización 3 fue posterior a la actualización 1. De esta forma podrá recuperar la puntuación máxima actualizada de cada jugador. Es posible que la transmisión no indique que las tres actualizaciones se hicieron en el mismo orden (es decir, que la actualización 2 fue posterior a la actualización 1 y anterior a la actualización 3), pero las actualizaciones a la puntuación máxima de cada jugador concreto sí aparecerán en el orden correcto.

P: ¿Necesito administrar la capacidad de una transmisión en DynamoDB Streams?

No, la característica DynamoDB Streams administra automáticamente la capacidad de la transmisión. Si aumenta notablemente el tráfico dirigido a su tabla de DynamoDB, DynamoDB ajustará automáticamente la capacidad de la transmisión de DynamoDB para poder seguir recibiendo todas las actualizaciones.

P: ¿A qué velocidad se puede leer desde DynamoDB Streams?

Las actualizaciones a las transmisiones de DynamoDB pueden leerse al doble de la velocidad de la capacidad de lectura provisionada de su tabla de DynamoDB. Por ejemplo, si ha aprovisionado suficiente capacidad para actualizar 1 000 elementos por segundo en su tabla de DynamoDB, podrá leer hasta 2 000 cambios por segundo procedentes de su transmisión.

P: Si elimino mi tabla de DynamoDB, ¿se eliminan también las transmisiones de DynamoDB?

No de forma inmediata. La transmisión seguirá estando presente durante 24 horas en las transmisiones de DynamoDB para que pueda leer las últimas actualizaciones realizadas en su tabla. Después de 24 horas, la transmisión se eliminará automáticamente de las transmisiones de DynamoDB.

P: ¿Qué sucede si desactivo las transmisiones de DynamoDB en mi tabla?

Si desactiva las transmisiones de DynamoDB, el servicio seguirá funcionando durante 24 horas, pero no se actualizará con ningún cambio adicional que se haya realizado en su tabla de DynamoDB.

P: ¿Qué sucede si desactivo las transmisiones de DynamoDB y luego vuelvo a activarlas?

Si desactiva las transmisiones de DynamoDB, el servicio seguirá funcionando durante 24 horas, pero no se actualizará con ningún cambio adicional que se haya realizado en su tabla de DynamoDB. Si vuelve a activar las transmisiones de DynamoDB, se creará una nueva transmisión en las transmisiones de DynamoDB que contendrá los cambios realizados en su tabla de DynamoDB a partir de la hora de creación de la nueva transmisión.

P: ¿Habrá lagunas o duplicados en las transmisiones de DynamoDB?

No, la característica DynamoDB Streams está diseñada de manera que cada actualización que se realice en la tabla se represente una única vez en la transmisión.

P: ¿Qué información se incluye en las transmisiones de DynamoDB?

La transmisión de DynamoDB contendrá información tanto del valor anterior como del valor que se ha cambiado para cada elemento. La transmisión también incluye el tipo de cambio realizado (INSERT, REMOVE y MODIFY) y la clave principal del elemento que se ha cambiado.

P: ¿Cómo puedo elegir qué información se incluye en las transmisiones de DynamoDB?

Si se trata de una tabla nueva, utilice el API CreateTable y especifique el parámetro ViewType para elegir qué información se incluye en la transmisión.
Si se trata de una tabla existente, utilice la llamada al API UpdateTable y especifique el parámetro ViewType para elegir qué información se debe incluir en la transmisión.

El parámetro ViewType adopta los siguientes valores:

ViewType: {
                    { KEYS_ONLY,
                      NEW_IMAGE,
                      OLD_IMAGE,
                      NEW_AND_OLD_IMAGES}
                }

Los valores tienen el siguiente significado: KEYS_ONLY: Solo se incluye en la transmisión el nombre de la clave de los elementos que se han cambiado.

  • NEW_IMAGE: se incluyen en la transmisión el nombre de la clave y el elemento después de la actualización (elemento nuevo).
  • OLD_IMAGE: en la transmisión se incluyen el nombre de la clave y el elemento antes de la actualización (elemento antiguo).
  • NEW_AND_OLD_IMAGES: se incluyen en la transmisión el nombre de la clave, el elemento antes de la actualización (elemento antiguo) y el elemento después de la actualización (elemento nuevo).

P: ¿Puedo utilizar mi biblioteca de clientes de Kinesis para obtener acceso a DynamoDB Streams?

Sí, a los desarrolladores que conozcan las API de Kinesis les resultará fácil utilizar las transmisiones de DynamoDB. Puede utilizar DynamoDB Streams Adapter, que implementa la interfaz de Amazon Kinesis, para que su aplicación pueda utilizar las bibliotecas de clientes de Amazon Kinesis (KCL) para obtener acceso a DynamoDB Streams. Para obtener más información sobre cómo usar la biblioteca KCL para obtener acceso a DynamoDB Streams, consulte nuestra documentación.

P: ¿Puedo cambiar el tipo de información que se incluye en DynamoDB Streams?

Si desea cambiar el tipo de información que se almacena en una transmisión una vez que se haya creado, deberá inhabilitarla y crear una nueva con ayuda del API UpdateTable.

P: Cuando realizo un cambio en mi tabla de DynamoDB, ¿cuánto tiempo tarda en mostrarse en una transmisión de DynamoDB?

Los cambios suelen tardar menos de un segundo en reflejarse en una transmisión de DynamoDB.

P: Si elimino un elemento, ¿se incluirá dicho cambio en las transmisiones de DynamoDB?

Sí. Cada cambio que se haga en una transmisión de DynamoDB contiene un parámetro que especifica si se trata de una eliminación, la inserción de un nuevo elemento o la modificación de un elemento ya existente. Para obtener más información sobre los distintos tipos de actualizaciones, consulte nuestra documentación.

P: Una vez que haya activado DynamoDB Streams en mi tabla, ¿cuándo puedo comenzar a leer de la transmisión?

Puede utilizar el API DescribeStream para consultar el estado actual de la transmisión. Cuando el estado cambie a “ENABLED”, todas las actualizaciones realizadas en su tabla estarán representadas en la transmisión.

Puede comenzar a leer de la transmisión en cuanto comience a crearla, pero es posible que la transmisión no contenga todas las actualizaciones realizadas en la tabla hasta que el estado no cambie a ENABLED.

P: ¿Qué es el complemento Logstash de Amazon DynamoDB para Elasticsearch?

Elasticsearch es un popular motor de búsqueda y análisis de código abierto diseñado para simplificar las búsquedas y el análisis de big data en tiempo real. Logstash es una canalización de datos de código abierto que funciona con Elasticsearch para ayudarle a procesar registros y otros datos de eventos. El complemento Logstash de Amazon DynamoDB facilita la integración de tablas de DynamoDB con clústeres de Elasticsearch.

P: ¿Cuánto cuesta el complemento Logstash de Amazon DynamoDB?

Descargar y utilizar el complemento Logstash de Amazon DynamoDB es gratis.

P: ¿Cómo se descarga e instala el complemento Logstash de Amazon DynamoDB?

El complemento Logstash de Amazon DynamoDB se encuentra disponible en GitHub. Lea nuestra página de documentación para obtener más información sobre la instalación y ejecución del complemento.


P: ¿Qué es el back-end de almacenamiento de DynamoDB para Titan?

El back-end de almacenamiento de DynamoDB para Titan es un complemento que le permite utilizar DynamoDB como capa de almacenamiento subyacente para una base de datos de gráficos de Titan. Es una solución del lado del cliente que implementa adyacencia sin índices para facilitar desplazamientos de gráficos rápidos en DynamoDB.

P: ¿Qué es una base de datos de gráficos?

Una base de datos de gráficos es un almacén de vértices y aristas dirigidas que los conectan. Tanto los vértices como las aristas pueden tener propiedades almacenadas como pares clave-valor.

Una base de datos de gráficos utiliza listas de adyacencia para almacenar las aristas que facilitan un desplazamiento sencillo. Un gráfico de una base de datos de gráficos se puede desplazar a lo largo de tipos de aristas específicos, o por todo el gráfico. Las bases de datos de gráficos pueden representar la relación entre entidades mediante acciones, propiedades, elementos primarios, etc.

P: ¿Qué aplicaciones son aptas para el uso con bases de datos de gráficos?

Cuando las conexiones o relaciones entre entidades forman parte fundamental de los datos que intenta modelar, una base de datos de gráficos constituye la elección más obvia. Por lo tanto, estas bases de datos resultan útiles para el modelado y la consulta de redes sociales, relaciones empresariales, dependencias, desplazamientos de transporte y más.

P: ¿Cómo puedo comenzar a utilizar el back-end de almacenamiento de DynamoDB para Titan?

La manera más sencilla de comenzar es lanzar una instancia EC2 ejecutando el servidor Gremlin con el back-end de almacenamiento de DynamoDB para Titan, mediante las plantillas de CloudFormation a las que se hace referencia en esta página de documentación. También puede clonar el proyecto del repositorio de GitHub y comenzar con los tutoriales de Marvel y Graph-Of-The-Gods en su equipo, utilizando las instrucciones de la documentación disponible aquí. Cuando esté listo para ampliar las pruebas o ejecutar en producción, puede pedir al back-end que utilice el servicio DynamoDB. Consulte la documentación de AWS si desea obtener más detalles.

P: ¿En qué difiere el back-end de almacenamiento de DynamoDB para Titan de otros back-end de almacenamiento de Titan?

DynamoDB es un servicio administrado, por lo que utilizarlo como back-end de almacenamiento para Titan le permite ejecutar cargas de trabajo de gráficos sin tener que administrar su propio clúster de almacenamiento de gráficos.

P: ¿Es el back-end de almacenamiento de DynamoDB para Titan un servicio totalmente administrado?

No. El back-end de almacenamiento de DynamoDB para Titan administra la capa de almacenamiento de la carga de trabajo de Titan. Sin embargo, el complemento no aprovisiona ni administra en el lado del cliente. Para lograr un aprovisionamiento sencillo de Titan, hemos desarrollado una plantilla de CloudFormation que configura el back-end de almacenamiento de DynamoDB para Titan con Gremlin Server. Consulte las instrucciones disponibles aquí.

P: ¿Cuánto cuesta el uso del back-end de almacenamiento de DynamoDB para Titan?

Se cobra el desempeño estándar de DynamoDB y los costos de almacenamiento. El uso de DynamoDB como back-end de almacenamiento para una carga de trabajo de gráficos de Titan no conlleva costos adicionales.

P: ¿Es el back-end de DynamoDB totalmente compatible con el conjunto de características de Titan de otros back-end?

En la documentación se encuentra disponible una tabla en la que se comparan los conjuntos de características de distintos back-end de almacenamiento de Titan.

P: ¿Con qué versiones de Titan es compatible el complemento?

Hemos publicado back-end de almacenamiento de DynamoDB para las versiones 0.5.4 y 1.0.0 de Titan.

P: En la actualidad, utilizo Titan con un back-end diferente. ¿Puedo pasarme a DynamoDB?

Por supuesto. El back-end de almacenamiento de DynamoDB para Titan implementa la interfaz de Titan KCV Store para que pueda pasar de un back-end distinto a DynamoDB realizando cambios mínimos en la aplicación. Consulte nuestra documentación, en la que se incluye una comparativa completa de los back-end de almacenamiento para Titan.

P: En la actualidad, utilizo Titan con un back-end diferente. ¿Cómo puedo efectuar la migración a DynamoDB?

Puede utilizar la carga por lotes para copiar su gráfico de un back-end de almacenamiento al back-end de almacenamiento de DynamoDB para Titan.

P: ¿Cómo conecto mi instancia de Titan con DynamoDB mediante el complemento?

Si crea un gráfico y una instancia de servidor Gremlin con el back-end de almacenamiento de DynamoDB para Titan instalado, para conectarse con DynamoDB basta con proporcionar un conjunto de entidades de seguridad/credenciales a la cadena del proveedor de credenciales de AWS predeterminado. Puede hacerlo mediante un perfil de instancia EC2, variables de entorno o el archivo de credenciales de su carpeta particular. Por último, debe elegir el punto de enlace de DynamoDB con el que desea conectarse.

P: ¿Cuál es la durabilidad de mis datos cuando se utiliza el back-end de almacenamiento de DynamoDB para Titan?

Al utilizar el back-end de almacenamiento de DynamoDB para Titan, sus datos se benefician de la excelente protección de DynamoDB, que se ejecuta en los centros de datos probados de alta disponibilidad de Amazon. El servicio replica datos en tres instalaciones de una región de AWS a fin de ofrecer tolerancia a errores en caso de que falle el servidor o de que se produzcan interrupciones en la zona de disponibilidad.

P: ¿Qué nivel de seguridad ofrece el back-end de almacenamiento de DynamoDB para Titan?

El back-end de almacenamiento de DynamoDB para Titan almacena datos de gráficos en varias tablas de DynamoDB, por lo que ofrece el mismo nivel de seguridad que todas las cargas de trabajo de DynamoDB. El control de acceso minucioso, las funciones IAM y los conjuntos de entidades de seguridad/credenciales de AWS controlan el acceso a las tablas de DynamoDB y los elementos contenidos en las mismas.

P: ¿Cómo se escala el back-end de almacenamiento de DynamoDB para Titan?

El back-end de almacenamiento de DynamoDB para Titan se escala como cualquier otra carga de trabajo de DynamoDB. Puede incrementar o reducir el desempeño necesario en cualquier momento.

P: ¿Cuántos vértices y aristas puede contener un gráfico?

Deberá atenerse a los límites de Titan (2^60) respecto al número máximo de aristas de un gráfico, siendo el número máximo de vértices la mitad, cuando utilice el modelo de varios elementos para edgestore. Si utiliza el modelo de un elemento, el número de aristas que puede almacenar en una clave de vértice de salida se ve limitado por el tamaño de elemento máximo de DynamoDB, que en la actualidad es 400 KB.

P: ¿Cuál es el tamaño máximo admitido para las propiedades de vértices y aristas?

La suma de todas las propiedades de aristas en un modelo de varios elementos no puede exceder los 400 KB, el tamaño máximo de elemento. En el modelo de varios elementos, cada propiedad de vértice puede tener un tamaño máximo de 400 KB. En el modelo de un elemento, el tamaño total del elemento (incluidas las propiedades de vértices, las aristas y las propiedades de aristas) no puede exceder los 400 KB.

P: ¿Cuántos modelos de datos existen? ¿Cuáles son las diferencias?

Existen dos modelos de almacenamiento distintos para el back-end de almacenamiento de DynamoDB para Titan: el de un elemento y el de varios elementos. En el modelo de un elemento, los vértices, las propiedades de vértices y las aristas se almacenan en un elemento. En el modelo de varios elementos, los vértices, las propiedades de vértices y las aristas se almacenan en elementos distintos. En ambos casos, las propiedades de aristas se almacenan en los mismos elementos que las aristas con los que se corresponden.

P: ¿Qué modelo de datos debería utilizar?

Por lo general, recomendamos utilizar el modelo de datos de varios elementos para las tablas edgestore y graphindex. De otro modo, tendrá que limitar el número de propiedades de aristas/vértices que se pueden almacenar para un vértice de salida, o bien limitar el número de entidades que se pueden indizar en un par nombre-valor de propiedad particular en un índice de gráfico. Por lo general, puede utilizar el modelo de un elemento para los otros 4 almacenamientos KCV de las versiones 0.5.4 y 1.0.0 de Titan, ya que cada uno de los elementos almacenados en ellos suele tener un tamaño inferior a 400 KB. Para obtener una lista completa de las tablas que el complemento de Titan crea en DynamoDB, haga clic aquí.

P: ¿Tengo que crear un esquema para las bases de datos de gráficos de Titan?

Titan admite la creación de tipos automática, de manera que las nuevas propiedades de aristas/vértices se registrarán sobre la marcha al utilizarlo por primera vez (consulte aquí los detalles). De forma predeterminada se utiliza el esquema Gremlin (etiquetas de la arista=MULTI, propiedades del vértice=SINGLE).

P: ¿Puedo cambiar el esquema de una base de datos de gráficos de Titan?

Sí. Sin embargo, no puede cambiar el esquema de las propiedades de vértices/aristas y etiquetas existentes. Consulte más información aquí.

P: ¿Cómo administra los supernodos el back-end de almacenamiento de DynamoDB para Titan?

DynamoDB administra los supernodos mediante la partición de las etiquetas de vértices. Si, al crearla, define una etiqueta de vértice como con particiones en el sistema de administración, puede introducir subconjuntos distintos de las propiedades de aristas y vértices procedentes de un vértice con claves de partición diferentes del espacio para claves partición-clase en la tabla edgestore. Normalmente, las particiones de la etiqueta del vértice se almacenan en particiones de DynamoDB físicas distintas, siempre y cuando la tabla edgestore disponga de más de una partición física. Para estimar la cantidad de particiones físicas de la tabla edgestore, consulte la información orientativa de la documentación.

P: ¿Es el back-end de almacenamiento de DynamoDB para Titan compatible con las operaciones de gráficos por lotes?

Sí, el back-end de almacenamiento de DynamoDB para Titan es compatible con la implementación de gráficos por lotes con Blueprints BatchGraph y mediante las opciones de configuración de la carga por lotes de Titan.

P: ¿Es el back-end de almacenamiento de DynamoDB para Titan compatible con las transacciones?

El back-end de almacenamiento de DynamoDB para Titan es compatible con el bloqueo optimista. Por lo tanto, puede establecer las condiciones de la escritura de pares clave-columna (en el modelo de varios elementos) o claves individuales (en el modelo de un elemento) en el valor de dicho par clave-columna o dicha clave.

P: ¿Puedo disponer de una instancia de Titan en una región y obtener acceso a DynamoDB en otra?

Es posible obtener acceso a un punto de enlace de DynamoDB en otra región distinta a la de la instancia de Titan de EC2, pero no se aconseja que lo haga. Cuando ejecute un servidor Gremlin desde EC2, aconsejamos que se conecte al punto de enlace de DynamoDB en la región de la instancia EC2, a fin de reducir las repercusiones en la latencia de las solicitudes entre regiones. Asimismo, aconsejamos que ejecute la instancia EC2 en una VPC para mejorar el desempeño de la red. La plantilla de CloudFormation se ocupa de realizar toda la configuración.

P: ¿Puedo utilizar este complemento con otras características de DynamoDB, como la actualización de transmisiones y la replicación entre regiones?

Puede utilizar la replicación entre regiones con las transmisiones de DynamoDB para crear réplicas de solo lectura de las tablas de gráficos en otras regiones.


P: ¿Informa Amazon DynamoDB de las métricas de CloudWatch?

Sí, Amazon DynamoDB informa de varias métricas de CloudWatch en el nivel de tabla. En función de estas métricas puede tomar decisiones operativas respecto a las tablas de Amazon DynamoDB y realizar acciones determinadas, como configurar alarmas. Para obtener una lista completa de las métricas de las que se informa, consulte la sección Monitoring DynamoDB with CloudWatch de la documentación.

P: ¿Cómo puedo ver las métricas de CloudWatch de una tabla de Amazon DynamoDB?

En la consola de Amazon DynamoDB, elija la tabla cuyas métricas de CloudWatch desea ver y seleccione la pestaña Metrics.

P: ¿Con qué frecuencia se informa de las métricas?

De la mayoría de las métricas de CloudWatch para Amazon DynamoDB se informa cada minuto, mientras que, para las demás métricas, el intervalo es de 5 minutos. Para obtener más detalles, consulte la sección Monitoring DynamoDB with CloudWatch de la documentación.


P: ¿Qué es una etiqueta?

Una etiqueta es una marca que se asigna a un recurso de AWS. Cada etiqueta consta de una clave y un valor, ambos definidos por usted. AWS utiliza las etiquetas como mecanismo para organizar los costos de los recursos en el informe de asignación de costos. Para obtener más información sobre el etiquetado, consulte la Guía del usuario de facturación y administración de costos de AWS.

P: ¿Qué recursos de DynamoDB puedo etiquetar?

Puede etiquetar tablas de DynamoDB. Los índices secundarios locales e índices secundarios globales asociados con las tablas etiquetadas reciben automáticamente las mismas etiquetas. Los cotos de los índices secundarios locales e índices secundarios globales aparecerán en las etiquetas utilizadas para la tabla de DynamoDB correspondiente.

P: ¿Por qué debería utilizar el etiquetado para DynamoDB?

Puede utilizar el etiquetado para DynamoDB para la asignación de costos. La utilización de etiquetas para la asignación de costos le permite etiquetar sus recursos de DynamoDB de manera que pueda monitorizar sus costos por proyecto o en función de otros criterios que reflejen su propia estructura de costos.

P: ¿Cómo puedo utilizar las etiquetas para la asignación de costos?

Puede utilizar las etiquetas de asignación de costos para categorizar y monitorizar sus costos de AWS. AWS Cost Explorer y los informes de facturación detallados le permiten desglosar los costos de AWS por etiqueta. Por lo general, los clientes utilizan etiquetas empresariales como el centro de costos/unidad empresarial o el proyecto para asociar los costos de AWS con dimensiones de asignación de costos tradicionales. Sin embargo, un informe de asignación de costos puede incluir cualquier etiqueta. Eso le permite asociar los costes de manera sencilla con dimensiones técnicas o de seguridad, como aplicaciones, entornos o programas de conformidad específicos.

P: ¿Cómo puedo ver los costos asociados con mis recursos etiquetados de AWS?

Puede ver los costos asignados a sus recursos etiquetados de AWS a través de Cost Explorer o su informe de asignación de costos.

Cost Explorer es una herramienta de AWS gratuita que puede utilizar para ver los costos de hasta los últimos 13 meses y predecir cuánto es probable que se gaste en los próximos tres meses. Puede ver los costos por etiquetas específicas si usa el filtro “Tag” y, a continuación, elige la clave y valor de la etiqueta (seleccione “No tag” si el valor de la etiqueta no se ha especificado).

El informe de asignación de costos incluye todos los costos de AWS para cada periodo de facturación. El informe incluye tanto recursos etiquetados como sin etiquetar, para que pueda organizar claramente los cargos de los recursos. Por ejemplo, si etiqueta recursos con el nombre de una aplicación, puede monitorizar el costo total de una única aplicación ejecutada en esos recursos. Puede encontrar más información sobre la asignación de costos en la Guía del usuario de facturación y administración de costos de AWS.

P: ¿Puede etiquetarse el uso de DynamoDB Streams?

No, en este momento no es posible etiquetar el uso de DynamoDB Streams.

P: ¿Aparecerá el uso de capacidad reservada como parte de las etiquetas de mi tabla en mi factura?

Sí, los cargos de la capacidad reservada de DynamoDB se mostrarán como parte de las etiquetas relevantes. Tenga en cuenta que la capacidad reservada se aplica al uso de DynamoDB por orden de llegada y en todas las cuentas de AWS asociadas. Eso significa que, incluso si su uso de DynamoDB en las tablas e índices es similar mes a mes, es posible que observe diferencias en los informes de asignación de costos por etiquetas, ya que la capacidad reservada se distribuirá en función de los recursos de DynamoDB que se midan primero.

P: ¿Aparecerán los cargos por uso de datos como parte de las etiquetas de mi tabla en mi factura?

No, los cargos por uso de datos de DynamoDB no se etiquetan. Esto se debe a que el uso de datos se factura a nivel de cuenta y no de tabla.

P: ¿Es necesario que mis etiquetas tengan un atributo de valor?

No, los valores de las etiquetas pueden dejarse vacíos.

P: ¿Distinguen las etiquetas el uso de mayúsculas y minúsculas?

Sí, las etiquetas distinguen el uso de mayúsculas y minúsculas.

P: ¿Cuántas etiquetas puedo agregar a una sola tabla de DynamoDB?

Puede agregar hasta 50 etiquetas a una sola tabla de DynamoDB. Las etiquetas con el prefijo "aws:" no pueden crearse de forma manual y no cuentan para el límite de etiquetas por recurso.

P: ¿Puedo aplicar etiquetas a mis tablas de DynamoDB de forma retroactiva?

No, las etiquetas comienzan a organizar y monitorizar los datos a partir de la fecha en que las aplica. Si crea una tabla el 1 de enero pero no designa una etiqueta para ella hasta el 1 de febrero, el uso de esa tabla en enero seguiría sin etiquetar.

P: Si elimino una etiqueta de mi tabla de DynamoDB antes de que acabe el mes, ¿seguirá apareciendo la etiqueta en mi factura?

Sí, si crea un informe de sus gastos monitorizados correspondiente a un periodo de tiempo específico, sus informes de costos mostrarán los costos de los recursos etiquetados durante ese tiempo.

P: ¿Qué pasa con las etiquetas existentes cuando se elimina una tabla de DynamoDB?

Cuando se elimina una tabla de DynamoDB, sus etiquetas se eliminan automáticamente.

P: ¿Qué pasa si agrego una etiqueta con una clave idéntica a una clave de una etiqueta existente?

Cada tabla de DynamoDB solo puede tener una etiqueta con la misma clave. Si agrega una etiqueta con la misma clave que otra etiqueta existente, la etiqueta existente se actualizará con el nuevo valor.


P: ¿Qué es DynamoDB Time-to-Live (TTL)?

DynamoDB Time-to-Live (TTL) es un mecanismo que le permite configurar un sello temporal específico para eliminar elementos que han expirado de sus tablas. Una vez que el sello temporal expira, el elemento correspondiente se marca como expirado y se elimina de la tabla. Al usar esta funcionalidad, no es necesario detectar los datos expirados y eliminarlos manualmente. TTL puede ayudarle a reducir el uso del almacenamiento y el costo de almacenar datos que ya no necesita.

P: ¿Por qué debo utilizar TTL?

Existen dos situaciones en las que TTL le puede resultar de utilidad:

  • Eliminar datos antiguos que ya no son necesarios, como logs de eventos, el historial de uso, los datos de la sesión, etc., Datos que con el tiempo crecen significativamente y que, aunque estén almacenados en el sistema, es posible que ya no se necesiten. En estas situaciones, es mejor eliminar estos registros antiguos del sistema y ahorrar los costos que conlleva almacenarlos.
  • A veces, puede que quiera almacenar los datos en DynamoDB durante un tiempo determinado por motivos de conformidad con las políticas de administración y retención de datos. Una vez expirado el plazo obligatorio, podría querer eliminar estos datos. No obstante, tenga en cuenta que TTL sigue un principio de mejor esfuerzo, con el fin de garantizar el desempeño necesario para otras operaciones críticas. DynamoDB intentará eliminar los elementos expirados en un plazo de dos días. El tiempo que tarde en realidad puede ser algo más largo, dependiendo del tamaño de los datos.

P: ¿Cómo funciona DynamoDB TTL?

Para habilitar TTL para una tabla, primero asegúrese de que hay un atributo capaz de almacenar el sello temporal de expiración para cada elemento de la tabla. Este sello temporal debe encontrarse en formato de tiempo Epoch. De este modo, se evitan las discrepancias entre clientes y servidores.

DynamoDB ejecuta un escáner de fondo que monitoriza todos los elementos. Si el sello temporal ha expirado, el proceso marcará el elemento como expirado y lo colocará en una cola para su eliminación.

Nota: TTL requiere un atributo de tabla DynamoDB numérico con un sello temporal Epoch para especificar el criterio de expiración de los datos. Tenga cuidado al configurar un valor para el atributo TTL, ya que el valor equivocado podría hacer que los elementos se eliminen antes de tiempo.

P: ¿Cómo puedo especificar TTL?

Para especificar TTL, primero habilite el ajuste TTL en la tabla y especifique el atributo que se va a usar como valor TTL. A medida que agrega elementos a la tabla, puede especificar un atributo TTL si desea que DynamoDB los elimine cuando expiren. Este valor es el tiempo de expiración, especificado en formato de tiempo Epoch. DynamoDB se ocupa del resto. TTL se puede especificar desde la consola, desde la pestaña de vista general de la tabla. Además, los desarrolladores pueden invocar la API de TTL para configurar TTL en la tabla. Consulte nuestra documentación y nuestra guía de la API.

P: ¿Puedo configurar TTL en tablas existentes?

Sí. Si una tabla ya está creada y tiene un atributo que se puede usar como TTL para sus elementos, entonces basta con habilitar TTL para la tabla y designar el atributo adecuado para TTL. Si la tabla no tiene un atributo que se pueda utilizar para TTL, tendrá que crear dicho atributo y actualizar los elementos con valores para TTL.

P: ¿Puedo eliminar una tabla entera configurando TTL en toda la tabla?

No. Aunque es necesario definir un atributo para que se utilice para TTL a nivel de tabla, la eliminación de datos se efectúa a nivel de elemento. Es decir, cada elemento de la tabla que ha de eliminarse una vez expirado ha de tener un valor definido para el atributo TTL. No existe la opción de eliminar automáticamente toda la tabla.

P: ¿Puedo configurar TTL solo para un subconjunto de elementos de la tabla?

Sí. TTL afecta solamente a aquellos elementos con un valor definido en el atributo TTL. Los demás elementos de la tabla no se ven afectados.

P: ¿Cuál es el formato para especificar TTL?

El valor TTL debería utilizar el formato de tiempo Epoch, que es la cantidad de segundos desde el 1 de enero de 1970 hora UTC. Si el valor especificado en el atributo TTL para un elemento no se encuentra en el formato adecuado, se ignorará y el elemento no se eliminará.

P: ¿Cómo puedo leer el valor TTL de los elementos de mi tabla?

El valor TTL es como cualquier otro atributo de los elementos. Se puede leer del mismo modo que los demás atributos. Para que resulte más sencillo confirmar los valores TTL visualmente, la consola de DynamoDB le permite pasar el cursor sobre un atributo TTL para ver su valor en hora UTC y local de lectura humana.

P: ¿Puedo crear un índice basado en los valores TTL asignados a los elementos de una tabla?

Sí. TTL se comporta como los demás atributos de los elementos. Puede crear índices del mismo modo que con otros atributos.

P: ¿Es posible proyectar el atributo TTL en un índice?

Sí. El atributo TTL se puede proyectar en un índice, al igual que cualquier otro atributo.

P: ¿Puedo editar el valor del atributo TTL una vez que se ha configurado para un elemento?

Sí. Puede modificar el valor del atributo TTL del mismo modo que modificaría cualquier otro atributo de un elemento.

P: ¿Puedo cambiar el atributo TTL de una tabla?

Sí. Si una tabla tiene TTL habilitado y quiere especificar un atributo TTL distinto, primero tiene que deshabilitar TTL en la tabla y, a continuación, puede volver a habilitarlo con un nuevo atributo TTL distinto. Tenga en cuenta que es posible que se tarde hasta una hora en deshabilitar TTL en todas las particiones, y no podrá volver a habilitar TTL hasta que se complete esta acción.

P: ¿Puedo usar la consola de administración de AWS para ver y editar los valores TTL?

Sí. La consola de administración de AWS le permite ver, configurar o actualizar el valor TTL de manera sencilla.

P: ¿Puedo configurar un atributo de un documento JSON para que sea el atributo TTL?

No. En la actualidad, no se admite la especificación de un atributo de un documento JSON como atributo TTL. Para configurar TTL, debe agregar el atributo TTL específicamente a cada elemento.

P: ¿Puedo configurar TTL para un elemento específico de un documento JSON?

No. Los valores TTL solo se pueden configurar para todo el documento. No se admite la eliminación de un elemento específico de un documento JSON una vez que expire.

P: ¿Qué pasa si tengo que eliminar TTL en elementos específicos?

Eliminar TTL es tan sencillo como eliminar el valor asignado al atributo TTL o eliminar el atributo de un elemento.

P: ¿Qué pasa si configuro el valor del sello temporal TTL a una fecha del pasado?

Es posible actualizar elementos con valores TTL antiguos. Cuando el proceso de fondo busque elementos expirados, encontrará, marcará y eliminará el elemento. Sin embargo, si el atributo TTL contiene un valor Epoch para un sello temporal correspondiente a más de 5 años en el pasado, DynamoDB ignorará el sello temporal y no eliminará el elemento. Eso se hace para mitigar la eliminación accidental de elementos cuando se almacenan valores muy bajos en el atributo TTL.

P: ¿Cuánto se tarda entre la expiración TTL de un elemento y el momento en que se elimina dicho elemento?

TTL escanea y elimina elementos expirados utilizando el desempeño disponible en el sistema. Como resultado, es posible que el elemento expirado no se elimine de la tabla inmediatamente. DynamoDB intentará eliminar los elementos expirados dentro de un periodo de dos días de acuerdo con un principio de mejor esfuerzo para garantizar la disponibilidad del desempeño de fondo del sistema para otras operaciones de datos. El momento exacto en que se eliminará un elemento una vez expirado dependerá de la naturaleza de la carga de trabajo y el tamaño de la tabla.

P: ¿Qué pasa si intento realizar consultas o buscar elementos que han sido expirados por TTL?

Teniendo en cuenta que puede pasar un tiempo desde que un elemento expira hasta que el proceso de fondo lo elimina, si intenta leer elementos que han expirado, pero todavía no se han eliminado, el resultado mostrará los elementos expirados. Puede filtrar dichos elementos a partir del valor TTL si desea que no se muestren los elementos expirados.

P: ¿Qué pasa con los datos de mi índice secundario local (LSI) si expiran?

Las consecuencias son las mismas que con cualquier operación de eliminación. El índice secundario local se almacena en la misma partición que el mismo elemento. Por lo tanto, si se elimina un elemento, se retira inmediatamente del índice secundario local.

P: ¿Qué pasa con los datos de mi índice secundario global (GSI) si expiran?

Las consecuencias son las mismas que con cualquier operación de eliminación. El índice secundario global (GSI) se sincroniza con el tiempo de modo que, aunque el elemento expirado se eliminará, es posible que el GSI tarde un tiempo en actualizarse.

P: ¿Cómo funciona TTL con DynamoDB Streams?

La expiración de los datos de una tabla por motivo de que el valor TTL active una eliminación se registra como una operación de eliminación. Por lo tanto, Streams también registrarán la operación de eliminación. El registro de eliminación incorporará un calificador adicional para que pueda distinguir entre las eliminaciones convencionales y aquellas que tengan lugar por TTL. La entrada de Streams se escribirá en el momento de la eliminación, no de la expiración TTL, para reflejar el momento exacto en que se eliminó el registro. Consulte nuestra documentación y nuestra guía de la API.

P: ¿Cuándo debería usar la operación de eliminación en lugar de TTL?

TTL es ideal para eliminar registros expirados de una tabla. Sin embargo, esta operación sigue un principio de mejor esfuerzo para ayudarle a eliminar datos no deseados y no garantiza el tiempo que se tarda en efectuar la eliminación. Por lo tanto, si los datos de su tabla deben eliminarse dentro de un periodo de tiempo específico (con frecuencia, al instante), recomendamos que utilice el comando de eliminación.

P: ¿Puedo controlar quién puede configurar o actualizar el valor TTL?

Sí. El atributo TTL es como cualquier otro atributo de una tabla. Puede controlar el acceso a nivel de atributo en una tabla. El atributo TTL seguirá los controles de acceso periódico especificados para la tabla.

P: ¿Existe alguna manera de recuperar los datos eliminados tras una expiración TTL?

No. No se realizan backups de los elementos expirados antes de eliminarlos. Puede utilizar DynamoDB Streams para monitorizar los cambios realizados en una tabla y restaurar los valores en caso necesario. El registro de eliminación se encuentra disponible en Streams durante 24 horas a partir del momento en que se elimina.

P: ¿Cómo puedo saber si TTL está habilitado en una tabla?

Puede consultar el estado de TTL en cualquier momento invocando la API DescribeTable o comprobando los detalles de la tabla en la consola de DynamoDB. Consulte nuestra documentación y nuestra guía de la API.

P: ¿Cómo puedo monitorizar los elementos eliminados por TTL?

Si ha habilitado DynamoDB Streams, todas las eliminaciones de TTL se mostrarán en DynamoDB Streams y se señalarán como eliminaciones del sistema para diferenciarlas de las eliminaciones realizadas explícitamente por usted. Puede leer los elementos en Streams y procesarlos según sea necesario. También es posible escribir una función de Lambda para archivar el elemento por separado. Consulte nuestra documentación y nuestra guía de la API.

P: ¿Tengo que pagar una cuota específica para habilitar la característica TTL para mis datos?

No. La habilitación de TTL no conlleva cargos adicionales.

P: ¿Cómo afectará la habilitación de TTL al uso general de mi desempeño aprovisionado?

Las operaciones de búsqueda y eliminación necesarias para TTL son realizadas por el sistema y no cuentan para el desempeño o uso aprovisionado.

P: ¿Tengo que pagar por las operaciones de búsqueda para monitorizar TTL?

No. No se le cobra por las operaciones de búsqueda internas para monitorizar la expiración TTL de los elementos. Además, estas operaciones no afectan al uso del desempeño de la tabla.

P: ¿Acumulan costos de almacenamiento los elementos expirados hasta que se eliminan?

Sí. Una vez que un elemento expira, se agrega a la cola de eliminación. Sin embargo, hasta que se elimine, incurrirá en cargos de almacenamiento, al igual que cualquier elemento convencional que se puede leer o actualizar.

P: Si realizo una consulta en un elemento expirado, ¿se utiliza mi capacidad de lectura?

Sí. Este comportamiento es el mismo que cuando realiza una consulta en un elemento que no existe en la tabla


P: ¿Qué es DynamoDB Accelerator (DAX)?

Amazon DynamoDB Accelerator (DAX) es una caché en memoria totalmente administrada y altamente disponible para DynamoDB que le permite beneficiarse de un desempeño en memoria rápido para aplicaciones exigentes. DAX mejora el desempeño de cargas de trabajo de DynamoDB de lectura intensiva, de manera que las lecturas repetidas de los datos almacenados en caché puedan realizarse de manera inmediata con muy baja latencia y sin necesidad de realizar otra consulta en DynamoDB. DAX recupera los datos de las tablas de DynamoDB automáticamente si estos no se encuentran en la caché. Las escrituras son write-through (es decir, los datos se escriben primero en DynamoDB y, a continuación, se actualizan en la caché de DAX).

Al igual que DynamoDB, DAX es tolerante a fallos y escalable. Un clúster de DAX tiene un nodo principal y cero o más nodos de réplica de lectura. Si se produce un fallo en el nodo principal, DAX realiza automáticamente una conmutación por error y elige un nuevo nodo principal. Para el escalado, puede añadir o eliminar réplicas de lectura.

Para comenzar, cree un clúster de DAX, descargue el SDK de DAX para Java o Node.js (compatible con las API de DynamoDB), modifique su aplicación de modo que use el cliente DAX en lugar del cliente DynamoDB y, por último, dirija el cliente DAX al punto de conexión del clúster DAX. No es necesario implementar ninguna lógica de caché adicional en la aplicación, ya que el cliente DAX implementa las mismas llamadas a la API que DynamoDB.

P: ¿Qué significa "compatibilidad con DynamoDBL"?

Significa que la mayor parte del código, las aplicaciones y las herramientas que ya usa con DynamoDB también se puede utilizar con DAX con cambios mínimos o sin necesidad de realizar ninguna modificación. El motor DAX está diseñado para ser compatible con las API de DynamoDB para leer y modificar datos en DynamoDB. No se admiten las operaciones de administración de tablas, como CreateTable/DescribeTable/UpdateTable/DeleteTable.

P: ¿Qué es el almacenamiento en caché en memoria y cómo ayuda a mi aplicación?

El almacenamiento en caché mejora el desempeño de las aplicaciones almacenando los datos críticos en memoria para un acceso de baja latencia y alto desempeño. En el caso de DAX, los resultados de las operaciones de DynamoDB se almacenan en caché. Cuando una aplicación solicita datos almacenados en la caché, DAX puede proporcionar esos datos inmediatamente sin necesidad de realizar una consulta en las tablas de DynamoDB convencionales. Para madurar o eliminar los datos de DAX, puede especificar un valor de tiempo de vida (TTL) para los datos. Si no, una vez agotada toda la memoria disponible, los elementos se eliminarán de acuerdo con el algoritmo de menos utilizado recientemente (LRU).

P: ¿Cuál es el modelo de coherencia de DAX?

Al leer datos de DAX, los usuarios pueden especificar si desean que la lectura tenga consistencia alta o final:

Lecturas de coherencia eventual (opción predeterminada): esta opción maximiza el desempeño de la lectura y minimiza la latencia. En caso de acierto en la caché, el cliente DAX devolverá el resultado directamente desde la caché. En caso de fallo en la caché, DAX realizará una consulta en DynamoDB, actualizará la caché y devolverá el conjunto de resultados. Conviene mencionar que una lectura de coherencia eventual podría no reflejar los resultados de una escritura completada recientemente. Si su aplicación requiere total coherencia, le recomendamos que utilice lecturas de coherencia alta.

Lecturas de coherencia alta: además de la opción de coherencia eventual de las lecturas, DAX ofrece la flexibilidad y el control para solicitar una lectura de coherencia alta si así lo requiere su aplicación o algún elemento de la misma. Una lectura de coherencia alta es pass-through para DAX, no almacena los resultados en DAX y devuelve un resultado que refleja todas las escrituras que han recibido una respuesta con éxito en DynamoDB antes de la lectura.

P: ¿Cuáles son los casos de uso comunes para DAX?

DAX tiene varios casos de uso que no son mutuamente excluyentes:

Aplicaciones que requieren los tiempos de respuesta más rápidos para las lecturas. Entre los ejemplos se encuentran las pujas en tiempo real, los juegos sociales y las aplicaciones de comercio. DAX proporciona un desempeño de lectura en memoria rápido para estos casos de uso.

Aplicaciones que leen una pequeña cantidad de elementos con más frecuencia que otros. Por ejemplo, considere un sistema de comercio electrónico en el que se lanzan rebajas de un día en un producto particular. Durante las rebajas, la demanda de ese producto (y de sus datos en DynamoDB) incrementaría significativamente en comparación con los demás productos. Para mitigar el impacto de una clave "caliente" y una distribución de los datos no uniforme, podría descargar la actividad de lectura a una caché de DAX hasta que concluyan las rebajas de un día.

Aplicaciones sensibles a las lecturas, pero también a los costos. Con DynamoDB, usted aprovisiona la cantidad de lecturas por segundo que necesita su aplicación. Si la actividad de lectura aumenta, puede incrementar el desempeño de lectura aprovisionado para su tabla (a un costo adicional). De forma alternativa, puede descargar la actividad de su aplicación a un clúster de DAX y reducir la cantidad de unidades de capacidad de lectura necesarias para realizar la compra.

Aplicaciones que requieren lecturas repetidas en un conjunto de datos de gran tamaño. Una aplicación así podría, potencialmente, desviar los recursos de las bases de datos de otras aplicaciones. Por ejemplo, un análisis constante de los datos meteorológicos regionales podrían consumir temporalmente toda la capacidad de lectura de una tabla de DynamoDB, lo que afectaría negativamente a otras aplicaciones que necesiten acceder a los mismos datos. Con DAX, el análisis meteorológico podría realizarse con datos almacenados en caché en vez.

Cómo funciona

P: ¿Qué administra DAX por mí?

DAX es una caché totalmente administrada para DynamoDB. Administra el trabajo que conlleva la configuración de nodos de caché dedicados, desde aprovisionar los recursos del servidor a instalar el software de DAX. Una vez que el clúster de caché de DAX está configurado y en funcionamiento, el servicio automatiza tareas administrativas comunes tales como la detección de errores, la recuperación y la aplicación de parches de software. DAX ofrece métricas de monitorización de CloudWatch detalladas asociadas con el clúster, lo que permite diagnosticar y abordar los problemas muy rápidamente. Con estas métricas, puede configurar umbrales para el envío de alarmas de CloudWatch. DAX se ocupa del almacenamiento en caché, la recuperación y la eliminación de los datos, para que no tenga que hacerlo la aplicación. Simplemente puede utilizar la API de DynamoDB para escribir y recuperar datos, y DAX se ocupa de la lógica de caché en segundo plano para ofrecer un mejor desempeño.

P: ¿Qué tipo de datos almacena en caché DAX?

DAX almacena en caché todas las llamadas a la API de lectura, y las solicitudes de alta coherencia se leen directamente en DynamoDB, mientras que las lecturas de coherencia eventual se leen en DAX si el elemento está disponible. Las llamadas a la API de lectura son write-through (escritura síncrona en DynamoDB que se actualiza en la caché si la escritura se realiza con éxito).

Las siguientes llamadas a la API harán que se examine la caché. Si se produce un acierto, se devolverá el elemento. En caso de fallo, la solicitud pasará y, cuando se produzca una recuperación con éxito, el elemento se almacenará en la caché y se devolverá.

• GetItem
• BatchGetItem
• Query
• Scan

Las siguientes llamadas a la API son operaciones write-through.

• BatchWriteItem
• UpdateItem
• DeleteItem
• PutItem

P: ¿Cómo efectúa DAX la eliminación de datos?

DAX efectúa la eliminación de la caché de tres maneras distintas. En primer lugar, usa un valor de tiempo de vida (TTL) que determina el periodo de tiempo que un elemento está disponible en la caché. En segundo lugar, cuando la caché está llena, un clúster de DAX usa un algoritmo de menos usado recientemente (LRU) para decidir qué elementos eliminar. Y en tercer lugar, con la funcionalidad write-through, DAX elimina los valores antiguos a medida que se escriben nuevos valores mediante DAX. Esto ayuda a mantener la caché de elementos de DAX coherente con el almacenamiento de datos subyacente con una sola llamada a la API.

P: ¿Trabaja DAX con las GSI y LIS de DynamoDB?

Al igual que con las tablas de DynamoDB, DAX almacenará en caché los conjuntos de resultados de las operaciones de consulta y escaneo de las GSI y LSI de DynamoDB.

P: ¿Cómo administra DAX los conjuntos de resultados de consultas y escaneos?

En un clúster de DAX, hay dos cachés distintas: 1) la caché de elementos y 2) la caché de consultas. La caché de elementos administra las solicitudes GetItem, PutItem, and DeleteItem para pares de valores de clave individuales. La caché de consultas almacena los conjuntos de resultados de las solicitudes de escaneos y consultas. En este sentido, el texto del escaneo o la consulta es la "clave" y el conjunto de resultados es el "valor". Tanto la caché de elementos como la caché de consultas se administran en el mismo clúster (y puede especificar valores TTL distintos para cada una), pero no se solapan. Por ejemplo, un escaneo de una tabla no rellena la caché de elementos; en vez, registra una entrada en la caché de consultas que almacena el conjunto de resultados del escaneo.

P: ¿Acaso una actualización en la caché de elementos actualiza o invalida los conjuntos de resultados de la caché de consultas?

No. La mejor manera de mitigar incoherencias entre los conjuntos de resultados en la caché de elementos y la caché de consultas es configurar la TTL para la caché de consultas de manera que sea un periodo de tiempo aceptable para que la aplicación pueda ocuparse de dichas incoherencias.

P: ¿Puedo conectarme a mi clúster de DAX desde fuera de mi VPC?

La única manera de conectarse el clúster de DAX desde fuera de la VPC es mediante una conexión VPN.

P: Al usar DAX, ¿qué pasa si se limitan mis tablas de DynamoDB subyacentes?

Si DAX está leyendo o escribiendo en una tabla de DynamoDB y recibe una excepción de limitación, DAX devolverá la excepción al cliente DAX. Además, el servicio DAX no realiza más intentos del lado del servidor.

P: ¿Admite DAX el precalentamiento de la caché?

DAX utiliza la carga diferida para rellenar la caché. Esto significa que, en la primera lectura de un elemento, DAX recupera el elemento de DynamoDB y, a continuación, rellena la caché. Mientras que DAX no admite el precalentamiento de la caché como característica, la caché de DAX puede precalentarse para una aplicación ejecutando un script o una aplicación externos que lea los datos necesarios.

P: ¿Cómo trabaja DAX con la característica TTL de DynamoDB?

Tanto DynamoDB como DAX tienen la característica "TTL" (tiempo de vida). En DynamoDB, TTL es una característica que permite a los clientes eliminar sus datos cuando maduren etiquetándolos con un atributo particular y el sello temporal correspondiente. Por ejemplo, si los clientes desean que los datos se eliminen cuando tengan un mes, pueden usar la característica TTL de DynamoDB para ello en lugar de tener que administrar el flujo de datos de maduración.

En DAX, TTL especifica el tiempo durante el cual es válido un elemento almacenado en la caché. Por ejemplo, si el TTL es 5 minutos, una vez que un elemento se ha escrito en la caché, este seguirá siendo válido y recuperado de la caché hasta que venza el periodo de 5 minutos. Aunque no está totalmente relacionado con este tema, TTL puede reemplazarse por escrituras en la caché del mismo elemento o si hay presión de memoria en el nodo DAX y LRU elimina el elemento ya que es el menos usado recientemente.

Mientras que la característica TTL de DynamoDB y DAX suele operar en escalas temporales distintas (es decir, TTL de DAX opera en minutos/horas y TTL de DynamoDB opera en semanas/meses/años), es posible que los clientes necesiten saber cómo estas dos características se afectan entre sí. Por ejemplo, imaginemos que el valor TTL de DynamoDB es inferior al valor TTL de DAX. En esta situación, un elemento podría almacenarse en caché en DAX y eliminarse a continuación de DynamoDB mediante la característica TTL de DynamoDB. El resultado sería una incoherencia en la caché. Aunque no es de esperar que esta situación ocurra a menudo, ya que las escalas temporales de las dos características son muy distintas, conviene saber cómo se relacionan entre sí.

P: ¿Admite DAX la replicación entre regiones?

En la actualidad, DAX solo admite tablas de DynamoDB en la misma región de AWS que el clúster de DAX.

P: ¿Se admite DAX como tipo de recurso en AWS CloudFormation?

Sí. Puede crear, actualizar y eliminar clústeres, grupos de parámetros y grupos de subred de DAX con AWS CloudFormation.

Introducción

P: ¿Cómo puedo comenzar a utilizar DAX?
Puede crear un clúster de DAX nuevo mediante la consola de AWS o el SDK de AWS para obtener el extremo del clúster de DAX. Deberá descargarse y usarse en la aplicación un cliente compatible con DAX con el nuevo extremo de DAX.

P: ¿Cómo puedo crear un clúster de DAX?

Puede crear un clúster de DAX con la consola de AWS o la CLI de DAX. Los clústeres de DAX tienen una gama de memoria caché desde 13 GiB (dax.r3.large) a 216 GiB (dax.r3.8xlarge) en los tipos de instancias R3 y desde 15,25 GiB (dax.r4.large) a 488 GiB (dax.r4.16xlarge) en los tipos de instancias R4. Con unos cuantos clics en la consola de AWS o una sola llamada a la API, puede añadir más réplicas a su clúster (hasta 10 réplicas) para un mayor desempeño.

La configuración de un solo nodo le permite comenzar a utilizar DAX con rapidez y rentabilidad, además de escalar a una configuración de varios nodos a medida que aumenten sus necesidades. La configuración de varios nodos consiste en un nodo principal que administra las lecturas, y hasta nueve nodos de réplica de lectura. El nodo principal se aprovisiona automáticamente.

Simplemente especifique sus grupos de subred o zonas de disponibilidad (opcional) preferidos, el número de nodos, los tipos de nodos, el grupo de subred VPC y otros ajustes del sistema. Una vez elegida su configuración deseada, DAX aprovisionará los recursos necesarios y configurará el clúster de caché específicamente para DynamoDB.

P: ¿Tienen que caber todos mis datos en la memoria para poder usar DAX?

No. DAX utilizará la memoria disponible en el nodo. Si usa TTL y/o LRU, los elementos se eliminarán para crear espacio para los datos nuevos cuando se agote el espacio en la memoria.

P: ¿Qué lenguajes admite DAX?

DAX ofrece SDK de DAX para Java y Node.js que puede descargar hoy mismo. Estamos trabajando en la compatibilidad con clientes adicionales.

P: ¿Puedo utilizar DAX y DynamoDB al mismo tiempo?

Sí, puede acceder al extremo de DAX y DynamoDB al mismo tiempo a través de clientes distintos. Sin embargo, DAX no podrá detectar cambios en los datos escritos directamente en DynamoDB a menos que estos cambios se rellenen explícitamente en DAX mediante una operación de lectura una vez realizada la actualización directamente en DynamoDB.

P: ¿Puedo utilizar varios clústeres de DAX para la misma tabla de DynamoDB?

Sí, puede aprovisionar varios clústeres de DAX para la misma tabla de DynamoDB. Estos clústeres proporcionarán distintos extremos que se pueden usar para casos de uso diferentes, garantizando el almacenamiento en caché óptimo para cada situación. Dos clústeres de DAX serán independientes entre sí y no compartirán estados ni actualizaciones, por lo que los usuarios deberían usar estos para tablas completamente distintas.

P: ¿Cómo puedo saber qué tipo de nodo DAX necesito para mi carga de trabajo?

Determinar el tamaño de un clúster DAX es un proceso iterativo. Se recomienda aprovisionar un clúster de tres nodos (para lograr una alta disponibilidad) con suficiente memoria como para abastecer el conjunto de trabajo de la aplicación en la memoria. En función del desempeño y rendimiento de la aplicación, el uso del clúster de DAX y la proporción de aciertos/fallos en la caché, es posible que tenga que escalar el clúster de DAX para lograr los resultados deseados.

P: ¿En qué tipos de instancias de EC2 se puede ejecutar DAX?

Los tipos de nodos válidos son los siguientes:

R3:  

• dax.r3.large (13 GiB)
• dax.r3.xlarge (26 GiB)
• dax.r3.2xlarge (54 GiB)
• dax.r3.4xlarge (108 GiB)
• dax.r3.8xlarge (216 GiB)

R4:

• dax.r4.large (15,25 GiB)
• dax.r4.xlarge (30,5 GiB)
• dax.r4.2xlarge (61 GiB)
• dax.r4.4xlarge (122 GiB)
• dax.r4.8xlarge (244 GiB)
• dax.r4.16xlarge (488 GiB)

P: ¿Admite DAX las instancias reservadas o la capa de uso gratuito de AWS?

En la actualidad, DAX solo admite las instancias bajo demanda.

P: ¿Cuáles son los precios de DAX?

El precio de DAX es por hora de nodo consumida, desde el momento en que el nodo se inicia hasta que se termina. Cada porción de hora de nodo consumida se facturará como una hora completa. Los precios se aplican a todos los nodos individuales del clúster de DAX. Por ejemplo, si tiene un clúster de DAX de tres nodos, se le cobrará por cada uno de ellos (tres nodos en total) de acuerdo con la tarifa por hora.

Disponibilidad

P: ¿Cómo puedo conseguir alta disponibilidad con mi clúster de DAX?

DAX proporciona compatibilidad con varias zonas de disponibilidad integrada, lo que le permite elegir las zonas de disponibilidad que prefiera para los nodos de su clúster de DAX. DAX utiliza la replicación asíncrona para proporcionar coherencia entre los nodos, de manera que, en caso de fallo, haya nodos adicionales que puedan abastecer las solicitudes del servicio. Para lograr una alta disponibilidad para su clúster de DAX, en caso de interrupciones planificadas y no planificadas, recomendamos que implemente al menos tres nodos en tres zonas de disponibilidad distintas. Cada zona de disponibilidad (AZ) se ejecuta en su propia infraestructura, independiente y físicamente distinta, y está diseñada para ofrecer elevados niveles de confianza.

P: ¿Qué pasa si falla un nodo de DAX?

Si se produce un error en el nodo principal, DAX lo detectará de manera automática, seleccionará una réplica de lectura disponible y la elevará para convertirla en la nueva principal. Además, DAX aprovisionará un nodo nuevo en la misma zona de disponibilidad que el nodo principal en el que se ha producido el error. Este nuevo nodo sustituirá a la réplica de lectura recién ascendida. Si el error del nodo principal se debe a una interrupción temporal en la zona de disponibilidad, la nueva réplica se lanzará en cuanto la zona de disponibilidad se haya recuperado. Si se produce un error en un clúster de un solo nodo, DAX lanzará un nuevo nodo en la misma zona de disponibilidad.

Escalabilidad

P: ¿Qué tipo de escalado admite DAX?

En la actualidad, DAX admite dos opciones de escalado. La primera opción es el escalado de lectura para incrementar el desempeño al añadir réplicas de lectura a un clúster. Un solo clúster de DAX admite hasta 10 nodos, lo que ofrece millones de solicitudes por segundo. Añadir o eliminar réplicas adicionales es una operación efectuada online. La segunda manera de escalar un clúster es incrementar o reducir la capacidad seleccionando tipos de instancias r2 más grandes o pequeños. Los nodos de mayor tamaño permiten al clúster almacenar una mayor cantidad del conjunto de datos de la aplicación en la memoria, lo que reduce las faltas de lecturas en la caché y mejora el desempeño general de la aplicación. Al crear un clúster de DAX, todos los nodos del clúster deben ser del mismo tipo de instancia. Además, si desea cambiar el tipo de instancia por su clúster de DAX (es decir, escalar de r3.large a r3.2xlarge), debe crear un nuevo clúster de DAX con el tipo de instancia deseado. En la actualidad, DAX no admite las operaciones de incremento o reducción de la capacidad efectuadas online.

P: ¿Cómo puedo escalar mi aplicación para la escritura?

En un clúster de DAX, solamente el nodo principal abastece las operaciones de escritura en DynamoDB. Por lo tanto, si añade más nodos al clúster de DAX, se incrementará el desempeño de lectura, pero no el de escritura. Para incrementar el desempeño de escritura para su aplicación, deberá escalar a un tipo de instancia de mayor tamaño o aprovisionar varios clústeres de DAX y crear particiones del espacio de claves en la capa de la aplicación.

Monitorización

P: ¿Cómo puedo monitorizar el desempeño de mi clúster de DAX?
Existen métricas del uso de CPU, los aciertos/fallos en la caché y el tráfico de lectura/escritura en el clúster de DAX disponibles mediante la consola de administración de AWS o las API de Amazon CloudWatch. También puede añadir métricas adicionales definidas por el usuario a través de la funcionalidad de métricas personalizadas de Amazon CloudWatch. Además de las métricas de CloudWatch, DAX también ofrece información sobre el desempeño de los aciertos/fallos en la caché, las consultas y el clúster a través de la consola de administración de AWS.

Mantenimiento

P: ¿Qué es una ventana de mantenimiento? ¿Estará disponible el clúster de DAX durante el mantenimiento del software?

Puede considerar una ventana de mantenimiento de DAX una oportunidad de controlar cuándo se producirán las modificaciones en el clúster, como los parches de software. Si hay un evento de "mantenimiento" programado para una determinada semana, se iniciará y completará en un punto determinado dentro de la ventana de mantenimiento que usted identifique.

Los parches requeridos que tienen que ver con seguridad o fiabilidad son los únicos que se programan automáticamente. La aplicación de parches se produce con poca frecuencia (por lo general, una vez cada ciertos meses). Si no especifica una ventana de mantenimiento semanal preferida al crear el clúster, se asignará un valor predeterminado. Si desea modificar el momento en que se realiza el mantenimiento, puede hacerlo mediante la modificación del clúster en la consola de administración de AWS o con la API UpdateCluster. Cada clúster puede tener diferentes ventanas de mantenimiento preferidas.

Para los clústeres de varios nodos, las actualizaciones se realizan en serie, es decir, se actualiza solo un nodo a la vez. Una vez actualizado el nodo, se sincronizará con uno de los puntos del clúster, de manera que el nodo tenga el conjunto actual de datos en funcionamiento. Para los clústeres de un solo nodo, aprovisionamos una réplica (sin costo adicional), sincronizamos la réplica con los datos más recientes y, a continuación, realizamos una conmutación por error para que la nueva réplica se convierta en el nodo principal. De este modo, no se pierde ningún dato durante la actualización del clúster de un nodo.  

P: ¿Qué son los puntos de enlace de la VPC para DynamoDB (VPCE para DynamoDB)?

Amazon Virtual Private Cloud (VPC) es un servicio de AWS que proporciona a los usuarios una nube privada virtual al aprovisionar una sección lógicamente aislada de la nube de Amazon Web Services (AWS). El punto de enlace de la VPC (VPCE) para DynamoDB es una entidad lógica dentro de una VPC que crea una conexión privada entre una VPC y DynamoDB sin necesidad de acceso a través de Internet, de un dispositivo NAT o de una conexión VPN. Para obtener más información sobre los puntos de enlace de la VPC, consulte la Guía del usuario sobre Amazon VPC.

P: ¿Por qué debería utilizar VPCE para DynamoDB?

Anteriormente, la manera principal de acceder a DynamoDB desde una VPC era a través de Internet, lo que podía requerir configuraciones complejas, como firewalls y VPN. Los puntos de enlace de la VPC para DynamoDB mejoran la privacidad y la seguridad para los clientes, sobre todo aquellos que administran cargas de trabajo confidenciales con requisitos de conformidad y auditoría, al habilitar el acceso privado a DynamoDB desde una VPC sin necesidad de un Internet Gateway o NAT Gateway. Además, los puntos de enlace de la VPC para DynamoDB son compatibles con las políticas de AWS Identity and Access Management (IAM) para simplificar el control del acceso a DynamoDB, por lo que puede restringir fácilmente el acceso a sus tablas de DynamoDB a un punto de enlace de la VPC específico.

P: ¿Cómo puedo comenzar a usar VPCE para DynamoDB?

Puede crear VPCE para DynamoDB usando la consola de administración de AWS, los SDK de AWS o la interfaz de línea de comandos de AWS (CLI). Debe especificar la VPC y las tablas de ruta existentes en la VPC, y describir la política que ha de asignarse al punto de enlace. Se agrega automáticamente una ruta a cada una de las tablas de ruta de la VPC especificada.

P: ¿Se asegura VPCE para DynamoDB de que el tráfico no se enrute fuera de la red de Amazon?

Sí, cuando utiliza VPCE para DynamoDB, los paquetes de datos entre DynamoDB y VPC permanecerán en la red de Amazon.

P: ¿Puedo conectar con una tabla de DynamoDB en una región distinta a mi VPC mediante VPCE para DynamoDB?

No, los puntos de enlace de la VPC solo se pueden crear para tablas de DynamoDB ubicadas en la misma región que la VPC.

P: ¿Limita VPCE para DynamoDB el desempeño en DynamoDB?

No, seguirá obteniendo el mismo desempeño en DynamoDB que obtiene hoy en día desde una instancia con una IP pública dentro de su VPC.

P: ¿Cuál es el precio del uso de VPCE para DynamoDB?

El uso de VPCE para DynamoDB no conlleva ningún costo adicional.

P: ¿Puedo acceder a DynamoDB Streams con VPCE para DynamoDB?

En la actualidad, no es posible acceder a DynamoDB Streams con VPCE para DynamoDB.

P: Actualmente uso un Internet Gateway y un NAT Gateway para enviar solicitudes a DynamoDB. ¿Tengo que cambiar el código de mi aplicación cuando uso un VPCE?

No es necesario cambiar el código de la aplicación. Simplemente cree un punto de enlace de la VPC, actualice su tabla de ruta para apuntar el tráfico de DynamoDB al VPCE de DynamoDB y acceda a DynamoDB directamente. Puede seguir usando el mismo código y los mismos nombres de DNS para acceder a DynamoDB.

P: ¿Puedo usar un solo VPCE para DynamoDB y otro servicio de AWS?

No, cada VPCE solo admite un servicio. Pero puede crear uno para DynamoDB y otro para el otro servicio de AWS y usar ambos en una tabla de ruta. 

P: ¿Puedo tener varios puntos de enlace de la VPC en una sola VPC?

Sí, puede disponer de varios puntos de enlace de la VPC en una sola VPC. Por ejemplo, puede tener un solo VPCE para S3 y otro VPCE para DynamoDB.

P: ¿Puedo tener varios VPCE para DynamoDB en una sola VPC?

Sí, puede disponer de varios VPCE para DynamoDB en una sola VPC. Los VPCE individuales pueden tener distintas políticas de VPCE. Por ejemplo, puede tener un VPCE de solo lectura y otro de lectura y escritura. Sin embargo, una única tabla de ruta de una VPC solo se puede asociar con un único VPCE para DynamoDB, ya que esa tabla de ruta enrutará todo el tráfico a DynamoDB a través del VPCE especificado.

P: ¿Cuáles son las diferencias entre VPCE para S3 y VPCE para DynamoDB?

La diferencia principal es que estos dos VPCE son compatibles con distintos servicios: S3 y DynamoDB.

P: ¿Qué dirección IP aparecerá en los logs de AWS CloudTrail para el tráfico procedente del VPCE para DynamoDB?

Los logs de AWS CloudTrail para DynamoDB contendrán la dirección IP privada de la instancia de EC2 en la VPC, y el identificador del VPCE (p. ej., sourceIpAddress=10.89.76.54, VpcEndpointId=vpce-12345678).

P: ¿Cómo puedo administrar VPCE a través de la interfaz de línea de comandos (CLI)?

Puede usar los siguientes comandos de la CLI para administrar VPCE: create-vpc-endpoint, modify-vpc-endpoint, describe-vpc-endpoints, delete-vpc-endpoint y descrive-vpc-endpoint-services. Debería identificar el nombre del servicio de DynamoDB específico a su VPC y región de DynamoDB, p. ej., ‘com.amazon.us.east-1.DynamoDB’. Puede encontrar más información sobre este tema aquí.

P: ¿Requiere VPCE para DynamoDB que los clientes conozcan y administren las direcciones P públicas de DynamoDB?

No, los clientes no necesitan conocer ni administrar los rangos de direcciones IP públicas de DynamoDB para usar esta característica. Se proporcionará una lista de prefijos para su uso en tablas de rutas y grupos de seguridad. AWS mantiene los rangos de direcciones en la lista. El nombre de la lista de prefijos es: com.amazonaws. .DynamoDB. Por ejemplo: com.amazonaws.us-east-1.DynamoDB.

P: ¿Puedo usar políticas de IAM en un VPCE para DynamoDB?

Sí. Puede adjuntar una política de IAM a su VPCE y esta se aplicará a todo el tráfico que pase por este punto de enlace. Por ejemplo, un VPCE que use esta política solo permite las llamadas a la API describe*:
{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:describe*",
            "Effect":"Allow",
            "Resource": "arn:aws:dynamodb:region:account-id:table/table-name",
            "Principal": "*"
        }
    ]
}

P: ¿Puedo limitar el acceso a mi tabla de DynamoDB table desde un punto de enlace de la VPC?

Sí, puede crear una política de IAM para restringir un usuario, grupo o función de IAM a tablas de VPCE para DynamoDB particulares.

Para ello, configure el elemento Resource de la política de IAM a una tabla de DynamoDB y la clave del elemento Condition a aws:sourceVpce. Puede encontrar más detalles en la Guía del usuario de IAM.

Por ejemplo, la siguiente política de IAM restringe el acceso a las tablas de DynamoDB a menos que sourceVpce se corresponda con “vpce-111bbb22”.

{
    "Statement":  [
       {
            "Sid": "Stmt1415116195105",
            "Action": "dynamodb:*",
            "Effect":"Deny",
            "Resource": "arn:aws:dynamodb:region:account-id:*",
            "Condition": { "StringNotEquals" : { "aws:sourceVpce": "vpce-111bbb22" } }
        }
    ]
}

P: ¿Es compatible VPCE para DynamoDB con las condiciones de políticas de IAM de un control del acceso minucioso (FGAC)?

Sí. VPCE para DynamoDB es compatible con todas las claves de acceso FGAC. Puede usar condiciones de políticas de IAM para FGAC para controlar el acceso a elementos y atributos de datos individuales. Puede encontrar más información sobre FGAC aquí.

P: ¿Puedo usar el generador de políticas de AWS para crear políticas de punto de enlace de la VPC o DynamoDB?

Puede usar el generador de políticas de AWS para crear sus políticas de punto de enlace de la VPC.

P: ¿Es compatible DynamoDB con políticas basadas en recursos similares a las políticas de buckets S3?

No, DynamoDB no es compatible con políticas basadas en recursos que afectan a tablas o elementos individuales, etc.