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

Redis explained

architecturenotes.co

Post reply on HN
Print view View original

61–70 of 104 posts

Re: Redis explained

#61

Post by jasonwatkinspdx »

darkcha0s wrote: post #17
theden wrote: post #13

This is great, the visual explanations work really well One thing that threw me off is that it says for an SSD a random read is 150μs, but 1MB sequential read is 1ms? Shouldn't sequential reads be faster, or are two different read sizes being compared or something? If so, the ambiguity may confuse some people to think random reads are faster

Well I'm guessing that it's referring to the fact that 1MB sequential is essentially a bunch of random reads? AFAIK, on SSD's there is no concept/guarantee that blocks are adjacent, so a sequential read is just a bunch of random reads.

The way the Flash Translation Layer works is complicated, but long story short, there's still an advantage to sequential reads and writes on SSDs. The difference in latency and throughput isn't as dramatic as with spinning disks, but is still there. Random vs sequential writes have big implications for the long term health and performance of the SSD.

Re: Redis explained

#62

Post by witnesser »

The only person stand out to witness a use case is a adserverer, I read the 1st 100lines of comments. It is like california highway system particularly when I witnessed, the billboard is very outstanding. The jams an pits, people are very nice to them.

Re: Redis explained

#63

Post by witnesser »

witnesser wrote: post #62

The only person stand out to witness a use case is a adserverer, I read the 1st 100lines of comments. It is like california highway system particularly when I witnessed, the billboard is very outstanding. The jams an pits, people are very nice to them.

The above is just random comment. So I have a long time question, how cache miss is handled.

Re: Redis explained

#64

Post by jbboehr »

btilly wrote: post #33
koolba wrote: post #30

Earlier quoted context omitted.

> One of those limits is that you really, really, really don't want to go outside of RAM. Think about what is stored, and be sure not to waste space. (It is surprisingly easy to leak memory.) You can have massive amounts of RAM these days. You’re sooner to hit big-O limits from bad architectural decisions than run out of memory. If you do get to that point you likely have enough value in your usage to justify scaling…

You can have massive amounts of RAM these days. You’re sooner to hit big-O limits from bad architectural decisions than run out of memory. If you do get to that point you likely have enough value in your usage to justify scaling out further and sharding. Absolute disagreement. It is very easily to accidentally leak a few hundred MB per week in a busy Redis system. The code will look and work fine...at first. It is co…

You can also "leak" rows in a traditional RDBMS or even a filesystem. Why is this particular notable for Redis?

Re: Redis explained

#65

Post by cerved »

avmich wrote: post #58
jrm4 wrote: post #51

As someone who doesn't code for a living but teaches it to mostly novices, this helps (because before this I had no clue what it was except that it had something to do with databases.) Typically for my courses we just use some flavor of SQL and call it a day (and that kind of spoils us because of how declarative it tends to be) -- roughly, what's the "explain like I'm 10" use case for Redis over something else? From…

Relational databases are optimized for typical operations over data structured in tables. So, joins and records. However sometime you want something simpler - like LIFO queue - and wouldn't mind to have is faster. Redis allows to have this - the variety of data structures it has is much bigger than with relational databases. They (Redis and RDBs) both have their uses, of course. Ideally you would structure your syste…

What data structures?

Re: Redis explained

#66

Post by detaro »

cerved wrote: post #65
avmich wrote: post #58

Earlier quoted context omitted.

Relational databases are optimized for typical operations over data structured in tables. So, joins and records. However sometime you want something simpler - like LIFO queue - and wouldn't mind to have is faster. Redis allows to have this - the variety of data structures it has is much bigger than with relational databases. They (Redis and RDBs) both have their uses, of course. Ideally you would structure your syste…

What data structures?

https://redis.io/docs/data-types/

Re: Redis explained

#67

Post by rfrey »

A question so noob I'm almost shy to ask it:

The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Re: Redis explained

#68

Post by louissm_it »

rfrey wrote: post #67

A question so noob I'm almost shy to ask it: The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Storing the data directly inside the application still means you need to store it somewhere, likely a SQL database (such as PostgreSQL). These databases are insanely well engineered and very very fast, but compared to a key value store such as Redis and Memchached they are comparatively slow and resource hungry (because they are optimized for different things).

So if you can fetch some cached data from a Redis key, even if on the same machine, it will cost you significantly less than querying a relational database.

Re: Redis explained

#69

Post by halukakin »

rfrey wrote: post #67

A question so noob I'm almost shy to ask it: The simplest scenario in the article is a single Redis instance residing on the same machine as the application. What's the benefit to this versus just storing data directly within the application?

Not all applications can store data out of the box. For instance some ways of PHP have embedded caches, some others don't have cache by default and you would need to install cache software (for instance apcu). Also, redis has many different types of data. For instance coding something similar to its "hash" data type is not trivial.

Re: Redis explained

#70

Post by itake »

tomnipotent wrote: post #54
itake wrote: post #43

Earlier quoted context omitted.

> You can have massive amounts of RAM these days. True, but I am finding that balancing CPU and RAM can be tricky. Slapping 128GB on a 1-core machine means you quickly have CPU limitations.

Redis is single-threaded and will have no problem saturating a 10G NIC with a single socket.

My concern is how fast it takes a CPU to scan through all of that memory.
Post reply on HN