Posts on KeyValueStore.com

Consistent Hashing Playground: Modulo Hashing Moves 83% of Keys When a Server Joins, Jump Hash 17%

Mon, 05 Oct 2026 00:00:00 +0000

Five cache servers share 100,000 keys. Traffic grows, and you add a sixth. With the obvious rule, hash the key and divide by the number of servers, 83% of the keys now belong somewhere else. Most of them move between servers that never changed. For a cache that’s a wave of misses landing on the database at once. For a store it’s a mountain of data copied across the network for no reason.

Hash Slot Calculator Shows the Redis or Valkey Cluster Slot for Any Key and Catches CROSSSLOT Errors

Mon, 05 Oct 2026 00:00:00 +0000

Code that ran fine against a single Redis or Valkey server often breaks the day it moves to a cluster. An MGET, a MULTI block or a Lua script that touched three keys now gets CROSSSLOT Keys in request don't hash to the same slot, because in a cluster those keys live on different servers.

The Hash Slot Calculator shows where keys land before that happens. Type a key and you get its slot and the primary that holds it, with the hashed part of the key marked. Paste a command and it tells you whether a cluster would run it. Paste a whole key list and it shows how the keys spread across your primaries, the busiest slots and the hash tags in use.

Keyspace Map Shows What a Redis or Valkey Keyspace Holds, From a Plain SCAN Key List

Mon, 05 Oct 2026 00:00:00 +0000

A key-value store has no tables and no schema to read. Everything sits in one flat list of keys, and the only structure is whatever people built into the names. After a few years and a few teams, the honest answer to “what’s in our Redis?” is often a shrug.

The Keyspace Map reads that structure back out of the names. Paste the output of redis-cli --scan or valkey-cli --scan, and a long key list becomes a short list of patterns with counts. In one test, 9,161 keys came down to 13 lines, led by user:<id>:profile with 3,000 keys, user:<id>:settings with 2,000 and session:<hex> with 1,500. The same keys show as a tree of prefixes you can open level by level, with how many bytes the key names take.

Mass Insert Builder Turns CSV and JSON Into a Bulk-Load File for Redis and Valkey

Mon, 05 Oct 2026 00:00:00 +0000

The slow way to load a million keys into Redis or Valkey is a loop that sends a command, waits for the answer, and sends the next. Most of the time goes on the waiting. At half a millisecond per round trip, a million commands take more than eight minutes before the server has done anything hard.

redis-cli --pipe and valkey-cli --pipe skip the wait. They stream commands as fast as the connection takes them, read the replies as they arrive, and end with a count: errors: 0, replies: 1000000. The catch is that they want their input already in the Redis protocol, where every value is preceded by its length in bytes. The Mass Insert Builder writes that file for you.

Snapshot Viewer Opens Redis and Valkey RDB Snapshots in the Browser, From Redis 2.8 to Valkey 9.1

Mon, 05 Oct 2026 00:00:00 +0000

A Redis server is using 40 GB and nobody is sure what’s in it. The usual tools all ask the server itself. --bigkeys scans every key, MEMORY USAGE asks about one key at a time, and a script over SCAN adds its own load to a machine that’s already the busiest in the building.

There’s a copy of the same data that answers those questions for free: the snapshot. The Snapshot Viewer opens a dump.rdb in your browser and shows the keys by type and database, the biggest keys, the prefixes that take the most space, how long expiring keys have left, and the value of any key you pick.

Traffic Analyzer Turns Redis and Valkey MONITOR Output Into a Cache Hit-Rate Curve That Matched a Real Server

Mon, 05 Oct 2026 00:00:00 +0000

A Redis server is running hot and the question is what with. INFO commandstats counts commands but can’t say which keys or which clients. The slow log only keeps the slow ones. MONITOR shows everything, every command with its keys and the address that sent it, but at 30,000 lines a second nobody reads it.

The Traffic Analyzer reads a MONITOR capture in your browser and adds it up: commands per second, the command mix, reads against writes, the busiest keys and key patterns, which clients send what, how the keys would spread over a cluster, commands worth a second look, and how many keys a cache would need to hold.

Typed JSON Converter Turns DynamoDB JSON Into Plain JSON and Back Without Losing a Digit

Mon, 05 Oct 2026 00:00:00 +0000

Ask DynamoDB for an item and you get every value wrapped in its type: {"name": {"S": "Ana"}, "visits": {"N": "17"}}. It’s exact, and it’s a pain to read, to diff, or to hand to anything that expects normal JSON. Going the other way is worse, because writing typed JSON by hand for a test item or a quick fix is slow and easy to get wrong.

The Typed JSON Converter does both directions. Paste the output of aws dynamodb scan and get a clean list of items. Paste plain JSON and get typed JSON ready for put-item, or a set of batch-write-item requests, 25 items each. It works out the direction on its own, and it reads the shapes the AWS tools print: Scan and Query output, GetItem and BatchGetItem results, exports to S3 in DynamoDB JSON, and DynamoDB Streams records as a Lambda function receives them.

Value Inspector Decodes Pickles, Java Objects and PHP Sessions From Redis and Valkey Without Running Them

Mon, 05 Oct 2026 00:00:00 +0000

Someone runs GET session:42 on a production Redis server to see why a user is stuck, and gets back "\xac\xed\x00\x05sr\x00\x11java.util.HashMap\x05\a\xda\xc1...". The data is all there. It’s in Java’s serialization format, behind redis-cli’s escapes, and nobody reads that by eye.

The Value Inspector does. Paste a value the way redis-cli printed it, or as hex, base64 or plain text, and it works out the format and decodes it: JSON, MessagePack, CBOR, BSON, Protocol Buffers, PHP sessions and igbinary, Java serialization, Python pickles and Ruby Marshal, inside base64, gzip, zlib, LZ4 or Snappy.

What Is a Key-Value Store? Redis, Valkey, DynamoDB and etcd Explained

Mon, 05 Oct 2026 00:00:00 +0000

A key-value store files every value under a key. You hand it a key and a value to keep, and later you hand it the key and get the value back. That’s the whole contract. Think of a coat check: you get a ticket, and the ticket is all anyone needs to find your coat. Nobody goes through the coats looking for a blue one.

That simple contract is why key-value stores are fast. Finding a value by its key is a direct jump, through a hash table or a sorted tree, with no query to plan and no tables to join. It’s also why they spread so well over many machines: if every request names its key, the key alone says which machine to ask.