Technical Self-Reliance — Valkey

a lil plant

Before talking about Valkey, it might be worthy to talk about Redis. Redis was for a long time open-source used as the basis for NoSQL databases, specifically an in-memory key-value store. Due to a license change, it is no longer open-source. For those curious, there is an interesting YouTube video that talks about the lore behind the license transition of Redis.

Valkey has appeared as an alternative to Redis, being forked from the open source Redis project before the transition to the new licenses. Valkey is described as a high-performance data structure server that primary serves key/value workloads.

There is a lot that one can do with valkey. To get a quick working demo the primary focus will be on using valkey as a key-value (kv) store. Unlike most Technical Self-Reliance articles, this will focus a lot less on building the software but more on how to get a bit familiar with it. (Naturally, some attempt at building it will happen as well)

Helpful tip: If you ever get stuck with anything, search “how to do <task> on redis” instead. Due to the core being the same, one can get pretty far with using the Redis documentation.

Getting Valkey (via Docker)

docker pull valkey/valkey:7.2.6

One of the big reasons behind pulling the valkey container is to get all the valkey binaries all in one place. To take a further view into what comes from the Docker image, I ran the following:

docker run --network=host --rm -it valkey/valkey:7.2.6 /bin/bash

With some investigation I found some interesting things:

The valkey-* binaries can be found in the /usr/local/bin/ directory, using the ls command yielded the following:

root@zarka:/usr/local/bin# ls valkey* 
valkey-benchmark  valkey-check-aof  valkey-check-rdb
valkey-cli        valkey-sentinel   valkey-server

There is an *.spdx.json file for valkey in the /usr/local/ directory. This provides an SPDX-formatted SBOM for Valkey.

Server

docker run --network=host --rm -it valkey/valkey:7.2.6 --loglevel debug

Note, that --loglevel debug is not necessary. I prefer to get some more insight into what events are occurring from the server-side (at least until I get a better understanding without having to deep dive into code). The container will start the valkey-server binary and that will begin to listen on port 6379, looking for any potential commands to the server.

Client

The server running is great, but to instrument any changes (storing data to the in-memory kv store) a client is required. I wouldn’t want to have to re-create any protocols that valkey uses to do it’s operations. Luckily, I can just make use of valkey-cli to make raw query to the “database”:

docker run --network=host --rm -it valkey/valkey:7.2.6 valkey-cli

Quick valkey Primer:

Get Andres O’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

> — Signifies the start of the prompt, similar to $ or #

# to get help 
127.0.0.1:6379> help

# note, using the `help` command doesn't provide all the commands available.
# however, cycling using `help <TAB>` can prove to be insightful ;)

# Store a Key-Value (kv) Pair 
127.0.0.1:6379> SET key value
OK

# Load a kv pair
127.0.0.1:6379> GET key
"value"

# Check the Existence of a key
127.0.0.1:6379> EXISTS key
(integer) 1

# Get more documentation on a certain command (GET)
127.0.0.1:6379> COMMAND DOCS GET
1) "get"
2)  1) "summary"
    2) "Returns the string value of a key."
    3) "since"
    4) "1.0.0"
    5) "group"
    6) "string"
    7) "complexity"
    8) "O(1)"
    9) "arguments"
   10) 1) 1) "name"
          2) "key"
          3) "type"
          4) "key"
          5) "display_text"
          6) "key"
          7) "key_spec_index"
          8) (integer) 0

# To list the keys
127.0.0.1:6379> keys *
1) "key"
2) "key2"

# To delete keys
127.0.0.1:6379> del key2
(integer) 1

# Dump valkey Config
127.0.0.1:6379> CONFIG GET *
... # lots of data about the config of valkey

# Save (Snapshot kv store)
127.0.0.1:6379> SAVE
OK

# note that saving (using `SAVE` will store data on the server)
# if using containers, use the /bin/bash as an entrypoint and 
# manually start the valkey-server. Then you will be able to see
# a dump of the data
# by default the data will be save to /data/dump.rdb, but confirm
# from the config

Building

To get a build of the valkey server on Debian, try the following commands:

# The necessary build packages
apt-get install -y make git pkg-config clang gcc

# valkey specifics build packages
apt-get install -y tcl 
# tcl: for testing build

# Cloning the Git Repo (& changing directories)
git clone https://github.com/valkey-io/valkey.git
cd ./valkey

# Building from source
make
# for a faster build process: make -j$(nproc)

# Running into the jemalloc/jemalloc.h error?
make distclean

# To test build
make test

# To use the compiled binaries:
cd src/

# Run the binary of your choice
./valkey-*

References

• https://www.youtube.com/watch?v=S3LtOQDxCJk
• https://redis.io/blog/redis-adopts-dual-source-available-licensing/
• https://hub.docker.com/r/valkey/valkey
• https://github.com/valkey-io/valkey
• https://valkey.io/blog/valkey-8-0-0-rc1/
• https://www.linuxfoundation.org/press/linux-foundation-launches-open-source-valkey-community
• https://stackoverflow.com/questions/11180999/redis-dump-rdb-saving-small-files