On Mar 4, 2011 10:38 PM, "dormando" <[email protected]> wrote: > soooooooooooooooooooooooooooooooooooooo. it's more about matching the tool > vs your actual needs. most of the problem here has always been separating > perceieved requirements from actual requirements.
yeah, that's an incredibly important distinction. i talk to a lot of people who seem to think that their data is so important, they can't possibly tolerate even a brief inconsistency. or that just because memcached *could* lose data means that it will. the truth is, we've been running a large (over 500GB on, at one point, up to 50 servers) installation and we've had very little data loss. generally, the only times a server went down were when we intentionally brought it down or the very rare hardware failure. obviously, it's not a persistent datastore and you need to keep your permanent data somewhere, but for anything ephemeral or that can be easily queried or recomputed, memcached is an excellent and fairly reliable choice. in fact, i would bet there are a lot of situations where a fairly high-traffic site chooses to store something like session in a slower but more "reliable" datastore because they "can't afford to lose the data," but end up with a lower QOS because the datastore can't keep up with the load and ends up with failled reads and/or writes. awl
