Getting rid of databases

[catwell]

As far as I understand, Redis databases (the ones you SELECT) are
deprecated. I was wondering what the easiest way to migrate all my
data from multiple DBs to DB 0 by prefixing them would be. For
instance: "some:thing" in DB 7 would become "prefix7:some:thing" in DB
0.

Ideally I would like to write a tool that could do that independently
of what is stored in DB 7. I don't care if it operates on a running
Redis server or a RDB file, which means I would be fine with the
following interface for a CLI tool:

redis-db-migrate -i dump-orig.rdb -o dump-out.rdb -n 7 -p
"prefix7"

Did anybody already do something like that? Do you have ideas what the
best way to implement it would be?

[Demis Bellot]

Yeah you can either use a standard prefix like "db1:"

or alternatively just spawn different redis server instances and use different ports to distinguish the dbs, i.e:

localhost:6379 -> DB 0

localhost:6380 -> DB 1
localhost:6381 -> DB 2, etc.

--
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.

--
- Demis

http://twitter.com/demisbellot

http://www.servicestack.net/mythz_blog

[Louis-Philippe Perron]

Would be nice to have namespace support from within Redis, 

right now we depend on the client lib to do this like in:

https://github.com/defunkt/redis-namespace

https://github.com/lp/redis-keyspace

to be usable this design principle also needs to be re-implemented in each other client languages, including the Lua Scripting interpreter...

[Salvatore Sanfilippo]

Hi, actually support for multiple DBs is not going to be deprecated in
short time, but will NOT be part of Redis Cluster.

In general however is a bad idea to use the same Redis server for
multiple applications: for this use case the right thing to do is
spawning multiple instances, one per application.
When instead namespacing in the context of the same application is
needed, either use a prefix, or try to make your design better in
order to avoid namespaces.

For instance in order to write an application supporting multiple
blogs at the same time, the idea of namespacing per blog is IMHO a
broken design, and a good design is instead to have a blog ID and have
all the rest using this blog ID like: comments.blog:<id>.post:<id> or
alike.

Cheers,
Salvatore

> --
> 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
open source developer - VMware

http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele

[catwell]

On Nov 3, 2:52 pm, Demis Bellot <demis.bel...@gmail.com> wrote:
> Yeah you can either use a standard prefix like "db1:"
> or alternatively just spawn different redis server instances and use
> different ports to distinguish the dbs, i.e:
>
> localhost:6379 -> DB 0
> localhost:6380 -> DB 1
> localhost:6381 -> DB 2, etc.

That's not really what I'm asking. My question is: I have legacy data
in non-zero DBs, how do I move it to DB 0.

[catwell]

On Nov 3, 3:12 pm, Salvatore Sanfilippo <anti...@gmail.com> wrote:
> Hi, actually support for multiple DBs is not going to be deprecated in
> short time, but will NOT be part of Redis Cluster.

I'm happy to know that since I don't expect to be using Redis Cluster
anytime soon.

> In general however is a bad idea to use the same Redis server for
> multiple applications: for this use case the right thing to do is
> spawning multiple instances, one per application.

Except you don't get consistency across applications (for instance it
is not trivial to snapshot a consistent state of all your
applications).

> For instance in order to write an application supporting multiple
> blogs at the same time, the idea of namespacing per blog is IMHO a
> broken design, and a good design is instead to have a blog ID and have
> all the rest using this blog ID like: comments.blog:<id>.post:<id> or
> alike.

I already do that when I have similar use cases. That's not my case
here. You can think of it as services that have their own data but
communicate together, and I want to make sure that SAVEs occur at the
same time for each service.

[Josiah Carlson]

MOVE <key> <db>

Regards,
- Josiah

[Seppo]

Going back to the original questions

> Did anybody already do something like that? Do you have ideas what
the best way to implement it would be?

I don't think anybody did that.

The best way to implement would be to run, for each key on the database,
RENAME <key> prefix:<key>
MOVE prefix:<key> <target db>

To fetch a list of all the keys on the source database you should
SELECT <source db>
KEYS *

[catwell]

On Nov 3, 5:17 pm, Seppo <seppo0...@gmail.com> wrote:

> The best way to implement would be to run, for each key on the database,
> RENAME <key> prefix:<key>
> MOVE prefix:<key> <target db>
>
> To fetch a list of all the keys on the source database you should
> SELECT <source db>
> KEYS *

Yes, that would work. It's so simple I don't know why I haven't
thought about that earlier. Thanks!