redis.tex

\chapter{Redis}

\begin{wrapfigure}{l}{0.3\textwidth}
  \vspace{-80pt}
  \begin{center}
    \includegraphics[width=0.28\textwidth]{redis.png}
  \end{center}
  \vspace{-20pt}
\end{wrapfigure}
Redis is an open source, advanced key-value store. It is often referred to as a data structure server since keys can contain strings, hashes, lists, sets and sorted sets.
You can run atomic operations on these types, like appending to a string; incrementing the value in a hash; pushing to a list; computing set intersection, union and difference; or getting the member with highest ranking in a sorted set.

\section{Short specification}

\begin{itemize}
  \item \textbf{Written in:} C/C++ (ANSI C)
  \item \textbf{Main point:} Blazing fast
  \item \textbf{License:} BSD
  \item \textbf{Protocol:} Telnet-like
  \item \textbf{Web site:} \href{http://redis.io}{redis.io}
\end{itemize}

\section{Main features}

\subsection{Speed}

Redis is written in ANSI C, and loads the whole dataset in memory, so it is wicked *fast!* Up to 110,000 SETs/second, 81,000 GETs/second can be achieved in an entry level Linux box.

\subsection{Support for Data Structure}

Values in Redis can be Strings as in a conventional key-value store, but also Lists, Sets, SortedSets. This data types allow pushing/poping elements, or adding/removing them, also perform server side union, intersection, difference between sets, and so forth depending on the types. Redis supports different kind of sorting abilities for Sets and Lists. You can think in Redis as a Data Structures Server, that allows you to model non trivial problems.

\subsection{Atomic Operations}

Redis operations working on the different Data Types are atomic, so setting or increasing a key, adding and removing elements from a set, increasing a counter will all be accomplished safely.

\subsection{Master/Slave Replication}

Redis supports a very simple and fast Master/Slave replication. Is so simple it takes only one line in the configuration file to set it up, and 21 seconds for a Slave to complete the initial sync of 10 MM key set in a Amazon EC2 instance.

\section{Strengths}

The obvious strength of Redis is speed, like so many key-value stores of its ilk. But more than most key-value stores, Redis provides the ability to store complex values like lists, hashes, and sets, and retrieve them based through operations specific to those datatypes. Beyond even a data structure store, however, Redis's durability options allow you to trade speed for data safety up to a fairly fine point. Built-in master-slave replication is another nice way of ensuring better durability without requiring the slowness of syncing an append-only file to disk on every operation. Additionally, replication is great for very high-read systems.\cite{seven_databases}

\section{Weaknesses}

Redis is fast largely because it resides in memory. Some may consider this cheating, since of course a database that never hits the disk will be fast. A main memory database has an inherent durability problem; namely, if you shut down the database before a snapshot occurs, you can lose data. Even if you set the append-only file to disk sync on every operation, you run a risk with playing back expiry values, since time-based events can never be counted on to replay in exactly the same manner—though in fairness this case is more hypothetical than practical.

Redis also does not support datasets larger than your available RAM (Redis is removing virtual memory support), so its size has a practical limitation. Although there is a Redis Cluster currently in development to grow beyond a single-machine’s RAM requirements, anyone wanting to cluster Redis must currently roll their own with a client that supports it.\cite{seven_databases}

\section{Tips}

\subsection{Using 32 bit instances}

Redis compiled with 32 bit target uses a lot less memory per key, since pointers are small, but such an instance will be limited to 4 GB of maximum memory usage. To compile Redis as 32 bit binary use make 32bit. RDB and AOF files are compatible between 32 bit and 64 bit instances (and between little and big endian of course) so you can switch from 32 to 64 bit, or the contrary, without problems.

\subsection{Use hashes when possible}

Small hashes are encoded in a very small space, so you should try representing your data using hashes every time it is possible. For instance if you have objects representing users in a web application, instead of using different keys for name, surname, email, password, use a single hash with all the required fields.

\section{Use cases}

\begin{itemize}
  \item Session Storage
  \item Cache Storage
  \item Job Queue
  \item Real time analysis
  \item Pub/Sub
\end{itemize}