But if that data in the HashMap must be available to another process, or you need more "features", Redis suddenly looks like a very easy solution.
Btw, Redis is extremely fast to set up, but as I sai, if all you need is a HashMap..
[1] - Almost always for the better if you ask me. That Java "enterprisy" way of development is the worst thing I have ever experienced in computing ;)
Sites that have any kind of download/upload component, even though does not have too much traffic, will need to serve multiple requests using threads/processes.
That is where we normally use relational database. However Redis presents a way to be faster than conventional databases by storing everything in memory. This is as close to a concurrency-safe HashMap that you can get with the least amount of effort.
If you think that blocking TCP calls to a redis server that serialises everything is going to be faster than a `new HashSplayTree<String>()` you're absolutely bonkers.
Is installing and configuring Redis, installing and configuring a client library, and integrating the usage of that client library with your system really a better use of a one-man startup developer's time than writing
and going back and fixing it later if it matters?I had a three hour argument the other night with a developer trying to implement some sort of complex logic involving caching for a fairly small blacklist file. I eventually had to make him go away and benchmark it ... at which point he realised what my original point was - loading that file off disk and parsing it on every request it was needed was actually faster than talking to a cache to get a pre-parsed version.
Overengineering is still overengineering, even when most of the components you use to do it are provided by somebody else.