C# client for Redis

[martinothamar]

Is there any supported client for .NET for the Redis service?
I tried connecting with StackExchange.Redis but am recieving the following errors:

System.Exception : Could not connect to Redis at: 127.0.0.1:6379
---- StackExchange.Redis.RedisConnectionException : It was not possible to connect to the redis server(s); to create a disconnected multiplexer, disable AbortOnConnectFail. Unexpected response to PING: BulkString: 4 bytes

Server logs:

I0129 17:48:47.377908   263 client-internal.cc:1218] Skipping reinitialize of master addresses, no REST endpoint or file specified
E0129 17:48:47.382961   264 redis_service.cc:817] Command SUBSCRIBE not yet supported. Arguments: [SUBSCRIBE, __Booksleeve_MasterChanged]. Raw: SUBSCRIBE\r\n$26\r\n__Booksleeve_MasterChanged
W0129 17:48:47.445613    39 inbound_call.cc:100] Connection torn down before Redis Call from 172.18.0.1:53598 could send its response: Network error (yb/util/net/socket.cc:522): Recv() got EOF from remote (error 108)
E0129 17:57:27.660684   264 redis_service.cc:817] Command CLUSTER not yet supported. Arguments: [CLUSTER, NODES]. Raw: CLUSTER\r\n$5\r\nNODES
W0129 17:57:27.724321    38 inbound_call.cc:100] Connection torn down before Redis Call from 172.18.0.1:53836 could send its response: Network error (yb/util/net/socket.cc:522): Recv() got EOF from remote (error 108)

[rkarthik007]

Thanks for reporting this! Assigning to @ramkumarvs to take a look.

[ramkumarvs]

@martinothamar Hey thanks for reporting this bug, Looks like we currently don't support couple of command that the StackExchange driver is using, by any chance you can exclude those commands?

ConfigurationOptions config = new ConfigurationOptions
{
   EndPoints =
     {
       { "localhost", 6379 },
     },
  CommandMap = CommandMap.Create(new HashSet<string>
    { // EXCLUDE commands not supported by YugaByte
      "SUBSCRIBE", "CLUSTER", "PING", "TIME"
    }, available: false)
};

ConnectionMultiplexer redis = ConnectionMultiplexer.Connect(config);

We will try to implement support for these commands on our end.

[kmuthukk]

@martinothamar : We don't currently support the publish/subscribe features of Redis. Let us know if your use case needs that capability. That's not in the immediate roadmap for YugaByte, but something we can prioritize based on user input.

[rkarthik007]

Also, created issues #31 and #32 tracking the need for the following commands:

• TIME
• CLUSTER NODES

[martinothamar]

Thanks for the quick responses! I don't need those commands yet so I excluded them as proposed, worked right away. Thanks!

I'm working on projects on the Orleans framework at the moment and am developing this library to test this database-system out.

The CLUSTER command not being supported does that have an effect on how data is distributed across the nodes or does YugaByteDB handle clustering differently to Redis or something? Thanks again.

[rkarthik007]

Hi @martinothamar,

Very impressive work! Just one small point (you probably already know it, but mentioning just in case), you have the following in your documentation here:
<< YugaByteDB provides 3 nodes while Redis is only installed as a single node >>
YugaByteDB is also a true database providing persistence (in addition to providing 3 or more nodes for scalability/data resilience).

<< The CLUSTER command not being supported does that have an effect on how data is distributed across the nodes or does YugaByteDB handle clustering differently to Redis or something? >>
No, the underlying data sharding, distribution or persistence is not at all affected. The support of the command is just a query layer request-response completion we have not gotten to yet.

Note that we are actively working on the CLUSTER SLOTS command (this will help make the Redis client even more efficient in performing reads). We will work on CLUSTER NODES next.

[martinothamar]

That's what I suspected, thanks for confirming. I just needed some numbers as I might propose using this for a project at work. I was actually specifically looking for a Key-Value store with persistence, so YugaByte seems to be a great fit. I'll be sure to update the readme. Thanks!

[bmatican]

Hey @martinothamar ! Since you mentioned that you were looking at numbers as well as KV + persistence, figured I'd chip in on the numbers part a bit as well:

TL;DR: For even better looking numbers on YugaByte side (and more apples to apples compare), you might consider running YB in RF1 and natively, instead of RF3 (default) and in docker, vs Redis native (which is also naturally RF1)

Longer version:
I noticed that you were testing YB in RF3 while naturally Redis only has RF1 and you probably were just using a single node anyway. This will naturally impact the latency numbers for YB on both reads and writes (network hops), but writes will take an extra hit (consensus).

For both reads and writes, your clients will be sending their requests to one of our nodes, that might not be the one responsible for actually handling the respective operation, so our query layer will have to forward that request to the appropriate server, so you're incurring an extra network hop just from that (the CLUSTER commands should help with).

However, for writes in particular, because of doing strongly consistent writes and going through Raft protocol, you'll always incur an extra network hop latency hit, as we'll have to wait for the write request to be replicated at least 2/3 nodes.

However, as @rkarthik007 was pointing out, in RF3 setup, you are trading off some latency numbers, but you're gaining persistence and replication on YB side.

Hope that helps.