Redis Stack(redis.io) |
Redis Stack(redis.io) |
Redis as a pure in-memory store (caching) engine just doesn't make as much money as "analytic system". I don't have a problem with this as they have to make money somehow.
Frankly, I don't see anything bad with it. Those who don't want to spend money get it for free and those who can afford will pay for it.
If so, what's your objection? To me this amounts to more or less just expanding the Redis ecosystem, which feels like a win-win.
Doesn't seem like that has changed to me
Having said this, it really gives me the sensation that Redis is trying to solve too many use cases, turning into some sort of Swiss knife.
The reality of Swiss knives is that they don't excel in anything of the things they do.
Except the one thing that do excel at: being swiss army knives.
Migraring data is no fun, but much more straightforward than rewriting a good part of your code when you decide to switch database.
Well I know that's obvious, but Redis is nearly the perfect solution in terms of performance. Unlike disk-based databases, Redis has consistently optimal performance on the order of millions of queries per second. And horizontal scaling is trivial with Redis Cluster (it involves running multiple Redis instances and many Redis service providers don't support it - I hope to have an easier way of running cluster though).
Given that memory is cheap it's quite plausible to store an entire database in a single Redis instance. I do hope that Redis finds its way to replace conventional databases. I think we just need an asynchronous `FLUSH` command, which blocks until the next `fsync`, and that should get us closer to ACID compliance.
"Wow this has a lot of features" vs "wow what are all these extra things I need to sift through to figure out what I need", no?
Instead a lot of product start out that way and then if it becomes popular scope creep rears it ugly head and it is extended to be mediocre at many things.
I find far too many developers once they start investing time in a product they want it to do all sorts of other things that there are allready tools that do it well.
Does anyone know what this RSAL license’s impact is for internal tools (e.g log analysis)?
As long as this log analysis is part of the production environment of your application, and you don't resell it as a tool, that should be fine.
Worth a watch for sure
Second, many Gigas is what you get from any small size server... And, on top of that Redis/TimeSeries supports an almost linear scale out which allows your memory to increase dynamically according to your needs. Last, Redis Enterprise (& Cloud) add Redis on Flash support extending your RAM to your local Flash storage.
Is this something Redis are likely to offer in future does anyone know?
e.g.
* https://github.com/npezza93/redi_search
* https://github.com/vachhanihpavan/rejson-rb
* https://github.com/dzunk/redis-time-series
You can see on each modules docs the list of clients developed by the community. e.g.
It's a datastore. It has clients for many languages, including a recommended one for Ruby. What support are you missing here?
So it appears that you are the one that is missing something.
Hopefully the doesn't happen with the product itself.
They were asking what library support was missing for that person's use case (which your question answers, but I think the snark is based on a misunderstanding).
Maybe my answer sounded more harsh in tone than what I meant, sorry for that.
I red the message as "Hey they didn’t cover my specific case!", and I felt like this was unfair to ask an opensource project to cover each corner case upfront and not even consider a lacking feature as something that can be reported or maybe even contributed back.
Yes, it came off sharp, it would have discouraged me from contributing. Sometimes people don't really get that the process is open to all and need to be invited, I think it can be good to try and see stuff like this as an opportunity to extend that invitation.
I think you misread this one because it is basically "excitement about new thing -> implied disappointment at not getting to use new thing", and I can't find an ask in that.
For instance, to create a "User" we need the PutItem API from DynamoDB [1]. Similarly, to retrieve a "User", there's the GetItem API [2].
Instead of making references to these APIs all over our codebase, we have a single `db-interface` module, which implements `get_user` and `create_user` functions. Each of these functions has an interface: they expect specific arguments with corresponding types. This interface is modeled against our data domain, not DynamoDB data domain quirks.
Inside the `db-interface` module, we implement the conversion from our data domain to Dynamo's. We also have general-purpose functions, like `create_item` and `get_item`, so that `get_user` and `create_user` are pretty much wrappers and only serve the purpose of defining the interface for interacting with the "User" data object.
The rest of our code only interacts with our internal interface, never with DynamoDB APIs directly.
If we were to switch database, we only need to re-implement the general-purpose functions (e.g. `create_item`, `get_item`).
May sound like a lot of work, but it took only a handful of days to implement the entire interface mapping everything we needed from DynamoDB.
Hope this helps clarifying a bit the application of this concept (develop for an interface, not an implementation) in the context of interacting with databases.
[1] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...
[2] https://docs.aws.amazon.com/amazondynamodb/latest/APIReferen...
But if the current database has features that can't be mapped to the new one, the interface won't save you.
Example: DynamoDB has a "time-to-live" feature [1]. You add a specific property to any item with a timestamp and it will auto-delete this item at the timestamp determined.
Few databases will provide this out of the box. If you choose to use it and later need to migrate, you'll have to implement your own kind of "TTL monitor" to perform the same task. The interface can't possibly save you from this.
But this would be an issue whether you decide to use a central interface or not, anyway...
[1] https://docs.aws.amazon.com/amazondynamodb/latest/developerg...