database names?

[Tim Lossen]

while writing up a recipe [1] on how to work with multiple databases,
i started to wonder: why is there no way in redis to give databases
a name? is there any deeper reason?

if you came across the statement

SELECT web-sessions

somewhere in your (or somebody elses) code, wouldn't that be much
clearer and easier to understand / debug than a cryptic

SELECT 7

statement?

just curious
tim

[1] http://www.rediscookbook.com/multiple_databases.html

--
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.
For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.

[Aníbal Rojas]

Tim,

The only thing I actually used another DB for is running our app
test suite in 15 in my dev box. In general another Redis instance make
much more sense than using another DB.

--
Aníbal Rojas
Ruby on Rails Web Developer
http://www.google.com/profiles/anibalrojas

[Mathias Meyer]

On Sat, May 15, 2010 at 12:15 PM, Tim Lossen <t...@lossen.de> wrote:
> while writing up a recipe [1] on how to work with multiple databases,
> i started to wonder: why is there no way in redis to give databases
> a name? is there any deeper reason?
>
> if you came across the statement
>
>  SELECT web-sessions
>
> somewhere in your (or somebody elses) code, wouldn't that be much
> clearer and easier to understand / debug than a cryptic
>
>  SELECT 7
>
> statement?
>

The simple answer is that you just shouldn't use the database feature
at all, but instead use proper key names to logically seperate your
data. Instead of having a database called web-sessions, use a key
namespace called web-sessions, and have all the keys in there.

I'd say (and that is just my opinion) using databases to logically
separate data is the wrong approach, and I wouldn't recommend it in
the cookbook either. Using appropriate key namespaces is the natural
way to do that in a key-value store like Redis, and using databases to
separate them doesn't give you any real advantage, just confusion. If
you need full separation, use a different Redis instance, then you can
fine-tune the parameters for the use case at hand. Adding database
names might reduce that confusion, but a good solution would probably
be to remove them altogether.

Cheers, Mathias
--
http://scalarium.com | http://paperplanes.de
http://twitter.com/roidrage

[Salvatore Sanfilippo]

On Sat, May 15, 2010 at 12:15 PM, Tim Lossen <t...@lossen.de> wrote:

> while writing up a recipe [1] on how to work with multiple databases,
> i started to wonder: why is there no way in redis to give databases
> a name? is there any deeper reason?
>
> if you came across the statement
>
>  SELECT web-sessions
>
> somewhere in your (or somebody elses) code, wouldn't that be much
> clearer and easier to understand / debug than a cryptic
>
>  SELECT 7

Hey Tim!

I understand how this can be useful, but unfortunately I consider
Redis multiple database errors my worst decision in Redis design at
all... without any kind of real gain, it makes the internals a lot
more complex. The reality is that databases don't scale well for a
number of reason, like active expire of keys and VM. If the DB
selection can be performed with a string I can see this feature being
used as a scalable O(1) dictionary layer, that instead it is not.

With DB numbers, with a default of a few DBs, we are communication
better what this feature is and how can be used I think. I hope that
at some point we can drop the multiple DBs support at all, but I think
it is probably too late as there is a number of people relying on this
feature for their work.

Cheers,
Salvatore

> statement?
>
> just curious
> tim
>
> [1] http://www.rediscookbook.com/multiple_databases.html
>
> --
> 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.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
>

--
Salvatore 'antirez' Sanfilippo
http://invece.org

"Once you have something that grows faster than education grows,
you’re always going to get a pop culture.", Alan Kay

[Demis Bellot]

Hi Salvatore,

I think if you wanted to drop database support in future that an alternate solution that supports with the use-case of 'partitioning data' should be available in its place.

I think you were throwing around the idea for having different config files for each instance, e.g:

6379.conf

6380.conf

I think that the above is a good idea as it will allow a 'master' init script to control all instances. Maybe some of the folk at VMWare has some alternate valuable input on this subject.

If it impacts the final solution at all, I think it should be transparent as possible to clients whether their dealing with a seperate redis instance on a different port, or one on a different host.

If its any consolation, 'your worst design decision in Redis' is what triggered our final decision to switch from memcached to Redis.

We have multiple application-level caches and we had a requirement to invalidate them independently.

Cheers,

Demis

[Demis Bellot]

Also if you want to be able to drop support for this in future you should clearly document 'SELECT' as a deprecated operation and steer potential users to partitioning using redis on different instances.

- Demis

[Tim Lossen]

salvatore, you write:

> unfortunately I consider
> Redis multiple database errors my worst decision in Redis design at
> all... without any kind of real gain, it makes the internals a lot
> more complex.

this is very interesting, as it is not mentioned anywhere on the wiki.

> I hope that
> at some point we can drop the multiple DBs support at all, but I think
> it is probably too late as there is a number of people relying on this
> feature for their work.

well, if you have the courage to admit your error -- then maybe you can
also find the courage to remove this feature from redis again? in fact,
if it really makes the internals a lot less complex, why not rip it
out for
the 2.0 release?

i would prefer a simple and robust redis implementation every time over
marginal features. and i say that as somebody who is actively using
multiple databases at the moment. but as others have pointed out, there
are easy workarounds.

and if you think it is already "too late" now ..... it will probably
only get
worse over time.

cheers
tim

--
http://tim.lossen.de

[Ted Nyman]

My €0.02 on the matter: multiple db/keyspaces can sometimes be
helpful for testing/benchmarking/etc.

So what we could do is be explicit both in the wiki and in redis.conf,
that *that* is the purpose of multi-db; and, also, at the same time,
begin to deprecate the feature in the 2.0 release. This would have the
double benefit of not breaking anyone's code, as well as informing
people about why they shouldn't use multi db's/when it might be okay
to do so.

-Ted