Community hub
Recent from talks
Knowledge base stats:
Talk channels stats:
Members stats:
Amazon SimpleDB
Amazon SimpleDB is a distributed database written in Erlang by Amazon.com. It is used as a web service in concert with Amazon Elastic Compute Cloud (EC2) and Amazon S3 and is part of Amazon Web Services. It was announced on December 13, 2007.
As with EC2 and S3, Amazon charges fees for SimpleDB storage, transfer, and throughput over the Internet. On December 1, 2008, Amazon introduced new pricing with Free Tier for 1 GB of data & 25 machine hours. Transfer to other Amazon Web Services is free of charge.
SimpleDB provides eventual consistency, which is a weaker form of consistency, compared to other database management systems. This is often considered a limitation, because it is harder to reason about, which makes it harder to write correct programs that make use of SimpleDB. This limitation is the result of a fundamental design trade-off. By forgoing consistency, the system is able to achieve two other highly desirable properties:
Component failures are assumed to be inevitable; thus, both of these properties were deemed necessary in order to provide a reliable web service. The CAP theorem states that it is not possible for a system to exhibit these properties along with consistency; thus, the designers need to settle for a weaker form of consistency.
Published limitations:
Conditional put and conditional delete are new operations that were added in February 2010. They address a problem that arises when accessing SimpleDB concurrently. Consider a simple program that uses SimpleDB to store a counter, i.e. a number that can be incremented. The program must do three things:
If this program runs while no other programs access SimpleDB, it will work correctly; however, it is often desirable for software applications (particularly web applications) to access the same data concurrently. When the same data is accessed concurrently, a race condition arises, which would result in undetectable data loss.
Continuing the previous example, consider two processes, A and B, running the same program. Suppose SimpleDB services requests for data, as described in step 1, from both A and B. A and B see the same value. Let's say that the current value of the counter is 0. Because of steps 2 and 3, A will try to store 1. B will try to do the same; thus, the final counter value will be 1, even though the expected final counter value is 2, because the system attempted two increment operations, one by A, and another by B.
Hub AI
Amazon SimpleDB AI simulator
(@Amazon SimpleDB_simulator)
Amazon SimpleDB
Amazon SimpleDB is a distributed database written in Erlang by Amazon.com. It is used as a web service in concert with Amazon Elastic Compute Cloud (EC2) and Amazon S3 and is part of Amazon Web Services. It was announced on December 13, 2007.
As with EC2 and S3, Amazon charges fees for SimpleDB storage, transfer, and throughput over the Internet. On December 1, 2008, Amazon introduced new pricing with Free Tier for 1 GB of data & 25 machine hours. Transfer to other Amazon Web Services is free of charge.
SimpleDB provides eventual consistency, which is a weaker form of consistency, compared to other database management systems. This is often considered a limitation, because it is harder to reason about, which makes it harder to write correct programs that make use of SimpleDB. This limitation is the result of a fundamental design trade-off. By forgoing consistency, the system is able to achieve two other highly desirable properties:
Component failures are assumed to be inevitable; thus, both of these properties were deemed necessary in order to provide a reliable web service. The CAP theorem states that it is not possible for a system to exhibit these properties along with consistency; thus, the designers need to settle for a weaker form of consistency.
Published limitations:
Conditional put and conditional delete are new operations that were added in February 2010. They address a problem that arises when accessing SimpleDB concurrently. Consider a simple program that uses SimpleDB to store a counter, i.e. a number that can be incremented. The program must do three things:
If this program runs while no other programs access SimpleDB, it will work correctly; however, it is often desirable for software applications (particularly web applications) to access the same data concurrently. When the same data is accessed concurrently, a race condition arises, which would result in undetectable data loss.
Continuing the previous example, consider two processes, A and B, running the same program. Suppose SimpleDB services requests for data, as described in step 1, from both A and B. A and B see the same value. Let's say that the current value of the counter is 0. Because of steps 2 and 3, A will try to store 1. B will try to do the same; thus, the final counter value will be 1, even though the expected final counter value is 2, because the system attempted two increment operations, one by A, and another by B.