Valkey-ს მონაცემთა ტიპები: რომელი გამოიყენო და როდის

Valkey არ არის key-value საცავი "შეინახე ბლობი სახელით" გაგებით. ყოველი გასაღები ტიპიზებულ სტრუქტურას ინახავს, და ბრძანებები სტრუქტურაზე ადგილზე მუშაობს: გაზარდე hash-ის ველი, ჩადე list-ის ბოლოში, დაამატე წევრი set-ს, წაიკითხე sorted set-ის პირველი ათეული. სწორი ტიპის არჩევა დიზაინის სამუშაოს უმეტესი ნაწილია, რადგან ის წყვეტს, რამდენ round trip-ს მოითხოვს ფუნქცია, ატომურია თუ არა განახლება და რამდენ მეხსიერებას იყენებს მონაცემი.

მოკლე ვერსია: string-ები ცალკეული მნიშვნელობებისა და მთვლელებისთვის, hash-ები ობიექტებისთვის, list-ები რიგებისა და ბოლო ელემენტებისთვის, set-ები წევრობისა და უნიკალურობისთვის, sorted set-ები ყველაფრისთვის, რაც რეიტინგით ან დროით არის დალაგებული, stream-ები მოვლენების ლოგებისთვის. bitmap-ები, HyperLogLog და გეოსივრცული ინდექსები სამ სპეციალიზებულ საქმეს ძალიან იაფად ფარავს. პოსტის დანარჩენი ნაწილი თითოეულს გადის მნიშვნელოვანი ბრძანებებით, მეხსიერების ქცევით და შეცდომებით, რომლებიც სწრაფ სერვერს ნელად აქცევს.

როგორ ინახავს Valkey გასაღებს#

ყოველ გასაღებს აქვს სახელი, ერთი ტიპი და არასავალდებულო ვადა. არასწორი ტიპის მოთხოვნა შეცდომაა და არა გარდაქმნა:

SET page:views 10LPUSH page:views 1(error) WRONGTYPE Operation against a key holding the wrong kind of valueTYPE page:viewsstring

ვადა მთელ გასაღებს ეკუთვნის. ბოლო დრომდე hash-ის ერთი ველის ან set-ის ერთი წევრის ვადის დაყენება არ შეგეძლო; Valkey 9.0-მა hash-ებს თითო ველის ვადა დაუმატა (ქვემოთ განვიხილავთ), მაგრამ სხვა ტიპებს ვადა ისევ ერთიანად გასდის. ეს დიზაინის შეზღუდვაა, რომლის ადრე ცოდნაც ღირს: თუ ელემენტებს ინდივიდუალური სიცოცხლის ხანგრძლივობა სჭირდება, მათ ჩვეულებრივ ინდივიდუალური გასაღებები ან ვადის დროით შეწონილი sorted set სჭირდება.

გასაღებების სახელები თავისუფალი ფორმის სტრიქონებია. კონვენცია, რომელიც გასაღებთა სივრცეს სამართავს ხდის, არის ორწერტილით გამოყოფილი სეგმენტები ზოგადიდან კონკრეტულისკენ - app:user:4182:profile - ვერსიის სეგმენტით იქ, სადაც მნიშვნელობის ფორმა შეიძლება შეიცვალოს. გრძელი სახელები ყოველ გასაღებზე მეხსიერებას ხარჯავს, ამიტომ app:u:4182 გამართლებულია, როცა ათეულობით მილიონი გაქვს; აპლიკაციების უმეტესობისთვის წაკითხვადობა იგებს.

ორი ბრძანება გეუბნება, რა არის გასაღები სინამდვილეში და რა ღირს:

OBJECT ENCODING user:4182"listpack"MEMORY USAGE user:4182(integer) 120

encoding-ს მნიშვნელობა აქვს, რადგან პატარა კოლექციები კომპაქტური ფორმით ინახება - listpack ან intset - რომელიც ზოგადი ფორმის მეხსიერების მცირე ნაწილს იყენებს. Valkey ზოგად ფორმაზე ავტომატურად გადადის, როცა კოლექცია ზომის ზღვარს გადაკვეთს. ამაზე მეტი მეხსიერების სექციაშია.

String-ები და მთვლელები#

