redis-server 0.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- data/LICENSE +38 -0
- data/README.md +33 -0
- data/bin/redis +114 -0
- data/redis/Makefile +5 -0
- data/redis/extconf.rb +3 -0
- data/redis/redis-2.2.11/00-RELEASENOTES +199 -0
- data/redis/redis-2.2.11/BUGS +1 -0
- data/redis/redis-2.2.11/CONTRIBUTING +13 -0
- data/redis/redis-2.2.11/COPYING +10 -0
- data/redis/redis-2.2.11/Changelog +1032 -0
- data/redis/redis-2.2.11/INSTALL +30 -0
- data/redis/redis-2.2.11/Makefile +22 -0
- data/redis/redis-2.2.11/README +83 -0
- data/redis/redis-2.2.11/TODO +4 -0
- data/redis/redis-2.2.11/client-libraries/README +11 -0
- data/redis/redis-2.2.11/deps/hiredis/COPYING +10 -0
- data/redis/redis-2.2.11/deps/hiredis/Makefile +115 -0
- data/redis/redis-2.2.11/deps/hiredis/README.md +311 -0
- data/redis/redis-2.2.11/deps/hiredis/TODO +2 -0
- data/redis/redis-2.2.11/deps/hiredis/adapters/ae.h +95 -0
- data/redis/redis-2.2.11/deps/hiredis/adapters/libev.h +113 -0
- data/redis/redis-2.2.11/deps/hiredis/adapters/libevent.h +76 -0
- data/redis/redis-2.2.11/deps/hiredis/async.c +321 -0
- data/redis/redis-2.2.11/deps/hiredis/async.h +112 -0
- data/redis/redis-2.2.11/deps/hiredis/example-ae.c +53 -0
- data/redis/redis-2.2.11/deps/hiredis/example-libev.c +47 -0
- data/redis/redis-2.2.11/deps/hiredis/example-libevent.c +48 -0
- data/redis/redis-2.2.11/deps/hiredis/example.c +67 -0
- data/redis/redis-2.2.11/deps/hiredis/fmacros.h +15 -0
- data/redis/redis-2.2.11/deps/hiredis/hiredis.c +1058 -0
- data/redis/redis-2.2.11/deps/hiredis/hiredis.h +170 -0
- data/redis/redis-2.2.11/deps/hiredis/net.c +170 -0
- data/redis/redis-2.2.11/deps/hiredis/net.h +43 -0
- data/redis/redis-2.2.11/deps/hiredis/sds.c +479 -0
- data/redis/redis-2.2.11/deps/hiredis/sds.h +77 -0
- data/redis/redis-2.2.11/deps/hiredis/test.c +479 -0
- data/redis/redis-2.2.11/deps/hiredis/util.h +40 -0
- data/redis/redis-2.2.11/deps/linenoise/Makefile +10 -0
- data/redis/redis-2.2.11/deps/linenoise/README.markdown +45 -0
- data/redis/redis-2.2.11/deps/linenoise/example.c +27 -0
- data/redis/redis-2.2.11/deps/linenoise/linenoise.c +609 -0
- data/redis/redis-2.2.11/deps/linenoise/linenoise.h +55 -0
- data/redis/redis-2.2.11/design-documents/REDIS-CLUSTER +214 -0
- data/redis/redis-2.2.11/design-documents/REDIS-CLUSTER-2 +343 -0
- data/redis/redis-2.2.11/doc/AppendCommand.html +48 -0
- data/redis/redis-2.2.11/doc/AppendOnlyFileHowto.html +41 -0
- data/redis/redis-2.2.11/doc/AuthCommand.html +39 -0
- data/redis/redis-2.2.11/doc/Benchmarks.html +129 -0
- data/redis/redis-2.2.11/doc/BgrewriteaofCommand.html +41 -0
- data/redis/redis-2.2.11/doc/BgsaveCommand.html +39 -0
- data/redis/redis-2.2.11/doc/BlpopCommand.html +51 -0
- data/redis/redis-2.2.11/doc/BrpoplpushCommand.html +39 -0
- data/redis/redis-2.2.11/doc/CommandReference.html +47 -0
- data/redis/redis-2.2.11/doc/Comparisons.html +42 -0
- data/redis/redis-2.2.11/doc/ConfigCommand.html +76 -0
- data/redis/redis-2.2.11/doc/Configuration.html +38 -0
- data/redis/redis-2.2.11/doc/ConnectionHandlingSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/ControlCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/Credits.html +38 -0
- data/redis/redis-2.2.11/doc/DbsizeCommand.html +38 -0
- data/redis/redis-2.2.11/doc/DelCommand.html +41 -0
- data/redis/redis-2.2.11/doc/DesignPatterns.html +37 -0
- data/redis/redis-2.2.11/doc/EventLibray.html +44 -0
- data/redis/redis-2.2.11/doc/ExistsCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ExpireCommand.html +96 -0
- data/redis/redis-2.2.11/doc/FAQ.html +70 -0
- data/redis/redis-2.2.11/doc/Features.html +38 -0
- data/redis/redis-2.2.11/doc/FlushallCommand.html +39 -0
- data/redis/redis-2.2.11/doc/FlushdbCommand.html +39 -0
- data/redis/redis-2.2.11/doc/FromSqlToDataStructures.html +37 -0
- data/redis/redis-2.2.11/doc/GenericCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/GetCommand.html +39 -0
- data/redis/redis-2.2.11/doc/GetbitCommand.html +39 -0
- data/redis/redis-2.2.11/doc/GetsetCommand.html +38 -0
- data/redis/redis-2.2.11/doc/HackingStrings.html +83 -0
- data/redis/redis-2.2.11/doc/HashCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/Hashes.html +37 -0
- data/redis/redis-2.2.11/doc/HdelCommand.html +39 -0
- data/redis/redis-2.2.11/doc/HexistsCommand.html +39 -0
- data/redis/redis-2.2.11/doc/HgetCommand.html +39 -0
- data/redis/redis-2.2.11/doc/HgetallCommand.html +40 -0
- data/redis/redis-2.2.11/doc/HincrbyCommand.html +45 -0
- data/redis/redis-2.2.11/doc/HlenCommand.html +38 -0
- data/redis/redis-2.2.11/doc/HmgetCommand.html +40 -0
- data/redis/redis-2.2.11/doc/HmsetCommand.html +40 -0
- data/redis/redis-2.2.11/doc/HsetCommand.html +40 -0
- data/redis/redis-2.2.11/doc/HsetnxCommand.html +41 -0
- data/redis/redis-2.2.11/doc/IncrCommand.html +43 -0
- data/redis/redis-2.2.11/doc/InfoCommand.html +48 -0
- data/redis/redis-2.2.11/doc/IntroductionToRedisDataTypes.html +152 -0
- data/redis/redis-2.2.11/doc/KeysCommand.html +43 -0
- data/redis/redis-2.2.11/doc/LastsaveCommand.html +39 -0
- data/redis/redis-2.2.11/doc/LindexCommand.html +40 -0
- data/redis/redis-2.2.11/doc/ListCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/Lists.html +42 -0
- data/redis/redis-2.2.11/doc/LlenCommand.html +41 -0
- data/redis/redis-2.2.11/doc/LpopCommand.html +41 -0
- data/redis/redis-2.2.11/doc/LrangeCommand.html +47 -0
- data/redis/redis-2.2.11/doc/LremCommand.html +41 -0
- data/redis/redis-2.2.11/doc/LsetCommand.html +38 -0
- data/redis/redis-2.2.11/doc/LtrimCommand.html +47 -0
- data/redis/redis-2.2.11/doc/MgetCommand.html +52 -0
- data/redis/redis-2.2.11/doc/MonitorCommand.html +63 -0
- data/redis/redis-2.2.11/doc/MoveCommand.html +42 -0
- data/redis/redis-2.2.11/doc/MsetCommand.html +44 -0
- data/redis/redis-2.2.11/doc/MultiExecCommand.html +166 -0
- data/redis/redis-2.2.11/doc/NonexistentCommands.html +51 -0
- data/redis/redis-2.2.11/doc/ObjectHashMappers.html +39 -0
- data/redis/redis-2.2.11/doc/Pipelining.html +36 -0
- data/redis/redis-2.2.11/doc/ProgrammingExamples.html +38 -0
- data/redis/redis-2.2.11/doc/ProtocolSpecification.html +137 -0
- data/redis/redis-2.2.11/doc/PublishSubscribe.html +115 -0
- data/redis/redis-2.2.11/doc/QuickStart.html +68 -0
- data/redis/redis-2.2.11/doc/QuitCommand.html +38 -0
- data/redis/redis-2.2.11/doc/README.html +119 -0
- data/redis/redis-2.2.11/doc/RandomkeyCommand.html +39 -0
- data/redis/redis-2.2.11/doc/Redis0100ChangeLog.html +67 -0
- data/redis/redis-2.2.11/doc/Redis0900ChangeLog.html +56 -0
- data/redis/redis-2.2.11/doc/RedisBigData.html +61 -0
- data/redis/redis-2.2.11/doc/RedisCLI.html +37 -0
- data/redis/redis-2.2.11/doc/RedisEventLibrary.html +70 -0
- data/redis/redis-2.2.11/doc/RedisGuides.html +37 -0
- data/redis/redis-2.2.11/doc/RedisInternals.html +38 -0
- data/redis/redis-2.2.11/doc/RedisPipelining.html +93 -0
- data/redis/redis-2.2.11/doc/RedisStatus.html +56 -0
- data/redis/redis-2.2.11/doc/Redis_1_2_0_Changelog.html +40 -0
- data/redis/redis-2.2.11/doc/Redis_2_0_0_Changelog.html +62 -0
- data/redis/redis-2.2.11/doc/Redis_2_0_Whats_new.html +59 -0
- data/redis/redis-2.2.11/doc/RenameCommand.html +39 -0
- data/redis/redis-2.2.11/doc/RenamenxCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ReplicationHowto.html +43 -0
- data/redis/redis-2.2.11/doc/ReplyTypes.html +42 -0
- data/redis/redis-2.2.11/doc/RoadMap.html +38 -0
- data/redis/redis-2.2.11/doc/RpoplpushCommand.html +44 -0
- data/redis/redis-2.2.11/doc/RpushCommand.html +40 -0
- data/redis/redis-2.2.11/doc/SaddCommand.html +41 -0
- data/redis/redis-2.2.11/doc/SaveCommand.html +39 -0
- data/redis/redis-2.2.11/doc/ScardCommand.html +41 -0
- data/redis/redis-2.2.11/doc/SdiffCommand.html +45 -0
- data/redis/redis-2.2.11/doc/SdiffstoreCommand.html +38 -0
- data/redis/redis-2.2.11/doc/SelectCommand.html +39 -0
- data/redis/redis-2.2.11/doc/SetCommand.html +39 -0
- data/redis/redis-2.2.11/doc/SetCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/SetbitCommand.html +45 -0
- data/redis/redis-2.2.11/doc/SetexCommand.html +42 -0
- data/redis/redis-2.2.11/doc/SetnxCommand.html +51 -0
- data/redis/redis-2.2.11/doc/SetrangeCommand.html +58 -0
- data/redis/redis-2.2.11/doc/Sets.html +36 -0
- data/redis/redis-2.2.11/doc/ShutdownCommand.html +39 -0
- data/redis/redis-2.2.11/doc/SideBar.html +36 -0
- data/redis/redis-2.2.11/doc/SinterCommand.html +40 -0
- data/redis/redis-2.2.11/doc/SinterstoreCommand.html +39 -0
- data/redis/redis-2.2.11/doc/SismemberCommand.html +42 -0
- data/redis/redis-2.2.11/doc/SlaveofCommand.html +41 -0
- data/redis/redis-2.2.11/doc/SmembersCommand.html +38 -0
- data/redis/redis-2.2.11/doc/SmoveCommand.html +44 -0
- data/redis/redis-2.2.11/doc/SortCommand.html +75 -0
- data/redis/redis-2.2.11/doc/SortedSetCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/SortedSets.html +36 -0
- data/redis/redis-2.2.11/doc/Speed.html +38 -0
- data/redis/redis-2.2.11/doc/SponsorshipHistory.html +38 -0
- data/redis/redis-2.2.11/doc/SpopCommand.html +40 -0
- data/redis/redis-2.2.11/doc/SrandmemberCommand.html +40 -0
- data/redis/redis-2.2.11/doc/SremCommand.html +42 -0
- data/redis/redis-2.2.11/doc/StringCommandsSidebar.html +36 -0
- data/redis/redis-2.2.11/doc/Strings.html +37 -0
- data/redis/redis-2.2.11/doc/StrlenCommand.html +39 -0
- data/redis/redis-2.2.11/doc/SubstrCommand.html +52 -0
- data/redis/redis-2.2.11/doc/SunionCommand.html +40 -0
- data/redis/redis-2.2.11/doc/SunionstoreCommand.html +38 -0
- data/redis/redis-2.2.11/doc/SupportedLanguages.html +60 -0
- data/redis/redis-2.2.11/doc/SupportedPlatforms.html +37 -0
- data/redis/redis-2.2.11/doc/TemplateCommand.html +38 -0
- data/redis/redis-2.2.11/doc/TtlCommand.html +38 -0
- data/redis/redis-2.2.11/doc/TwitterAlikeExample.html +250 -0
- data/redis/redis-2.2.11/doc/TypeCommand.html +46 -0
- data/redis/redis-2.2.11/doc/UnstableSource.html +39 -0
- data/redis/redis-2.2.11/doc/VirtualMemorySpecification.html +156 -0
- data/redis/redis-2.2.11/doc/VirtualMemoryUserGuide.html +66 -0
- data/redis/redis-2.2.11/doc/ZaddCommand.html +43 -0
- data/redis/redis-2.2.11/doc/ZcardCommand.html +41 -0
- data/redis/redis-2.2.11/doc/ZincrbyCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ZrangeCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ZrangebyscoreCommand.html +77 -0
- data/redis/redis-2.2.11/doc/ZrankCommand.html +43 -0
- data/redis/redis-2.2.11/doc/ZremCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ZremrangebyrankCommand.html +39 -0
- data/redis/redis-2.2.11/doc/ZremrangebyscoreCommand.html +39 -0
- data/redis/redis-2.2.11/doc/ZscoreCommand.html +41 -0
- data/redis/redis-2.2.11/doc/ZunionCommand.html +42 -0
- data/redis/redis-2.2.11/doc/ZunionstoreCommand.html +43 -0
- data/redis/redis-2.2.11/doc/index.html +43 -0
- data/redis/redis-2.2.11/doc/redis.png +0 -0
- data/redis/redis-2.2.11/doc/style.css +25 -0
- data/redis/redis-2.2.11/redis.conf +417 -0
- data/redis/redis-2.2.11/src/Makefile +177 -0
- data/redis/redis-2.2.11/src/adlist.c +325 -0
- data/redis/redis-2.2.11/src/adlist.h +92 -0
- data/redis/redis-2.2.11/src/ae.c +390 -0
- data/redis/redis-2.2.11/src/ae.h +117 -0
- data/redis/redis-2.2.11/src/ae_epoll.c +91 -0
- data/redis/redis-2.2.11/src/ae_kqueue.c +93 -0
- data/redis/redis-2.2.11/src/ae_select.c +72 -0
- data/redis/redis-2.2.11/src/anet.c +347 -0
- data/redis/redis-2.2.11/src/anet.h +57 -0
- data/redis/redis-2.2.11/src/aof.c +675 -0
- data/redis/redis-2.2.11/src/config.c +627 -0
- data/redis/redis-2.2.11/src/config.h +64 -0
- data/redis/redis-2.2.11/src/db.c +543 -0
- data/redis/redis-2.2.11/src/debug.c +314 -0
- data/redis/redis-2.2.11/src/dict.c +721 -0
- data/redis/redis-2.2.11/src/dict.h +156 -0
- data/redis/redis-2.2.11/src/fmacros.h +15 -0
- data/redis/redis-2.2.11/src/help.h +638 -0
- data/redis/redis-2.2.11/src/intset.c +422 -0
- data/redis/redis-2.2.11/src/intset.h +19 -0
- data/redis/redis-2.2.11/src/lzf.h +100 -0
- data/redis/redis-2.2.11/src/lzfP.h +159 -0
- data/redis/redis-2.2.11/src/lzf_c.c +295 -0
- data/redis/redis-2.2.11/src/lzf_d.c +150 -0
- data/redis/redis-2.2.11/src/mkreleasehdr.sh +9 -0
- data/redis/redis-2.2.11/src/multi.c +268 -0
- data/redis/redis-2.2.11/src/networking.c +899 -0
- data/redis/redis-2.2.11/src/object.c +484 -0
- data/redis/redis-2.2.11/src/pqsort.c +197 -0
- data/redis/redis-2.2.11/src/pqsort.h +15 -0
- data/redis/redis-2.2.11/src/pubsub.c +267 -0
- data/redis/redis-2.2.11/src/rdb.c +1020 -0
- data/redis/redis-2.2.11/src/redis-benchmark.c +530 -0
- data/redis/redis-2.2.11/src/redis-check-aof.c +185 -0
- data/redis/redis-2.2.11/src/redis-check-dump.c +681 -0
- data/redis/redis-2.2.11/src/redis-cli.c +773 -0
- data/redis/redis-2.2.11/src/redis.c +1677 -0
- data/redis/redis-2.2.11/src/redis.h +1022 -0
- data/redis/redis-2.2.11/src/release.c +13 -0
- data/redis/redis-2.2.11/src/replication.c +557 -0
- data/redis/redis-2.2.11/src/sds.c +639 -0
- data/redis/redis-2.2.11/src/sds.h +78 -0
- data/redis/redis-2.2.11/src/sha1.c +276 -0
- data/redis/redis-2.2.11/src/sha1.h +17 -0
- data/redis/redis-2.2.11/src/solarisfixes.h +22 -0
- data/redis/redis-2.2.11/src/sort.c +389 -0
- data/redis/redis-2.2.11/src/syncio.c +154 -0
- data/redis/redis-2.2.11/src/t_hash.c +476 -0
- data/redis/redis-2.2.11/src/t_list.c +986 -0
- data/redis/redis-2.2.11/src/t_set.c +610 -0
- data/redis/redis-2.2.11/src/t_string.c +438 -0
- data/redis/redis-2.2.11/src/t_zset.c +1084 -0
- data/redis/redis-2.2.11/src/testhelp.h +54 -0
- data/redis/redis-2.2.11/src/util.c +243 -0
- data/redis/redis-2.2.11/src/valgrind.sup +5 -0
- data/redis/redis-2.2.11/src/version.h +1 -0
- data/redis/redis-2.2.11/src/vm.c +1149 -0
- data/redis/redis-2.2.11/src/ziplist.c +1323 -0
- data/redis/redis-2.2.11/src/ziplist.h +15 -0
- data/redis/redis-2.2.11/src/zipmap.c +455 -0
- data/redis/redis-2.2.11/src/zipmap.h +48 -0
- data/redis/redis-2.2.11/src/zmalloc.c +278 -0
- data/redis/redis-2.2.11/src/zmalloc.h +47 -0
- data/redis/redis-2.2.11/tests/assets/default.conf +308 -0
- data/redis/redis-2.2.11/tests/integration/aof.tcl +104 -0
- data/redis/redis-2.2.11/tests/integration/redis-cli.tcl +208 -0
- data/redis/redis-2.2.11/tests/integration/replication.tcl +98 -0
- data/redis/redis-2.2.11/tests/support/redis.tcl +241 -0
- data/redis/redis-2.2.11/tests/support/server.tcl +294 -0
- data/redis/redis-2.2.11/tests/support/test.tcl +190 -0
- data/redis/redis-2.2.11/tests/support/tmpfile.tcl +15 -0
- data/redis/redis-2.2.11/tests/support/util.tcl +296 -0
- data/redis/redis-2.2.11/tests/test_helper.tcl +221 -0
- data/redis/redis-2.2.11/tests/unit/auth.tcl +15 -0
- data/redis/redis-2.2.11/tests/unit/basic.tcl +616 -0
- data/redis/redis-2.2.11/tests/unit/cas.tcl +135 -0
- data/redis/redis-2.2.11/tests/unit/expire.tcl +74 -0
- data/redis/redis-2.2.11/tests/unit/other.tcl +240 -0
- data/redis/redis-2.2.11/tests/unit/printver.tcl +6 -0
- data/redis/redis-2.2.11/tests/unit/protocol.tcl +62 -0
- data/redis/redis-2.2.11/tests/unit/pubsub.tcl +195 -0
- data/redis/redis-2.2.11/tests/unit/quit.tcl +40 -0
- data/redis/redis-2.2.11/tests/unit/sort.tcl +189 -0
- data/redis/redis-2.2.11/tests/unit/type/hash.tcl +300 -0
- data/redis/redis-2.2.11/tests/unit/type/list.tcl +819 -0
- data/redis/redis-2.2.11/tests/unit/type/set.tcl +334 -0
- data/redis/redis-2.2.11/tests/unit/type/zset.tcl +587 -0
- data/redis/redis-2.2.11/utils/build-static-symbols.tcl +22 -0
- data/redis/redis-2.2.11/utils/generate-command-help.rb +112 -0
- data/redis/redis-2.2.11/utils/mktarball.sh +13 -0
- data/redis/redis-2.2.11/utils/redis-copy.rb +78 -0
- data/redis/redis-2.2.11/utils/redis-sha1.rb +52 -0
- data/redis/redis-2.2.11/utils/redis_init_script +42 -0
- metadata +362 -0
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>TypeCommand: Contents</b><br> <a href="#TYPE _key_">TYPE _key_</a><br> <a href="#Return value">Return value</a><br> <a href="#See also">See also</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">TypeCommand</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="GenericCommandsSidebar.html">GenericCommandsSidebar</a><h1><a name="TYPE _key_">TYPE _key_</a></h1>
|
|
30
|
+
<i>Time complexity: O(1)</i><blockquote>Return the type of the value stored at <i>key</i> in form of astring. The type can be one of "none", "string", "list", "set"."none" is returned if the key does not exist.</blockquote>
|
|
31
|
+
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Status code reply</a>, specifically:<br/><br/><pre class="codeblock python" name="code">
|
|
32
|
+
"none" if the key does not exist
|
|
33
|
+
"string" if the key contains a String value
|
|
34
|
+
"list" if the key contains a List value
|
|
35
|
+
"set" if the key contains a Set value
|
|
36
|
+
"zset" if the key contains a Sorted Set value
|
|
37
|
+
"hash" if the key contains a Hash value
|
|
38
|
+
</pre><h2><a name="See also">See also</a></h2>
|
|
39
|
+
<ul><li> <a href="DataTypes.html">Redis Data Types</a></li></ul>
|
|
40
|
+
</div>
|
|
41
|
+
|
|
42
|
+
</div>
|
|
43
|
+
</div>
|
|
44
|
+
</body>
|
|
45
|
+
</html>
|
|
46
|
+
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>UnstableSource: Contents</b><br> <a href="#Get the latest Redis source code">Get the latest Redis source code</a><br> <a href="#Unstable code">Unstable code</a><br> <a href="#Stable code">Stable code</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">UnstableSource</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
<h1><a name="Get the latest Redis source code">Get the latest Redis source code</a></h1><h2><a name="Unstable code">Unstable code</a></h2>
|
|
30
|
+
The development version of Redis is <a href="http://github.com/antirez/redis/tree/master" target="_blank">hosted here at Github</a>, have fun cloning the source code with Git. If you are not familar with Git just use the <b>download</b> button to get a tarball.<h2><a name="Stable code">Stable code</a></h2>
|
|
31
|
+
<b>Warning:</b> the development source code is only intended for people that want to develop Redis or absolutely need the latest features still not available on the stable releases. You may have a better experience with the <a href="http://code.google.com/p/redis/downloads/list" target="_blank">latest stable tarball</a>.
|
|
32
|
+
|
|
33
|
+
</div>
|
|
34
|
+
|
|
35
|
+
</div>
|
|
36
|
+
</div>
|
|
37
|
+
</body>
|
|
38
|
+
</html>
|
|
39
|
+
|
|
@@ -0,0 +1,156 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>VirtualMemorySpecification: Contents</b><br> <a href="#Virtual Memory technical specification">Virtual Memory technical specification</a><br> <a href="#Keys vs Values: what is swapped out?">Keys vs Values: what is swapped out?</a><br> <a href="#How does a swapped value looks like internally">How does a swapped value looks like internally</a><br> <a href="#The Swap File">The Swap File</a><br> <a href="#Transfering objects from memory to swap">Transfering objects from memory to swap</a><br> <a href="#Loading objects back in memory">Loading objects back in memory</a><br> <a href="#How blocking VM works">How blocking VM works</a><br> <a href="#Blocking VM swapping">Blocking VM swapping</a><br> <a href="#What values to swap when we are out of memory?">What values to swap when we are out of memory?</a><br> <a href="#Blocking VM loading">Blocking VM loading</a><br> <a href="#Background saving when VM is active">Background saving when VM is active</a><br> <a href="#The problem with the blocking VM">The problem with the blocking VM</a><br> <a href="#Threaded VM">Threaded VM</a><br> <a href="#I/O Threads">I/O Threads</a><br> <a href="#Non blocking VM as probabilistic enhancement of blocking VM">Non blocking VM as probabilistic enhancement of blocking VM</a><br> <a href="#Blocking clients on swapped keys">Blocking clients on swapped keys</a><br> <a href="#Aborting I/O jobs">Aborting I/O jobs</a><br> <a href="#Questions?">Questions?</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">VirtualMemorySpecification</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="RedisInternals.html">RedisInternals</a><h1><a name="Virtual Memory technical specification">Virtual Memory technical specification</a></h1>This document details the internals of the Redis Virtual Memory subsystem. The intended audience is not the final user but programmers willing to understand or modify the Virtual Memory implementation.<h2><a name="Keys vs Values: what is swapped out?">Keys vs Values: what is swapped out?</a></h2>
|
|
30
|
+
The goal of the VM subsystem is to free memory transferring Redis Objects from memory to disk. This is a very generic command, but specifically, Redis transfers only objects associated with <i>values</i>. In order to understand better this concept we'll show, using the DEBUG command, how a key holding a value looks from the point of view of the Redis internals:
|
|
31
|
+
<pre class="codeblock python" name="code">
|
|
32
|
+
redis> set foo bar
|
|
33
|
+
OK
|
|
34
|
+
redis> debug object foo
|
|
35
|
+
Key at:0x100101d00 refcount:1, value at:0x100101ce0 refcount:1 encoding:raw serializedlength:4
|
|
36
|
+
</pre>
|
|
37
|
+
As you can see from the above output, the Redis top level hash table maps Redis Objects (keys) to other Redis Objects (values). The Virtual Memory is only able to swap <i>values</i> on disk, the objects associated to <i>keys</i> are always taken in memory: this trade off guarantees very good lookup performances, as one of the main design goals of the Redis VM is to have performances similar to Redis with VM disabled when the part of the dataset frequently used fits in RAM.<h2><a name="How does a swapped value looks like internally">How does a swapped value looks like internally</a></h2>
|
|
38
|
+
When an object is swapped out, this is what happens in the hash table entry:
|
|
39
|
+
<ul><li> The key continues to hold a Redis Object representing the key.</li><li> The value is set to NULL</li></ul>So you may wonder where we store the information that a given value (associated to a given key) was swapped out. Just in the key object!<br/><br/>This is how the Redis Object structure <i>robj</i> looks like:
|
|
40
|
+
<pre class="codeblock python python" name="code">
|
|
41
|
+
/* The actual Redis Object */
|
|
42
|
+
typedef struct redisObject {
|
|
43
|
+
void *ptr;
|
|
44
|
+
unsigned char type;
|
|
45
|
+
unsigned char encoding;
|
|
46
|
+
unsigned char storage; /* If this object is a key, where is the value?
|
|
47
|
+
* REDIS_VM_MEMORY, REDIS_VM_SWAPPED, ... */
|
|
48
|
+
unsigned char vtype; /* If this object is a key, and value is swapped out,
|
|
49
|
+
* this is the type of the swapped out object. */
|
|
50
|
+
int refcount;
|
|
51
|
+
/* VM fields, this are only allocated if VM is active, otherwise the
|
|
52
|
+
* object allocation function will just allocate
|
|
53
|
+
* sizeof(redisObjct) minus sizeof(redisObjectVM), so using
|
|
54
|
+
* Redis without VM active will not have any overhead. */
|
|
55
|
+
struct redisObjectVM vm;
|
|
56
|
+
} robj;
|
|
57
|
+
</pre>
|
|
58
|
+
As you can see there are a few fields about VM. The most important one is <i>storage</i>, that can be one of this values:
|
|
59
|
+
<ul><li> REDIS_VM_MEMORY: the associated value is in memory.</li><li> REDIS_VM_SWAPPED: the associated values is swapped, and the value entry of the hash table is just set to NULL.</li><li> REDIS_VM_LOADING: the value is swapped on disk, the entry is NULL, but there is a job to load the object from the swap to the memory (this field is only used when threaded VM is active).</li><li> REDIS_VM_SWAPPING: the value is in memory, the entry is a pointer to the actual Redis Object, but there is an I/O job in order to transfer this value to the swap file.</li></ul>If an object is swapped on disk (REDIS_VM_SWAPPED or REDIS_VM_LOADING), how do we know where it is stored, what type it is, and so forth? That's simple: the <i>vtype</i> field is set to the original type of the Redis object swapped, while the <i>vm</i> field (that is a <i>redisObjectVM</i> structure) holds information about the location of the object. This is the definition of this additional structure:
|
|
60
|
+
<pre class="codeblock python python python" name="code">
|
|
61
|
+
/* The VM object structure */
|
|
62
|
+
struct redisObjectVM {
|
|
63
|
+
off_t page; /* the page at which the object is stored on disk */
|
|
64
|
+
off_t usedpages; /* number of pages used on disk */
|
|
65
|
+
time_t atime; /* Last access time */
|
|
66
|
+
} vm;
|
|
67
|
+
</pre>
|
|
68
|
+
As you can see the structure contains the page at which the object is located in the swap file, the number of pages used, and the last access time of the object (this is very useful for the algorithm that select what object is a good candidate for swapping, as we want to transfer on disk objects that are rarely accessed).<br/><br/>As you can see, while all the other fields are using unused bytes in the old Redis Object structure (we had some free bit due to natural memory alignment concerns), the <i>vm</i> field is new, and indeed uses additional memory. Should we pay such a memory cost even when VM is disabled? No! This is the code to create a new Redis Object:
|
|
69
|
+
<pre class="codeblock python python python python" name="code">
|
|
70
|
+
... some code ...
|
|
71
|
+
if (server.vm_enabled) {
|
|
72
|
+
pthread_mutex_unlock(&server.obj_freelist_mutex);
|
|
73
|
+
o = zmalloc(sizeof(*o));
|
|
74
|
+
} else {
|
|
75
|
+
o = zmalloc(sizeof(*o)-sizeof(struct redisObjectVM));
|
|
76
|
+
}
|
|
77
|
+
... some code ...
|
|
78
|
+
</pre>
|
|
79
|
+
As you can see if the VM system is not enabled we allocate just <code name="code" class="python">sizeof(*o)-sizeof(struct redisObjectVM)</code> of memory. Given that the <i>vm</i> field is the last in the object structure, and that this fields are never accessed if VM is disabled, we are safe and Redis without VM does not pay the memory overhead.<h2><a name="The Swap File">The Swap File</a></h2>
|
|
80
|
+
The next step in order to understand how the VM subsystem works is understanding how objects are stored inside the swap file. The good news is that's not some kind of special format, we just use the same format used to store the objects in .rdb files, that are the usual dump files produced by Redis using the SAVE command.<br/><br/>The swap file is composed of a given number of pages, where every page size is a given number of bytes. This parameters can be changed in redis.conf, since different Redis instances may work better with different values: it depends on the actual data you store inside it. The following are the default values:
|
|
81
|
+
<pre class="codeblock python python python python python" name="code">
|
|
82
|
+
vm-page-size 32
|
|
83
|
+
vm-pages 134217728
|
|
84
|
+
</pre>
|
|
85
|
+
Redis takes a "bitmap" (an contiguous array of bits set to zero or one) in memory, every bit represent a page of the swap file on disk: if a given bit is set to 1, it represents a page that is already used (there is some Redis Object stored there), while if the corresponding bit is zero, the page is free.<br/><br/>Taking this bitmap (that will call the page table) in memory is a huge win in terms of performances, and the memory used is small: we just need 1 bit for every page on disk. For instance in the example below 134217728 pages of 32 bytes each (4GB swap file) is using just 16 MB of RAM for the page table.<h2><a name="Transfering objects from memory to swap">Transfering objects from memory to swap</a></h2>
|
|
86
|
+
In order to transfer an object from memory to disk we need to perform the following steps (assuming non threaded VM, just a simple blocking approach):<br/><br/><ul><li> Find how many pages are needed in order to store this object on the swap file. This is trivially accomplished just calling the function <code name="code" class="python">rdbSavedObjectPages</code> that returns the number of pages used by an object on disk. Note that this function does not duplicate the .rdb saving code just to understand what will be the length <b>after</b> an object will be saved on disk, we use the trick of opening /dev/null and writing the object there, finally calling <code name="code" class="python">ftello</code> in order check the amount of bytes required. What we do basically is to save the object on a virtual very fast file, that is, /dev/null.</li><li> Now that we know how many pages are required in the swap file, we need to find this number of contiguous free pages inside the swap file. This task is accomplished by the <code name="code" class="python">vmFindContiguousPages</code> function. As you can guess this function may fail if the swap is full, or so fragmented that we can't easily find the required number of contiguous free pages. When this happens we just abort the swapping of the object, that will continue to live in memory.</li><li> Finally we can write the object on disk, at the specified position, just calling the function <code name="code" class="python">vmWriteObjectOnSwap</code>.</li></ul>As you can guess once the object was correctly written in the swap file, it is freed from memory, the storage field in the associated key is set to REDIS_VM_SWAPPED, and the used pages are marked as used in the page table.
|
|
87
|
+
<h2><a name="Loading objects back in memory">Loading objects back in memory</a></h2>
|
|
88
|
+
Loading an object from swap to memory is simpler, as we already know where the object is located and how many pages it is using. We also know the type of the object (the loading functions are required to know this information, as there is no header or any other information about the object type on disk), but this is stored in the <i>vtype</i> field of the associated key as already seen above.<br/><br/>Calling the function <code name="code" class="python">vmLoadObject</code> passing the key object associated to the value object we want to load back is enough. The function will also take care of fixing the storage type of the key (that will be REDIS_VM_MEMORY), marking the pages as freed in the page table, and so forth.<br/><br/>The return value of the function is the loaded Redis Object itself, that we'll have to set again as value in the main hash table (instead of the NULL value we put in place of the object pointer when the value was originally swapped out).
|
|
89
|
+
<h2><a name="How blocking VM works">How blocking VM works</a></h2>
|
|
90
|
+
Now we have all the building blocks in order to describe how the blocking VM works. First of all, an important detail about configuration. In order to enable blocking VM in Redis <code name="code" class="python">server.vm_max_threads</code> must be set to zero.
|
|
91
|
+
We'll see later how this max number of threads info is used in the threaded VM, for now all it's needed to now is that Redis reverts to fully blocking VM when this is set to zero.<br/><br/>We also need to introduce another important VM parameter, that is, <code name="code" class="python">server.vm_max_memory</code>. This parameter is very important as it is used in order to trigger swapping: Redis will try to swap objects only if it is using more memory than the max memory setting, otherwise there is no need to swap as we are matching the user requested memory usage.
|
|
92
|
+
<h2><a name="Blocking VM swapping">Blocking VM swapping</a></h2>
|
|
93
|
+
Swapping of object from memory to disk happens in the cron function. This function used to be called every second, while in the recent Redis versions on git it is called every 100 milliseconds (that is, 10 times per second).
|
|
94
|
+
If this function detects we are out of memory, that is, the memory used is greater than the vm-max-memory setting, it starts transferring objects from memory to disk in a loop calling the function <code name="code" class="python">vmSwapOneObect</code>. This function takes just one argument, if 0 it will swap objects in a blocking way, otherwise if it is 1, I/O threads are used. In the blocking scenario we just call it with zero as argument.<br/><br/>vmSwapOneObject acts performing the following steps:
|
|
95
|
+
<ul><li> The key space in inspected in order to find a good candidate for swapping (we'll see later what a good candidate for swapping is).</li><li> The associated value is transfered to disk, in a blocking way.</li><li> The key storage field is set to REDIS_VM_SWAPPED, while the <i>vm</i> fields of the object are set to the right values (the page index where the object was swapped, and the number of pages used to swap it).</li><li> Finally the value object is freed and the value entry of the hash table is set to NULL.</li></ul>The function is called again and again until one of the following happens: there is no way to swap more objects because either the swap file is full or nearly all the objects are already transfered on disk, or simply the memory usage is already under the vm-max-memory parameter.
|
|
96
|
+
<h2><a name="What values to swap when we are out of memory?">What values to swap when we are out of memory?</a></h2>
|
|
97
|
+
Understanding what's a good candidate for swapping is not too hard. A few objects at random are sampled, and for each their <i>swappability</i> is commuted as:
|
|
98
|
+
<pre class="codeblock python python python python python python" name="code">
|
|
99
|
+
swappability = age*log(size_in_memory)
|
|
100
|
+
</pre>
|
|
101
|
+
The age is the number of seconds the key was not requested, while size_in_memory is a fast estimation of the amount of memory (in bytes) used by the object in memory. So we try to swap out objects that are rarely accessed, and we try to swap bigger objects over smaller one, but the latter is a less important factor (because of the logarithmic function used). This is because we don't want bigger objects to be swapped out and in too often as the bigger the object the more I/O and CPU is required in order to transfer it.
|
|
102
|
+
<h2><a name="Blocking VM loading">Blocking VM loading</a></h2>
|
|
103
|
+
What happens if an operation against a key associated with a swapped out object is requested? For instance Redis may just happen to process the following command:
|
|
104
|
+
<pre class="codeblock python python python python python python python" name="code">
|
|
105
|
+
GET foo
|
|
106
|
+
</pre>
|
|
107
|
+
If the value object of the <code name="code" class="python">foo</code> key is swapped we need to load it back in memory before processing the operation. In Redis the key lookup process is centralized in the <code name="code" class="python">lookupKeyRead</code> and <code name="code" class="python">lookupKeyWrite</code> functions, this two functions are used in the implementation of all the Redis commands accessing the keyspace, so we have a single point in the code where to handle the loading of the key from the swap file to memory.<br/><br/>So this is what happens:
|
|
108
|
+
<ul><li> The user calls some command having as argumenet a swapped key</li><li> The command implementation calls the lookup function</li><li> The lookup function search for the key in the top level hash table. If the value associated with the requested key is swapped (we can see that checking the <i>storage</i> field of the key object), we load it back in memory in a blocking way before to return to the user.</li></ul>
|
|
109
|
+
This is pretty straightforward, but things will get more <i>interesting</i> with the threads. From the point of view of the blocking VM the only real problem is the saving of the dataset using another process, that is, handling BGSAVE and BGREWRITEAOF commands.
|
|
110
|
+
<h2><a name="Background saving when VM is active">Background saving when VM is active</a></h2>
|
|
111
|
+
The default Redis way to persist on disk is to create .rdb files using a child process. Redis calls the fork() system call in order to create a child, that has the exact copy of the in memory dataset, since fork duplicates the whole program memory space (actually thanks to a technique called Copy on Write memory pages are shared between the parent and child process, so the fork() call will not require too much memory).<br/><br/>In the child process we have a copy of the dataset in a given point in the time. Other commands issued by clients will just be served by the parent process and will not modify the child data.<br/><br/>The child process will just store the whole dataset into the dump.rdb file and finally will exit. But what happens when the VM is active? Values can be swapped out so we don't have all the data in memory, and we need to access the swap file in order to retrieve the swapped values. While child process is saving the swap file is shared between the parent and child process, since:
|
|
112
|
+
<ul><li> The parent process needs to access the swap file in order to load values back into memory if an operation against swapped out values are performed.</li><li> The child process needs to access the swap file in order to retrieve the full dataset while saving the data set on disk.</li></ul>In order to avoid problems while both the processes are accessing the same swap file we do a simple thing, that is, not allowing values to be swapped out in the parent process while a background saving is in progress. This way both the processes will access the swap file in read only. This approach has the problem that while the child process is saving no new values can be transfered on the swap file even if Redis is using more memory than the max memory parameters dictates. This is usually not a problem as the background saving will terminate in a short amount of time and if still needed a percentage of values will be swapped on disk ASAP.<br/><br/>An alternative to this scenario is to enable the Append Only File that will have this problem only when a log rewrite is performed using the BGREWRITEAOF command.
|
|
113
|
+
<h2><a name="The problem with the blocking VM">The problem with the blocking VM</a></h2>
|
|
114
|
+
The problem of blocking VM is that... it's blocking :)
|
|
115
|
+
This is not a problem when Redis is used in batch processing activities, but for real-time usage one of the good points of Redis is the low latency. The blocking VM will have bad latency behaviors as when a client is accessing a swapped out value, or when Redis needs to swap out values, no other clients will be served in the meantime.<br/><br/>Swapping out keys should happen in background. Similarly when a client is accessing a swapped out value other clients accessing in memory values should be served mostly as fast as when VM is disabled. Only the clients dealing with swapped out keys should be delayed.<br/><br/>All this limitations called for a non-blocking VM implementation.
|
|
116
|
+
<h2><a name="Threaded VM">Threaded VM</a></h2>
|
|
117
|
+
There are basically three main ways to turn the blocking VM into a non blocking one.
|
|
118
|
+
<ul><li> 1: One way is obvious, and in my opionion, not a good idea at all, that is, turning Redis itself into a theaded server: if every request is served by a different thread automatically other clients don't need to wait for blocked ones. Redis is fast, exports atomic operations, has no locks, and is just 10k lines of code, <b>because</b> it is single threaded, so this was not an option for me.</li><li> 2: Using non-blocking I/O against the swap file. After all you can think Redis already event-loop based, why don't just handle disk I/O in a non-blocking fashion? I also discarded this possiblity because of two main reasons. One is that non blocking file operations, unlike sockets, are an incompatibility nightmare. It's not just like calling select, you need to use OS-specific things. The other problem is that the I/O is just one part of the time consumed to handle VM, another big part is the CPU used in order to encode/decode data to/from the swap file. This is I picked option three, that is...</li><li> 3: Using I/O threads, that is, a pool of threads handling the swap I/O operations. This is what the Redis VM is using, so let's detail how this works.</li></ul><h2><a name="I/O Threads">I/O Threads</a></h2>
|
|
119
|
+
The threaded VM design goals where the following, in order of importance:
|
|
120
|
+
<ul><li> Simple implementation, little room for race condtions, simple locking, VM system more or less completeley decoupled from the rest of Redis code.</li><li> Good performances, no locks for clients accessing values in memory.</li><li> Ability to decode/encode objects in the I/O threads.</li></ul>The above goals resulted in an implementation where the Redis main thread (the one serving actual clients) and the I/O threads communicate using a queue of jobs, with a single mutex.
|
|
121
|
+
Basically when main thread requires some work done in the background by some I/O thread, it pushes an I/O job structure in the <code name="code" class="python">server.io_newjobs</code> queue (that is, just a linked list). If there are no active I/O threads, one is started. At this point some I/O thread will process the I/O job, and the result of the processing is pushed in the <code name="code" class="python">server.io_processed</code> queue. The I/O thread will send a byte using an UNIX pipe to the main thread in order to signal that a new job was processed and the result is ready to be processed.<br/><br/>This is how the <code name="code" class="python">iojob</code> structure looks like:
|
|
122
|
+
<pre class="codeblock python python python python python python python python" name="code">
|
|
123
|
+
typedef struct iojob {
|
|
124
|
+
int type; /* Request type, REDIS_IOJOB_* */
|
|
125
|
+
redisDb *db;/* Redis database */
|
|
126
|
+
robj *key; /* This I/O request is about swapping this key */
|
|
127
|
+
robj *val; /* the value to swap for REDIS_IOREQ_*_SWAP, otherwise this
|
|
128
|
+
* field is populated by the I/O thread for REDIS_IOREQ_LOAD. */
|
|
129
|
+
off_t page; /* Swap page where to read/write the object */
|
|
130
|
+
off_t pages; /* Swap pages needed to save object. PREPARE_SWAP return val */
|
|
131
|
+
int canceled; /* True if this command was canceled by blocking side of VM */
|
|
132
|
+
pthread_t thread; /* ID of the thread processing this entry */
|
|
133
|
+
} iojob;
|
|
134
|
+
</pre>
|
|
135
|
+
There are just three type of jobs that an I/O thread can perform (the type is specified by the <code name="code" class="python">type</code> field of the structure):
|
|
136
|
+
<ul><li> REDIS_IOJOB_LOAD: load the value associated to a given key from swap to memory. The object offset inside the swap file is <code name="code" class="python">page</code>, the object type is <code name="code" class="python">key->vtype</code>. The result of this operation will populate the <code name="code" class="python">val</code> field of the structure.</li><li> REDIS_IOJOB_PREPARE_SWAP: compute the number of pages needed in order to save the object pointed by <code name="code" class="python">val</code> into the swap. The result of this operation will populate the <code name="code" class="python">pages</code> field.</li><li> REDIS_IOJOB_DO_SWAP: Transfer the object pointed by <code name="code" class="python">val</code> to the swap file, at page offset <code name="code" class="python">page</code>.</li></ul>The main thread delegates just the above three tasks. All the rest is handled by the main thread itself, for instance finding a suitable range of free pages in the swap file page table (that is a fast operation), deciding what object to swap, altering the storage field of a Redis object to reflect the current state of a value.
|
|
137
|
+
<h2><a name="Non blocking VM as probabilistic enhancement of blocking VM">Non blocking VM as probabilistic enhancement of blocking VM</a></h2>
|
|
138
|
+
So now we have a way to request background jobs dealing with slow VM operations. How to add this to the mix of the rest of the work done by the main thread? While blocking VM was aware that an object was swapped out just when the object was looked up, this is too late for us: in C it is not trivial to start a background job in the middle of the command, leave the function, and re-enter in the same point the computation when the I/O thread finished what we requested (that is, no co-routines or continuations or alike).<br/><br/>Fortunately there was a much, much simpler way to do this. And we love simple things: basically consider the VM implementation a blocking one, but add an optimization (using non the no blocking VM operations we are able to perform) to make the blocking <b>very</b> unlikely.<br/><br/>This is what we do:
|
|
139
|
+
<ul><li> Every time a client sends us a command, <b>before</b> the command is executed, we examine the argument vector of the command in search for swapped keys. After all we know for every command what arguments are keys, as the Redis command format is pretty simple.</li><li> If we detect that at least a key in the requested command is swapped on disk, we block the client instead of really issuing the command. For every swapped value associated to a requested key, an I/O job is created, in order to bring the values back in memory. The main thread continues the execution of the event loop, without caring about the blocked client.</li><li> In the meanwhile, I/O threads are loading values in memory. Every time an I/O thread finished loading a value, it sends a byte to the main thread using an UNIX pipe. The pipe file descriptor has a readable event associated in the main thread event loop, that is the function <code name="code" class="python">vmThreadedIOCompletedJob</code>. If this function detects that all the values needed for a blocked client were loaded, the client is restarted and the original command called.</li></ul>
|
|
140
|
+
So you can think at this as a blocked VM that almost always happen to have the right keys in memory, since we pause clients that are going to issue commands about swapped out values until this values are loaded.<br/><br/>If the function checking what argument is a key fails in some way, there is no problem: the lookup function will see that a given key is associated to a swapped out value and will block loading it. So our non blocking VM reverts to a blocking one when it is not possible to anticipate what keys are touched.<br/><br/>For instance in the case of the SORT command used together with the GET or BY options, it is not trivial to know beforehand what keys will be requested, so at least in the first implementation, SORT BY/GET resorts to the blocking VM implementation.
|
|
141
|
+
<h2><a name="Blocking clients on swapped keys">Blocking clients on swapped keys</a></h2>
|
|
142
|
+
How to block clients? To suspend a client in an event-loop based server is pretty trivial. All we do is cancelling its read handler. Sometimes we do something different (for instance for BLPOP) that is just marking the client as blocked, but not processing new data (just accumulating the new data into input buffers).
|
|
143
|
+
<h2><a name="Aborting I/O jobs">Aborting I/O jobs</a></h2>
|
|
144
|
+
There is something hard to solve about the interactions between our blocking and non blocking VM, that is, what happens if a blocking operation starts about a key that is also "interested" by a non blocking operation at the same time?<br/><br/>For instance while SORT BY is executed, a few keys are being loaded in a blocking manner by the sort command. At the same time, another client may request the same keys with a simple <i>GET key</i> command, that will trigger the creation of an I/O job to load the key in background.<br/><br/>The only simple way to deal with this problem is to be able to kill I/O jobs in the main thread, so that if a key that we want to load or swap in a blocking way is in the REDIS_VM_LOADING or REDIS_VM_SWAPPING state (that is, there is an I/O job about this key), we can just kill the I/O job about this key, and go ahead with the blocking operation we want to perform.<br/><br/>This is not as trivial as it is. In a given moment an I/O job can be in one of the following three queues:
|
|
145
|
+
<ul><li> server.io_newjobs: the job was already queued but no thread is handling it.</li><li> server.io_processing: the job is being processed by an I/O thread.</li><li> server.io_processed: the job was already processed.</li></ul>The function able to kill an I/O job is <code name="code" class="python">vmCancelThreadedIOJob</code>, and this is what it does:
|
|
146
|
+
<ul><li> If the job is in the newjobs queue, that's simple, removing the iojob structure from the queue is enough as no thread is still executing any operation.</li><li> If the job is in the processing queue, a thread is messing with our job (and possibly with the associated object!). The only thing we can do is waiting for the item to move to the next queue in a <b>blocking way</b>. Fortunately this condition happens very rarely so it's not a performance problem.</li><li> If the job is in the processed queue, we just mark it as <i>canceled</i> marking setting the <code name="code" class="python">canceled</code> field to 1 in the iojob structure. The function processing completed jobs will just ignored and free the job instead of really processing it.</li></ul>
|
|
147
|
+
<h2><a name="Questions?">Questions?</a></h2>
|
|
148
|
+
This document is in no way complete, the only way to get the whole picture is reading the source code, but it should be a good introduction in order to make the code review / understanding a lot simpler.<br/><br/>Something is not clear about this page? Please leave a comment and I'll try to address the issue possibly integrating the answer in this document.
|
|
149
|
+
|
|
150
|
+
</div>
|
|
151
|
+
|
|
152
|
+
</div>
|
|
153
|
+
</div>
|
|
154
|
+
</body>
|
|
155
|
+
</html>
|
|
156
|
+
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>VirtualMemoryUserGuide: Contents</b><br> <a href="#Virtual Memory User Guide">Virtual Memory User Guide</a><br> <a href="#Virtual Memory explained in simple words">Virtual Memory explained in simple words</a><br> <a href="#When using Virtual Memory is a good idea">When using Virtual Memory is a good idea</a><br> <a href="#VM Configuration">VM Configuration</a><br> <a href="#The vm-max-memory setting">The vm-max-memory setting</a><br> <a href="#Configuring the swap file">Configuring the swap file</a><br> <a href="#Threaded VM vs Blocking VM">Threaded VM vs Blocking VM</a><br> <a href="#Random things to know">Random things to know</a><br> <a href="#A good place for the swap file">A good place for the swap file</a><br> <a href="#Monitoring the VM">Monitoring the VM</a><br> <a href="#Redis with VM enabled: better .rdb files or Append Only File?">Redis with VM enabled: better .rdb files or Append Only File?</a><br> <a href="#Using as little memory as possible">Using as little memory as possible</a><br> <a href="#VM Stability">VM Stability</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">VirtualMemoryUserGuide</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="RedisGuides.html">RedisGuides</a><h1><a name="Virtual Memory User Guide">Virtual Memory User Guide</a></h1>Redis Virtual Memory is a feature that will appear for the first time in a stable Redis distribution in Redis 2.0. However Virtual Memory (called VM starting from now) is already available and stable enough to be tests in the unstable branch of Redis available <a href="http://github.com/antirez/redis" target="_blank">on Git</a>.<h2><a name="Virtual Memory explained in simple words">Virtual Memory explained in simple words</a></h2>Redis follows a Key-Value model. You have keys associated with some values.
|
|
30
|
+
Usually Redis takes both Keys and associated Values in memory. Sometimes this is not the best option, and while Keys <b>must</b> be taken in memory for the way Redis is designed (and in order to ensure fast lookups), Values can be swapped out to disk when they are rarely used.<br/><br/>In practical terms this means that if you have a dataset of 100,000 keys in memory, but only 10% of this keys are often used, Redis with Virtual Memory enabled will try to transfer the values associated to the rarely used keys on disk.<br/><br/>When this values are requested, as a result of a command issued by a client, the values are loaded back from the swap file to the main memory.<h2><a name="When using Virtual Memory is a good idea">When using Virtual Memory is a good idea</a></h2>Before using VM you should ask yourself if you really need it. Redis is a disk backed, in memory database. The right way to use Redis is almost always to have enough RAM to fit all the data in memory. Still there are a scenarios where to hold all the data in memory is not possible:
|
|
31
|
+
<ul><li> Data access is very biased. Only a small percentage of keys (for instance related to active users in your web site) gets the vast majority of accesses. At the same time there is too much data per key to take everything in memory.</li><li> There is simply not enough memory available to hold all the data in memory, regardless of the data access pattern, and values are large. In this configuration Redis can be used as an on-disk DB where keys are in memory, so the key lookup is fast, but the access to the actual values require accessing the (slower) disk.</li></ul>
|
|
32
|
+
An important concept to take in mind is that Redis <b>is not able to swap the keys</b>, so if your memory problems are related to the fact you have too much keys with very small values, VM is not the solution.<br/><br/>Instead if a good amount of memory is used because values are pretty large (for example large strings, lists, sets or hashes with many elements), then VM can be a good idea.<br/><br/>Sometimes you can turn your "many keys with small values" problem into a "less keys but with very large values" one just using Hashes in order to group related data into fields of a single key. For instance instead of having a key for every attribute of your object you have a single key per object where Hash fields represent the different attributes.<h1><a name="VM Configuration">VM Configuration</a></h1>Configuring the VM is not hard but requires some care to set the best parameters accordingly to the requirements.<br/><br/>The VM is enabled and configured editing redis.conf, the first step is switching it on with:<br/><br/><pre class="codeblock python" name="code">
|
|
33
|
+
vm-enabled yes
|
|
34
|
+
</pre>Many other configuration options are able to change the behavior of VM. The rule is that you don't want to run with the default configuration, as every problem and dataset requires some tuning in order to get the maximum advantages.<h2><a name="The vm-max-memory setting">The vm-max-memory setting</a></h2>The <b>vm-max-memory</b> setting specifies how much memory Redis is free to use before starting swapping values on disk.<br/><br/>Basically if this memory limit is still not reached, no object will be swapped, Redis will work all in memory as usually. Once this limit is hit, enough objects are swapped out in order to return just under the limit.<br/><br/>The swapped objects are the one with the highest "age" (that is, the number of seconds since they are not used in any way) mainly, but the "swappability" of an object is also proportional to the logarithm of it's size in memory. So basically older objects are preferred, but when they are about the same size, bigger objects are preferred.<br/><br/><b>WARNING:</b> Because keys can't be swapped out, Redis will not be able to honour the <b>vm-max-memory</b> setting if the keys alone are using more space than the limit.<br/><br/>The best value for this setting is enough RAM in order to hold the "working set" of data. In practical terms, just give Redis as much memory as you can, and swapping will work better.<h2><a name="Configuring the swap file">Configuring the swap file</a></h2>In order to transfer data from memory to disk, Redis uses a swap file. The swap file has nothing to do with durability of data, and can be removed when a Redis instance is terminated. Still the swap file should not be moved, deleted, or altered in any other way while Redis is running.<br/><br/>Because the Redis swap file is used mostly in a random access fashion, to put the swap file into a Solid State Disk will lead to better performances.<br/><br/>The swap file is divided into "pages". A value can be swapped into one or multiple pages, but a single page can't hold more than a value.<br/><br/>There is no direct way to tell Redis how much bytes of swap file it should be using. Instead two different values are configured, that multiplied together will produce the total number of bytes used. This two values are the number of pages inside the swap file, and the page size. It is possible to configure this two parameters in redis.conf.<br/><br/><ul><li> The <b>vm-pages</b> configuration directive is used to set the total number of pages in the swap file.</li><li> the <b>vm-page-size</b> configuration directive is used in order to set the page size in bytes.</li></ul>
|
|
35
|
+
So for instance if the page size is set to the value of 32 bytes, and the total number of pages is set to 10000000 (10 millions), the swap file can hold a total of 320 MB of data.<br/><br/>Because a single page can't be used to hold more than a value (but a value can be stored into multiple pages), care must be taken in setting this parameters.
|
|
36
|
+
Usually the best idea is setting the page size so that the majority of the values can be swapped using a few pages.<h2><a name="Threaded VM vs Blocking VM">Threaded VM vs Blocking VM</a></h2>Another very important configuration parameter is <b>vm-max-threads</b>:<br/><br/><pre class="codeblock python python" name="code">
|
|
37
|
+
# The default vm-max-threads configuration
|
|
38
|
+
vm-max-threads 4
|
|
39
|
+
</pre>This is the maximum number of threads used in order to perform I/O from/to the swap file. A good value is just to match the number of cores in your system.<br/><br/>However the special value of "0" will enable blocking VM. When VM is configured to be blocking it performs the I/O in a synchronous blocking way. This is what you can expect from blocking VM:
|
|
40
|
+
<ul><li> Clients accessing swapped out keys will block other clients while reading from disk, so the latency experimented by clients can be larger, especially if the disk is slow or busy and/or if there are big values swapped on disk.</li><li> The blocking VM performances are <b>overall</b> better, as there is no time lost in synchronization, spawning of threads, resuming blocked clients waiting for values.</li></ul>So if you are willing to accept an higher latency from time to time, blocking VM can be a good pick, especially if swapping happens rarely as most of your often accessed data happens to fit in your memory.<br/><br/>If instead you have a lot of swap in and swap out operations and you have many cores that you want to exploit, and in general when you don't want that clients dealing with swapped values will block other clients for a few milliseconds (or more if the swapped value is very big), then it's better to use threaded VM.<br/><br/>To experiment with your dataset and different configurations is warmly encouraged...<h1><a name="Random things to know">Random things to know</a></h1>
|
|
41
|
+
<h2><a name="A good place for the swap file">A good place for the swap file</a></h2>In many configurations the swap file can be fairly large, even 40GB or more.
|
|
42
|
+
Not all the kind of file systems are able to deal with large files in a good way, especially Mac OS X file system tends to be really lame about it.<br/><br/>The suggestion is to use Linux ext3 file system, or any other file system with good support for <b>sparse files</b>. What are sparse files?<br/><br/>Sparse files are files where a lot of the content happen to be empty. Advanced file systems like ext2, ext3, ext4, RaiserFS, Raiser4, and many others, are able to encode this files in a more efficient way and will allocate more space for the file when needed, that is, when more actual blocks of the file will be used.<br/><br/>The swap file is obviously pretty sparse, especially if the server is running since little time or it is much bigger compared to the amount of data swapped out. A file system not supporting sparse files can at some point block the Redis process while creating a very big file at once.<br/><br/>For a list of file systems supporting spare files <a href="http://en.wikipedia.org/wiki/Comparison_of_file_systems" target="_blank">check this Wikipedia page comparing different files systems</a>.<h2><a name="Monitoring the VM">Monitoring the VM</a></h2>Once you have a Redis system with VM enabled up and running, you may be very interested in knowing how it's working: how many objects are swapped in total, the number of objects swapped and loaded every second, and so forth.<br/><br/>There is an utility that is very handy in checking how the VM is working, that is part of <a href="http://github.com/antirez/redis-tools" target="_blank">Redis Tools</a>. This tool is called redis-stat, and using it is pretty straightforward:<br/><br/><pre class="codeblock python python python" name="code">
|
|
43
|
+
$ ./redis-stat vmstat
|
|
44
|
+
--------------- objects --------------- ------ pages ------ ----- memory -----
|
|
45
|
+
load-in swap-out swapped delta used delta used delta
|
|
46
|
+
138837 1078936 800402 +800402 807620 +807620 209.50M +209.50M
|
|
47
|
+
4277 38011 829802 +29400 837441 +29821 206.47M -3.03M
|
|
48
|
+
3347 39508 862619 +32817 870340 +32899 202.96M -3.51M
|
|
49
|
+
4445 36943 890646 +28027 897925 +27585 199.92M -3.04M
|
|
50
|
+
10391 16902 886783 -3863 894104 -3821 200.22M +309.56K
|
|
51
|
+
8888 19507 888371 +1588 895678 +1574 200.05M -171.81K
|
|
52
|
+
8377 20082 891664 +3293 899850 +4172 200.10M +53.55K
|
|
53
|
+
9671 20210 892586 +922 899917 +67 199.82M -285.30K
|
|
54
|
+
10861 16723 887638 -4948 895003 -4914 200.13M +312.35K
|
|
55
|
+
9541 21945 890618 +2980 898004 +3001 199.94M -197.11K
|
|
56
|
+
9689 17257 888345 -2273 896405 -1599 200.27M +337.77K
|
|
57
|
+
10087 18784 886771 -1574 894577 -1828 200.36M +91.60K
|
|
58
|
+
9330 19350 887411 +640 894817 +240 200.17M -189.72K
|
|
59
|
+
</pre>The above output is about a redis-server with VM enable, around 1 million of keys inside, and a lot of simulated load using the redis-load utility.<br/><br/>As you can see from the output a number of load-in and swap-out operations are happening every second. Note that the first line reports the actual values since the server was started, while the next lines are differences compared to the previous reading.<br/><br/>If you assigned enough memory to hold your working set of data, probably you should see a lot less dramatic swapping happening, so redis-stat can be a really valuable tool in order to understand if you need to shop for RAM ;)<h2><a name="Redis with VM enabled: better .rdb files or Append Only File?">Redis with VM enabled: better .rdb files or Append Only File?</a></h2>When VM is enabled, saving and loading the database are <b>much slower</b> operations. A DB that usually loads in 2 seconds takes 13 seconds with VM enabled if the server is configured to use the smallest memory possible (that is, vm-max-memory set to 0).<br/><br/>So you probably want to switch to a configuration using the Append Only File for persistence, so that you can perform the BGREWRITEAOF from time to time.<br/><br/>It is important to note that while a BGSAVE or BGREWRITEAOF is in progress Redis does <b>not</b> swap new values on disk. The VM will be read-only while there is another child accessing it. So if you have a lot of writes while there is a child working, the memory usage may grow.<h2><a name="Using as little memory as possible">Using as little memory as possible</a></h2>An interesting setup to turn Redis into an on-disk DB with just keys in memory is setting vm-max-memory to 0. If you don't mind some latency more and poorer performances but want to use very little memory for very big values, this is a good setup.<br/><br/>In this setup you should first try setting the VM as blocking (vm-max-threads 0) as with this configuration and high traffic the number of swap in and swap out operations will be huge, and threading will consume a lot of resources compared to a simple blocking implementation.<h2><a name="VM Stability">VM Stability</a></h2>VM is still experimental code, but in the latest weeks it was tested in many ways in development environments, and even in some production environment. No bugs were noticed during this testing period. Still the more obscure bugs may happen in non controlled environments where there are setups that we are not able to reproduce for some reason.<br/><br/>In this stage you are encouraged to try VM in your development environment, and even in production if your DB is not mission critical, but for instance just a big persistent cache of data that may go away without too much problems.<br/><br/>Please report any problem you will notice to the Redis Google Group or by IRC joining the #redis IRC channel on freenode.
|
|
60
|
+
</div>
|
|
61
|
+
|
|
62
|
+
</div>
|
|
63
|
+
</div>
|
|
64
|
+
</body>
|
|
65
|
+
</html>
|
|
66
|
+
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>ZaddCommand: Contents</b><br> <a href="#ZADD _key_ _score_ _member_ (Redis >">ZADD _key_ _score_ _member_ (Redis ></a><br> <a href="#Return value">Return value</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">ZaddCommand</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="SortedSetCommandsSidebar.html">SortedSetCommandsSidebar</a><h1><a name="ZADD _key_ _score_ _member_ (Redis >">ZADD _key_ _score_ _member_ (Redis ></a></h1> 1.1) =
|
|
30
|
+
<i>Time complexity O(log(N)) with N being the number of elements in the sorted set</i><blockquote>Add the specified <i>member</i> having the specifeid <i>score</i> to the sortedset stored at <i>key</i>. If <i>member</i> is already a member of the sorted setthe score is updated, and the element reinserted in the right position toensure sorting. If <i>key</i> does not exist a new sorted set with the specified_member_ as sole member is crated. If the key exists but does not hold asorted set value an error is returned.</blockquote>
|
|
31
|
+
<blockquote>The score value can be the string representation of a double precision floatingpoint number.</blockquote>
|
|
32
|
+
<blockquote>For an introduction to sorted sets check the <a href="IntroductionToRedisDataTypes.html">Introduction to Redis data types</a> page.</blockquote>
|
|
33
|
+
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Integer reply</a>, specifically:<br/><br/><pre class="codeblock python" name="code">
|
|
34
|
+
1 if the new element was added
|
|
35
|
+
0 if the element was already a member of the sorted set and the score was updated
|
|
36
|
+
</pre>
|
|
37
|
+
</div>
|
|
38
|
+
|
|
39
|
+
</div>
|
|
40
|
+
</div>
|
|
41
|
+
</body>
|
|
42
|
+
</html>
|
|
43
|
+
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>ZcardCommand: Contents</b><br> <a href="#ZCARD _key_ (Redis >">ZCARD _key_ (Redis ></a><br> <a href="#Return value">Return value</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">ZcardCommand</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="SortedSetCommandsSidebar.html">SortedSetCommandsSidebar</a><h1><a name="ZCARD _key_ (Redis >">ZCARD _key_ (Redis ></a></h1> 1.1) =
|
|
30
|
+
<i>Time complexity O(1)</i><blockquote>Return the sorted set cardinality (number of elements). If the <i>key</i> does notexist 0 is returned, like for empty sorted sets.</blockquote>
|
|
31
|
+
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Integer reply</a>, specifically:<br/><br/><pre class="codeblock python" name="code">
|
|
32
|
+
the cardinality (number of elements) of the set as an integer.
|
|
33
|
+
</pre>
|
|
34
|
+
|
|
35
|
+
</div>
|
|
36
|
+
|
|
37
|
+
</div>
|
|
38
|
+
</div>
|
|
39
|
+
</body>
|
|
40
|
+
</html>
|
|
41
|
+
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>ZincrbyCommand: Contents</b><br> <a href="#ZINCRBY _key_ _increment_ _member_ (Redis >">ZINCRBY _key_ _increment_ _member_ (Redis ></a><br> <a href="#Return value">Return value</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">ZincrbyCommand</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="SortedSetCommandsSidebar.html">SortedSetCommandsSidebar</a><h1><a name="ZINCRBY _key_ _increment_ _member_ (Redis >">ZINCRBY _key_ _increment_ _member_ (Redis ></a></h1> 1.1) =
|
|
30
|
+
<i>Time complexity O(log(N)) with N being the number of elements in the sorted set</i><blockquote>If <i>member</i> already exists in the sorted set adds the <i>increment</i> to its scoreand updates the position of the element in the sorted set accordingly.If <i>member</i> does not already exist in the sorted set it is added with_increment_ as score (that is, like if the previous score was virtually zero).If <i>key</i> does not exist a new sorted set with the specified_member_ as sole member is crated. If the key exists but does not hold asorted set value an error is returned.</blockquote>
|
|
31
|
+
<blockquote>The score value can be the string representation of a double precision floatingpoint number. It's possible to provide a negative value to perform a decrement.</blockquote>
|
|
32
|
+
<blockquote>For an introduction to sorted sets check the <a href="IntroductionToRedisDataTypes.html">Introduction to Redis data types</a> page.</blockquote>
|
|
33
|
+
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Bulk reply</a><pre class="codeblock python" name="code">
|
|
34
|
+
The new score (a double precision floating point number) represented as string.
|
|
35
|
+
</pre>
|
|
36
|
+
</div>
|
|
37
|
+
|
|
38
|
+
</div>
|
|
39
|
+
</div>
|
|
40
|
+
</body>
|
|
41
|
+
</html>
|
|
42
|
+
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
|
|
2
|
+
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
3
|
+
<html>
|
|
4
|
+
<head>
|
|
5
|
+
<link type="text/css" rel="stylesheet" href="style.css" />
|
|
6
|
+
</head>
|
|
7
|
+
<body>
|
|
8
|
+
<div id="page">
|
|
9
|
+
|
|
10
|
+
<div id='header'>
|
|
11
|
+
<a href="index.html">
|
|
12
|
+
<img style="border:none" alt="Redis Documentation" src="redis.png">
|
|
13
|
+
</a>
|
|
14
|
+
</div>
|
|
15
|
+
|
|
16
|
+
<div id="pagecontent">
|
|
17
|
+
<div class="index">
|
|
18
|
+
<!-- This is a (PRE) block. Make sure it's left aligned or your toc title will be off. -->
|
|
19
|
+
<b>ZrangeCommand: Contents</b><br> <a href="#ZRANGE _key_ _start_ _end_ `[`WITHSCORES`]`(Redis >">ZRANGE _key_ _start_ _end_ `[`WITHSCORES`]`(Redis ></a><br> <a href="#ZREVRANGE _key_ _start_ _end_ `[`WITHSCORES`]` (Redis >">ZREVRANGE _key_ _start_ _end_ `[`WITHSCORES`]` (Redis ></a><br> <a href="#Return value">Return value</a>
|
|
20
|
+
</div>
|
|
21
|
+
|
|
22
|
+
<h1 class="wikiname">ZrangeCommand</h1>
|
|
23
|
+
|
|
24
|
+
<div class="summary">
|
|
25
|
+
|
|
26
|
+
</div>
|
|
27
|
+
|
|
28
|
+
<div class="narrow">
|
|
29
|
+
#sidebar <a href="SortedSetCommandsSidebar.html">SortedSetCommandsSidebar</a><h1><a name="ZRANGE _key_ _start_ _end_ `[`WITHSCORES`]`(Redis >">ZRANGE _key_ _start_ _end_ `[`WITHSCORES`]`(Redis ></a></h1> 1.1) =
|
|
30
|
+
<h1><a name="ZREVRANGE _key_ _start_ _end_ `[`WITHSCORES`]` (Redis >">ZREVRANGE _key_ _start_ _end_ `[`WITHSCORES`]` (Redis ></a></h1> 1.1) =
|
|
31
|
+
<i>Time complexity: O(log(N))+O(M) (with N being the number of elements in the sorted set and M the number of elements requested)</i><blockquote>Return the specified elements of the sorted set at the specifiedkey. The elements are considered sorted from the lowerest to the highestscore when using ZRANGE, and in the reverse order when using ZREVRANGE.Start and end are zero-based indexes. 0 is the first elementof the sorted set (the one with the lowerest score when using ZRANGE), 1the next element by score and so on.</blockquote>
|
|
32
|
+
<blockquote>_start_ and <i>end</i> can also be negative numbers indicating offsetsfrom the end of the sorted set. For example -1 is the last element ofthe sorted set, -2 the penultimate element and so on.</blockquote>
|
|
33
|
+
<blockquote>Indexes out of range will not produce an error: if start is overthe end of the sorted set, or start <code name="code" class="python">></code> end, an empty list is returned.If end is over the end of the sorted set Redis will threat it just likethe last element of the sorted set.</blockquote>
|
|
34
|
+
<blockquote>It's possible to pass the WITHSCORES option to the command in order to return notonly the values but also the scores of the elements. Redis will return the dataas a single list composed of value1,score1,value2,score2,...,valueN,scoreN but clientlibraries are free to return a more appropriate data type (what we think is thatthe best return type for this command is a Array of two-elements Array / Tuple inorder to preserve sorting).</blockquote>
|
|
35
|
+
<h2><a name="Return value">Return value</a></h2><a href="ReplyTypes.html">Multi bulk reply</a>, specifically a list of elements in the specified range.
|
|
36
|
+
</div>
|
|
37
|
+
|
|
38
|
+
</div>
|
|
39
|
+
</div>
|
|
40
|
+
</body>
|
|
41
|
+
</html>
|
|
42
|
+
|