[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)