CN113821537A - 读取数据的方法、装置、设备以及存储介质 - Google Patents
读取数据的方法、装置、设备以及存储介质 Download PDFInfo
- Publication number
- CN113821537A CN113821537A CN202110134152.0A CN202110134152A CN113821537A CN 113821537 A CN113821537 A CN 113821537A CN 202110134152 A CN202110134152 A CN 202110134152A CN 113821537 A CN113821537 A CN 113821537A
- Authority
- CN
- China
- Prior art keywords
- data
- account
- relationship chain
- database
- dynamic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24552—Database cache management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2455—Query execution
- G06F16/24553—Query execution of query operations
- G06F16/24554—Unary operations; Data partitioning operations
- G06F16/24556—Aggregation; Duplicate elimination
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/24—Querying
- G06F16/245—Query processing
- G06F16/2457—Query processing with adaptation to user needs
- G06F16/24578—Query processing with adaptation to user needs using ranking
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
本申请实施例公开了读取数据的方法、装置、设备以及存储介质,涉及互联网技术领域。该读取数据的方法的一具体实施方式包括:响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,目标数据包括关系链数据和/或关注动态数据;响应于检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据;将目标数据的更新数据写入Redis数据库,从而采用MongoDB数据库替代Feed系统中Redis数据库的存储角色,降低Redis数据库引起的内存开销,缩减成本。
Description
技术领域
本申请涉及计算机技术领域,具体涉及互联网技术领域,尤其涉及读取数据的方法、装置、设备以及存储介质。
背景技术
Feed流是一个目前常见的功能,在众多产品中都有展现,例如微博、朋友圈、消息广场等等。通过Feed流可以把动态实时地传播给订阅者,是用户获取信息流的一种有效方式。Feed流中的每一条状态或者消息都是Feed。
通常,Feed系统的存储次数可以达到千万级/日,存储量更是达到拍字节(PB,Petabytes)级别。Feed系统中的推送功能需要满足每秒百万次的查询率。因此,Feed系统复杂度高,构建难度大,维护成本高。
发明内容
本申请实施例提供了读取数据的方法、装置、设备以及存储介质。
第一方面,本申请实施例提供了读取数据的方法,包括:响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,目标数据包括关系链数据和/或关注动态数据;响应于检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据;将目标数据的更新数据写入Redis数据库。
第二方面,本申请实施例提供了读取数据的装置,包括:第一读取模块,被配置成响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,目标数据包括关系链数据和/或关注动态数据;拉取模块,被配置成响应于检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据;写入模块,被配置成将目标数据的更新数据写入Redis数据库。
第三方面,本申请实施例提出了一种电子设备,包括:至少一个处理器;以及与至少一个处理器通信连接的存储器;其中,存储器存储有可被至少一个处理器执行的指令,指令被至少一个处理器执行,以使至少一个处理器能够执行如第一方面中任一实现方式描述的方法。
第四方面,本申请实施例提出了一种存储有计算机指令的非瞬时计算机可读存储介质,计算机指令用于使计算机执行如第一方面中任一实现方式描述的方法。
本申请实施例提供的读取数据的方法、装置、设备以及存储介质,首先响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,目标数据包括关系链数据和/或关注动态数据;之后响应于检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据;最后将目标数据的更新数据写入Redis数据库,从而采用MongoDB数据库替代Feed系统中Redis数据库的存储角色,降低Redis数据库引起的内存开销,缩减成本。
应当理解,本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征,也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述,本申请的其它特征、目的和优点将会变得更明显。附图用于更好地理解本方案,不构成对本申请的限定。其中:
图1是本申请可以应用于其中的示例性系统架构图;
图2是根据本申请的读取数据的方法的一个实施例的流程示意图;
图3是根据本申请的读取数据的方法的另一个实施例的流程示意图;
图4是根据本申请的读取数据的方法的一个实施例的应用场景示意图;
图5是本申请的读取数据的装置的一个实施例的结构示意图;
图6是用来实现本申请实施例的读取数据的方法的电子设备的框图。
具体实施方式
下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是,此处所描述的具体实施例仅仅用于解释相关发明,而非对该发明的限定。另外还需要说明的是,为了便于描述,附图中仅示出了与有关发明相关的部分。
需要说明的是,在不冲突的情况下,本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。
图1示出了可以应用本申请的读取数据的方法或读取数据的装置的实施例的示例性系统架构100。
如图1所示,系统架构100可以包括终端设备101、网络102、服务器103。网络102用以在终端设备101和服务器103之间提供通信链路的介质。网络102可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
终端设备101可以通过网络102与服务器103交互。终端设备101可以使用网络社区账号发布消息或状态、关注其它网络社区账号等,包括但不限于数据库、用户终端等等。
服务器103可以提供各种服务,例如服务器103可以对从终端设备101获取到的消息或状态、网络社区账号之间的关注数据等数据进行分析等处理,生成处理结果(例如从MongoDB数据库中拉取关注动态数据和/或关系链数据)。
需要说明的是,服务器103可以是硬件,也可以是软件。当服务器103为硬件时,可以实现成多个服务器组成的分布式服务器集群,也可以实现成单个服务器。当服务器103为软件时,可以实现成多个软件或软件模块(例如用来提供分布式服务),也可以实现成单个软件或软件模块。在此不做具体限定。
需要说明的是,本申请实施例所提供的读取数据的方法一般由服务器103执行,相应地,读取数据的装置一般设置于服务器103中。
应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
继续参考图2,示出了根据本申请的读取数据的方法的一个实施例的流程200。该方法包括以下步骤:
步骤201,响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据。
在本实施例中,读取数据的方法的执行主体(例如图1所示的服务器103)可以执行响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据。
其中,目标数据包括关系链数据和/或关注动态数据。其中,关系链数据指的是网络社区中的账号关系(例如关注列表),它是由一系列的变长链表组成。关注动态数据指的是网络社区中账号发布的消息或状态(即Feed),关注动态数据包括消息或状态的内容(即Feed内容)、消息或状态的标识(即Feed ID)。
其中,Redis是一个基于键/值对非关系型的数据库,其作为缓存器,只存储部分目标数据,例如Redis数据库只存储网络社区账号上次读取到的关注动态数据的范围。其中,关注动态数据的范围可以以时间顺序排序,也可以按某个非时间的因子排序(例如按照用户的喜好度排序)。
其中,用户若要读取目标数据,可以在终端设备101上执行触发操作,然后终端设备101将用户执行的触发操作信息发送至上述执行主体。其中,触发操作信息指的是预置的、用于执行读取目标数据的最新数据的指令信息,例如用户登录网络社区的账号或登录应用程序等。
其中,Redis数据库可以支持高速的读/写操作,但成本较高,对于轻量数据的存储使用Redis数据库会造成资源浪费。因此,可以根据需要对Redis数据库存储的数据量级进行限制,以节省开支。
步骤202,检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据。
在本实施例中,上述执行主体可以检测到目标数据失效,并从MongoDB数据库中拉取目标数据的更新数据。
MongoDB是一个基于分布式文件存储的非关系型的数据库。其中,MongoDB数据库用于存储全量的目标数据,包括全量的关系链数据和全量的关注动态数据。MongoDB数据库支持中低速的读/写操作,成本较低,适于轻量级的数据量的存储。其中,可以将关系链数据和关注动态数据全部写入到MongoDB数据库。
其中,网络社区中的账号可以不断发布新的消息或状态,并且其可以不断关注新账号或取消已关注账号,因此,该账号的关系链数据和关注动态数据处于持续不断的变化中。其中,可以判断目标数据是否属于最新数据;若目标数据不是最新数据,则从MongoDB数据库中拉取最新数据。
其中,目标数据失效指的是该目标数据的范围与每次触发操作信息所要获取的关系链数据和/或关注动态数据的范围不一致。例如,触发操作信息所要获取的关注动态数据的时间范围为[2020.1.1-2020.1.2],而目标数据的时间范围为[2019.12.30-2019.12.31],那么目标数据已失效。
其中,若目标数据失效,则可以从MongoDB数据库中拉取触发操作信息所要获取的关系链数据和/或关注动态数据的范围,并将其作为目标数据的更新数据。
步骤203,将目标数据的更新数据写入Redis数据库。
在本实施例中,上述执行主体可以将目标数据的更新数据写入Redis数据库。
本申请上述实施例提供的读取数据的方法,采用MongoDB数据库替代Feed系统中Redis数据库的存储角色,降低Redis数据库引起的内存开销,缩减成本。同时由于舍弃了存储量级较重的Redis数据库,本申请实施例也有助于轻量化的Feed系统的开发。
进一步参考图3,其示出了根据本申请的读取数据的方法的另一个实施例的流程图,该方法包括如下步骤:
步骤301,响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据。
步骤301与步骤201基本相同,因此不再赘述。
步骤302,检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据。
步骤302与步骤202基本相同,因此不再赘述。
步骤303,将目标数据的更新数据写入Redis数据库。
步骤303与步骤203基本相同,因此不再赘述。
步骤304,从Redis数据库读取目标数据的更新数据。
Feed系统的推送方案包括两种,一种是拉方案,也称读扩散,另一种是推方案,也称为写扩散。对于拉方案而言,用户发布消息或状态后,该消息或状态先存储于用户的发件箱或个人页;对于推方案而言,用户发布消息或状态后,该消息或状态先存储于用户的关注者/粉丝的收件箱或关注页。无论是拉方案还是推方案,都需要对最新的消息或状态进行读取,其中,可以在接收到对最新的消息或状态进行读取的指令后,从Redis数据库读取目标数据的更新数据。
在本实施例的一些可选的实现方式中,读取数据的方法还包括:采用全文搜索引擎对关注动态数据进行聚合。
全文搜索引擎就是通过从互联网上提取的各个网站的信息而建立的数据库中,检索与用户查询条件匹配的相关记录,然后按一定的排列顺序将结果返回给用户。其中,可以通过全文搜索引擎对关注动态数据进行排序,并将排序好的关注动态数据进行聚合,例如ElasticSearch。
在本实施例的一些可选的实现方式中,目标数据包括关系链数据,关系链数据的写入方法包括:响应于接收到关注行为信息,将基于关注行为信息所产生的关系链数据写入MongoDB数据库;将关系链数据从MongoDB数据库中缓存至Redis数据库。
其中,用户可以在终端设备101上对网络社区中的账号进行关注,上述执行主体接收到终端设备101的关注行为信息后,可以产生对应的关系链数据。例如用户A关注了账号B,那么可以产生“A→B”这条单向边的关系链数据。其中,得到对应的关系链数据后,可以将其写入至MongoDB数据库。其中,可以根据缓存请求,将得到的关系链数据缓存至Redis数据库中。
在本实施例的一些可选的实现方式中,上述响应于接收到关注行为信息,将基于关注行为信息所产生的关系链数据写入MongoDB数据库还包括:通过消息队列,将关系链数据写入关系型数据库。
消息队列是在消息的传输过程中保存消息的容器。其中,在得到基于关注行为信息所产生的关系链数据后,可以生成该关系链数据的写入指令,并将该写入指令存储至消息队列中。当执行消息队列中的该写入指令时,可以将该关系链数据写入至关系型数据库。例如,关系型数据库可以采用MySQL数据库。
在本实施例中,通过将全量的关系链数据异步存储至关系型数据库,相当于为关系链数据作了备份,可以避免在MongoDB数据库出现异常时,关系链的数据丢失。
在本实施例的一些可选的实现方式中,关系链数据包括第一账号,其中,第一账号的关注动态数据的产生方法包括:响应于接收到第一账号发布的动态信息,确定第一账号的关注者账号的数量是否小于或等于设定的阈值;响应于第一账号的关注者账号的数量小于或等于设定的阈值,从MongoDB数据库中拉取关注者账号信息,并根据关注者账号信息和动态信息确定第一账号的关注动态数据。
其中,在网络社区中一些账号(记为“头部账号”,例如“大V”)拥有海量的关注者或粉丝,社区中这些账号的数量占比极小,但是动态发布却集中;具有中等或少量关注者或粉丝的账号(记为“普通账号”,例如“小V”)量级占比极大,但是动态发布少。鉴于此,本申请实施例对Feed系统中的推送方案进行了优化,即头部账号的动态信息的扩散采用拉方案,普通账号的动态信息的扩散采用推方案。
其中,用户在终端设备101发布动态信息后,可以将动态信息发送至上述执行主体。其中,接收到动态信息后,可以获取用户的关注者账号列表,并判断用户的关注者账号的数量是否小于或等于设定的阈值(例如2000个)。若用户的关注者账号的数量小于或等于设定的阈值,则可以将用户判断为普通账号。对于用户是普通账号而言,推送方案可以采用推扩散,因此可以将用户发布的动态内容写入该用户的每个关注者的关注页或收件箱,进而得到有关该用户的关注动态数据。由于,本申请方案中的全量关系链数据存储在MongoDB数据库中,因此可以从MongoDB数据库中拉取关注者账号信息。其中,第一账号的关注动态数据指的是第一账号的关注者的关注页或收件箱中,与第一账号发布的动态信息有关的动态数据。第一账号可以是普通账号。
在本实施例的一些可选的实现方式中,关系链数据包括第二账号,包括第二账号的关系链数据的存储步骤包括:响应于用户为第二账号的关注者,确定第二账号的关注者账号的数量;响应于第二账号的关注者账号的数量大于设定的阈值,将包括第二账号的关系链数据存储至Redis数据库。
其中,用户可以在终端设备101中关注网络社区中的账号,若用户关注的账号为头部账号,则可以将该头部账号写入至用户关注的头部账号池。第二账号可以是头部账号。本申请实施例通过扫描用户全量关注者或粉丝,维护每个关注者或粉丝关注的头部账号,该方案的优点是无集中爆发点,在时间维度上相对散列均匀,对系统压力小。
为了便于理解,图4示出了根据本申请的读取数据的方法的一个实施例的应用场景示意图。
在互联网医疗场景下,用户(患者)购买医生服务(问诊、开方、购药等)后,医生和患者之间则自动建立起基于供求交易的医患关系,医生可以在应用程序或者公众号等终端发布自己的动态或健康建议,其绑定的患者则可以在登录应用程序后拉取到该动态或健康建议;除此之外,应用程序或者公众号作为公共终端,可以允许店铺(药店)等发布店内优惠活动,关注店铺的患者也可以拉取到这些信息;另外,患者可以自定义其感兴趣的话题标签,服务器自动推送相关素材到患者手机以达到宣传效果。
其中,当用户(患者)登录应用程序终端时,会自动获取(拉取)大V、圈子、店铺、标签等动态,并通过ElasticSearch根据指定用户/圈子/标签实时聚合好排序的Feed;小V等好友动态的推送方案采用写扩散离线维护,通过网络层并发请求归并结果并缓存后返回。
进一步参考图5,作为对上述各图所示方法的实现,本申请提供了一种读取数据的装置的一个实施例,该装置实施例与图2所示的方法实施例相对应,该装置具体可以应用于各种电子设备中。
如图5所示,本实施例的读取数据的装置500可以包括:第一读取模块501、拉取模块502、写入模块503。其中,第一读取模块501,被配置成响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,目标数据包括关系链数据和/或关注动态数据;拉取模块502,被配置成响应于检测到目标数据失效,从MongoDB数据库中拉取目标数据的更新数据;写入模块503,被配置成将目标数据的更新数据写入Redis数据库。
在本实施例中,读取数据的装置500中:第一读取模块501、拉取模块502、写入模块503的具体处理及其所带来的技术效果可分别参考图2对应实施例中的步骤201-203的相关说明,在此不再赘述。
在本实施例的一些可选的实现方式中,装置还包括:第二读取模块,被配置成从Redis数据库读取目标数据的更新数据。
在本实施例的一些可选的实现方式中,目标数据的更新数据包括关注动态数据,装置还包括:聚合模块,被配置成采用全文搜索引擎对关注动态数据进行聚合。
在本实施例的一些可选的实现方式中,目标数据包括关系链数据,装置还包括关系链数据写入模块,关系链数据写入模块包括:第一写入模块,被配置成响应于接收到关注行为信息,将基于关注行为信息所产生的关系链数据写入MongoDB数据库;缓存模块,被配置成将关系链数据从MongoDB数据库中缓存至Redis数据库。
在本实施例的一些可选的实现方式中,第一写入模块还包括:第二写入模块,被配置成通过消息队列,将关系链数据写入关系型数据库。
在本实施例的一些可选的实现方式中,关系链数据包括第一账号,其中,第一账号的关注动态数据的产生方法包括:响应于接收到第一账号发布的动态信息,确定第一账号的关注者账号的数量是否小于或等于设定的阈值;响应于第一账号的关注者账号的数量小于或等于设定的阈值,从MongoDB数据库中拉取关注者账号信息,并根据关注者账号信息和动态信息确定第一账号的关注动态数据。
在本实施例的一些可选的实现方式中,关系链数据包括第二账号,包括第二账号的关系链数据的存储步骤包括:响应于用户为第二账号的关注者,确定第二账号的关注者账号的数量;响应于第二账号的关注者账号的数量大于设定的阈值,将包括第二账号的关系链数据存储至Redis数据库。
在本实施例的一些可选的实现方式中,第一账号的关注动态数据的推送方式为写扩散,第二账号的关注动态数据的推送方式为读扩散。
根据本公开的实施例,本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本公开的实现。
如图6所示,设备600包括计算单元601,其可以根据存储在只读存储器(ROM)602中的计算机程序或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序,来执行各种适当的动作和处理。在RAM 603中,还可存储设备600操作所需的各种程序和数据。计算单元601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。
设备600中的多个部件连接至I/O接口605,包括:输入单元606,例如键盘、鼠标等;输出单元607,例如各种类型的显示器、扬声器等;存储单元608,例如磁盘、光盘等;以及通信单元609,例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理,例如读取数据的。例如,在一些实施例中,读取数据的可被实现为计算机软件程序,其被有形地包含于机器可读介质,例如存储单元608。在一些实施例中,计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到RAM 603并由计算单元601执行时,可以执行上文描述的方法XXX的一个或多个步骤。备选地,在其他实施例中,计算单元601可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行读取数据的。
本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器,使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
在本公开的上下文中,机器可读介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
为了提供与用户的交互,可以在计算机上实施此处描述的系统和技术,该计算机具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)和互联网。
计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。
应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本公开公开的技术方案所期望的结果,本文在此不进行限制。
上述具体实施方式,并不构成对本公开保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等,均应包含在本公开保护范围之内。
Claims (18)
1.一种读取数据的方法,包括:
响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,所述目标数据包括关系链数据和/或关注动态数据;
响应于检测到所述目标数据失效,从MongoDB数据库中拉取所述目标数据的更新数据;
将所述目标数据的更新数据写入所述Redis数据库。
2.根据权利要求1所述的方法,所述方法还包括:
从所述Redis数据库读取所述目标数据的更新数据。
3.根据权利要求2所述的方法,所述目标数据的更新数据包括关注动态数据,所述方法还包括:
采用全文搜索引擎对所述关注动态数据进行聚合。
4.根据权利要求2所述的方法,所述目标数据包括关系链数据,所述关系链数据的写入方法包括:
响应于接收到关注行为信息,将基于所述关注行为信息所产生的关系链数据写入所述MongoDB数据库;
将所述关系链数据从所述MongoDB数据库中缓存至Redis数据库。
5.根据权利要求4所述的方法,所述响应于接收到关注行为信息,将基于所述关注行为信息所产生的关系链数据写入所述MongoDB数据库还包括:
通过消息队列,将所述关系链数据写入关系型数据库。
6.根据权利要求1所述的方法,所述关系链数据包括第一账号,其中,所述第一账号的关注动态数据的产生方法包括:
响应于接收到第一账号发布的动态信息,确定所述第一账号的关注者账号的数量是否小于或等于设定的阈值;
响应于所述第一账号的关注者账号的数量小于或等于设定的阈值,从所述MongoDB数据库中拉取所述关注者账号信息,并根据所述关注者账号信息和所述动态信息确定所述第一账号的关注动态数据。
7.根据权利要求1所述的方法,所述关系链数据包括第二账号,所述包括第二账号的关系链数据的存储步骤包括:
响应于用户为第二账号的关注者,确定所述第二账号的关注者账号的数量;
响应于所述第二账号的关注者账号的数量大于设定的阈值,将包括第二账号的关系链数据存储至所述Redis数据库。
8.根据权利要求6或7所述的方法,所述第一账号的关注动态数据的推送方式为写扩散,所述第二账号的关注动态数据的推送方式为读扩散。
9.一种读取数据的装置,其中,所述装置包括:
第一读取模块,被配置成响应于接收到触发操作信息,从Redis数据库中读取缓存的目标数据,其中,所述目标数据包括关系链数据和/或关注动态数据;
拉取模块,被配置成响应于检测到所述目标数据失效,从MongoDB数据库中拉取所述目标数据的更新数据;
写入模块,被配置成将所述目标数据的更新数据写入所述Redis数据库。
10.根据权利要求9所述的装置,所述装置还包括:
第二读取模块,被配置成从所述Redis数据库读取所述目标数据的更新数据。
11.根据权利要求10所述的装置,所述目标数据的更新数据包括关注动态数据,所述装置还包括:
聚合模块,被配置成采用全文搜索引擎对所述关注动态数据进行聚合。
12.根据权利要求10所述的装置,所述目标数据包括关系链数据,所述装置还包括关系链数据写入模块,所述关系链数据写入模块包括:
第一写入模块,被配置成响应于接收到关注行为信息,将基于所述关注行为信息所产生的关系链数据写入所述MongoDB数据库;
缓存模块,被配置成将所述关系链数据从所述MongoDB数据库中缓存至Redis数据库。
13.根据权利要求12所述的装置,所述第一写入模块还包括:
第二写入模块,被配置成通过消息队列,将所述关系链数据写入关系型数据库。
14.根据权利要求10所述的装置,所述关系链数据包括第一账号,其中,所述第一账号的关注动态数据的产生方法包括:
响应于接收到第一账号发布的动态信息,确定所述第一账号的关注者账号的数量是否小于或等于设定的阈值;
响应于所述第一账号的关注者账号的数量小于或等于设定的阈值,从所述MongoDB数据库中拉取所述关注者账号信息,并根据所述关注者账号信息和所述动态信息确定所述第一账号的关注动态数据。
15.根据权利要求10所述的装置,所述关系链数据包括第二账号,所述包括第二账号的关系链数据的存储步骤包括:
响应于用户为第二账号的关注者,确定所述第二账号的关注者账号的数量;
响应于所述第二账号的关注者账号的数量大于设定的阈值,将包括第二账号的关系链数据存储至所述Redis数据库。
16.根据权利要求14或15所述的装置,所述第一账号的关注动态数据的推送方式为写扩散,所述第二账号的关注动态数据的推送方式为读扩散。
17.一种电子设备,包括:
至少一个处理器;以及
与所述至少一个处理器通信连接的存储器;其中,
所述存储器存储有可被所述至少一个处理器执行的指令,所述指令被所述至少一个处理器执行,以使所述至少一个处理器能够执行权利要求1-8中任一项所述的方法。
18.一种存储有计算机指令的非瞬时计算机可读存储介质,所述计算机指令用于使所述计算机执行权利要求1-8中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110134152.0A CN113821537A (zh) | 2021-01-29 | 2021-01-29 | 读取数据的方法、装置、设备以及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110134152.0A CN113821537A (zh) | 2021-01-29 | 2021-01-29 | 读取数据的方法、装置、设备以及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN113821537A true CN113821537A (zh) | 2021-12-21 |
Family
ID=78912374
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110134152.0A Pending CN113821537A (zh) | 2021-01-29 | 2021-01-29 | 读取数据的方法、装置、设备以及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN113821537A (zh) |
-
2021
- 2021-01-29 CN CN202110134152.0A patent/CN113821537A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP3244312B1 (en) | A personal digital assistant | |
CN109522483B (zh) | 用于推送信息的方法和装置 | |
US20170091808A1 (en) | Tracking interaction with sponsored and unsponsored content | |
US9378295B1 (en) | Clustering content based on anticipated content trend topics | |
KR102110265B1 (ko) | 온라인 시스템에서 사용자 행위에 기초한 특성 질의 | |
CN111522940A (zh) | 用于处理评论信息的方法和装置 | |
CN110866040A (zh) | 用户画像生成方法、装置和系统 | |
CN115481227A (zh) | 人机交互对话方法、装置以及设备 | |
CN115202847A (zh) | 任务的调度方法和装置 | |
CN112579897A (zh) | 信息搜索方法和装置 | |
CN111783013A (zh) | 评论信息发布的方法、装置、设备及计算机可读存储介质 | |
CN113821537A (zh) | 读取数据的方法、装置、设备以及存储介质 | |
CN110990007A (zh) | 银行软件功能界面生成方法和装置 | |
CN113656689B (zh) | 模型生成方法和网络信息的推送方法 | |
CN110838019A (zh) | 确定试用品发放人群的方法和装置 | |
CN114785749A (zh) | 一种消息群发处理方法和装置 | |
CN110472055B (zh) | 用于标注数据的方法和装置 | |
CN113360672A (zh) | 用于生成知识图谱的方法、装置、设备、介质和产品 | |
CN114357280A (zh) | 一种信息推送方法、装置、电子设备及计算机可读介质 | |
CN112184370A (zh) | 一种推送产品的方法和装置 | |
JP2011243078A (ja) | 記事管理装置 | |
CN112070564A (zh) | 广告拉取方法、装置、系统与电子设备 | |
CN112148988A (zh) | 用于生成信息的方法、装置、设备以及存储介质 | |
CN113360765B (zh) | 事件信息的处理方法、装置、电子设备和介质 | |
CN114449330B (zh) | 基于直播的信息显示的方法、装置、设备以及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |