"Fossies" - the Fresh Open Source Software Archive

Member "redis-7.0.8/MANIFESTO" (16 Jan 2023, 6888 Bytes) of package /linux/misc/redis-7.0.8.tar.gz:

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