Total overkill, especially given that replicated RAM storage is quite pricey when compared to traditional alternatives. Ideally, you just use Redis to store (<i>cough</i> cache <i>cough</i>) latest forum threads/comments and have everything else on disk (maybe in a RDBMS?). You get performance and price.<p>EDIT:<p>>Another of those tricks has to do with the fact that nearly half of our code is also written in LUA running directly on Redis.<p>Urgh. Ugly.
> The API servers that we are able to push this load with cost a mere $90/month<p>That would be about an EC2 m1.medium<p>It would be interesting to see how much it costs to run the whole cluster.
I'd also love to know which part of the redis featureset they really use. Redis is great, but I think a lot of other database backends will give comparable performance when allowed to store all their data in RAM (MongoDB, Postgres, Riak, Cassandra, ...). The advantage of these (especially Riak/Cassandra) would be that for pure key/value semantics, they take care of all of the annoying operations overhead like rolling updates.
I'd be really interested in seeing if you benchmarked fsync at every query vs your fsync every second policy.<p>My main beef with fsync every second is just that you will never, ever get a "this is what the server looked like when it went down". If the fsync at every query was only worse by a relatively small factor, and if you used write transactions for the majority of your writes (meaning fewer times needed to fsync for every query) which I'm guessing you are to protect integrity on writes, I don't see why this wouldn't be more appealing than fsync at every second?
<i>If you are envisioning network partition scenarios where perhaps the master is isolated from the slaves, this is minimized by replication checks to slaves (set an arbitrary key to an arbitrary value and check if the slaves update). If a master is isolated we block writes: Consistent and Partition tolerant at the cost of Availability.</i><p>Could you describe these checks in more detail, please?
I've been using Redis Cloud by Garantia Data for the past few months. They have automated infrastructure for (what I assume are) sharded Redis DBs, and they have a super reasonable pay-as-you-grow plan. <a href="http://redis-cloud.com/" rel="nofollow">http://redis-cloud.com/</a><p>They claim to support Redis DBs of "unlimited size"... until they run out of ram in the cloud :)
We've been using Redis as a primary data store for about two years, and it works great. We have a simple master-slave config and do periodic RDB snapshots -- no EBS. We manually failover from master to slave, but in practice this is rarely necessary (our current master has been up for 9 months).
Redis as primary data source? Good<p>If it fits your ram of course (and no, swap space is not RAM, just don't)<p>But you can organize yourself, putting bigger data in the FS for example, and it should be ok.<p>The only issue with Redis is that it's much 'lower level' than other DBs so don't expect to do a 'SELECT * where condition' out of the box.
How much does maintaining this infrastructure cost? I'd guess that spending a bit more on (virtual) hardware would have been a much cheaper solution. Only when the service proves to be popular and you want to save money you should invest in an architecture like this.
How do you delete data from redis ?
Eg. Let's say that a customer no longer wants an account, and you want to delete all the keys related to an account. Do you manually write delete key statements ?
I built out a connection pool for the Python redis client for these types of setups where you'd want master / slave failover. It's meant to be paired with something like sentinel or custom failover scripts. <a href="https://github.com/StartTheShift/jondis" rel="nofollow">https://github.com/StartTheShift/jondis</a>