这篇文章给大家介绍使用复述之前5个必须了解的事情有哪些,内容非常详细,感兴趣的小伙伴们可以参考借鉴,希望对大家能有所帮助。
使用复述,开发应用程序是一个很愉快的过程,但是就像其他技术一样,基于复述的应用程序设计你同样需要牢记几点。在之前,你可能已经对关系型数据库开发的那一整个套路了然如胸,而基于复述的应用程序开发也有许多相似的地方,但是你必须牢记以下两点——复述是个内存数据库,同时它是单线程的,因此,在使用复述时,你需要注意以下几点:
<强> 1。掌控储存在复述中的所有键
数据库的主要功能是储存数据,但是对于开发者来说,因为应用程序需求或者数据使用方法的改变,忽略存储在数据库中的某些数据是非常正常的,在复述中同样如此。你可能忽视期满某些键,也可能因为应用程序的某个模块弃用而忘掉这些数据。
无论哪种情况,复述,都存储了一些不再使用的数据,平白无故的占用了一些空间.Redis的弱结构数据模式让集中储存的内容很难被弄清,除非你为键使用一套非常成熟的命名法则。使用合适的命名方法会简化你的数据库管理,当你通过你的应用程序或者服务做键的命名空间时(通常情况下是使用冒号来划分键名),你就可以在数据迁移,转换或者删除时轻松的识别。
复述,另一个常见用例是作为热数据项作的第二数据存储,大部分的数据被保存在其他的数据库中,比如PostgreSQL或MongoDB。在这些用例中,当数据从主存储移除时,开发者经常会忘记删除复述中对应的数据。这种存在跨数据存储的情况下,通常需要做级联删除,这种情况下,可以通过在复述,配置保存特定数据项的所有识别符来实现,从而保证数据在主数据库被删除后,系统会调用一个清理程序来删除所有相关副本和信息。
<强> 2。控制所有键名的长度
在上文我们说过要使用合适的命名规则,并且添加前缀来识别数据走向,因此这一条看起来似乎与之违背。但是,请别忘记,复述是个内存数据库,键越短你需要的空间就越少。理所当然,当数据库中拥有数百万或者数十亿键时,键名的长度将影响重大。
举个例子:在一个32位的复述,服务器上,如果储存一百万个键,每个值的长度是个32个字符,那么在使用六个长度键名时,将会消耗大约96 mb的空间,但是如果使用长度长度的键名时,空间消耗则会提升至111 mb左右。随着键的增多,15%的额外开销将产生重大的影响。
<强> 3。使用合适的数据结构
不管是内存使用或者是性能,有的时候数据结构将产生很大的影响,下面是一些可以参考的最佳实践:
取代将数据存储为数千(或者数百万)独立的字符串,可以考虑使用哈希数据结构将相关数据进行分组。哈希表是非常有效率的,并且可以减少你的内存使用;同时,哈希还更有益于细节抽象和代码可读。
合适时候,使用列表代替集。如果你不需要使用组特性,列表在使用更少内存的情况下可以提供比设置更快的速度。
排序集是最昂贵的数据结构,不管是内存消耗还是基本操作的复杂性。如果你只是需要一个查询记录的途径,并不在意排序这样的属性,那么轻建议使用哈希表。
复述中一个经常被忽视的功能就是位图或者bitsets (V2.2之后).Bitsets允许你在复述,值上执行多个位操作,比如一些轻量级的分析。
<强> 4。使用扫描时别使用键
从复述v2.8开始,扫描命令已经可用,它允许使用游标从用于中检索键。对比键命令,虽然扫描无法一次性返回所有匹配结果,但是却规避了阻塞系统这个高风险,从而也让一些操作可以放在主节点上执行。
需要注意的是,扫描命令是一个基于游标的迭代器.SCAN命令每次被调用之后,都会向用户返回一个新的游标,用户在下次迭代时需要使用这个新游标作为扫描命令的游标参数,以此来延续之前的迭代过程。同时,使用扫描,用户还可以使用keyname模式和计数选项对命令进行调整。
扫描相关命令还包括SSCAN命令,HSCAN命令和ZSCAN命令,分别用于集合,哈希键及有续集等。
<强> 5。使用服务器端Lua脚本
在复述,使用过程中,Lua脚本的支持无疑给开发者提供一个非常友好的开发环境,从而大幅度解放用户的创造力。如果使用得当,Lua脚本可以给性能和资源消耗带来非常大的改善。取代将数据传送给CPU、脚本允许你在最接近数据的地方执行逻辑,从而减少网络延时和数据的冗余传输。
