FAQ
Hi everyone,

This mail to propose to you some ideas:

[0] "stats" command.

    stats allow to "upgrade" the info command.
    The main difference is a standardized dot notation of keys.

    stats is able to return some statistics unavalaible now with info:
        - the number of processed commands "read-only"-like: all the
commands used without data modifications
        - the number of processed commands "update"-like: all the commands
used to modify the data (set/update/delete)
        - the number of processed commands "admin"-like: all the commands to
drive the server.

    Why ? I'm monitoring our servers and get the number of processed command
to have an idea of the server activity.
    But I monitor the servers with an "info" command each 5sec... which
gives a wrong "real" processed commands.

[1] "delkeys" [pattern] command to go with the "del" [key] as discussed in
the "del" command documentation

    I have a process that needs to flush it's previous work (hundreds of
keys) on boot to recreate a fresh set of keys.
    I have to cheat a bit to do the work done and I guess it should be a
nice to have feature.

    Example: delkeys "work:*"

[2] "slaveof" [ip] [port] [pattern] [pattern]

    A process works actively into an instance and publish the final results
into an other instance because of security ("clients" should only see the
final data in read-only)

    I thought about a read-only "slave of" architecture based on a process
but I guess that a "slaveof" [pattern] could be better in terms of load.

    Example: a config line like "slaveof 127.0.0.1 6380 final:*"
synchronizes only the "final:*" keys into the slave.


What do you think about these features ?

Thanks for your time,

Christophe

