CODEWITHSUNDEEP
databaseamazon-web-servicesamazon-simpledbamazon-rds
Phil
Phil

Reputation: 113

Performance of Amazon SimpleDB/Amazon RDS?

Has anyone using Amazon SimpleDB or Amazon RDS had any problems with response time, uptime, stability, etc.? Would you say overall you're happy with the service? No issues with data loss or needing reboots etc.? We're thinking about using one of them for a project.

I like the idea a lot, although since we need to use some math functions (sine, cosine, etc.) we probably will need RDS not SimpleDB. Just wondering if the execution is as great as the idea?

Upvotes: 2

Views: 933

Answers (1)

timmers
timmers

Reputation: 65

I've used SimpleDB in all the way up to one production environment so far, and whilst the production load wasn't that high, load testing was performed to a much higher level than we needed, and SimpleDB stood up to this quite nicely.

SimpleDB overall seems to have very good uptime characteristics and reliability, compared to RDs for example, where you are only as reliable as the setup you are prepared to pay for 24/7 - if you make no hits to SimpleDB it costs almost nothing, as well, which is handy.

I've also yet to see data loss, and there is no concept of running instances for SimpleDB so no reboots either, whereas with RDS you are talking all the usual management of EC2 instances running the RDS instances.

You will on the other hand as you have noted, not be able to perform functions inside the database, outside of a very limited set of operations (well just count(*) actually), so that would have to go on at application layer.

Also, you should not underestimate the change in mindset between working via JDBC where connections are long-running, but a precious commodity, as opposed to SimpleDB where each request is an HTTP request, but there is far less restriction in concurrent connection count.

In my case on our first production use of SimpleDB, it took some heavy load tests and unimpressive results to have us realise this meant we could parallelise operations to what would normally seem an obscene level - for example when collating 'like' counts for 1300 likeable things, rather than go with the original plam, and get these counts serially via "SELECT COUNT(*)..." we instead made 100 of these requests in parallel at a time, and could have gone higher veyr easily.

The TL;DR - Don't underestimate the change in mindset going to a NoSQL approach, but also don't dismiss it.

Upvotes: 1

Related Questions