需要帮助概念化在Redis / NoSQL [英] Need help conceptualizing in Redis/NoSQL

查看:138
本文介绍了需要帮助概念化在Redis / NoSQL的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想我很好地掌握了使用Redis的所有命令,但是我很难弄清楚使用它的最佳方法。我正在设计一个客户通知系统,通过他们首选的方法(电子邮件,SNMP,Syslog)通知他们,当他们的任何电路发生警报。



所以,我得到一个设备名称和一个端口。我需要将其与单个客户相关联,然后将该客户与交付方法相关联。使用关系数据库,它可能看起来像这样:

 设备名称:Los_Angeles 
端口:11

从customer_info中选择Customer_ID,Customer_name,其中device_port ='Los_Angeles:11'
从客户
中选择Customer_protocol,SNMP_destination,Syslog_destination其中Customer_ID =< customer_id从上面>

(非常简化的例子)



我可以看到如何使用列表的散列或哈希散列来编程。但是我想我在Redis中遇到麻烦的是那些更复杂的数据结构对我来说是不可用的(据我所知)。那么,如何将多条信息与一个关键字相关联?我可以想到我可以做的几种方法,但他们似乎都涉及多个步骤,我想要一些来自当前Redis程序员的一些投入,说明最好的方法。

解决方案

你是正确的,只有简单的数据结构可以与Redis一起使用,并且它们不能被值组合(就像你可以用一个面向文档的数据库,如CouchDB或MongoDB)。然而,可以通过引用来组合数据结构,这是一个非常常见的模式。



例如,一个集合中包含的项可以是其他的键对象(列表,哈希表,其他集合等)。我们尝试将其应用于您的示例。



要建模客户与设备+端口之间的关系,您可以使用包含客户ID的集合。要存储有关客户的信息,每个客户的一个哈希表是正常的。



以下是客户:

  hmset c:1名称史密斯协议tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2 
hmset c:2名称杰克逊协议udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:3名称Davis协议tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4

这些记录的关键是c:ID



我们将其中两个与设备和端口相关联:

  sadd d:Los_Angeles:11 2 3 

此集合的关键是d:device:港口。 c:和d:前缀只是一个约定。
应创建一个设备/端口。给定的客户可以属于多个套件(因此与几个设备/端口相关联)。



现在,通过附加到此设备/端口的客户端查找客户,我们只需要检索该集合的内容。

  smembers d:Los_Angeles:11 
1)2
2)3

然后相应的客户信息可以通过流水线hgetall命令:

  hgetall c:2 
hgetall c:3
1)name
2)杰克逊
3)协议
4)udp
5)snmp_dest
6)127.0.0.1
7 )syslog_dest
8)127.0.0.2
1)name
2)Davis
3)协议
4)tcp
5)snmp_dest
6)127.0.0.3
7)syslog_dest
8)127.0.0.4

不要害怕命令的数量。它们非常快,大多数Redis客户端都有能力管理查询,因此只需要最少的往返行程。通过只使用一个成员和几个hgetall,问题可以通过两次往返来解决。



现在,由于无处不在的SORT,可以进一步优化命令。这可能是Redis中最复杂的命令,它可以用于在这里保存往返。

  sort d:Los_Angeles: 11由nosort获取c:*  - > name get c:*  - > protocol get c:*  - > snmp_dest get c:*  - > syslog_dest 
1)Jackson
2) udp
3)127.0.0.1
4)127.0.0.2
5)戴维斯
6)tcp
7) 127.0.0.3
8)127.0.0.4

在一个命令中,它检索设备/端口的内容设置并获取相应的客户信息。



这个例子是微不足道的,但更普遍的是,当你可以用Redis表示复杂的数据结构时不立即。您需要在结构和数据访问方面仔细考虑模型(即在设计时,坚持使用您的数据和)。


I think I have a good grasp of all the commands to use Redis, but I'm having difficulty figuring out the best way to use it. I'm designing a customer notification system that will notify them via their preferred method (Email, SNMP, Syslog) when there's an alarm on any of their circuits.

So, I get a device name and a port. I need to associate that with a single customer, and then associate that customer to a delivery method. With a relational db, it would look probably look something like this:

Device name: Los_Angeles
Port: 11

SELECT Customer_ID, Customer_name from device_info where device_port = 'Los_Angeles:11'
SELECT Customer_protocol, SNMP_destination, Syslog_destination from CUSTOMER 
    where Customer_ID = <customer_id from above>

(Greatly simplified example).

I can see how to do this programatically with a hash of lists or hash of hashes. But I guess what I'm having trouble with in Redis is that those more complex data structures aren't available to me (as far as I know). So, how do I associate multiple pieces of information with a single key? I can think of a few ways I can do it, but they all seem to involve multiple steps, and I'd like some input from current Redis programmers about what the "best" way to do this.

解决方案

You are correct that only simple data structures are available with Redis, and they cannot be composed by value (like you could do with a document oriented database such as CouchDB or MongoDB). However, it is possible to compose data structures by reference, and this is a very common pattern.

For instance, the items contained in a set can be the keys for other objects (lists, hash tables, other sets, etc ...). Let's try to apply this to your example.

To model a relationship between customers and device+port, you can use sets containing customer IDs. To store information about the customers, one hash table per customer is fine.

Here are the customers:

hmset c:1 name Smith protocol tcp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:2 name Jackson protocol udp snmp_dest 127.0.0.1 syslog_dest 127.0.0.2
hmset c:3 name Davis protocol tcp snmp_dest 127.0.0.3 syslog_dest 127.0.0.4

The keys of these records are c:ID

Let's associate two of them to a device and port:

sadd d:Los_Angeles:11 2 3

The key of this set is d:device:port. The c: and d: prefixes are just a convention. One set per device/port should be created. A given customer could belong to several sets (and therefore associated to several device/port).

Now to find the customers with delivery methods attached to this device/port, we just have to retrieve the content of the set.

smembers d:Los_Angeles:11
1) "2"
2) "3"

then the corresponding customer information can be retrieved by pipelining a number of hgetall commands:

hgetall c:2
hgetall c:3
1) "name"
2) "Jackson"
3) "protocol"
4) "udp"
5) "snmp_dest"
6) "127.0.0.1"
7) "syslog_dest"
8) "127.0.0.2"
1) "name"
2) "Davis"
3) "protocol"
4) "tcp"
5) "snmp_dest"
6) "127.0.0.3"
7) "syslog_dest"
8) "127.0.0.4"

Don't be afraid of the number of commands. They are very fast, and most Redis clients have the capability to pipeline the queries so that only a minimum number of roundtrips are needed. By just using one smembers and several hgetall, the problem can be solved with just two roundtrips.

Now, it is possible to optimize a bit further, thanks to the ubiquitous SORT command. This is probably the most complex command in Redis, and it can be used to save a roundtrip here.

sort d:Los_Angeles:11 by nosort get c:*->name get c:*->protocol get c:*->snmp_dest get c:*->syslog_dest
1) "Jackson"
2) "udp"
3) "127.0.0.1"
4) "127.0.0.2"
5) "Davis"
6) "tcp"
7) "127.0.0.3"
8) "127.0.0.4"

In one command, it retrieves the content of a device/port set and fetches the corresponding customer information.

This example was trivial, but more generally, while you can represent complex data structures with Redis, it is not immediate. You need to carefully think about the model both in term of structure and of data access (i.e. at design time, stick to your data AND your use cases).

这篇关于需要帮助概念化在Redis / NoSQL的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