Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redis Stack

redis.io

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Redis Stack

#61

Post by Lio »

gkorland wrote: post #40
Lio wrote: post #36

It’s a shame they don’t offer first class Ruby support. I could see myself using some this stuff. Is this something Redis are likely to offer in future does anyone know?

You're right, we would love to provide a much better experience in Ruby it was just a matter of priorities... BTW, all the modules already have ruby based clients developed by the community. 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. https…

Thank you, that'll be a good place to start. Cheers.

Re: Redis Stack

#62

Post by manishsharan »

I have used Redis TimeSeries a few years ago and I found it easy to use and very performant for my needs. I think it is still chugging along at my last employer. The development team is already familiar with Redis and therefore found TimeSeries simple and easy to use. None of us wanted to use ( and learn) a dedicated TimeSeries database API and business did not want an expanded footprint to maintain. So Redis TimeSeries was an excellent solution for us

Re: Redis Stack

#63

Post by aelzeiny »

pachico wrote: post #25

True, you can always run vanilla Redis. 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.

It's always been a Swiss Army Knife. It's a single-threaded-in-memory caching, pubSubing, streaming, distributed-locking beast.

Re: Redis Stack

#64

Post by rmbyrro »

Zababa wrote: post #57
rmbyrro wrote: post #55

Earlier quoted context omitted.

The project I'm currently working uses AWS DynamoDB as primary DB. Since it's proprietary, we ensure the AWS-specific APIs are contained in small and specific part of the codebase. 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` mod…

That's interesting. Have you tested this with another DB? The design makes a lot of sense, but I feel like it's the kind of thing that's hard to get right unless you actually test it. At the company I currently work, they switched DB some time ago. They already used interfaces but even that was not enough to make the switch, due to some differences in how the DBs worked.

If you can map the differences in your code and your interface does not leak any implementation detail, you won't have problems.

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...

Re: Redis Stack

#65

Post by throwaway6532 »

pachico wrote: post #25

True, you can always run vanilla Redis. 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.

>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.

Re: Redis Stack

#66

Post by renonce »

The only thing I hate about Redis is that all data has to stay in memory...

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.

Re: Redis Stack

#67

Post by psychoslave »

burnished wrote: post #43
psychoslave wrote: post #37

Earlier quoted context omitted.

What is preventing you to contribute and create it?

Probably some combination of knowledge, experience, time and interest. Frankly it sounds like kind of an intimidating ask. Do you have special knowledge that makes this seem simple, or is it actually not challenging once you really get all the pieces involved? I'd love to be confident that I could see a statement like the one you replied to and immediately execute on it, so if you have any tips to share please do!

Well, to start, have you tried to send information in their issue tracker?

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.

Re: Redis Stack

#68

Post by burnished »

psychoslave wrote: post #67
burnished wrote: post #43

Earlier quoted context omitted.

Probably some combination of knowledge, experience, time and interest. Frankly it sounds like kind of an intimidating ask. Do you have special knowledge that makes this seem simple, or is it actually not challenging once you really get all the pieces involved? I'd love to be confident that I could see a statement like the one you replied to and immediately execute on it, so if you have any tips to share please do!

Well, to start, have you tried to send information in their issue tracker? 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.

Nope, I wasn't the top level comment.

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.

Re: Redis Stack

#69

Post by Zababa »

rmbyrro wrote: post #64
Zababa wrote: post #57

Earlier quoted context omitted.

That's interesting. Have you tested this with another DB? The design makes a lot of sense, but I feel like it's the kind of thing that's hard to get right unless you actually test it. At the company I currently work, they switched DB some time ago. They already used interfaces but even that was not enough to make the switch, due to some differences in how the DBs worked.

If you can map the differences in your code and your interface does not leak any implementation detail, you won't have problems. 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 databas…

Thanks, that "time-to-live" feature is a great exemple of what I was talking about. At work if I remember correctly it was something about not being able to read a write just after making it, and having to wait one second. I guess that's the kind of things where you either need people to be very careful when developing the implementation, or have people that have already been burned by that to think about that.
Post reply on HN