--
You received this message because you are subscribed to the Google Groups "Redis DB" group.
To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
To post to this group, send email to redis-db@googlegroups.com.
Visit this group at http://groups.google.com/group/redis-db.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Christophe at Feb 16, 2014 at 7:57 am
    Is there a better channel to propose new features ?

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josiah Carlson at Feb 18, 2014 at 6:00 am
    No, but let me respond.


    On Sat, Feb 15, 2014 at 11:57 PM, christophe
    wrote:
    Is there a better channel to propose new features ?

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josiah Carlson at Feb 18, 2014 at 6:10 am

    On Wed, Feb 12, 2014 at 6:43 AM, christophe wrote:

    Hi everyone,

    This mail to propose to you some ideas:

    [0] "stats" command.

    stats allow to "upgrade" the info command.
    The main difference is a standardized dot notation of keys.

    stats is able to return some statistics unavalaible now with info:
    - the number of processed commands "read-only"-like: all the
    commands used without data modifications
    - the number of processed commands "update"-like: all the commands
    used to modify the data (set/update/delete)
    - the number of processed commands "admin"-like: all the commands
    to drive the server.

    Why ? I'm monitoring our servers and get the number of processed
    command to have an idea of the server activity.
    But I monitor the servers with an "info" command each 5sec... which
    gives a wrong "real" processed commands.
    There is no reason to add a new command vs. just adding more output to
    INFO. Considering that INFO has section requests, which includes "stats" (
    http://redis.io/commands/info), there really is no reason not to just add
    the output to INFO.

    [1] "delkeys" [pattern] command to go with the "del" [key] as discussed in
    the "del" command documentation

    I have a process that needs to flush it's previous work (hundreds of
    keys) on boot to recreate a fresh set of keys.
    I have to cheat a bit to do the work done and I guess it should be a
    nice to have feature.

    Example: delkeys "work:*"
    Aside from the slight memory bloat for your "hundreds of keys", there is no
    reason not to just use a Lua script for this. You get the same results
    (though it won't be cluster-compatible), very similar speed to implementing
    it directly, and you don't get to hear Salvatore say, "No."

    [2] "slaveof" [ip] [port] [pattern] [pattern]
    A process works actively into an instance and publish the final results
    into an other instance because of security ("clients" should only see the
    final data in read-only)

    I thought about a read-only "slave of" architecture based on a process
    but I guess that a "slaveof" [pattern] could be better in terms of load.

    Example: a config line like "slaveof 127.0.0.1 6380 final:*"
    synchronizes only the "final:*" keys into the slave.
    This is interesting, but I'm not sure it's really in the scope of what
    Redis should do. Also, it wouldn't work with the way Lua scripts are
    currently executed on slaves (the scripts are executed via EVAL or EVALSHA,
    which wouldn't necessarily work with a partial keyspace).

    Also, perhaps your clients shouldn't be hitting Redis directly - remember
    that Redis has very limited security features (I'd argue that they are
    effectively only to prevent mistakes, not to prevent access), and you
    shouldn't be exposing Redis to any non-trusted clients. Perhaps you should
    set up a RESTful web server whose only purpose is to do client verification
    and to pull data from Redis as requested. There might already be a daemon
    for this.

      - Josiah

    What do you think about these features ?
    Thanks for your time,

    Christophe

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Christophe at Feb 19, 2014 at 4:15 am

    On Tuesday, February 18, 2014 7:10:10 AM UTC+1, Josiah Carlson wrote:

    On Wed, Feb 12, 2014 at 6:43 AM, christophe <christoph...@gmail.com<javascript:>
    wrote:
    Hi everyone,

    This mail to propose to you some ideas:

    [0] "stats" command.

    stats allow to "upgrade" the info command.
    The main difference is a standardized dot notation of keys.

    stats is able to return some statistics unavalaible now with info:
    - the number of processed commands "read-only"-like: all the
    commands used without data modifications
    - the number of processed commands "update"-like: all the commands
    used to modify the data (set/update/delete)
    - the number of processed commands "admin"-like: all the commands
    to drive the server.

    Why ? I'm monitoring our servers and get the number of processed
    command to have an idea of the server activity.
    But I monitor the servers with an "info" command each 5sec... which
    gives a wrong "real" processed commands.
    There is no reason to add a new command vs. just adding more output to
    INFO. Considering that INFO has section requests, which includes "stats" (
    http://redis.io/commands/info), there really is no reason not to just add
    the output to INFO.
    OK, it was not a good example for name of course, the idea was to don't
    break the info output but we can add a new section in the info command.
    I'm more interested by the real content I need (read-only, update, admin
    processed commands) of course.

    [1] "delkeys" [pattern] command to go with the "del" [key] as discussed in
    the "del" command documentation

    I have a process that needs to flush it's previous work (hundreds of
    keys) on boot to recreate a fresh set of keys.
    I have to cheat a bit to do the work done and I guess it should be a
    nice to have feature.

    Example: delkeys "work:*"
    Aside from the slight memory bloat for your "hundreds of keys", there is
    no reason not to just use a Lua script for this. You get the same results
    (though it won't be cluster-compatible), very similar speed to implementing
    it directly, and you don't get to hear Salvatore say, "No."
    For simple things, in relational database, I try to avoid stored procedure
    and in redis, I try to avoid Lua scripts.
    Of course Lua scripts works. It's powerful, reliable and fun to use but,
    for simple things like a delete with constraints, I prefer use the client
    features instead of scripting the job.

    We should then have a Lua script to inject into redis at each boot to have
    a client feature complement.

    But OK.

    [2] "slaveof" [ip] [port] [pattern] [pattern]
    A process works actively into an instance and publish the final
    results into an other instance because of security ("clients" should only
    see the final data in read-only)

    I thought about a read-only "slave of" architecture based on a process
    but I guess that a "slaveof" [pattern] could be better in terms of load.

    Example: a config line like "slaveof 127.0.0.1 6380 final:*"
    synchronizes only the "final:*" keys into the slave.
    This is interesting, but I'm not sure it's really in the scope of what
    Redis should do. Also, it wouldn't work with the way Lua scripts are
    currently executed on slaves (the scripts are executed via EVAL or EVALSHA,
    which wouldn't necessarily work with a partial keyspace).

    Also, perhaps your clients shouldn't be hitting Redis directly - remember
    that Redis has very limited security features (I'd argue that they are
    effectively only to prevent mistakes, not to prevent access), and you
    shouldn't be exposing Redis to any non-trusted clients. Perhaps you should
    set up a RESTful web server whose only purpose is to do client verification
    and to pull data from Redis as requested. There might already be a daemon
    for this.
    I thought about exposing the data through a light app server but it's
    adding a component to maintain and to monitor.
    But you' right, it's maybe out of scope.

    Thanks for your time,

    Christophe.



    - Josiah

    What do you think about these features ?
    Thanks for your time,

    Christophe

    --
    You received this message because you are subscribed to the Google Groups
    "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to redis-db+u...@googlegroups.com <javascript:>.
    To post to this group, send email to redi...@googlegroups.com<javascript:>
    .
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josiah Carlson at Feb 20, 2014 at 2:14 am

    On Tue, Feb 18, 2014 at 8:15 PM, christophe wrote:


    On Tuesday, February 18, 2014 7:10:10 AM UTC+1, Josiah Carlson wrote:


    There is no reason to add a new command vs. just adding more output to
    INFO. Considering that INFO has section requests, which includes "stats" (
    http://redis.io/commands/info), there really is no reason not to just
    add the output to INFO.
    OK, it was not a good example for name of course, the idea was to don't
    break the info output but we can add a new section in the info command.
    I'm more interested by the real content I need (read-only, update, admin
    processed commands) of course.
    Submit a pull request, more information is good for everyone :)

    Aside from the slight memory bloat for your "hundreds of keys", there is
    no reason not to just use a Lua script for this. You get the same results
    (though it won't be cluster-compatible), very similar speed to implementing
    it directly, and you don't get to hear Salvatore say, "No."
    For simple things, in relational database, I try to avoid stored procedure
    and in redis, I try to avoid Lua scripts.
    I know the feeling, I do the same. But when composite functionality is
    needed, and an extra round-trip is not desired for one reason or another, I
    use Lua scripting.

    Of course Lua scripts works. It's powerful, reliable and fun to use but,
    for simple things like a delete with constraints, I prefer use the client
    features instead of scripting the job.
    Then you can use KEYS + DEL. That will work the same, and probably won't be
    an issue if you only have a few hundred keys (both matching and unmatching).

    We should then have a Lua script to inject into redis at each boot to have
    a client feature complement.
    The script load/execute client function that I always use for Lua scripts
    automatically loads the script on first call (in the calling process) to
    get the hash for subsequent evalsha calls, and will use EVAL on any "script
    missing" failure later (if someone calls SCRIPT FLUSH).

    I thought about exposing the data through a light app server but it's
    adding a component to maintain and to monitor.
    But you' right, it's maybe out of scope.
    If I'm right about anything here, this is it.

      - Josiah

    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Christophe at Feb 27, 2014 at 7:13 am
    Hi Josiah,

    Sorry about the delay, I was off-topic since few days.
    On Thursday, February 20, 2014 3:14:10 AM UTC+1, Josiah Carlson wrote:

    On Tue, Feb 18, 2014 at 8:15 PM, christophe <christoph...@gmail.com<javascript:>
    wrote:
    On Tuesday, February 18, 2014 7:10:10 AM UTC+1, Josiah Carlson wrote:


    There is no reason to add a new command vs. just adding more output to
    INFO. Considering that INFO has section requests, which includes "stats" (
    http://redis.io/commands/info), there really is no reason not to just
    add the output to INFO.
    OK, it was not a good example for name of course, the idea was to don't
    break the info output but we can add a new section in the info command.
    I'm more interested by the real content I need (read-only, update, admin
    processed commands) of course.
    Submit a pull request, more information is good for everyone :)
    I'll do.

    Aside from the slight memory bloat for your "hundreds of keys", there is
    no reason not to just use a Lua script for this. You get the same results
    (though it won't be cluster-compatible), very similar speed to implementing
    it directly, and you don't get to hear Salvatore say, "No."
    For simple things, in relational database, I try to avoid stored
    procedure and in redis, I try to avoid Lua scripts.
    I know the feeling, I do the same. But when composite functionality is
    needed, and an extra round-trip is not desired for one reason or another, I
    use Lua scripting.

    Of course Lua scripts works. It's powerful, reliable and fun to use but,
    for simple things like a delete with constraints, I prefer use the client
    features instead of scripting the job.
    Then you can use KEYS + DEL. That will work the same, and probably won't
    be an issue if you only have a few hundred keys (both matching and
    unmatching).

    We should then have a Lua script to inject into redis at each boot to
    have a client feature complement.
    The script load/execute client function that I always use for Lua scripts
    automatically loads the script on first call (in the calling process) to
    get the hash for subsequent evalsha calls, and will use EVAL on any "script
    missing" failure later (if someone calls SCRIPT FLUSH).
    I already rename some lethal functions and I forgot this one.
    Thanks :-)

    I thought about exposing the data through a light app server but it's
    adding a component to maintain and to monitor.
    But you' right, it's maybe out of scope.
    If I'm right about anything here, this is it.

    - Josiah
    --
    You received this message because you are subscribed to the Google Groups "Redis DB" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to redis-db+unsubscribe@googlegroups.com.
    To post to this group, send email to redis-db@googlegroups.com.
    Visit this group at http://groups.google.com/group/redis-db.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupredis-db @
categoriesredis
postedFeb 12, '14 at 2:47p
activeFeb 27, '14 at 7:13a
posts7
users2
websiteredis.io
irc#redis

2 users in discussion

Christophe: 4 posts Josiah Carlson: 3 posts

People

Translate

site design / logo © 2022 Grokbase