91–100 of 135 posts
Earlier quoted context omitted.
HN doesn't show vote totals, but it does sort posts based on the number of votes (descending), so the more popular posts rise to the top, just like the front page.
That isn't how the frontpage works, and if it did, we would rarely have news turnover.
I simply do not see how competing cloud vendors can keep up with this. Most of them are still struggling to provide anything beyond a simple API to start/stop machines.
They are making money on the read/write and are selling the capacity at current cost. Which — knowing the tendency for AWS to decrease the prices very slowly combined with the huge decrease of the prices of the SSD drives in the past months/years — is not a bad strategy to convince us to switch.
Earlier quoted context omitted.
Since HN doesn't show vote totals I wanted to chime in and say this would be really useful to me as well.
HN doesn't show vote totals, but it does sort posts based on the number of votes (descending), so the more popular posts rise to the top, just like the front page.
This still seems a bit expensive to me for an application that would require thousands of writes per second? ie. 5k writes per second is ~$120/day. Using this for performance based analytics for example would seem out of the realm of reason for the moment.
Can you explain your use case a bit more? I'm having a hard time imagining something that does ~430M DB writes/day but can't easily afford to pay $120 for those writes.
Now I'm not sure this would be the ideal solution for such a thing (in fact it probably is not), but it's just the first thing that came to mind. In the grand scheme of things sure that may seem like a trivial amount due to the use case, but we're still more in the realm of a startup where dropping ~$3k/month on the data store alone makes me cringe a little when we have other expenses to account for also. :)
I already have a bunch of (large-ish, deeply nested) JSON objects defined for my application. I don't really want to go about redefining these since they work great between my various node processes and the front end. I am saving them in a nosql database already, I am curious about switching (to save on devops costs). I only request based on 1 Hash Key (int) and 1 Range Key (int) for all my current get operations.
Looking through the docs/examples I see a lot of this type of thing:
{"TableName":"comp5",
"Item":
{"time":{"N":"300"},
"feeling":{"S":"not surprised"},
"user":{"S":"Riley"}
},
"Expected":
{"feeling":{"Value":{"S":"surprised"},"Exists":true}}
"ReturnValues":"ALL_OLD"
}
Ok, my question: Do my JSON objects need to conform to this 'type syntax' JSON notation in the examples? Or can I save just any JSON object into this database and only annotate the Hash Key and Range Key using this special notation?
"Amazon DynamoDB stores data on Solid State Drives (SSDs)" This is big.
When Amazon notes "SSD," from a client's perspective, it is only marketing. The storage media matter when you are managing your own hardware. The storage media do not matter in SaaS. For example, the storage media could be floppys and you would get satisfactory performance if there was a memory cache. Similarly you could get poor performance with SSD media if the networking layer(s) were slow. Similarly if the storag…
A feature request (I see that Werner is reading this message thread): for development it woud be very nice to have the Java AWS SDK have a local emulation mode for SimpleDB and DynamoDB. This would allow development while flying or otherwise off the Internet. Similar functionality as AppEngine's local dev mode.
Very interesting that there's no mention of the CAP theorem here, despite Amazon's heavy reliance on it in the past when marketing their non-relational stuff.