I love a lot of the feature ideas: composable query language (as long as the DB also supports sql) would be great, soft delete would be great too.
For the more complex features, as a platform-phobic engineer, I find I gravitate towards composable solutions and am happy to re-build unsupported features on top of simple tools because I'm scared of getting trapped in a platform that my needs eventually outgrow. It's great if platform creators are proactive about providing some escape hatches or some modularity so its easy to continue on their platform while also adding in features they lack or aren't a fit for my system.
Related to that, I feel platforms have a higher cost to vet prior to adoption than a single purpose solution. This is at odds with most startup engineering work cycles where you need to get something done _today_ for a specific problem and you plan to grow your understanding of the problem & system incrementally over time. I'm not sure how any software/database platform can overcome this problem.
Hi, I'm the author of the post. I'll have to look into getting the metrics from Twemproxy in the future. I typically only run MONITOR for a few seconds 'cause I'm usually just looking for high volume commands & keys.
Hi, thats a good point and the approach you describe would work for a single Redis instance. In our case, we were using Twemproxy in front of Redis and it doesn't support Redis's "SCRIPT LOAD" command so we would need a way to load the script on each Redis node ahead of time. One other concern when using EVAL and EVALSHA through Twemproxy is guaranteeing that all keys in the command map to the same Redis node, in our case we only had one key so wasn't a concern. Documentation on that can be found here https://github.com/twitter/twemproxy/blob/master/notes/redis...
You don't owe taxes at the time you buy publicly traded stocks and if you were exercising options on a publicly traded stock you could sell some percent to cover your taxes, that's different than owning a completely illiquid asset yet still having taxes on it.
For the more complex features, as a platform-phobic engineer, I find I gravitate towards composable solutions and am happy to re-build unsupported features on top of simple tools because I'm scared of getting trapped in a platform that my needs eventually outgrow. It's great if platform creators are proactive about providing some escape hatches or some modularity so its easy to continue on their platform while also adding in features they lack or aren't a fit for my system.
Related to that, I feel platforms have a higher cost to vet prior to adoption than a single purpose solution. This is at odds with most startup engineering work cycles where you need to get something done _today_ for a specific problem and you plan to grow your understanding of the problem & system incrementally over time. I'm not sure how any software/database platform can overcome this problem.