[HN Gopher] K/V Benchmark: PostgreSQL vs. Redis vs. Memcached
       ___________________________________________________________________
        
       K/V Benchmark: PostgreSQL vs. Redis vs. Memcached
        
       Author : klaussilveira
       Score  : 22 points
       Date   : 2021-08-25 20:26 UTC (2 hours ago)
        
 (HTM) web link (www.cybertec-postgresql.com)
 (TXT) w3m dump (www.cybertec-postgresql.com)
        
       | mscdex wrote:
       | I wonder why such an old version of Redis was used in these
       | benchmarks? Redis 3.0.7 was released back in January 2016. The
       | current stable version as of this writing is 6.2.5.
       | 
       | EDIT: Additionally the version of memcached used in the
       | benchmarks was from July of 2012 -- even older!
        
         | bdibs wrote:
         | Well the site does seem to be some sort of PostgreSQL
         | consultancy.
        
         | mianos wrote:
         | In the "Other thoughts/notes" he acknowledges all of the tested
         | software was old. (And it being I/O bound). The whole thing is
         | more of "this is kind of interesting, you should do this test",
         | than hard facts. I'd do it myself today but I have a busy one.
        
           | mscdex wrote:
           | That doesn't answer the _why_ though. It just makes it seem
           | suspicious. How hard could it have been to use the latest
           | versions of the non-Postgres software? Even as a  "this is
           | kind of interesting" experiment it seems like you'd have to
           | go out of your way to install such old versions.
        
       | forrest2 wrote:
       | I would note that these rows have almost no content in them.
       | 
       | In my experience, your cache entries are usually gonna be a ton
       | of pre-serialized bytes or some json blobs -- which could be on
       | the order of kbs or mbs. That'll be where redis/memcached start
       | to really shine.
        
       | Lio wrote:
       | I wonder how Sqlite would fair, especially for the read test.
        
       | mdavidn wrote:
       | The measurement will be dominated by network IO time. Does the
       | driver wait for acknowledgement when writing? Does it wait for
       | each read before transmitting the next query? These details
       | matter.
       | 
       | Postgres reads might be so fast because the test script reads
       | keys in the order they were written. Postgres benefits from cache
       | locality, as the table file maintains that order.
        
         | merb wrote:
         | also the value data structure is way to beneficial for
         | postgres. the value should be a string and change in size and
         | if the value changes more table bloat is occured so that a
         | fillfactor might be a good idea. also most cache at least
         | support a ttl which might be even worse for postgres on the
         | query side since it needs to evaluate the expiration date on
         | the client side while redis supports that directly.
        
       ___________________________________________________________________
       (page generated 2021-08-25 23:01 UTC)