საბაზისო ტიპი, სახელის მიუხედავად, ბინარულად უსაფრთხო ბაიტების თანმიმდევრობაა 512 MB-მდე. ის ინახავს ტექსტს, JSON-ს, სერიალიზებულ ობიექტებს, სურათებსაც, თუ დაჟინებით გინდა, და მთელ ან წილად რიცხვებს, რომლებზეც სერვერს არითმეტიკის გაკეთება შეუძლია.

SET NX-ითა და EX-ით მარტივი lock-ისა და იდემპოტენტურობის დამცავების საფუძველია: "მხოლოდ პირველი მოთხოვნა ამ id-ით გრძელდება". INCR მთვლელებისა და rate limit-ების საფუძველია (rate limiting Valkey-ით მასზე აგებს). ქეშირებისთვის string სერიალიზებული JSON-ით ნაგულისხმევი არჩევანია და ჩვეულებრივ სწორიც; Valkey-ს ქეშირების ნიმუშები TTL-ებსა და ინვალიდაციას განიხილავს.

გავრცელებული შეცდომაა დიდი JSON დოკუმენტის string-ად შენახვა და შემდეგ მთლიანად გადაწერა ერთი ველის შესაცვლელად. თუ ობიექტის ნაწილებს დამოუკიდებლად ანახლებ, ის hash უნდა იყოს.

Hash-ები ობიექტებისთვის#

hash არის ველების რუკა string მნიშვნელობებზე ერთი გასაღების ქვეშ - ბუნებრივი ფორმა მომხმარებლის ჩანაწერისთვის, სესიისთვის, პროდუქტისთვის, კონფიგურაციის ბლოკისთვის.

HSET user:4182 name "Nino" plan "pro" logins 17HGET user:4182 planHINCRBY user:4182 logins 1HMGET user:4182 name planHGETALL user:4182HDEL user:4182 plan

ყოველი ველის წაკითხვა და განახლება დამოუკიდებლად შეიძლება, HINCRBY ატომურია თითო ველზე, და პატარა hash-ები ძალიან კომპაქტურად ინახება. ბევრი პატარა hash Valkey-ში ობიექტური მონაცემების შენახვის ერთ-ერთი ყველაზე მეხსიერებაეფექტური გზაა.

hash-ის მნიშვნელობები ბრტყელი string-ებია. ჩადგმული მონაცემები ან სერიალიზებული JSON-ის სახით ერთ ველში მიდის, ან ბრტყელდება ველების სახელებად, როგორიცაა address.city. თუ ჩადგმული დოკუმენტების შიგნით მოთხოვნები გჭირდება, შენ დოკუმენტურ ბაზას აღწერ და არა hash-ს - იხილე რომელი ბაზა გამოიყენო.

Valkey 9.0-მა hash-ის ცალკეული ველების ვადა დაამატა: ბრძანებები, როგორიცაა HSETEX, HGETEX, HEXPIRE, HTTL და HPERSIST, ერთ ველზე TTL-ს აყენებს, კითხულობს და ასუფთავებს. ეს ერთ hash-ს გამოსადეგს ხდის ისეთი რამისთვის, როგორიცაა მოწყობილობების token-ების ნაკრები, რომელთაგან თითოეულს ვადა თავისით გასდის. სანამ ამას დაეყრდნობი, შეამოწმე სერვერის ვერსია INFO server-ით (Valkey აბრუნებს valkey_version ველს redis_version-თან ერთად, რომელიც კლიენტებთან თავსებადობისთვის რჩება) და ზუსტი სინტაქსი ბრძანებების ცნობარში - ძველი სერვერები უცნობი ბრძანების შეცდომას აბრუნებენ.

List-ები რიგებისა და ბოლო ელემენტებისთვის#

list არის string-ების დალაგებული თანმიმდევრობა სწრაფი ოპერაციებით ორივე ბოლოში.

LPUSH events:recent "login 4182"LTRIM events:recent 0 99LRANGE events:recent 0 9RPUSH jobs '{"task":"email","user":4182}'BLMOVE jobs jobs:processing LEFT RIGHT 5

