「RedisReadme」の編集履歴（バックアップ）一覧はこちら

「RedisReadme」(2009/06/13 (土) 18:07:39) の最新版変更点

追加された行は緑色になります。

削除された行は赤色になります。

Updated May 22, 2009 by antirez
README  

 イントロダクション

Redis はデータベースです。redis をより特徴付けているのは、キーに関連付けられた値を辞書として実装しているとてもシンプルなデータベースということです。例えば、キー "surname_1992" は文字列 "Smith" を取り出せます。 Redis で面白いのは、キーに関連付けられる値は単純な文字列だけに限らず、 たくさんのサーバ側でのこのデータ型に関連付けられたアトミックな操作の lists や sets も関連付けることができることです。 

Redis はメモリにデータセットを置きますが、非同期でデータセットのダンプをディスクに時々書き込むのでデータセットは永続化されます。このダンプはサーバが再起動したときにいつも読み込まれます。

Redis は数秒の elapzed やデータが変更された後にデータセットを保存するように構成できます。例えば、1000の変更があると保存するようにや、少なくとも 60 秒毎に保存するように Redis に伝えることができます。あなたはこのたくさんの組み合わせを指定できます。

データは非同期で書かれているため、もしシステムクラッシュが起こったとしても、最後の少しの問い合わせが失われるだけです（これはほとんどのアプリケーションで許容されています）。Redis は もしあなたのアプリケーションが少しのレコードでも失われるのが許容できないなら、早いうちから問題ないようにするために master-slave レプリケーションをサポートしようと思っています。（？）

 key-value 型データベースを超えて

ほとんどの key-value 型データベースははキーと値は単なる文字列です。Redis ではキーはもちろん文字列だけですが、関連付けられた値は文字列やリストやセットやこのデータ型に対する複雑な単一操作を実行するコマンドがあるので、Redis をデータ構造サーバとして考えることが出来ます。

例えば、 O(1) に LPUSH か RPUSH 操作を使って、キー"mylist"に保存されたリストに要素を追加することが出来ます。その後、LRANGE で要素のレンジを取得したり LTRIM でリストを整えたりすることが出来ます。Sets もまたとてもフレキシブルで、Sets (ソートされていない文字列の集合)から要素を加えたり除いたりでき、 サーバ側でintersection , union,  Sets の違いを問い合わせます。

この特徴（ソートされたリストとセットのサポート）すべてのおかげで、スケーラブルなアプリケーションのための唯一のDBとしてどんな関係データベースも必要とせず Redis を使うことが可能なのです。私たちは実世界に例を示すために PHP + Redis でシンプルな Twitter クローンを書きました。このリンクの先にはとても単純な言葉でデザインと内部について説明する記事があります。


 Redis と Memcached との違いは何か

違いは以下：

Memcached は永続化されず、キャッシュとして使うことを主な目標として、節約せず単にメモリにすべて保持するだけです。Redis はアプリケーションのメインDBとして使うことが出来ます。 私たちは Redis だけをデータベースとして使う単純な Twitter クローンを書きました。
Redis は memcached のように key-value モデルで、キーは単なる文字列ですが、Redis の値はリストとセットや intersections のような複雑な操作ができ、 set/get リストの n番目の要素を設定したり取得したり、要素を pop/push したりすることがセットとリストに対して出来ます。これは list をメッセージキューとして利用できることを意味します。


 Redis と Tokyo Cabinet / Tyrant との違いは何か

Redis と Tokyo Cabinet は同じアプリケーションに利用できますが、実際は大きく異なっています。もしあなたがスケーラブルなものにかかわる人の twitter メッセージを読んだら、両方の製品ともうまくいくと報告されるでしょうが、どちらか一方がベストチョイスな時があるのも確かです。いくつかの違いをフォローします (私は偏っていると思うので自分で確かめてください)。

