Amazon SimpleDB es una base de datos distribuida escrita en Erlang [1] por Amazon.com . Se utiliza como servicio web en conjunto con Amazon Elastic Compute Cloud (EC2) y Amazon S3 y es parte de Amazon Web Services . Se anunció el 13 de diciembre de 2007. [2]
Al igual que con EC2 y S3, Amazon cobra tarifas por el almacenamiento, la transferencia y el rendimiento de SimpleDB a través de Internet. El 1 de diciembre de 2008, Amazon introdujo un nuevo precio con el nivel gratuito [3] por 1 GB de datos y 25 horas de máquina. La transferencia a otros servicios web de Amazon es gratuita. [2]
SimpleDB proporciona consistencia eventual , que es una forma más débil de consistencia, en comparación con otros sistemas de administración de bases de datos . Esto a menudo se considera una limitación, porque es más difícil razonar al respecto, lo que dificulta la escritura de programas correctos que utilicen SimpleDB. Esta limitación es el resultado de una disyuntiva fundamental de diseño. Al renunciar a la consistencia, el sistema puede lograr otras dos propiedades muy deseables:
Se supone que las fallas de los componentes son inevitables; por lo tanto, ambas propiedades se consideraron necesarias para brindar un servicio web confiable . El teorema CAP establece que no es posible que un sistema presente estas propiedades junto con la consistencia; por lo tanto, los diseñadores debieron conformarse con una forma más débil de consistencia.
Limitaciones publicadas: [4]
Las operaciones de colocación y eliminación condicionales son nuevas operaciones que se agregaron en febrero de 2010. Abordan un problema que surge al acceder a SimpleDB simultáneamente. Considere un programa simple que utiliza SimpleDB para almacenar un contador, es decir, un número que se puede incrementar. El programa debe hacer tres cosas:
Si este programa se ejecuta mientras ningún otro programa accede a SimpleDB, funcionará correctamente; sin embargo, a menudo es deseable que las aplicaciones de software (en particular, las aplicaciones web ) accedan a los mismos datos simultáneamente. Cuando se accede a los mismos datos simultáneamente, surge una condición de carrera , que daría como resultado una pérdida de datos indetectable.
Continuando con el ejemplo anterior, considere dos procesos, A y B, que ejecutan el mismo programa. Suponga que los servicios SimpleDB solicitan datos, como se describe en el paso 1, tanto de A como de B. A y B ven el mismo valor. Supongamos que el valor actual del contador es 0. Debido a los pasos 2 y 3, A intentará almacenar 1. B intentará hacer lo mismo; por lo tanto, el valor final del contador será 1, aunque el valor final del contador esperado sea 2, porque el sistema intentó dos operaciones de incremento, una por parte de A y otra por parte de B.
Este problema se puede resolver mediante el uso de put condicional. Supongamos que cambiamos el paso 3 de la siguiente manera: en lugar de almacenar incondicionalmente el nuevo valor, el programa le pide a SimpleDB que almacene el nuevo valor solo si el valor que tiene actualmente es el mismo que el valor que se recuperó en el paso 1. Entonces, podemos estar seguros de que el valor del contador realmente aumenta. Esto introduce cierta complejidad adicional; si SimpleDB no pudo almacenar el nuevo valor porque el valor actual no era el esperado, el programa debe repetir los pasos 1 a 3 hasta que la operación put condicional realmente cambie el valor almacenado.
La lectura consistente fue una nueva característica que se lanzó al mismo tiempo que la opción de poner y eliminar condicionalmente. Como sugiere el nombre, la lectura consistente soluciona los problemas que surgen debido al modelo de consistencia eventual de SimpleDB (consulte la sección Limitaciones). Considere la siguiente secuencia de operaciones:
La garantía de consistencia eventual de SimpleDB no nos permite decir que los datos recuperados en el paso 2 reflejan las actualizaciones que se realizaron en el paso 1. La consistencia eventual solo garantiza que el paso 2 refleje el conjunto completo de actualizaciones del paso 1, o ninguna de esas actualizaciones. La lectura consistente se puede utilizar para garantizar que los datos recuperados en el paso 2 reflejen los cambios realizados en el paso 1.
La razón por la que pueden surgir resultados inconsistentes cuando no se utiliza la operación de lectura consistente es que SimpleDB almacena datos en múltiples ubicaciones (para disponibilidad) y los nuevos datos en el paso 1 podrían no escribirse en todas las ubicaciones cuando SimpleDB recibe la solicitud de datos en el paso 2. En ese caso, es posible que la solicitud de datos en el paso 2 se atienda en una de las ubicaciones donde no se han escrito los nuevos datos.
Amazon desaconseja el uso de lecturas consistentes, a menos que sean necesarias para la corrección. El motivo de esta recomendación es que la velocidad a la que se realizan las operaciones de lectura consistente es menor que la de las lecturas normales.
Se ha hablado de que SimpleDB podría ser reemplazado por DynamoDB (ya no se está "iterando" [6] , aunque Amazon no tiene planes de eliminarlo). DynamoDB parece ser su sucesor. [7] [8]