Your company plans to host a large donation website on Amazon Web Services (AWS). You anticipate a large
and undetermined amount of traffic that will create many database writes. To be certain that you do not drop
any writes to a database hosted on AWS. Which service should you use?
A.
Amazon RDS with provisioned IOPS up to the anticipated peak write throughput.
B.
Amazon Simple Queue Service (SOS) for capturing the writes and draining the queue to write to the
database.
C.
Amazon ElastiCache to store the writes until the writes are committed to the database.
D.
Amazon DynamoDB with provisioned write throughput up to the anticipated peak write throughput.
Explanation:
http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html
B
It is B. Because there is no limit on the number of messages that can be pushed onto SQS. The retention period of the SQS is 4 days by default and it can be changed to 14 days. This will make sure that no writes are missed.
A&C are incorrect. You can’t anticipate the PEAK as the questions clearly says undetermined.
B is incorrect because SQS does not guarantee the transfer of all messages. It guarantees one but not all.
C is the answer.
Let’s discuss.
A&C are incorrect, C is the answer.?? you are confusing.
do you mean to say that D is the answer?
A short poll does not guarantee delivery of all. The queue items still exist and are retrievable via short polling or long-polling.
Doesnt SQS guarantee the transfer of every message at least once ?
Cache is for read, man. Common sense.
Amazon ElastiCache is used for enhancing the performance of read-heavy application workloads and not for writes.
The answer should be D. Agree with tom it’s not C b/c Elasticache is mainly use to scale static contents. DynamoDB is optimal for high traffic sites. This question did not indicate high traffic would be sporadic.
A
While Amazon DynamoDB tackles the core problems of database scalability, management, performance, and reliability, it does not have all the functionality of a relational database. It does not support complex relational queries (e.g. joins) or complex transactions. If your workload requires this functionality, or you are looking for compatibility with an existing relational engine, you may wish to run a relational engine on Amazon RDS or Amazon EC2. While relational database engines provide robust features and functionality, scaling a workload beyond a single relational database instance is highly complex and requires significant time and expertise. As such, if you anticipate scaling requirements for your new application and do not need relational features, Amazon DynamoDB may be the best choice for you.
answer is b
https://aws.amazon.com/sqs/faqs/
My problem with B SQS is possible multiple delivery of the same message, wouldn’t the customer be charged multiple times if this occurred?
The application can handle it. If the same donation from same person and with a same timestamp (or another type of unique id) comes second time, it can be ignored. The applications behind the SQS should be aware of the fact that the message can come more than once.
The main points here are:
1. large and undetermined amount of traffic
2. do not drop
any writes to a database hosted on AWS
Only SQS will guarantee for both.
From https://aws.amazon.com/sqs/
“You can use SQS to transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available.”
Even with “Amazon RDS with provisioned IOPS” there is still no guarantee that RDS will be able to absorb all the DB writes due to undetermined amount of traffic. And if RDS goes down (or failover) there is a very small possibility of losing DB write. Only SQS can address such requirement
I think you’re right. I’ll go with you.
the key words in SQS explaination makes sense. I agree with you.
B
I think this should be a multi-choice question
A&B are the answers
Right answer is D
A and D are not good answers since “you anticipate a large and *undetermined* amount of traffic”, so regardless of any provisioned IOPS there is always a risk it will not be enough.
However with SQS you always have opportunity to monitor and scale without actually dropping a single write.
So B is the right answer.
B is the answer, anybody that has worked with a queue before (and if youre doing this cert i hope you would have) would know this
Agree with B
Amazon SQS guarantees delivery of each message at least once BUT DOES NOT guarantee the order (best effort) in which they are delivered to the queue. In other words it does not guarantee first in first out order.
However, Amazon SWF guarantees order as well
Your logic was right when you wrote it but no longer valid. SQS does provide FIFO now
IMHO A and D
B: SQS is a pull model I do not know of a method how DBMS can pull data from Queue. SQS is generally used for decoupling applications and not for databases
C: Elasticache is a MemCached used for Read not for write
D: Though this can be one plausible option moreover its a choice of DB engine. Since I donn’t wish to lose any data I would still choose a DB with ACID properties.
I would go with D since Dynamo DB is scalable on the fly given the uncertainty of the peak anticipated
My Answer is B
Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable hosted
queue for storing messages as they travel between computers. By using Amazon SQS,
developers can simply move data between distributed application components performing
different tasks, without losing messages or requiring each component to be always
available. Amazon SQS makes it easy to build a distributed, decoupled application, working
in close conjunction with the Amazon Elastic Compute Cloud (Amazon EC2) and the other
AWS infrastructure web services.
It is certain that RDS and DynamoDB are the only options for answer.
We know RDS requires us to choose the size of instance based on the anticipated traffic volume and it will be priced irrespective of the actual consumption. RDS gives us the flexibility to scale up the instance, but that would incur maintenance window. Of course, we can choose Multi-AZ where this will not incur any downtime.
Looking at DynamoDB, it gives us the flexibility to choose the PIOPS and you have no concern about managing the instance size. I see this and the cost advantage as a tick for choosing DynamoDB