Tokyo Cabinet writes synchronously on disk, Redis takes the whole dataset on memory and writes on disk asynchronously. Tokyo Cabinet is safer and probably a better idea if your dataset is going to be bigger than RAM, but Redis is faster (note that Redis supports master-slave replication that is trivial to setup, so you are safe anyway if you want a setup where data can't be lost even after a disaster).
Redis supports higher level operations and data structures. Tokyo Cabinet supports a kind of database that is able to organize data into rows with named fields (in a way very similar to Berkeley DB) but can't do things like server side List and Set operations Redis is able to do: pushing or popping from Lists in an atomic way, in O(1) time complexity, server side Set intersections, SortCommand ing of schema free data in complex ways (Btw TC supports sorting in the table-based database format). Redis on the other hand does not support the abstraction of tables with fields, the idea is that you can build this stuff in software easily if you really need a table-alike approach.
Tokyo Cabinet does not implement a networking layer. You have to use a networking layer called Tokyo Tyrant that interfaces to Tokyo Cabinet so you can talk to Tokyo Cabinet in a client-server fashion. In Redis the networking support is built-in inside the server, and is basically the only interface between the external world and the dataset.
Redis is reported to be much faster, especially if you plan to access Tokyo Cabinet via Tokyo Tyrant. Here I can only say that with Redis you can expect 100,000 operations/seconds with a normal Linux box and 50 concurrent clients. You should test Redis, Tokyo, and the other alternatives with your specific work load to get a feeling about performances for your application.
Redis is (IMHO) generally an higher level and simpler to use beast in the operations supported, and to get started. the command reference CommandReference to get a feeling. You can even start playing with Redis by telnet after reading the five minutes tutorial at the end of this README file. To implement new client libraries is trivial. the protocol specification ProtocolSpecification for more information.
Redis is not an on-disk DB engine like Tokyo: the latter can be used as a fast DB engine in your C project without the networking overhead just linking to the library. Still in many scalable applications you need multiple servers talking with multiple clients, so the client-server model is almost always needed, this is why in Redis this is built-in.


 Redis はロックをサポートしますか？

いいえ、これはロックフリーアルゴリズムによってプログラマーが redis を使うようアトミック関数を提供するつもりだからです。例えば10台のコンピュータと1台の Redis サーバがあるとしましょう。あなたはとても大きなテキストにある言葉を数えたがっています。この大きなテキストは10台のコンピュータにそれぞれ分割され、どのコンピュータも部分を処理して単語を見つける毎にアトミックにカウンタを増やす Redis の INCR コマンドを使うでしょう。

INCR/DECR はアトミックプリミティブだけではなく、リストの PUSH/POP のような POP RANDOM KEY 操作, UPDATE など。例えば、分散アルゴリズムを実装して Tuple Space (http://en.wikipedia.org/wiki/Tuple_space) のように Redis を使うことも出来ます。 

(News: key-granularity（主な粒度？）でのロックは計画されています)


 複数の databases サポート

他の同期関数は複数のデータベースをサポートします。 既定では、 DB 0 がすべての新しい接続に選択されますが、SELECT コマンドを使うことにより別のデータベースを選択することが可能です。 MOVE 操作であるデータベースから別のデータベースにアトミックにアイテムを移動させることが出来ます。これは'RANDOMKEY' コマンドと一緒にロックフリーアルゴリズムのベースとして使うことが出来ます。 


 Redis データ型

Redis は値として次の3つのデータ型をサポートします。：

Strings：単なるバイト列。 Redis Stringはバイナリセーフで、テキストだけでなく画像や圧縮データなどを保持します。
Lists：文字列のリスト, 先頭や最後に新しい文字を追加するような、リストの長さや要素の幅を取得したり、与えられた長さにリストを切り出したり、リストをソートしたりする操作などをサポートします。
Sets: 文字列のソートされていないセット。セットから要素を追加したり削除したり、セットの和集合や全集合や差集合などを取ったり出来ます。

値は Strings や Lists や Sets かも知れません。キーは改行("\n")やスペース(" ")を含まない文字列のサブセットです。

String は Redis が分析しないといけない数値を持っている可能性に注意してください。例えば INCR コマンドは、指定されたキーに保存されている値をアトミックに増加させます。この場合、Redis は、内部で64-bit で署名された整数の'long long'型で保存された整数として扱うことが出来きます。

 実装の詳細

Strings は動的に文字の文字列を割り当てるよう実装されています。 Lists は2倍にリンクされたリストのキャッシュ長で実装されています。 Sets は衝突を回避するのに推論(？)を使用したハッシュテーブルを使って実装されています。

 Redis チュートリアル

(note, you can skip this section if you are only interested in "formal" doc.)

Later in this document you can find detailed information about Redis commands, the protocol specification, and so on. This kind of documentation is useful but... if you are new to Redis it is also BORING! The Redis protocol is designed so that is both pretty efficient to be parsed by computers, but simple enough to be used by humans just poking around with the 'telnet' command, so this section will show to the reader how to play a bit with Redis to get an initial feeling about it, and how it works.

To start just compile redis with 'make' and start it with './redis-server'. The server will start and log stuff on the standard output, if you want it to log more edit redis.conf, set the loglevel to debug, and restart it.

You can specify a configuration file as unique parameter:

./redis-server /etc/redis.conf
This is NOT required. The server will start even without a configuration file using a default built-in configuration.

Now let's try to set a key to a given value:

$ telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SET foo 3  
bar
+OK
The first line we sent to the server is "set foo 3". This means "set the key foo with the following three bytes I'll send you". The following line is the "bar" string, that is, the three bytes. So the effect is to set the key "foo" to the value "bar". Very simple!

(note that you can send commands in lowercase and it will work anyway, commands are not case sensitive)

Note that after the first and the second line we sent to the server there is a newline at the end. The server expects commands terminated by "\r\n" and sequence of bytes terminated by "\r\n". This is a minimal overhead from the point of view of both the server and client but allows us to play with Redis with the telnet command easily.

The last line of the chat between server and client is "+OK". This means our key was added without problems. Actually SET can never fail but the "+OK" sent lets us know that the server received everything and the command was actually executed.

Let's try to get the key content now:

GET foo
$3
bar
Ok that's very similar to 'set', just the other way around. We sent "get foo", the server replied with a first line that is just the $ character follwed by the number of bytes the value stored at key contained, followed by the actual bytes. Again "\r\n" are appended both to the bytes count and the actual data. In Redis slang this is called a bulk reply.

What about requesting a non existing key?

GET blabla
$-1
When the key does not exist instead of the length, just the "$-1" string is sent. Since a -1 length of a bulk reply has no meaning it is used in order to specifiy a 'nil' value and distinguish it from a zero length value. Another way to check if a given key exists or not is indeed the EXISTS command:

EXISTS nokey
:0
EXISTS foo
:1
As you can see the server replied ':0' the first time since 'nokey' does not exist, and ':1' for 'foo', a key that actually exists. Replies starting with the colon character are integer reply.

Ok... now you know the basics, read the REDIS COMMAND REFERENCE section to learn all the commands supported by Redis and the PROTOCOL SPECIFICATION section for more details about the protocol used if you plan to implement one for a language missing a decent client implementation.



ライセンス

Redis is released under the BSD license. See the COPYING file for more information.

Credits

Redis is written and maintained by Salvatore Sanfilippo, Aka 'antirez'.

Enjoy, antirez

Updated May 22, 2009 by antirez
README  

 イントロダクション

Redis はデータベースです。redis をより特徴付けているのは、キーに関連付けられた値を辞書として実装しているとてもシンプルなデータベースということです。例えば、キー "surname_1992" は文字列 "Smith" を取り出せます。 Redis で面白いのは、キーに関連付けられる値は単純な文字列だけに限らず、 たくさんのサーバ側でのこのデータ型に関連付けられたアトミックな操作の lists や sets も関連付けることができることです。 

Redis はメモリにデータセットを置きますが、非同期でデータセットのダンプをディスクに時々書き込むのでデータセットは永続化されます。このダンプはサーバが再起動したときにいつも読み込まれます。

Redis は数秒の elapzed やデータが変更された後にデータセットを保存するように構成できます。例えば、1000の変更があると保存するようにや、少なくとも 60 秒毎に保存するように Redis に伝えることができます。あなたはこのたくさんの組み合わせを指定できます。

データは非同期で書かれているため、もしシステムクラッシュが起こったとしても、最後の少しの問い合わせが失われるだけです（これはほとんどのアプリケーションで許容されています）。Redis は もしあなたのアプリケーションが少しのレコードでも失われるのが許容できないなら、早いうちから問題ないようにするために master-slave レプリケーションをサポートしようと思っています。（？）

 key-value 型データベースを超えて

ほとんどの key-value 型データベースははキーと値は単なる文字列です。Redis ではキーはもちろん文字列だけですが、関連付けられた値は文字列やリストやセットやこのデータ型に対する複雑な単一操作を実行するコマンドがあるので、Redis をデータ構造サーバとして考えることが出来ます。

例えば、 O(1) に LPUSH か RPUSH 操作を使って、キー"mylist"に保存されたリストに要素を追加することが出来ます。その後、LRANGE で要素のレンジを取得したり LTRIM でリストを整えたりすることが出来ます。Sets もまたとてもフレキシブルで、Sets (ソートされていない文字列の集合)から要素を加えたり除いたりでき、 サーバ側でintersection , union,  Sets の違いを問い合わせます。

この特徴（ソートされたリストとセットのサポート）すべてのおかげで、スケーラブルなアプリケーションのための唯一のDBとしてどんな関係データベースも必要とせず Redis を使うことが可能なのです。私たちは実世界に例を示すために PHP + Redis でシンプルな Twitter クローンを書きました。このリンクの先にはとても単純な言葉でデザインと内部について説明する記事があります。


 Redis と Memcached との違いは何か

違いは以下：

Memcached は永続化されず、キャッシュとして使うことを主な目標として、節約せず単にメモリにすべて保持するだけです。Redis はアプリケーションのメインDBとして使うことが出来ます。 私たちは Redis だけをデータベースとして使う単純な Twitter クローンを書きました。
Redis は memcached のように key-value モデルで、キーは単なる文字列ですが、Redis の値は List と Set の 共通集合のような複雑な操作ができ、 set/get リストの n番目の要素を設定したり取得したり、要素を pop/push したりすることがセットとリストに対して出来ます。これは list をメッセージキューとして利用できることを意味します。


 Redis と Tokyo Cabinet / Tyrant との違いは何か

Redis と Tokyo Cabinet は同じアプリケーションに利用できますが、実際は大きく異なっています。もしあなたがスケーラブルなものにかかわる人の twitter メッセージを読んだら、両方の製品ともうまくいくと報告されるでしょうが、どちらか一方がベストチョイスな時があるのも確かです。いくつかの違いをフォローします (私は偏っていると思うので自分で確かめてください)。

Tokyo Cabinet writes synchronously on disk, Redis takes the whole dataset on memory and writes on disk asynchronously. Tokyo Cabinet is safer and probably a better idea if your dataset is going to be bigger than RAM, but Redis is faster (note that Redis supports master-slave replication that is trivial to setup, so you are safe anyway if you want a setup where data can't be lost even after a disaster).
Redis supports higher level operations and data structures. Tokyo Cabinet supports a kind of database that is able to organize data into rows with named fields (in a way very similar to Berkeley DB) but can't do things like server side List and Set operations Redis is able to do: pushing or popping from Lists in an atomic way, in O(1) time complexity, server side Set intersections, SortCommand ing of schema free data in complex ways (Btw TC supports sorting in the table-based database format). Redis on the other hand does not support the abstraction of tables with fields, the idea is that you can build this stuff in software easily if you really need a table-alike approach.
Tokyo Cabinet does not implement a networking layer. You have to use a networking layer called Tokyo Tyrant that interfaces to Tokyo Cabinet so you can talk to Tokyo Cabinet in a client-server fashion. In Redis the networking support is built-in inside the server, and is basically the only interface between the external world and the dataset.
Redis is reported to be much faster, especially if you plan to access Tokyo Cabinet via Tokyo Tyrant. Here I can only say that with Redis you can expect 100,000 operations/seconds with a normal Linux box and 50 concurrent clients. You should test Redis, Tokyo, and the other alternatives with your specific work load to get a feeling about performances for your application.
Redis is (IMHO) generally an higher level and simpler to use beast in the operations supported, and to get started. the command reference CommandReference to get a feeling. You can even start playing with Redis by telnet after reading the five minutes tutorial at the end of this README file. To implement new client libraries is trivial. the protocol specification ProtocolSpecification for more information.
Redis is not an on-disk DB engine like Tokyo: the latter can be used as a fast DB engine in your C project without the networking overhead just linking to the library. Still in many scalable applications you need multiple servers talking with multiple clients, so the client-server model is almost always needed, this is why in Redis this is built-in.


 Redis はロックをサポートしますか？

いいえ、これはロックフリーアルゴリズムによってプログラマーが redis を使うようアトミック関数を提供するつもりだからです。例えば10台のコンピュータと1台の Redis サーバがあるとしましょう。あなたはとても大きなテキストにある言葉を数えたがっています。この大きなテキストは10台のコンピュータにそれぞれ分割され、どのコンピュータも部分を処理して単語を見つける毎にアトミックにカウンタを増やす Redis の INCR コマンドを使うでしょう。

INCR/DECR はアトミックプリミティブだけではなく、リストの PUSH/POP のような POP RANDOM KEY 操作, UPDATE など。例えば、分散アルゴリズムを実装して Tuple Space (http://en.wikipedia.org/wiki/Tuple_space) のように Redis を使うことも出来ます。 

(News: key-granularity（主な粒度？）でのロックは計画されています)


 複数の databases サポート

他の同期関数は複数のデータベースをサポートします。 既定では、 DB 0 がすべての新しい接続に選択されますが、SELECT コマンドを使うことにより別のデータベースを選択することが可能です。 MOVE 操作であるデータベースから別のデータベースにアトミックにアイテムを移動させることが出来ます。これは'RANDOMKEY' コマンドと一緒にロックフリーアルゴリズムのベースとして使うことが出来ます。 


 Redis データ型

Redis は値として次の3つのデータ型をサポートします。：

Strings：単なるバイト列。 Redis Stringはバイナリセーフで、テキストだけでなく画像や圧縮データなどを保持します。
Lists：文字列のリスト, 先頭や最後に新しい文字を追加するような、リストの長さや要素の幅を取得したり、与えられた長さにリストを切り出したり、リストをソートしたりする操作などをサポートします。
Sets: 文字列のソートされていないセット。セットから要素を追加したり削除したり、セットの和集合や全集合や差集合などを取ったり出来ます。

値は Strings や Lists や Sets かも知れません。キーは改行("\n")やスペース(" ")を含まない文字列のサブセットです。

String は Redis が分析しないといけない数値を持っている可能性に注意してください。例えば INCR コマンドは、指定されたキーに保存されている値をアトミックに増加させます。この場合、Redis は、内部で64-bit で署名された整数の'long long'型で保存された整数として扱うことが出来きます。

 実装の詳細

Strings は動的に文字の文字列を割り当てるよう実装されています。 Lists は2倍にリンクされたリストのキャッシュ長で実装されています。 Sets は衝突を回避するのに推論(？)を使用したハッシュテーブルを使って実装されています。

 Redis チュートリアル

(note, you can skip this section if you are only interested in "formal" doc.)

Later in this document you can find detailed information about Redis commands, the protocol specification, and so on. This kind of documentation is useful but... if you are new to Redis it is also BORING! The Redis protocol is designed so that is both pretty efficient to be parsed by computers, but simple enough to be used by humans just poking around with the 'telnet' command, so this section will show to the reader how to play a bit with Redis to get an initial feeling about it, and how it works.

To start just compile redis with 'make' and start it with './redis-server'. The server will start and log stuff on the standard output, if you want it to log more edit redis.conf, set the loglevel to debug, and restart it.

You can specify a configuration file as unique parameter:

./redis-server /etc/redis.conf
This is NOT required. The server will start even without a configuration file using a default built-in configuration.

Now let's try to set a key to a given value:

$ telnet localhost 6379
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
SET foo 3  
bar
+OK
The first line we sent to the server is "set foo 3". This means "set the key foo with the following three bytes I'll send you". The following line is the "bar" string, that is, the three bytes. So the effect is to set the key "foo" to the value "bar". Very simple!

(note that you can send commands in lowercase and it will work anyway, commands are not case sensitive)

Note that after the first and the second line we sent to the server there is a newline at the end. The server expects commands terminated by "\r\n" and sequence of bytes terminated by "\r\n". This is a minimal overhead from the point of view of both the server and client but allows us to play with Redis with the telnet command easily.

The last line of the chat between server and client is "+OK". This means our key was added without problems. Actually SET can never fail but the "+OK" sent lets us know that the server received everything and the command was actually executed.

Let's try to get the key content now:

GET foo
$3
bar
Ok that's very similar to 'set', just the other way around. We sent "get foo", the server replied with a first line that is just the $ character follwed by the number of bytes the value stored at key contained, followed by the actual bytes. Again "\r\n" are appended both to the bytes count and the actual data. In Redis slang this is called a bulk reply.

What about requesting a non existing key?

GET blabla
$-1
When the key does not exist instead of the length, just the "$-1" string is sent. Since a -1 length of a bulk reply has no meaning it is used in order to specifiy a 'nil' value and distinguish it from a zero length value. Another way to check if a given key exists or not is indeed the EXISTS command:

EXISTS nokey
:0
EXISTS foo
:1
As you can see the server replied ':0' the first time since 'nokey' does not exist, and ':1' for 'foo', a key that actually exists. Replies starting with the colon character are integer reply.

Ok... now you know the basics, read the REDIS COMMAND REFERENCE section to learn all the commands supported by Redis and the PROTOCOL SPECIFICATION section for more details about the protocol used if you plan to implement one for a language missing a decent client implementation.



ライセンス

Redis is released under the BSD license. See the COPYING file for more information.

Credits

Redis is written and maintained by Salvatore Sanfilippo, Aka 'antirez'.

Enjoy, antirez