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

In-memory database Redis wants to dabble in disk

theregister.com

Post reply on HN
Print view View original

21–30 of 63 posts

Re: In-memory database Redis wants to dabble in disk

#21

Post by rezonant »

Xeoncross wrote: post #20
whalesalad wrote: post #11

> One main criticism of Redis had been its lack of support for SQL, the ubiquitous query language. Trollope said that was fixed now. A module RediSQL is available on GitHub. I think redisql has been supplanted by zeesql - https://zeesql.com/

I don't understand this. How can you want SQL for something that you are using because it's faster than SQL? If your dataset fits in memory and you want relations then just use PostgreSQL/MySQL. Why would you pick the unique data structures and performance of redis sets/lists/pubsub/HLL and want SQL in front of it?

because it's web scale

Re: In-memory database Redis wants to dabble in disk

#22

Post by chokolad »

lmm wrote: post #19
super_scooper wrote: post #15

Earlier quoted context omitted.

>You’d be surprised what people want! If what you want is persistent k/v, then there are already tons databases that can do that. Redis has a different use case, so what are you trying to say? That you want to misuse tools?

> If what you want is persistent k/v, then there are already tons databases that can do that. Are there? What's a good, mainstream, persistent k/v for cheap single-node instances? PostgreSQL's KV support isn't good enough, Cassandra and MongoDB expect to be set up as a cluster and have all the overhead of that, BikeshedDB is alpha and I won't touch their upstream for obvious reasons, CouchDB is pretty much unmaintain…

How about LMDB ? It’s single writer/multiple reader, very fast and reliable.

Re: In-memory database Redis wants to dabble in disk

#23

Post by lmm »

chokolad wrote: post #22
lmm wrote: post #19

Earlier quoted context omitted.

> If what you want is persistent k/v, then there are already tons databases that can do that. Are there? What's a good, mainstream, persistent k/v for cheap single-node instances? PostgreSQL's KV support isn't good enough, Cassandra and MongoDB expect to be set up as a cluster and have all the overhead of that, BikeshedDB is alpha and I won't touch their upstream for obvious reasons, CouchDB is pretty much unmaintain…

How about LMDB ? It’s single writer/multiple reader, very fast and reliable.

This thread is my first time hearing of it, it doesn't seem particularly established/mature (e.g. I can't find cloud services offering managed instances, whereas there are plenty of those for Redis)

Re: In-memory database Redis wants to dabble in disk

#24

Post by [deleted] »

mrinterweb wrote: post #10

I was confused because I know Redis already offers persistence. https://redis.io/docs/management/persistence/ The main difference here is how its runtime will shift from runtime data only in RAM to not storing as much data in RAM and looking up on disk. Current Redis persistence looks like the runtime is stored in RAM and changes are periodically or append only persisted to disk. I hope I got that right.

[deleted]

Re: In-memory database Redis wants to dabble in disk

#26

Post by djbusby »

Xeoncross wrote: post #20
whalesalad wrote: post #11

> One main criticism of Redis had been its lack of support for SQL, the ubiquitous query language. Trollope said that was fixed now. A module RediSQL is available on GitHub. I think redisql has been supplanted by zeesql - https://zeesql.com/

I don't understand this. How can you want SQL for something that you are using because it's faster than SQL? If your dataset fits in memory and you want relations then just use PostgreSQL/MySQL. Why would you pick the unique data structures and performance of redis sets/lists/pubsub/HLL and want SQL in front of it?

Memory only sqlite is a (rad) thing. Redis for KV things but one can have a shared, multi GB sqlite thing when you want fast sql things.

Re: In-memory database Redis wants to dabble in disk

#27

Post by MenhirMike »

rezonant wrote: post #21
Xeoncross wrote: post #20

Earlier quoted context omitted.

I don't understand this. How can you want SQL for something that you are using because it's faster than SQL? If your dataset fits in memory and you want relations then just use PostgreSQL/MySQL. Why would you pick the unique data structures and performance of redis sets/lists/pubsub/HLL and want SQL in front of it?

because it's web scale

No, that's MongoDB. (Not as webscale as /dev/null though)

Re: In-memory database Redis wants to dabble in disk

#29

Post by b112 »

SteveNuts wrote: post #14
karmakaze wrote: post #3

They mention both flash and disk, which finally gets explained as tiers 2 and 3. Also less clear though I assume this applies to their hosted service offering and not the core software. > "We can take the lesser-used data that hasn't been touched in a while and shuttle it off to flash where it can sit for a while. When the user comes back eventually, it's very easy for us to seamlessly move it from flash back into me…

I would like at least two more tiers: S3, and an LTO tape drive.

What about the stenographer tier? A simple terminal, a little transcription, and I bet we'd keep restore delay down under a few seconds + 5 minute file lookup of stored paperwork.
Post reply on HN