Not all devices are phone-like end-user devices.
I can imagine a machine that produces something. It is full of sensors and actuators, plus logic that uses sensor input to compute what the actuators most be doing. Typically one would store some recent sensor + actuator decision data in RAM to calculate averages, do all kinds of computations, etc.
Storing the same data in Redis instead gives you all that, but persistence for free. That's great, because it means developers / maintenance people / support people can always get a decent dump of what recently happened, without much overhead or extra work. The memory is the log. Elegant!
Computer systems that control factory processes, such as SCADA and MES systems, often have to deal with large amounts of data coming in from many different machines. Most vendors therefore wrote what they call a "real-time database", even though it is not really real-time, just fast. Redis would be a great substitute for such a database.
A high-performance multifunctional office printer has a large memory of jobs sent to it by many different people; print jobs, scan jobs, and so on. These often incorporate fair amounts of data, but the data processing speed requirements are very high because the printer is so ridiculously fast. I imagine that right now the entire job data structure is effectively held in memory and hand-persisted just in case the printer fails; people wouldn't want to lose their print jobs, would they? Persisting data that must be held in RAM for performance reasons. Hmm, where have I heard that before?
I'm not saying Redis is the ideal choice for these particular cases. I'm just quickly braindumping some examples.
I must admit I can't come up with a great end-user business SW example right now though. Maybe I was off the mark there.
That said, as more business applications are moving to the web too, Redis would be very much applicable there. Many organisations (think offices, services sector) have their entire custom-built internal IT systems based on Windows. Much of this is probably a relic of the vendor lock-in practices that MS was very effective with a decade ago, but they're still there and as MS keeps supplying excellent dev tooling, it's unlikely to go away any time soon. Imagine a team of 10 sysadmins for a 3000 person company all highly skilled in administering Windows systems. Moving such people to Linux "just" to administer a Redis installation is impractical, and the company will rather disregard Redis for other options.
I should have asked "inside devices running windows , or as a component in 'end-user' business software running windows " I thought that was implied given the context.
Specifically about printers - they're not that fast that sqlite or postgres can't deal with them. Really. redis is for the 50MB/sec pushing-things-around speed. Fastest printers are at the 10MB/sec, which MSSQL, PosgreSQL and SQLite handle perfectly well. Also, redis is about lots (hundreds of millions) of small items. printers are about few (thousands) of large items.
> Computer systems that control factory processes, such as SCADA and MES systems, often have to deal with large amounts of data coming in from many different machines. Most vendors therefore wrote what they call a "real-time database", even though it is not really real-time, just fast. Redis would be a great substitute for such a database.
They should pay for a "real" in memory databsae if they can pay for windows. TimesTen, Sybase IQ, Kx. Yes virginia, there are consequences to using the proprietary eco-system.
> Imagine a team of 10 sysadmins for a 3000 person company all highly skilled in administering Windows systems. Moving such people to Linux "just" to administer a Redis installation is impractical, and the company will rather disregard Redis for other options.
You're spending $1M/year in sysadmin salary alone here - probably $1M/year more on hardware and other licenses. Shell out $50K for TimesTen and be done with it. Or pay someone (possibly even antirez) who'll produce a windows port. If it's not worth $50K to this company, it's not worth even a single minute of antirez' time.
also, you seem to very much want me to demand that antirez codes a windows port, for free, pronto. i never asked for anything like that. i was, and still am, only referring to antirez's conclusion that POSIX is the 99.99% platform for all places where Redis could the best fitting option. I was hoping for him to slightly adjust that conclusion. What he does with it afterwards is entirely up to him.
I apologize for implying that if I did. That was not my intention.
(offtopic) Really, it's this stuff that keeps me on HN. The ability to shake hands and move on is quite seldom on internet forums.
Exactly. You're inventing weird use cases that only half-fit Redis's properties, instead of carefully considering the design and architecture of your application.
Software that attempts to solve all problems becomes Emacs.
a decent response to my post would be to explain why Redis fits web/cloud only and why its design is a misfit for other areas by nature.
Redis may or may not be an appropriate tool for any particular design. I've solved a lot of problems with it, but my employer still has Oracle and MySQL databases that are unlikely to ever go away. I've also solved a lot of problems with Python on Ubuntu, but some of our infrastructure uses Windows and C#.
You've got a hammer and you're searching for nail-like objects. You need to put down the hammer, and figure out whether you even have nails in your project.
I really feel like I've been getting a fair amount of fire here for writing things that I feel aren't that offensive or stupid. I can see that you may disagree, but I can't see where the heat comes from.
When I design a new piece of software, you can be sure that I'll find my nails before I choose my hammer. When discussing whether hammer X fits nail Y, please pardon me that I try and consider that in detail before I dismiss the hammer at all.
This entire thread is about whether it makes sense to support Redis on Windows. This discussion, in it's very essense, is a "we've got a hammer (Redis) that could be changed so it can be used on some more nails (db/persistence problems on Windows)". I list some Windows-heavy situations in which Redis may be an excellent hammer indeed. You respond by lecturing me. What's up with that?
Once more, to avoid the standard anti-MS downvote: I'm not demanding a Redis port. I'm not claiming Windows is superior. I'm not claiming to some "right" to get good software for free on my chosen platform. I'm only pointing out that more than the 0.01% of Redis users that antirez quotes in his blog post could prefer Windows, for good reasons.
> It might make sense for end-user business software if that software ever has to be run offline.
I'm sorry, I'm entirely unimaginative -- but I can't think of a use case for an "end-user" offline Redis server (regardless of O/S) that is better served by redis' sweet spot than by a local sqlite or postgres install. Can you help me here?
Redis does one small thing and does it amazingly well -- an in-memory database with persistence and some very useful operations (such as FIFO lists) that do not need roundtrips.
That does not make sense inside a device unless you have ridiculous amounts of RAM to spare (which has never been the case in my experience).
Similarly, it makes very little sense in an "end-user" business software, unless there are _multiple_ processes needing access to the same in-memory data. And that (to me) means a "server" is going to appear sooner or later.
Really, unless you run it on a "server", then sqlite with properly set cache parameters is almost surely a better choice, and works on Win32 since 2002 or so.
Where it makes sense to deploy Redis, looks to me like antirez is right and Unix has won. And even though Redis likely works on iOS and Android out of the box, it makes no sense to do so, at least not at this point.