11–18 of 18 posts
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
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.
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.
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?
That's what we call "scaling".
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.
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...
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
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.
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.