Ask HN: Anyone using SimpleDB? | Hacker News Reader

Ask HN: Anyone using SimpleDB?

35 pointspetervandijck17 comments

http://aws.amazon.com/simpledb/ With all the other options available, I'd like to hear some stories. What types of things is it good for? Why not just MySQL?

View on HN

I have used SimpleDB and wrote some basic Scala bindings for it:

http://github.com/crawshaw/saws

No service outages yet, but response time rarely drops below 50ms (from an EC2 instance) and there is a serious long tail on queries. I have seen 10 minute windows in which the fastest response time was 500ms. That is amazingly slow.

I've used it in the past for a logging tool that we wrote for our production app servers. I was super unimpressed with it. Bindings (for ruby) at the time really sucked, and were not clear which ones to use.

Also, SLOW. HTTP WAN db access is what you expect it to be.

Lastly, I don't like their data storage format at all, arrays of arrays, is painful and requires a lot of hoop jumping at times.

We switched to a local mongodb server as a near drop-in replacement, and it was a billion time faster and more efficient.

The final nail in the coffin was the data storage per record limitation, I think it was 1MB or something, so it was easy to piss off when capturing stack traces, hardly better than syslog at that point.

GetGlue apparently stores much of their data in SDB. CEO (Alex Iskold) talked about it in TWiST #78: http://thisweekin.com/thisweekin-startups/this-week-in-start...

Netflix is also migrating to SimpleDB from Oracle: http://highscalability.com/blog/2010/10/22/paper-netflixs-tr...

I use it, it's expensive and slow and hard to develop for, but it never goes down or causes operational headaches

You must pair it with an in memory cache, even then it's still slow and expensive

I'd still recommend it though for some use cases

So it's slow and needs memcached or something? That's dissapointing. What usecases would you use it for?

Never going down just doesn't seem that big of a deal for me, their aws mysql service also "never" goes down, so I might as well use that and gain all the sql advantages, right?

Never going down in a database doesn't just mean that it doesn't have downtime, it also means that as a whole system it's immune to bad queries.

Bad queries can destroy you in MySQL, if you are doing dynamically created queries that hit un-optimized areas, it can bring down all the other queries too.

I'd typically use Memcache with MySQL too, so there isn't any real difference in that case.

One use case I like SimpleDb for is for small scripts that need a very simple data store.

It depends on what you think "slow" means. It's the same speed when you're running one concurrent query as it is when you're running a hundred million concurrent queries.

That's what we call "scaling".

Never goes down or causes operational headaches is something I've found SQLite excels at, plus you get all the benefit from a query-optimizing relational database, plus a hot backup is just cp the database file.

We use SimpleDB from outside of AWS datacenters (Rackspace), and it does go down every now and then. Usually once a week for a couple of minutes we get timeouts and connection resets.

For us it was a good choice because we were on tight schedule, and didn't have to spend time on operation. In the longer term however, we'll migrate back to an in-house solution.

We use it as a subscription table for a constantly running process that pulls reports from search engine APIs (paid search data from google, for example).

Each SimpleDB Item represents an account for which we want search engine reports. The Item contains all the pieces necessary to tailor the API request for a specific account. When we need data for new accounts we just add them as new Items to SimpleDB, and the reports are picked up in the next run.

Cheap, available to any EC2 instance, and we never have to worry about DB maintenance or failures.

We're using it for our multiplayer platform (http://flockengine.com) to store user accounts and attributes.

Advantages: Easy to use and no need to maintain a custom database infrastructure, high availability, no SQL injections, great Python library (boto)

Downsides: Slow requests, not exactly cheap, lots of limits on entries(1), need to carefully handle numerical data for sorting(2), horrible PHP library

[1] http://docs.amazonwebservices.com/AmazonSimpleDB/latest/Deve...

[2] http://docs.amazonwebservices.com/AmazonSimpleDB/latest/Deve...

We tried using SimpleDB initially for a startup. We store a lot of numerical data. When it came time to actually query this data and do anything meaningful with it we ran into a lot of issues because all values are stored as untyped strings (comparison and ordering is always lexicographic). There are ways around this using zero-padding, but they are ugly and difficult. The SimpleDB query language is also limiting if you are accustomed to SQL and relational data structures. In the end it just wasn't the right fit and we reverted to an RDBMS.

I have used it, but not much. It is fast enough when client apps are running on an EC2 instance, but for some reason it is extremely slow for remote access (more than what I would expect from remote network access). As a result, it is a nuisance for development using my laptop.

I tried a Python SimpleDB simulator (for development) a year ago, but did not have much joy with it. For Ruby, there is a gem that wraps CouchDB and SimpleDB with (mostly) the same API.

We use it to power the Simple Database for QuickFuse: http://quickfuseapps.com

As some have mentioned here, there is a latency cost for every request, maybe around 200ms. So, we try to pack as much into each request as possible.

QuickFuse is a voice app development environment. Since customers are using QuickFuse's Simple Database to store completely arbitrary, semi-table-structured data, SimpleDB was really one of the few choices we had for allowing this data storage to scale on the backend. One of our main requirements was that customers wouldn't need to specify the structure of their tables in advance, so most other databases weren't an option, except maybe Couch.

What's perhaps more interesting, for anybody who's tried out QuickFuse, is that we wrap everything in both a nice GUI so people can upload "tables" of data and work with them, and also an API so data can be uploaded and downloaded programatically. Both the API and GUI make calls through our servers to SimpleDB.

I've used it for some small scale distributed business apps. Latency isn't really a concern and the usage pretty much fits into the 'free' tier.

It saves having to worry about any other infrastructure -- these are desktop apps that need to access some shared state.

The .NET bindings provided by simplesavant.codeplex.com made it very easy to integrate.

Also, when they mention "high availability", does that mean it's fast? Or that it doesn't go down? They do mention that from ec2 instances, the speed is "near-LAN", whatever that means in practice.

'High availability' means that it doesn't go down - or at least is much less likely to than a non-HA system.

It's not really to do with being 'fast' per se, although sufficiently slow response times are indistinguishable from downtime.

Reply on news.ycombinator.com