hubot-redis-brain icon indicating copy to clipboard operation
hubot-redis-brain copied to clipboard

Hash versus giant string?

Open johnseekins-pathccm opened this issue 4 months ago • 8 comments

Someone has written an MIT-licensed Redis brain that uses hget/hset commands for adding removing data from the brain. Is it worth exploring this more broadly for the main Redis brain? I think it would make a horizontally scalable Hubot backed by Redis possible?

johnseekins-pathccm avatar Feb 20 '24 17:02 johnseekins-pathccm

Yes. I think so because this one just stores everything in a single JSON document and saves that document to Redis. That large granularity has scaling and usage limits.

@johnseekins-pathccm do you have a current use case? Or were you just thinking about possible use cases for the future?

joeyguerra avatar Feb 20 '24 17:02 joeyguerra

I mean...I'd like our deploys of Hubot to not require downtime. Which using this brain does require. Also, I think it would address issues like #39 .

johnseekins-pathccm avatar Feb 20 '24 17:02 johnseekins-pathccm

Can you elaborate on what's causing the downtime?

joeyguerra avatar Feb 20 '24 17:02 joeyguerra

My understanding is we can only have one instance of Hubot running at a time (because the brain reads/writes a string, which can overwrite values between two instances). Thus, we tear down the old instance before starting the new one.

johnseekins-pathccm avatar Feb 20 '24 17:02 johnseekins-pathccm

I'm speculating here ... I think the problem with > 1 instances of Hubot is that in the "save to Redis" scenario, the last write wins. Which could result in data loss, multiple instances writing at the same time. Both of the hubot-redis implementations have this problem. I think it's a design problem with the Hubot Brain. It assumes that there's just 1 instance of Hubot and that all data is kept in memory. I believe that was the intent.

joeyguerra avatar Feb 20 '24 18:02 joeyguerra

In that case, I guess we leave this be as there's no real difference. Other than some scenarios have slightly improved read/write speed. Which isn't enough of an argument.

johnseekins-pathccm avatar Feb 20 '24 18:02 johnseekins-pathccm

I'm fine with keeping this issue open just in case others want to chime in. I'm interested in redesigning the Brain to accommodate multiple Hubot instances. And I'd also like to redesign the Hubot-redis design to not use JSON, but leverage some of Redis' data structures instead.

joeyguerra avatar Feb 20 '24 19:02 joeyguerra

I'd love to see Hubot actually able to run more than one instance. If it's just the internal API for the brain causing the issues, that seems solvable. I'm no javascript guy, but if I can help, I'm happy to try.

johnseekins-pathccm avatar Feb 21 '24 17:02 johnseekins-pathccm