21–30 of 47 posts
> Redis is probably the only top-used database system developed mostly by a single individual currently isn't SQLite pretty much just Richard Hipp?
Dan Kennedy does a lot of work, certainly appearing to be a similar order of magnitude to DRH. Joe Mistachkin appears to do Windows almost exclusively and I can't tell if he is part time or full time. https://www.sqlite.org/crew.html
Earlier quoted context omitted.
I don't pay super close attention to this stuff, but it's very obvious to me that not everyone likes Redis; in particular, the kinds of people who have problems with Mongodb tend also to have the same problems with Redis; long-term operational reliability is a big question mark with it. For my part: on only a few occasions (mostly fuzzer farm stuff) have I ever used Redis and been happy with the decision. I usually r…
I don't know, I don't think it should be compared (or considered as an alternative to) MongoDB, and certainly never SQL. I use it to store cached keys, session data and similar other data that I can always regenerate. I've also had great success using it as a message queue on multiple projects. What was your use case, and what was your experience with it?
To summarize quickly for those that didn't read the article, this focuses mostly on the new "clustering" aspect not on the "classic" single Redis server (if you wish). I think it is important to be honest with the users and make it clear how and what happens behind the scenes, how data could be lost. And Salvatore has done most of this, maybe just make it a bit more explicit, as there still seems to be some confusion…
In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick at most two).
There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you want consistent semantics in a very fast database, you can't pick either. So you end up somewhere in the middle of the triangle.
The consequence of picking zero is that you'll lose a time window of data roughly proportional to the replication lag when the master fails/partitions. There are many applications for which bounded data loss is a perfectly reasonable paradigm.
This is the first time I've ever heard any criticism for redis. As far as I know, everyone loves it, it's a great tool for many jobs and it's amazingly written and solid to boot. I think many of the critics are trying to apply it in ways it wasn't meant to be used. As far as I know, its main purpose is non-critical data that needs to be accessed as quickly as possible in various different ways, and that's where redis…
It would be great to also enumerate other examples where it shines. I've used it for caching, session and transient objects connected to Rails without issue for the last two years. Additionally, I've been looking at it recently for a simple database to perform fast matches on sorted data (E.g. get me the lowest number in this set).
And one more: - Storing diffs like those used for Google Docs (literally every change) for a real-time communication system.
The last one works by the client not getting a response and continuing to queue up its diff and send it once the server is back up. Manual conflict resolution is likely necessary after a drop in availability, but consistency is easy to figure out with monotonically increasing IDs.
To summarize quickly for those that didn't read the article, this focuses mostly on the new "clustering" aspect not on the "classic" single Redis server (if you wish). I think it is important to be honest with the users and make it clear how and what happens behind the scenes, how data could be lost. And Salvatore has done most of this, maybe just make it a bit more explicit, as there still seems to be some confusion…
I think Antirez is simply doing a master/slave system with async replication. This is what mysql, solr, elasticsearch, kafka, etc do. This is not an unusual model at all. In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick at most two). There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you wa…
Earlier quoted context omitted.
I think Antirez is simply doing a master/slave system with async replication. This is what mysql, solr, elasticsearch, kafka, etc do. This is not an unusual model at all. In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick at most two). There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you wa…
I assert that this design actually allows for arbitrarily long windows of data loss, but I haven't verified that the implementation matches my understanding of antirez's WAIT/failover algorithm yet. Pretty sure though.
Just to be clear, the criticism is of Redis Cluster, which has been redesigned because the first design was so lax it was effectively unusable. The real issue, is that as of right now I have no idea what the exact semantics and failure conditions of Redis cluster are. I'm not clear that anyone really knows. Salvatore thinks he knows, but we can't be sure that he does. With all this talk of practicality, what really m…
To summarize quickly for those that didn't read the article, this focuses mostly on the new "clustering" aspect not on the "classic" single Redis server (if you wish). I think it is important to be honest with the users and make it clear how and what happens behind the scenes, how data could be lost. And Salvatore has done most of this, maybe just make it a bit more explicit, as there still seems to be some confusion…
I think Antirez is simply doing a master/slave system with async replication. This is what mysql, solr, elasticsearch, kafka, etc do. This is not an unusual model at all. In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick at most two). There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you wa…
Even you are using "I think antirez is simply doing..."
Not arguing the design is not useful or it is a bad design, Savlatore's code is great, I think it is just a matter of more testing, docs or a blog post.
This is the first time I've ever heard any criticism for redis. As far as I know, everyone loves it, it's a great tool for many jobs and it's amazingly written and solid to boot. I think many of the critics are trying to apply it in ways it wasn't meant to be used. As far as I know, its main purpose is non-critical data that needs to be accessed as quickly as possible in various different ways, and that's where redis…
I don't pay super close attention to this stuff, but it's very obvious to me that not everyone likes Redis; in particular, the kinds of people who have problems with Mongodb tend also to have the same problems with Redis; long-term operational reliability is a big question mark with it. For my part: on only a few occasions (mostly fuzzer farm stuff) have I ever used Redis and been happy with the decision. I usually r…
Mongodb seems like a solution that was optimized for a certain performance sweet spot that, post-SSD and huge RAM, hardly anybody ever really encounters and 99% of the times it's used you would be better off with Postgres.
Redis on the other hand hits a (probably permanent) sweet spot of ultra-high performance one level of abstraction lower than your usual database; which is a use case everyone trying to saturate metal and squeeze out the last bit of performance on a minimal budget has.
To summarize quickly for those that didn't read the article, this focuses mostly on the new "clustering" aspect not on the "classic" single Redis server (if you wish). I think it is important to be honest with the users and make it clear how and what happens behind the scenes, how data could be lost. And Salvatore has done most of this, maybe just make it a bit more explicit, as there still seems to be some confusion…
I think Antirez is simply doing a master/slave system with async replication. This is what mysql, solr, elasticsearch, kafka, etc do. This is not an unusual model at all. In CAP theorem terms, Redis has picked zero (remember CAP theorem is pick at most two). There's a bunch of people who've made this choice, but why? C incurs a synchronization cost. A means that you have to reconcile different writestreams. If you wa…
No, he picked P, Partition Tolerance. You can't not pick P. Unless you assume a never-failing network with never-failing nodes.