Redis internal representations - redis

Why do I get the result "raw" from the following?
redis 127.0.0.1:6379> set massage "hello"
OK
redis 127.0.0.1:6379> object encoding massage
"raw"
Does it have anything to do with?
#define REDIS_ENCODING_EMBSTR_SIZE_LIMIT 39

The 39 is to decide if to embed it or not. If you look at the exact piece of code where the define is it explains it all:
https://github.com/antirez/redis/blob/73a809b1591378e1042a1028d0b8e10217e6e7c7/src/object.c#L87
With regards to the raw that is the type for all what you call strings, if it is a valid number representation it is an Int.
Examples:
127.0.0.1:6379> set str "hello"
OK
127.0.0.1:6379> object encoding str
"raw"
127.0.0.1:6379> set int 1
OK
127.0.0.1:6379> object encoding int
"int"
127.0.0.1:6379> lpush list hello
(integer) 1
127.0.0.1:6379> object encoding list
"ziplist"
127.0.0.1:6379> zadd zset 1 1
(integer) 1
127.0.0.1:6379> object encoding zset
"ziplist"
127.0.0.1:6379> sadd set 1
(integer) 1
127.0.0.1:6379> object encoding set
"intset"
127.0.0.1:6379> hset hash field value
(integer) 1
127.0.0.1:6379> object encoding hash
"ziplist"
As you can can see this is how the object is represented internally to Redis.
If you want the actual type you could try the type command.
P.S. Please make your question more clear next time. It may also be worth adding references for where you have looked. You can not simply stumble across that define

Related

Redis inconsistency between bigkeys and llen

When I scan entire redis instance using redis-cli --bigkeys following shortened result is returned
-------- summary -------
Sampled 241145 keys in the keyspace!
Total key length in bytes is 13013217 (avg len 53.96)
Biggest string found 'celery-task-meta-52b14b66-b924-4c40-b7dc-7d5b9b633470' has 6510 bytes
**Biggest list found 'celery9' has 156519 items**
Biggest set found '_kombu.binding.celeryev' has 52 members
Biggest hash found 'unacked' has 544 fields
Biggest zset found 'unacked_index' has 550 members
As you can see my biggest list is celery9 with length 156519. I am using only one keyspace
127.0.0.1:6379> info keyspace
# Keyspace
db0:keys=256672,expires=256659,avg_ttl=1701804
But when I connect to redis instance using redis-cli or even with redis connector from python and run following commands
127.0.0.1:6379> get celery9
(nil)
127.0.0.1:6379> llen celery9
(integer) 0
127.0.0.1:6379>
nil or zero is returned as if there was no key celery9.
So the question is, how to get correct length of this key? All others keys are working perfectly

redis,set a value to 3,but its type is string

I use redis 6.2.4,in the redis-cli i input command:
127.0.0.1:6379> set k5 3
OK
127.0.0.1:6379> type k5
string
127.0.0.1:6379>
why the type of k5 is string but not number?
number is not a Redis (data) type.
I'm adding some links for your reference:
TYPE command
Redis data types in brief
Introduction to Redis data types
OBJECT ENCODING command may suit your need.
127.0.0.1:6379> set k5 3
OK
127.0.0.1:6379> OBJECT ENCODING k5
"int"

WRONGTYPE Operation against a key holding the wrong kind of value redis

When I directly run the below GET command in my redis cloud,
GET 1000:125:1603875000
I am getting error
WRONGTYPE Operation against a key holding the wrong kind of value redis
When I check
type 1000:125:1603875000
gives me
Hash
But if I execute SET before Get, like this
SET 1000:125:1603875000 11
I get "11" on executing GET command.
Why does the string is considered as Hash? How can I execute GET with the specified string.
That's because when you RUN 'SET 1000:125:1603875000' to 11, you are overwriting the initial '1000:125:1603875000' which was a hash and once you set '1000:125:1603875000' as '11' you can run a GET command to get the value of the key.
To get the value of a redis hash you can run HGETALL to get all the values in the hash or HGET KEYNAME to get a specific key of the hash.
To illustrate the use of these commands:
127.0.0.1:6379> HSET employee name Ankit
(integer) 1
127.0.0.1:6379> GET employee
(error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379> HGETALL employee
1) "name"
2) "Ankit"
127.0.0.1:6379> HGET employee name
"Ankit"
127.0.0.1:6379> SET employee Ankit
OK
127.0.0.1:6379> GET employee
"Ankit"
127.0.0.1:6379>

Redis sorted set wrong score

Let's try this.
redis 127.0.0.1:6379> zadd aaa 999999999999991.1 one
(integer) 0
redis 127.0.0.1:6379> zscore aaa one
"999999999999991.12"
redis 127.0.0.1:6379> zadd aaa 999999999999991.2 one
(integer) 0
redis 127.0.0.1:6379> zscore aaa one
"999999999999991.25"
Any solution?
Thanks.
Your redis is using IEEE 754 64-bit numbers.
When you try to represent 999999999999991.1 in a 64-bit floating-point register, the closest hex representation is 430c6bf52633ffb9. The exact decimal representation for that is 999999999999991.125 which your redis-cli is displaying as 999999999999991.12.
Similarly when you enter 999999999999991.2 the closest bit pattern found is 430c6bf52633ffba, which is exactly 999999999999991.25 -- which your redis-cli is able to show.
This loss-of-precision because of fixed register size shows up in nearly every system, Redis is no exception.

Copy a redis sorted set to a set

How do I copy a sorted set in redis to a regular, unsorted set? Is there a redis command that can do this? I can manually iterate through the sorted set and manually insert in the unsorted set, but it seems like there might be a better way to do this.
I don't think there is any command to do this directly.
But you can write simple lua script to do it on server instead downloading the sorted sets content to client and then pushing it back to new set.
Redis commands:
SCRIPT LOAD "for i,v in ipairs(redis.call('zrange', KEYS[1], 0, -1)) do redis.call('sadd', KEYS[2], v) end"
ZADD zset 1 first
ZADD zset 2 second
ZADD zset 3 third
EVALSHA dd1c22a22108d758b93c26eb92d1ef2933cec314 2 zset set
SMEMBERS set
Result:
"dd1c22a22108d758b93c26eb92d1ef2933cec314"
(integer) 0
(integer) 0
(integer) 0
(nil)
1) "second"
2) "first"
3) "third"
SCRIPT LOAD defines the script and returns its sha hash, EVALSHA than executes. Arguments are 2 to indicate that 2 key names follows, first is sorted set to copy from, second is set to copy to.