基于某项目的NoSQL数据库设计与研究

李顺

[摘           要]  基于为学校开发的实际项目，首先对NoSQL数据库的理论和方向进行阐述，然后从总体的设计与需求出发，对以Redis技术为主的NoSQL数据库应用进行探究。

[关    键   词]  数据库;NoSQL技术;Redis

[中图分类号]  TP311.1           [文献标志码]  A            [文章编号]  2096-0603（2019）15-0034-02

数据库是数据存储的主要场所，当前的数据库技术主要是以MySQL、PosrareSQL等为主的关系数据库。随着网站技术的发展，特别是微博之类大型网站的出现让人们意识到了关系数据库的局限性，那就是关系数据库的设计约束不够灵活和海量数据处理能力不足，使用户的体验过程很不理想。所以为了优化用户的体验，满足数据库低延时和高并发的需求，研究人员开始将目光投入到非关系数据库上，也就是本文所研究的NoSQL技术。从本质上来说，NoSQL技术是对关系数据库的补足，主要是应对高并发和大数据的需求进行构架，充分开发了以集合论为代数基础的结构化查询语言，保证了事物的一致性，满足了网站对数据库伸缩性和高可用性的要求。

一、NoSQL简介

NoSQL是基于CAP理论、最终一致性和BASE思想而构建起来的技术体系，与传统的关系数据库的数据模型有着很大的区别。传统的关系数据库的数据模型表现为关系型数据模型，而NoSQL抛弃了关系型模型的框架和模式，从键值、文档、列、图四个存储应用方向出发进行构架。

键值（key-value）存储是一张类似于HashTable集合的数据结构的哈希表，能够根据结构中的key值进行存储，与其对应的value没有过多的限制，能够根据产品的不同进行不同的操作。但是通常情况下的NoSQL数据库不提供针对单独value值的操作，而是根据key值开放delet、set等操作，目前常见的键值数据库产品为Redis。

文档（key-文档）存储与键值存储类似，但对应的vale值从任意数值变成了结构化的文档。文档存储的优势在于只要文档满足XML、JSON等存储格式，就能够实现文档内嵌套的复杂存储方式。所以文档存储可以看作是键值存储的升级版本，目前常见的文档存储数据库产品为CouchDB。

列（key-列）存储在设计上与前两种截然不同，它是一种能够以传统关系结构的表模型（Table）为基础，打破了多行进行连续存储的方式，从而提高压缩率和缓存的利用率。但列存储因为结构特性有着无法聚集、无法形成唯一索引、无法包含稀疏列等缺点，所以列存储的应用范围有限，通常被应用在数据仓库或者汇总上，目前常见的列存储数据库产品为HBase。

图存储是利用图结构的算法来实现存储，常见的图存储算法为最短路径寻址算法。图存储的计算方式是基于整个图进行，所以其复杂算法不适合分布式集群方案。图存储的主要应用范围在社交网络这类能够构建出关系图谱的平台上，目前常见的图存储数据库产品为InfoGrid等。

二、基于NoSQL技术的数据库设计

本次研究所构架NoSQL数据库的方向为键值存储，研究的项目为redis问答系统设计与实现，旨在解决用户对笔者所在学校及其相关办学情况的疑惑。用户可以在問答系统上自行发布问题，由学校内部人员进行解答。

（一）总体设计与需求分析

首先，需要对用户的相关需求进行分析，用户登录系统之后需要先对问题进行搜索，借助搜索引擎对问题进行定位;其次，如果用户没有发现相关问题，那么就可以通过自行提问，然后由学校安排特定人员进行登录解答;最后，用户对感兴趣的问题进行关注，从而随之对问题答案消息进行接收。所以跟据以上三种情况，笔者将主要的模块分为四种：用户模块、关注模块、点赞模块和问题与评论模块。全文搜索相关功能需要借助其他框架实现，本文不多进行赘述。本次研究项目后台使用Java，采用了SSM的架构方式。

1.用户模块

用户在浏览网站首页的时候需要进行权限认证，然后跳转至登录页面进行登录，在登录验证成功后就可以跳转到之前的目标界面，如果没有成功再会提示用户信息出现问题。登录验证也分为新用户和老用户两种验证方式，新用户需要提交权限认证和注册，老用户只需要输入账号密码。

因为学校的用户规模有限，并且各个用户之间的关联性较强，所以用户模块的数据存储使用的是关系型数据库，并且使用了MD5加密技术进行加密。在用户模块字段的描述方面：id表示系统记录的用户主键序号;name表示账户名;password表示密码;slat表示根据原始密码生成的加密技术;head url表示头像的url。

2.问题与评论模块

用户在没有找到自己想要了解的问题情况下，就需要自行进行发布请求的提交，这时系统会检查用户是否已经登录，如果用户没有登录，就会弹出相应登录界面。在用户已经登陆的情况下就可以提示用户是否需要进行问题的发布，如果需要，就进入相关发布界面;如果不需要，就进入相关评论界面，两个界面都需要填写信息后提交，最终结果会在对应的界面上显示。问题与评论模块是相互对应进行设计的，所以选用的是传统关系型数据库进行数据存储。

