Well, there are other services: Google's Big Table, among others. But the title begs a different, better question: What about a local version of S3?
What would be great is a small engine that would run on my hosted server (and locally) that would imitate both S3 and SimpleDB services.
In your case, you could use it as an additional backup for S3. In my case, S3 would be the backup. Plus the performance (especially of SimpleDB) is killing me. It fails regularly. So this would be much faster and simpler.
That said, it sounds like the filesystem is the right tool for your purposes.
I don't want to manage (all) my storage, but I'm trying to avoid using S3 as both the primary and backup (thus wasting the money and effort spent attempting to reduce risk).
Thanks; you're right. Doing disk + S3 is a great idea. I'll implement it immediately. I also have an idea of how I can implement disk + SimpleDB as well, which would make everything faster and easier. (It also solves the inconsistency from the delay before written data is replicated across SimpleDB servers.)
Thanks for that! (I wish I could help you with an answer to your dilemma in return. :)
5 comments
[ 2.9 ms ] story [ 19.1 ms ] threadAnd of course, I could manage the storage myself, but I could grow my own rice too. I'd rather let capitalism do its job, so I can focus on mine.
What would be great is a small engine that would run on my hosted server (and locally) that would imitate both S3 and SimpleDB services.
In your case, you could use it as an additional backup for S3. In my case, S3 would be the backup. Plus the performance (especially of SimpleDB) is killing me. It fails regularly. So this would be much faster and simpler.
That said, it sounds like the filesystem is the right tool for your purposes.
I don't want to manage (all) my storage, but I'm trying to avoid using S3 as both the primary and backup (thus wasting the money and effort spent attempting to reduce risk).
Thanks for that! (I wish I could help you with an answer to your dilemma in return. :)