数据服务的层面上来说,各个服务器依旧是完全独立的。
这些操作如果一定要实现,当然可以通过客户端代码来实现(效率有多高且不说),类似的问题memcached集群当然也会遇上,但是原本memcached就不支持复杂的操作和数据类型,许多运算逻辑原本就是由客户端代码或应用程序自己处理的。
MR类批处理应用
提供指定范围的遍历操作,是支持类似MapReduce这样的批处理应用逻辑的关键之一,但是要在基于hash方式存储的数据结构的基础上提供这样的支持并不容易(或者说要实现高效的范围或遍历操作并不容易)
Redis支持Scan操作用于遍历数据集,这一操作基于其内部数据结构及实现的限制,可以保证在Scan开始时的所有数据都能被获取到,但是不能保证不返回重复的数据,这需要由客户端来检查,或者客户端对此无所谓。Scan操作还支持Match条件用来过滤键值,虽然存在一定的局限性,例如match条件的比较是在获取数据之后再执行的,效率是一个问题,更明显的问题是不能保证每次scan的iterate过程都能返回同样数量的有效数据。
对于范围操作,Redis的Ordered Set支持在插入时指定数据的分数(Score)用于排序,而后支持在指定Score范围内的各种操作,虽然由于不支持基于字符串的或自定义的基准的Range操作,这样的范围操作应用起来有很大的局限性(或者说需要满足特定的应用模式),但是还是比没有好了
Memcached核心协议本身不支持任何范围类的操作,也没有对遍历操作的支持,甚至不存在官方合法的列举所有Key的操作,这当然很大程度上源于其设计思想和精简的架构
此外Redis的Hashes数据结构,在一定程度上可以满足获取特定子集数据的应用逻辑需求。
综上来说,如果要实现类似HBase支持的scan操作,不论是Redis还是memcached都无法做到,但是对于Redis来说,能否用于批处理类应用,不能一概而论,取决于具体的数据的格式逻辑和使用方式。通过适当的调整应用程序使用数据的方式,还是有可能在一定程度上实现对MR类批处理,或范围查询类应用逻辑的支持的。而对于键值分布在一个较大的连续空间,数量不确定,同时又无法很好的映射为数值进而使用ordered set来处理的这样一些数据结构,应该还是很难高效的分区遍历的