ნებისმიერ ბოლოში ჩადება და ამოღება მუდმივი დროისაა. გრძელი list-ის შუიდან ინდექსით წაკითხვა - არა: LINDEX და LSET list-ს გადიან. ორი გავრცელებული გამოყენება ამ ფორმას ერგება:

• შეზღუდული ბოლო ელემენტების list. LPUSH და შემდეგ LTRIM 0 99 უახლეს ას ელემენტს ინახავს, pipeline-ით ერთ round trip-ში. აქტივობის ლენტები, ბოლო ვიზიტების ლოგები, ბოლო ძიებები.
• მარტივი რიგი. producer-ები RPUSH-ს აკეთებენ, მომხმარებლები ბლოკავენ BLPOP-ზე ან, უკეთესი, BLMOVE-ზე, რომელიც ელემენტს ატომურად გადაიტანს დამუშავების list-ში, რომ ჩავარდნილმა მომხმარებელმა ის არ დაკარგოს. ეს ის საფუძველია, რაზეც RQ-ის მსგავსი ბიბლიოთეკები აგებენ; სერიოზული რამისთვის ბიბლიოთეკა გამოიყენე - ამოცანების რიგები Valkey-ით მათ ფარავს.

ნუ გამოიყენებ list-ს წევრობის შესამოწმებლად ("არის 4182 ამ list-ში?") - ეს წრფივი სკანირებაა. ამისთვის არის set-ები.

Set-ები და sorted set-ები#

set არის უნიკალური string-ების დაულაგებელი კოლექცია.

SADD online:users 4182 5530 7781SISMEMBER online:users 4182SCARD online:usersSINTER tags:valkey tags:tutorialSRANDMEMBER giveaway:entrants 3

დამატება და წევრობის შემოწმება მუდმივი დროისაა, დუბლიკატები კი აგებულებითვე შეუძლებელია. გამოყენებები: ონლაინ მომხმარებლები, თეგები, "ამ მომხმარებელმა უკვე მისცა ხმა?", crawl-ის დუბლიკატების მოშორება, უნიკალური ვიზიტორები, როცა ზუსტ რაოდენობას აქვს მნიშვნელობა და რიცხვები პატარაა. SINTER, SUNION და SDIFF სიმრავლეთა ალგებრას სერვერზე ითვლის, რაც აჯობებს ორი სიის აპლიკაციაში გადმოტანას.

sorted set ყოველ უნიკალურ წევრს მცურავმძიმიან ქულას აძლევს და წევრებს მის მიხედვით დალაგებულს ინახავს. ეს Valkey-ს ყველაზე მრავალმხრივი ტიპია.

ZADD leaderboard 3120 "nino" 2875 "giorgi" 4010 "ana"ZINCRBY leaderboard 50 "giorgi"ZRANGE leaderboard 0 9 REV WITHSCORESZREVRANK leaderboard "nino"ZRANGE delayed 0 1791468000000 BYSCORE LIMIT 0 100ZREMRANGEBYSCORE sessions:active 0 1791460000000

დამატება, წაშლა და რანგის ძიება ლოგარითმულია; დიაპაზონის წაკითხვა ლოგარითმულია პლუს დიაპაზონის ზომა. sorted set-ები უმკლავდება:

• ლიდერბორდებსა და რეიტინგებს, სადაც ZINCRBY და ZREVRANK ზუსტად საჭირო ოპერაციებია.
• დროით დალაგებულ ინდექსებს, დროის ნიშნულით როგორც ქულით: "ამოცანები, რომელთა დრო ახლამდე დგება", "სესიები, უმოქმედო ერთი საათის წინანდელი დროიდან", "ბოლო დღის პოსტები".
• დაყოვნებულ ამოცანებსა და დაგეგმვას, იგივე რამ მეორე მხრიდან დანახული.
• sliding-window rate limit-ებს, ყოველი მოთხოვნის დროის ჩაწერით.
• მეორად ინდექსებს, რომლებსაც თვითონ მართავ: "პროდუქტები ფასის მიხედვით" როგორც პროდუქტების id-ების sorted set, შეწონილი ფასით.

დიდი ბრძანებები გახსოვდეს. SMEMBERS და ZRANGE 0 -1 მილიონწევრიან set-ზე მილიონ წევრს ერთი ბლოკირებადი გამოძახებით აბრუნებს; გამოიყენე SSCAN და ZSCAN, ან შეზღუდული დიაპაზონები.

