More than 1 DB discouraged and will be deprecated?

[re...@jwhitesolutions.com]

Hello,

 

I have seen in various posts that more than 1 DB in Redis is discouraged and will be deprecated in the future.  Is this the "official" guidance?  It seems that a common "workaround" is to have the clients prefix keys in a single DB to create pseudo namespaces.  Is this a feature that might be included/supported/managed by Redis in the future?

 

For my own knowledge, why is it a better option to have the clients manage these namespaces instead of Redis?

 

Thanks,

 

Joe

[Pedro Melo]

On Thu, Jan 24, 2013 at 4:18 PM, <re...@jwhitesolutions.com> wrote:

Hello,

 

I have seen in various posts that more than 1 DB in Redis is discouraged and will be deprecated in the future.  Is this the "official" guidance?

Yes. With redis-cluster, only a single DB will be supported.

 

  It seems that a common "workaround" is to have the clients prefix keys in a single DB to create pseudo namespaces.  Is this a feature that might be included/supported/managed by Redis in the future?

Clients can do that on their side just fine. What would be the point of moving that to the server? And how would you map a connection to a specific namespace?

While it is an interesting idea, implementing it on the client side is equally simple and effective.

For my own knowledge, why is it a better option to have the clients manage these namespaces instead of Redis?

I don't think there is a "better" one way or the other. Both solutios have merit. I don't recall why Salvatore decided to deprecate multiple DBs…

As for server-side namespaces, I guess you could code a "NAMESPACE blargh" command that would set the connection namespace to "blargh" and from then on, all operations on keys would assume the "blargh" prefix. It is an interesting concept, but again you can do most of this on the client side.

Bye,

-- 

Pedro Melo
@pedromelo
http://www.simplicidade.org/
http://about.me/melo
xmpp:me...@simplicidade.org
mailto:me...@simplicidade.org

[Dave Peticolas]

2013/1/24 Pedro Melo <me...@simplicidade.org>

On Thu, Jan 24, 2013 at 4:18 PM, <re...@jwhitesolutions.com> wrote:

Hello,

 

I have seen in various posts that more than 1 DB in Redis is discouraged and will be deprecated in the future.  Is this the "official" guidance?

Yes. With redis-cluster, only a single DB will be supported.

With redis-cluster only a single DB will be supported, but I believe the last word is that

multiple DBs *will continue to be supported for non-cluster mode*.

 

 

  It seems that a common "workaround" is to have the clients prefix keys in a single DB to create pseudo namespaces.  Is this a feature that might be included/supported/managed by Redis in the future?

Clients can do that on their side just fine. What would be the point of moving that to the server? And how would you map a connection to a specific namespace?

While it is an interesting idea, implementing it on the client side is equally simple and effective.

For my own knowledge, why is it a better option to have the clients manage these namespaces instead of Redis?

I don't think there is a "better" one way or the other. Both solutios have merit. I don't recall why Salvatore decided to deprecate multiple DBs…

He also decided to un-deprecate it for non-cluster mode.

 

As for server-side namespaces, I guess you could code a "NAMESPACE blargh" command that would set the connection namespace to "blargh" and from then on, all operations on keys would assume the "blargh" prefix. It is an interesting concept, but again you can do most of this on the client side.

Bye,

-- 

Pedro Melo
@pedromelo
http://www.simplicidade.org/
http://about.me/melo
xmpp:me...@simplicidade.org
mailto:me...@simplicidade.org

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To post to this group, send email to redi...@googlegroups.com.
To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Pedro Melo]

Hi,

On Thu, Jan 24, 2013 at 4:38 PM, Dave Peticolas <da...@krondo.com> wrote:

2013/1/24 Pedro Melo <me...@simplicidade.org>

On Thu, Jan 24, 2013 at 4:18 PM, <re...@jwhitesolutions.com> wrote:

I have seen in various posts that more than 1 DB in Redis is discouraged and will be deprecated in the future.  Is this the "official" guidance?

Yes. With redis-cluster, only a single DB will be supported.

With redis-cluster only a single DB will be supported, but I believe the last word is that

multiple DBs *will continue to be supported for non-cluster mode*.

[…] 

 

I don't think there is a "better" one way or the other. Both solutios have merit. I don't recall why Salvatore decided to deprecate multiple DBs…

He also decided to un-deprecate it for non-cluster mode.

Thanks, I missed that part.

Bye,

-- 

[CharSyam]

See the cluster.c source. it just allows only DB 0,

I think using mulitple DB in one instance has the same performance compare to using one DB. but I know it is often convenient to manage data. and it makes using proxy(like twemproxy) hard.

I just recommend considering using one DB

2013/1/24 Pedro Melo <me...@simplicidade.org>

--

[re...@jwhitesolutions.com]

Pedro,

My interest in Redis is for caching.  I understand that this may not be Redis's core/intended functionality.  With that in mind though, there are several key/value stores that support having "named" maps.  The idea is that each named map is used to store a specific segment of data (Similar to how collections are used in Mongo).  The advantage is that usually you could have different configurations for each map (transactional behavior, eviction policies etc.).  Granted Redis doesn't support these configurations now, it would certainly be a nice feature in the future.  It would also allow you to get statistics about the caches usage for each of the maps independent of the other.  Today, because everything looks the same on the server side, we don't have a lot of insight into how the cache is used.

Thoughts?

-joe

[Pedro Melo]

Hi,

On Thu, Jan 24, 2013 at 6:50 PM, <re...@jwhitesolutions.com> wrote:

Pedro,

My interest in Redis is for caching.  I understand that this may not be Redis's core/intended functionality.

Actually, it is my main use for Redis also.

 

  With that in mind though, there are several key/value stores that support having "named" maps.  The idea is that each named map is used to store a specific segment of data (Similar to how collections are used in Mongo).  The advantage is that usually you could have different configurations for each map (transactional behavior, eviction policies etc.).  Granted Redis doesn't support these configurations now, it would certainly be a nice feature in the future.  It would also allow you to get statistics about the caches usage for each of the maps independent of the other.  Today, because everything looks the same on the server side, we don't have a lot of insight into how the cache is used.

Thoughts?

Given that Redis is single threaded, I think you'll be better off running multiple redis instances.

You can tailor each one to the specific needs of the objects you'll cache into them, and if you have multiple processors, you'll be able to use more of them. You'll also be able to monitor them (statistics and such) to tweak the performance of each one independently.

So you already can have most of you mentioned above.

Best regards,

[Joe Public]

Good points Pedro, thanks.

Joe

--