

Ask HN: Anyone using SimpleDB? - petervandijck

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?
======
crawshaw
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.

------
perezd
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.

------
rykov
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...](http://thisweekin.com/thisweekin-startups/this-week-in-startups-
with-alex-iskold-getglue/)

Netflix is also migrating to SimpleDB from Oracle:
[http://highscalability.com/blog/2010/10/22/paper-netflixs-
tr...](http://highscalability.com/blog/2010/10/22/paper-netflixs-transition-
to-high-availability-storage-syste.html)

------
alexbosworth
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

~~~
petervandijck
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?

~~~
alexbosworth
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.

------
crcastle
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.

------
metachris
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...](http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?SDBLimits.html)

[2]
[http://docs.amazonwebservices.com/AmazonSimpleDB/latest/Deve...](http://docs.amazonwebservices.com/AmazonSimpleDB/latest/DeveloperGuide/index.html?SDBLimits.html)

------
jread
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.

------
mark_l_watson
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.

------
pak
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.

------
aquark
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.

------
petervandijck
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.

~~~
semanticist
'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.