Stream-ები, bitmap-ები, HyperLogLog და გეოსივრცული#

stream-ები მხოლოდ დამატებადი ლოგია id-ებით, consumer group-ებითა და დადასტურებებით - pub/sub-ის მდგრადი ალტერნატივა. მათ საკმარისი სიღრმე აქვთ საკუთარი პოსტისთვის: Valkey pub/sub და streams.

bitmap-ები ცალკე ტიპი არ არის, არამედ string-ის ბრძანებებია, რომლებიც string-ს ბიტების მასივად განიხილავს.

SETBIT active:2026-10-08 4182 1GETBIT active:2026-10-08 4182BITCOUNT active:2026-10-08BITOP AND active:both active:2026-10-07 active:2026-10-08

მომხმარებლების რიცხვითი id-ებით როგორც offset-ებით, ერთი ბიტი თითო მომხმარებელზე იწერს "აქტიური დღეს". მილიონი მომხმარებელი დღეში დაახლოებით 125 KB ჯდება, ხოლო BITOP პასუხობს "აქტიური ორივე დღეს"-ს აპლიკაციასთან შეხების გარეშე. მახე ისაა, რომ string ყველაზე მაღალი offset-ის სიგრძისაა: ერთი მომხმარებელი id-ით 4,000,000,000 500 MB-ს გამოყოფს. bitmap-ები მხოლოდ მჭიდრო, პატარა მთელი რიცხვის id-ებით გამოიყენე.

HyperLogLog აფასებს განსხვავებული ელემენტების რაოდენობას მნიშვნელობების ნაკადში, გასაღებზე მაქსიმუმ დაახლოებით 12 KB-ის გამოყენებით, 0.81 პროცენტიანი სტანდარტული ცდომილებით.

PFADD visitors:2026-10-08 "203.0.113.5" "198.51.100.7"PFCOUNT visitors:2026-10-08PFMERGE visitors:week visitors:2026-10-02 visitors:2026-10-08

უნიკალური ვიზიტორები, უნიკალური საძიებო ტერმინები, განსხვავებული მოწყობილობები - ყველგან, სადაც მიახლოებითი რაოდენობა საკმარისია და ყოველი მნიშვნელობის შენახვა ზედმეტი იქნებოდა. წევრების უკან ჩამოთვლა არ შეგიძლია; ის მხოლოდ ითვლის.

გეოსივრცული ინდექსები sorted set-ებია, რომელთა ქულაში კოორდინატებია კოდირებული.

GEOADD stores 44.7930 41.7151 "tbilisi-1" 13.4050 52.5200 "berlin-1"GEOSEARCH stores FROMLONLAT 44.80 41.71 BYRADIUS 5 km ASC COUNT 5 WITHDISTGEODIST stores "tbilisi-1" "berlin-1" km

შეამჩნიე თანმიმდევრობა: ჯერ გრძედი, შემდეგ განედი. თუ აურევ, შენი თბილისის მაღაზია ინდოეთის ოკეანეში აღმოჩნდება.

ზოგი რამ, რასაც ხალხი ელოდება, Valkey-ს ბირთვის ნაწილი არ არის: JSON დოკუმენტები path მოთხოვნებით, სრულტექსტოვანი ძიება, Bloom ფილტრები და დროითი მწკრივები მოდულებიდან მოდის, და სერვერს, რომელზეც ეს მოდულები ჩატვირთული არ არის, ეს ბრძანებები არ აქვს. ნუ დააპროექტებ მათზე დაყრდნობით, სანამ არ დაადასტურებ, რომ ისინი იმ სერვერზე არსებობს, რომელსაც გამოიყენებ - MODULE LIST აჩვენებს, რა არის ჩატვირთული, თუ შენს მომხმარებელს მისი გაშვების უფლება აქვს.

მეხსიერება, encoding-ები და დიდი გასაღებები#