在问题模块字段的描述方面：id表示系统记录的问题主键序号;title表示标题;content表示内容;user-id表示发布者的用户表序号;created-time表示创建问题时间;comment-count表示问题下方的评论数量。

在评论模块字段的描述方面：id表示系统记录的评论主键序号;content表示评论内容;user-id表示发布者的用户表序号;entity-id表示评论对象的用户表序号;entity-type表示评论对象的类型;created time表示创建评论时间。

3.点赞模块

点赞模块是优化用户体验的重要内容，如果用户很喜欢某个答案，就可以点赞来作为认可。首先用户需要提交点赞请求，系统会检查用户是否已经登录，如果用户没有登录，就会弹出相应登录界面。在用户已经登陆的情况下就可以让后台获取用户和问题的相关信息，针对用户的需求进行Redis数据库的操作，操作完成后返回页面显示成果。

点赞模块的设计较为复杂，需要记录点赞者、被点赞目标和目标得到点赞数等多项信息才能进行完整的描述，所以关系型数据库已经不能够满足描述的需要，导致整体点赞行为的读写压力较大，所以笔者采用Redis技术进行数据的存储。

4.关注模块

关注模块主要是让用户能够第一时间接收到站内的通知，提醒用户新的答案或者所关注者的新动态。首先用户需要提交关注请求，系统会检查用户是否已经登录，如果用户没有登录，就会弹出相应登录界面。在用户已经登陆的情况下就可以让后台获取到用户和问题的相关信息，针对用户的需求进行Redis数据库的操作，操作完成后返回页面显示成果。

关注模块是大型网站的主要应用模块，因为每个用户都有不沟通的关注和被关注的需求，所以需要根据用户建立不同类型的列表，数据量庞大，适合Redis这类NoSQL技术数据库的发挥。具体方法是利用Redis的有序集合将关注实体进行划分，用户所关注的其他用户为entity type（1），所关注的问题为entity type（2），从而确保类型的不同。

（二）Redis问答系统的设计

作为NoSQL数据库的代表，Redis数据库有其固有的优势与劣势。在一些特定的场景下，非常适合采用Redis数据库存储数据，而在其他场景下，Redis有时无法胜任，只能采用传统的关系型数据库。本节主要介绍Redis在此问答系统中的设计，并对Redis的适应场景做一般性的总结。

1.功能型设计

作为一种新兴的数据库，NoSQL能够独立承担一些业务场景的数据存储工作。当存储的数据对结构化要求不高，比如不需进行join查询，并且这些数据是海量的，无法对数据的规模、数据的增长速度进行预期时，就非常适合采用NoSQL数据库，虽然也可使用关系型数据库完成同样功能，但性能以及扩展性却远不如NoSQL数据库。

以此问答系统为例，对问题和评论场景，只需对问题、评论用户等数据进行存储，无需进行联表查询，对数据的结构化要求不高，而且当系统发展到一定规模后，用户数据急剧上涨时，对一个热点问题的评论数可能达到万级别以上，而且这只是单个问题，当热点问题数据规模达到百级别时，单独评论功能的数据规模就可以达到百万级别以上，这些数据是相当可观的。如果采用传统的关系型数据库，需要额外建立一张表，按照上述数据规模，此表的数据可达到百万条记录，无疑会对数据库的读写带来极大压力，并有可能成为系统扩展的瓶颈。

考虑采用Redis实现，可以借助Redis内置的数据结构set集合实现。可以为每个问题都分配一个集合，集合内存放的数据即为给此问题点赞的用户id。由于集合内存储的元素只是用户的id，即使达到百万级别，其占用的内存也是G级别的，相比内存的高效存取，完全可以接受，而且用户每点赞一次，只需向特定集合内增加用户id即可，无须重复问题id，减少了数据冗余。此外，Redis提供了相应的集合操作方法，比如统计每个集合内元素数量scard（）、判断集合内是否包含某元素sismember（）等，可以方便高效地满足各种需求。

2.类缓存设计

为了平衡时间与空间的矛盾，考虑使用Redis+MySQL的架构，以Redis作为数据的缓存，数据的主体部分存储在关系型数据库MySQL中。每个用户依然存在一个关注列表，为了减少占用内存空间，关注列表不再存储关注的主体内容，而是关注的主键记，关注的主体内容存储在MySQL数据库的关注表中，获取事件id后，再根据id到MySQL获取实际内容。由于列表内只存储关注的id，其占用的数据量大大减少，解决了完全采用Redis存储大量数据冗余的问题;由于根据关注的主键id到MySQL中获取信息，其效率也大大提高（关系型数据中一般都提供根据主键获取信息的优化措施），解决了完全采用MySQL存储性能低下的问题。

参考文献：

[1]许鑫，时雷，何龙，等.基于NoSQL数据库的农田物联网云存储系统设计与实现[J].农业工程学报，2019，35（1）：172-179.

[2]熊英，程玉.大数据时代数据库原理及应用教程的教学模式探索[J].教育现代化，2018，5（50）：27-29.

[3]刘玉程，李港.NoSQL数据库与关系型数据库对比[J].中国新通信，2018，20（7）：81.

[4]洪漪，赵栋祥，赵一鸣.大数据环境下的信息架構与数据模型[J].信息资源管理学报，2018，8（1）：29-38.

编辑 冯永霞