4 ms·
Agreed, but if your values aren't large and if your client can do the obvious filtering then you can emulate it quite easily. This is actually what Mark Atwoo
by bayareaguy 18y ago
Agreed, but if your values aren't large and if your client can do the obvious filtering then you can emulate it quite easily. This is actually what Mark Atwood's S3 storage layer for MySQL did.
I'm still curious about the values you're using in your test. Did you use exactly the same ones described on the "Indexing and Querying Amazon S3 Metadata with Amazon SimpleDB" page?
- cperciva 18y agoAgreed, but if your values aren't large and if your client can do the obvious filtering then you can emulate it quite easily. True, but the S3 LIST operations you need for that can get expensive quickly. I considered it for the application I intend to use SimpleDB for, and decided that SimpleDB was far cheaper. I'm still curious about the values you're using in your test. They were utterly synthetic -- the first things which came to mind: The item names were 0000, 0001, 0002, ... 9999, the attribute names were "square" and "cube", and I think you can guess what the attribute values were. :-)
- bayareaguy 18y agoThanks. I remember your earlier article where you wrote Third, if you have an item with only one attribute, and your read:write ratio is more than 22:1, it's cheaper to use S3 instead of SimpleDB -- even ignoring the storage cost -- since S3's 1 μ$ per GET is cheaper than SimpleDB's 1.305 μ$ per GetAttributes request. and wondered if that still held true for varying I/O rates.
- cperciva 18y agoYes, still true -- the price (per BoxUsage) of SimpleDB requests doesn't depend on how many requests you're making per second.