ყოველ გასაღებს ზედნადები აქვს - გასაღების სახელი, შიდა ობიექტის თავსართი, ვადის ჩანაწერი, თუ დაყენებულია - დაახლოებით ბაიტების ათეულები მნიშვნელობამდე. ამიტომ მილიონი პაწაწინა გასაღები პაწაწინა მონაცემთა ნაკრები არ არის. დაკავშირებული პატარა მნიშვნელობების ერთ hash-ში დაჯგუფება ხშირად მეხსიერებას ორჯერ ამცირებს, რადგან პატარა hash კომპაქტური listpack-ის სახით ინახება.

ზღვრები კონფიგურაციის პარამეტრებია (hash-max-listpack-entries, hash-max-listpack-value, set-max-intset-entries, set-max-listpack-entries, zset-max-listpack-entries და დანარჩენი). მათ მიღმა სტრუქტურა ზოგად ფორმაზე გადადის, რომელიც დიდი კოლექციებისთვის უფრო სწრაფია და ელემენტზე შესამჩნევად მეტ მეხსიერებას იყენებს. ნაგულისხმევების შეცვლა იშვიათად გჭირდება; ის კი უნდა იცოდე, რომ OBJECT ENCODING ხსნის, რატომ არის ერთი hash მეორეზე ათჯერ დიდი.

უფრო დიდი ოპერაციული რისკი დიდი გასაღებია: ერთი კოლექცია მილიონობით წევრით, ან ერთი string ასობით მეგაბაიტით. მისი წაშლა DEL-ით სერვერს ბლოკავს, სანამ მეხსიერებას ათავისუფლებს (გამოიყენე UNLINK, რომელიც ფონზე ათავისუფლებს). მისი მთლიანად წაკითხვა სერვერს ბლოკავს და ქსელს ავსებს. იპოვე ისინი:

$ valkey-cli -h 203.0.113.20 -p 6380 --askpass --bigkeys$ valkey-cli -h 203.0.113.20 -p 6380 --askpass --memkeys

ორივე გასაღებთა სივრცეს SCAN-ით ამოწმებს შერჩევით, ამიტომ ცოცხალ სერვერზე უსაფრთხოა. Valkey-ს მეხსიერება და eviction პოლიტიკები ფარავს, რა ხდება, როცა მეხსიერება ამოიწურება.

RE:NODE-ზე Valkey გეგმები 256 MB-დან 4 GB-მდე მეხსიერებით მუშაობს, და სწორედ ამ რიცხვზე უნდა შეარჩიო ზომა: ზემოთ ყველაფერი RAM-ში ცხოვრობს, დისკი კი AOF-ისა და snapshot-ის ასლებს ინახავს.

ტიპის არჩევა: გარჩეული მაგალითი#

პატარა გეიმინგ საზოგადოების საიტს სურს: მოთამაშეების პროფილები, კვირის ლიდერბორდი, "ვინ არის ონლაინ", ბოლო ორმოცდაათი მოვლენის ლენტა, დღიური აქტიური მოთამაშეების რაოდენობა და ჩატში თითო მოთამაშის rate limit-ები.

აქ ორი არჩევანის შემჩნევა ღირს. "ახლა ონლაინ" set-ის ნაცვლად sorted set-ს იყენებს, რადგან set-ს არ შეუძლია წევრების მოშორება, რომლებმაც heartbeat-ების გაგზავნა შეწყვიტეს - დროით შეწონილ sorted set-ს კი შეუძლია, ერთი ბრძანებით. ლიდერბორდი კი ყოველ კვირას ახალ გასაღებს იღებს TTL-ით, ამიტომ წინა კვირის ცხრილი წაკითხვადი რჩება, სანამ ვადა არ გაუვა, და კვირა დღეს შუაღამისას ქულების განულება არაფერს სჭირდება.

რამდენიმე ტიპის ერთდროულად განახლება

ნამდვილი ფუნქციები ერთზე მეტ გასაღებს ეხება. როცა მოთამაშე მატჩს ამთავრებს, საიტი ზრდის მის ქულას ლიდერბორდში, ზრდის ველს მის პროფილში და ლენტაში მოვლენას ჩადებს. ამის გაგზავნის სამი გზა, სხვადასხვა გარანტიით:

• pipeline სამივე ბრძანებას ერთი ქსელური round trip-ით აგზავნის და პასუხებს ერთად კითხულობს. ეს ყველაზე იაფი ვარიანტია და სწორი ნაგულისხმევი, როცა ბრძანებები ერთმანეთზე არ არის დამოკიდებული. ის ატომური არ არის: სხვა კლიენტის ბრძანება შეიძლება მათ შორის შესრულდეს.
• `MULTI` და `EXEC` ბრძანებებს რიგში აყენებს და ერთ შეუწყვეტელ ბლოკად უშვებს. შუაში სხვა არაფერი სრულდება. თუმცა rollback არ არის - თუ ერთი ბრძანება ჩავარდა, მაგალითად WRONGTYPE შეცდომით, დანარჩენები მაინც სრულდება.
• Lua სკრიპტი ატომურად სრულდება და შეუძლია განშტოება იმის მიხედვით, რასაც კითხულობს: "დაამატე ლიდერბორდში მხოლოდ მაშინ, თუ მატჩის id ჯერ არ არის ჩაწერილი". გამოიყენე, როცა გადაწყვეტილება მიმდინარე მნიშვნელობებზეა დამოკიდებული.

MULTIZINCRBY lb:2026-w41 120 "nino"HINCRBY p:4182 matches 1LPUSH feed "nino won on Dust"LTRIM feed 0 49EXEC

WATCH MULTI-ს ოპტიმისტურ locking-ს უმატებს: დააკვირდი გასაღებს, წაიკითხე, და თუ ვინმე შენს EXEC-მდე შეცვლის, ტრანზაქცია უქმდება და თავიდან ცდი. ეს მუშაობს, მაგრამ კონკურენციის პირობებში მოკლე Lua სკრიპტი ჩვეულებრივ უფრო მარტივია. მთვლელებისა და ლიდერბორდებისთვის ცალკეული ბრძანებები, როგორიცაა INCR და ZINCRBY, უკვე თავისთავად ატომურია, და ეს არის მთავარი მიზეზი, აირჩიო ტიპი, რომელშიც საჭირო ოპერაცია ჩაშენებულია.

FAQ#

შემიძლია JSON-ის შენახვა Valkey-ში?

კი, string-ის სახით, და ეს ჩვეულებრივი გზაა. მთელ დოკუმენტს კითხულობ და წერ. თუ ცალკეულ ველებს ხშირად ანახლებ, ამის ნაცვლად hash გამოიყენე. JSON-ში path მოთხოვნებს JSON მოდული სჭირდება, რომელიც Valkey-ს ბირთვის ნაწილი არ არის.

რა არის მნიშვნელობის მაქსიმალური ზომა?

string შეიძლება იყოს 512 MB-მდე, ხოლო კოლექციას პრინციპში მილიარდობით ელემენტის დატევა შეუძლია. პრაქტიკაში მნიშვნელობები პატარა შეინახე: ყველაფერი რამდენიმე მეგაბაიტზე მეტი ნელა გადაიცემა და სერვერს ბლოკავს, სანამ იკითხება ან იწერება.

Hash თუ ბევრი string გასაღები?

რამდენიმე ველიანი ობიექტისთვის - hash: ერთი გასაღების ზედნადები, კომპაქტური encoding და ველების ატომური განახლებები. ცალკე string გასაღებები სწორია, როცა ყოველ მნიშვნელობას საკუთარი TTL სჭირდება, სერვერებზე, სადაც hash-ის თითო ველის ვადა არ არის.

რატომ დაბლოკა ბრძანებამ მთელი სერვერი?

ბრძანებები სათითაოდ სრულდება, ამიტომ ძვირი ბრძანება - KEYS, SMEMBERS უზარმაზარ set-ზე, DEL უზარმაზარ გასაღებზე, ZRANGE 0 -1 დიდ sorted set-ზე - ყველა სხვა კლიენტს ალოდინებს. გამოიყენე SCAN-ის ოჯახი და შეზღუდული დიაპაზონები, და UNLINK DEL-ის ნაცვლად.

string-ებად შენახული რიცხვები მეტ მეხსიერებას იყენებს?

მთელი რიცხვის მნიშვნელობები კომპაქტური მთელი რიცხვის ფორმით ინახება, ამიტომ SET counter 12345 თვითონ გასაღებზე ოდნავ მეტი ჯდება. წილადი რიცხვები და რიცხვები წამყვანი ნულებით ტექსტად ინახება.