Amazon DynamoDB

Una tabla de DynamoDB es una agrupación lógica de elementos que representan los datos almacenados en ella. Dada la naturaleza NoSQL de DynamoDB, las tablas no requieren que todos sus elementos se ajusten a un esquema predefinido. ^{[ 7 ]}

En DynamoDB, un elemento es un conjunto de atributos que se pueden identificar de forma única en una tabla. Un atributo es una entidad de datos atómica que, a su vez, es un par clave-valor. La clave siempre es de tipo cadena, mientras que el valor puede ser de varios tipos de datos.

Un elemento se identifica de forma única en una tabla mediante un subconjunto de sus atributos denominados claves. ^{[ 7 ]}

DynamoDB admite tipos de datos numéricos, de cadena, booleanos, de documento y de conjunto. ^{[ 8 ]}

La clave primaria de una tabla es el índice predeterminado o primario de una tabla de DynamoDB.

Además, una tabla de DynamoDB puede tener índices secundarios. Un índice secundario se define en un atributo diferente de la clave de partición o la clave de ordenación que utiliza el índice principal.

Cuando un índice secundario tiene la misma clave de partición que el índice primario, pero una clave de ordenación diferente, se le denomina índice secundario local.

Cuando el índice primario y el índice secundario tienen claves de partición diferentes, el índice secundario se conoce como índice secundario global. ^{[ 7 ]}

DynamoDB utiliza funciones hash y árboles B para gestionar los datos. Al ingresar, los datos se distribuyen primero en diferentes particiones mediante el cálculo de la función hash en la clave de partición. Cada partición puede almacenar hasta 10 GB de datos y manejar de forma predeterminada 1000 unidades de capacidad de escritura (WCU) y 3000 unidades de capacidad de lectura (RCU). ^{[ 20 ]} Una RCU representa una lectura fuertemente consistente por segundo o dos lecturas eventualmente consistentes por segundo para elementos de hasta 4 KB de tamaño. ^{[ 21 ]} Una WCU representa una escritura por segundo para un elemento de hasta 1 KB de tamaño.

Para evitar la pérdida de datos, DynamoDB cuenta con un sistema de copia de seguridad de dos niveles que combina replicación y almacenamiento a largo plazo. ^{[ 22 ]} Cada partición consta de tres nodos, cada uno de los cuales contiene una copia de los datos de dicha partición. Cada nodo también contiene dos estructuras de datos: un árbol B utilizado para localizar elementos y un registro de replicación que registra todos los cambios realizados en el nodo. DynamoDB toma instantáneas periódicas de estas dos estructuras de datos y las almacena durante un mes en S3 para que los ingenieros puedan realizar restauraciones puntuales de sus bases de datos.

Dentro de cada partición, uno de los tres nodos se designa como el "nodo líder". Todas las operaciones de escritura pasan primero por el nodo líder antes de propagarse, lo que garantiza la consistencia de las escrituras en DynamoDB. Para mantener su estado, el líder envía una señal de actividad a cada uno de los demás nodos cada 1,5 segundos. Si un nodo deja de recibir señales de actividad, puede iniciar una nueva elección de líder. DynamoDB utiliza el algoritmo Paxos para la elección de líderes.

Los ingenieros de Amazon inicialmente evitaron DynamoDB debido a los costos generales de ingeniería, como el aprovisionamiento y la administración de particiones y nodos. ^{[ 6 ]} En respuesta, el equipo de DynamoDB creó un servicio llamado AutoAdmin para administrar una base de datos. ^{[ 22 ]} AutoAdmin reemplaza un nodo cuando deja de responder copiando datos de otro nodo. Cuando una partición supera cualquiera de sus tres umbrales (RCU, WCU o 10 GB), AutoAdmin agrega automáticamente particiones adicionales para segmentar aún más los datos. ^{[ 20 ]}

Al igual que los sistemas de indexación en el modelo relacional, DynamoDB exige que cualquier actualización de una tabla se refleje en cada uno de sus índices. DynamoDB gestiona esto mediante un servicio denominado "propagador de registros", que se suscribe a los registros de replicación en cada nodo y envía solicitudes adicionales de inserción, actualización y eliminación a los índices según sea necesario. ^{[ 22 ]} Dado que los índices generan una disminución considerable del rendimiento en las solicitudes de escritura, DynamoDB permite a un usuario un máximo de cinco índices en cualquier tabla. ^{[ 23 ]}

Supongamos que un usuario de DynamoDB realiza una operación de escritura (Put, Update o Delete). Mientras que un sistema relacional típico convertiría la consulta SQL a álgebra relacional y ejecutaría algoritmos de optimización, DynamoDB omite ambos procesos. ^{[ 22 ]} La solicitud llega al enrutador de solicitudes de DynamoDB, que la autentica —«¿La solicitud proviene de dónde/quién dice ser?»— y verifica la autorización —«¿El usuario que envía la solicitud tiene los permisos necesarios?» Si estas verificaciones son exitosas, el sistema aplica un hash a la clave de partición de la solicitud para que llegue a la partición correspondiente. Dentro de la partición hay tres nodos, cada uno con una copia de los datos de la partición. El sistema primero escribe en el nodo líder, luego en un segundo nodo, después envía un mensaje de «éxito» y finalmente continúa la propagación al tercer nodo. Las escrituras son consistentes porque siempre viajan primero a través del nodo líder.

Finalmente, el propagador de registros propaga el cambio a todos los índices. Para cada índice, obtiene el valor de la clave primaria del elemento y luego realiza la misma escritura en ese índice sin propagación de registros. Si la operación es una actualización de un elemento preexistente, el atributo actualizado puede servir como clave primaria para un índice, por lo que el árbol B de ese índice también debe actualizarse. Los árboles B solo manejan operaciones de inserción, eliminación y lectura, por lo que, en la práctica, cuando el propagador de registros recibe una operación de actualización, emite una operación de eliminación y una operación de inserción a todos los índices.

Supongamos ahora que un usuario de DynamoDB realiza una operación Get. El enrutador de solicitudes procede como antes con la autenticación y la autorización. A continuación, como se indicó anteriormente, aplicamos un hash a nuestra clave de partición para obtener el hash correspondiente. Ahora bien, surge un problema: con tres nodos en consistencia eventual entre sí, ¿cómo podemos decidir cuál investigar? DynamoDB ofrece al usuario dos opciones al realizar una lectura: consistente y eventualmente consistente. Una lectura consistente visita el nodo líder. Sin embargo, la disyuntiva entre consistencia y disponibilidad vuelve a manifestarse aquí: en sistemas con muchas lecturas, leer siempre del líder puede sobrecargar un solo nodo y reducir la disponibilidad.

La segunda opción, una lectura con consistencia eventual , selecciona un nodo aleatorio. En la práctica, aquí es donde DynamoDB sacrifica la consistencia por la disponibilidad. Si elegimos esta opción, ¿cuál es la probabilidad de una inconsistencia? Necesitaríamos que una operación de escritura devolviera "éxito" y comenzara a propagarse al tercer nodo, pero sin finalizar. También necesitaríamos que nuestra operación Get se dirigiera a este tercer nodo. Esto significa una probabilidad de 1 entre 3 de inconsistencia dentro de la ventana de propagación de la operación de escritura. ¿Cuánto dura esta ventana? Diversas catástrofes podrían provocar que un nodo se retrase, pero en la gran mayoría de los casos, el tercer nodo se actualiza en cuestión de milisegundos con respecto al líder.