1*572c4311Sfengbojiang[Note: this is the Redis manifesto, for general information about 2*572c4311Sfengbojiang installing and running Redis read the README file instead.] 3*572c4311Sfengbojiang 4*572c4311SfengbojiangRedis Manifesto 5*572c4311Sfengbojiang=============== 6*572c4311Sfengbojiang 7*572c4311Sfengbojiang1 - A DSL for Abstract Data Types. Redis is a DSL (Domain Specific Language) 8*572c4311Sfengbojiang that manipulates abstract data types and implemented as a TCP daemon. 9*572c4311Sfengbojiang Commands manipulate a key space where keys are binary-safe strings and 10*572c4311Sfengbojiang values are different kinds of abstract data types. Every data type 11*572c4311Sfengbojiang represents an abstract version of a fundamental data structure. For instance 12*572c4311Sfengbojiang Redis Lists are an abstract representation of linked lists. In Redis, the 13*572c4311Sfengbojiang essence of a data type isn't just the kind of operations that the data types 14*572c4311Sfengbojiang support, but also the space and time complexity of the data type and the 15*572c4311Sfengbojiang operations performed upon it. 16*572c4311Sfengbojiang 17*572c4311Sfengbojiang2 - Memory storage is #1. The Redis data set, composed of defined key-value 18*572c4311Sfengbojiang pairs, is primarily stored in the computer's memory. The amount of memory in 19*572c4311Sfengbojiang all kinds of computers, including entry-level servers, is increasing 20*572c4311Sfengbojiang significantly each year. Memory is fast, and allows Redis to have very 21*572c4311Sfengbojiang predictable performance. Datasets composed of 10k or 40 millions keys will 22*572c4311Sfengbojiang perform similarly. Complex data types like Redis Sorted Sets are easy to 23*572c4311Sfengbojiang implement and manipulate in memory with good performance, making Redis very 24*572c4311Sfengbojiang simple. Redis will continue to explore alternative options (where data can 25*572c4311Sfengbojiang be optionally stored on disk, say) but the main goal of the project remains 26*572c4311Sfengbojiang the development of an in-memory database. 27*572c4311Sfengbojiang 28*572c4311Sfengbojiang3 - Fundamental data structures for a fundamental API. The Redis API is a direct 29*572c4311Sfengbojiang consequence of fundamental data structures. APIs can often be arbitrary but 30*572c4311Sfengbojiang not an API that resembles the nature of fundamental data structures. If we 31*572c4311Sfengbojiang ever meet intelligent life forms from another part of the universe, they'll 32*572c4311Sfengbojiang likely know, understand and recognize the same basic data structures we have 33*572c4311Sfengbojiang in our computer science books. Redis will avoid intermediate layers in API, 34*572c4311Sfengbojiang so that the complexity is obvious and more complex operations can be 35*572c4311Sfengbojiang performed as the sum of the basic operations. 36*572c4311Sfengbojiang 37*572c4311Sfengbojiang4 - We believe in code efficiency. Computers get faster and faster, yet we 38*572c4311Sfengbojiang believe that abusing computing capabilities is not wise: the amount of 39*572c4311Sfengbojiang operations you can do for a given amount of energy remains anyway a 40*572c4311Sfengbojiang significant parameter: it allows to do more with less computers and, at 41*572c4311Sfengbojiang the same time, having a smaller environmental impact. Similarly Redis is 42*572c4311Sfengbojiang able to "scale down" to smaller devices. It is perfectly usable in a 43*572c4311Sfengbojiang Raspberry Pi and other small ARM based computers. Faster code having 44*572c4311Sfengbojiang just the layers of abstractions that are really needed will also result, 45*572c4311Sfengbojiang often, in more predictable performances. We think likewise about memory 46*572c4311Sfengbojiang usage, one of the fundamental goals of the Redis project is to 47*572c4311Sfengbojiang incrementally build more and more memory efficient data structures, so that 48*572c4311Sfengbojiang problems that were not approachable in RAM in the past will be perfectly 49*572c4311Sfengbojiang fine to handle in the future. 50*572c4311Sfengbojiang 51*572c4311Sfengbojiang5 - Code is like a poem; it's not just something we write to reach some 52*572c4311Sfengbojiang practical result. Sometimes people that are far from the Redis philosophy 53*572c4311Sfengbojiang suggest using other code written by other authors (frequently in other 54*572c4311Sfengbojiang languages) in order to implement something Redis currently lacks. But to us 55*572c4311Sfengbojiang this is like if Shakespeare decided to end Enrico IV using the Paradiso from 56*572c4311Sfengbojiang the Divina Commedia. Is using any external code a bad idea? Not at all. Like 57*572c4311Sfengbojiang in "One Thousand and One Nights" smaller self contained stories are embedded 58*572c4311Sfengbojiang in a bigger story, we'll be happy to use beautiful self contained libraries 59*572c4311Sfengbojiang when needed. At the same time, when writing the Redis story we're trying to 60*572c4311Sfengbojiang write smaller stories that will fit in to other code. 61*572c4311Sfengbojiang 62*572c4311Sfengbojiang6 - We're against complexity. We believe designing systems is a fight against 63*572c4311Sfengbojiang complexity. We'll accept to fight the complexity when it's worthwhile but 64*572c4311Sfengbojiang we'll try hard to recognize when a small feature is not worth 1000s of lines 65*572c4311Sfengbojiang of code. Most of the time the best way to fight complexity is by not 66*572c4311Sfengbojiang creating it at all. Complexity is also a form of lock-in: code that is 67*572c4311Sfengbojiang very hard to understand cannot be modified by users in an independent way 68*572c4311Sfengbojiang regardless of the license. One of the main Redis goals is to remain 69*572c4311Sfengbojiang understandable, enough for a single programmer to have a clear idea of how 70*572c4311Sfengbojiang it works in detail just reading the source code for a couple of weeks. 71*572c4311Sfengbojiang 72*572c4311Sfengbojiang7 - Threading is not a silver bullet. Instead of making Redis threaded we 73*572c4311Sfengbojiang believe on the idea of an efficient (mostly) single threaded Redis core. 74*572c4311Sfengbojiang Multiple of such cores, that may run in the same computer or may run 75*572c4311Sfengbojiang in multiple computers, are abstracted away as a single big system by 76*572c4311Sfengbojiang higher order protocols and features: Redis Cluster and the upcoming 77*572c4311Sfengbojiang Redis Proxy are our main goals. A shared nothing approach is not just 78*572c4311Sfengbojiang much simpler (see the previous point in this document), is also optimal 79*572c4311Sfengbojiang in NUMA systems. In the specific case of Redis it allows for each instance 80*572c4311Sfengbojiang to have a more limited amount of data, making the Redis persist-by-fork 81*572c4311Sfengbojiang approach more sounding. In the future we may explore parallelism only for 82*572c4311Sfengbojiang I/O, which is the low hanging fruit: minimal complexity could provide an 83*572c4311Sfengbojiang improved single process experience. 84*572c4311Sfengbojiang 85*572c4311Sfengbojiang8 - Two levels of API. The Redis API has two levels: 1) a subset of the API fits 86*572c4311Sfengbojiang naturally into a distributed version of Redis and 2) a more complex API that 87*572c4311Sfengbojiang supports multi-key operations. Both are useful if used judiciously but 88*572c4311Sfengbojiang there's no way to make the more complex multi-keys API distributed in an 89*572c4311Sfengbojiang opaque way without violating our other principles. We don't want to provide 90*572c4311Sfengbojiang the illusion of something that will work magically when actually it can't in 91*572c4311Sfengbojiang all cases. Instead we'll provide commands to quickly migrate keys from one 92*572c4311Sfengbojiang instance to another to perform multi-key operations and expose the 93*572c4311Sfengbojiang trade-offs to the user. 94*572c4311Sfengbojiang 95*572c4311Sfengbojiang9 - We optimize for joy. We believe writing code is a lot of hard work, and the 96*572c4311Sfengbojiang only way it can be worth is by enjoying it. When there is no longer joy in 97*572c4311Sfengbojiang writing code, the best thing to do is stop. To prevent this, we'll avoid 98*572c4311Sfengbojiang taking paths that will make Redis less of a joy to develop. 99*572c4311Sfengbojiang 100*572c4311Sfengbojiang10 - All the above points are put together in what we call opportunistic 101*572c4311Sfengbojiang programming: trying to get the most for the user with minimal increases 102*572c4311Sfengbojiang in complexity (hanging fruits). Solve 95% of the problem with 5% of the 103*572c4311Sfengbojiang code when it is acceptable. Avoid a fixed schedule but follow the flow of 104*572c4311Sfengbojiang user requests, inspiration, Redis internal readiness for certain features 105*572c4311Sfengbojiang (sometimes many past changes reach a critical point making a previously 106*572c4311Sfengbojiang complex feature very easy to obtain). 107