CN117472293B - 一种数据存储的方法、电子设备及计算机可读存储介质 - Google Patents

Abstract

一种数据存储的方法、电子设备及计算机可读存储介质，涉及数据处理技术领域。电子设备中包括动态随机存取存储器DRAM和非易失性存储器NVM，DRAM中包括缓存组件，NVM中包括数据库，缓存组件和数据库用于存储数据。在第一时间区间内，电子设备在缓存组件中存储第一生命周期的第一数据，在数据库中存储第二生命周期的第一数据。在第二时间区间内，电子设备在缓存组件中存储第三生命周期的第一数据，在数据库中存储第二生命周期的第一数据；其中，第一生命周期、第二生命周期和第三生命周期两两不相同。上述方案，电子设备采用数据库和缓存组件存储数据，且缓存组件存储数据的生命周期可以动态变化，可以节省查询耗时。

Description

一种数据存储的方法、电子设备及计算机可读存储介质

技术领域

本申请实施例涉及数据处理技术领域，尤其涉及一种数据存储的方法、电子设备及计算机可读存储介质。

背景技术

在电子设备的过程中，电子设备可以采集电子设备的位置数据、联网情况等数据。或者，在经用户授权后，电子设备也可以采集用户的行为数据，如对应用程序的使用数据、运动数据等。电子设备可以存储上述采集的数据。后续，电子设备可以在有需要的情况下查询并使用存储的数据，如使用查询到的数据为用户提供服务。

现有技术中，上述采集的数据通常存储在电子设备的非易失性存储器(nonvolatilememory，NVM)（如磁盘）中。可以理解的是，从NVM中读取数据的效率是较低的。因此，电子设备在查询上述存储在NVM中的数据时，通常会出现查询耗时长的问题，从而无法快速查询到结果并使用。

发明内容

本申请提供一种数据存储的方法、电子设备及计算机可读存储介质，通过运行内存(Dynamic Random Access Memory,DRAM)和NVM结合存储的形式，并动态调节DRAM中的存储参数，以节约查询耗时。

为达到上述目的，本申请采用如下技术方案：

第一方面，本申请提供了一种数据存储方法，应用于电子设备，电子设备中包括动态随机存取存储器DRAM和非易失性存储器NVM，DRAM中包括缓存组件，NVM中包括数据库，缓存组件和数据库用于存储数据。在第一时间区间内，电子设备在缓存组件中存储第一生命周期的第一数据，在数据库中存储第二生命周期的第一数据。其中，第一生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第一时长内产生的第一数据，第二生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第二时长内产生的第一数据，和/或，第一生命周期的第一数据包括当前时刻之前最新产生的第一数量的第一数据，第二生命周期的第一数据包括当前时刻之前最新产生的第二数量的第一数据。第二时长大于第一时长，第二数量大于第一数量。

在第二时间区间内，电子设备在缓存组件中存储第三生命周期的第一数据，在数据库中存储第二生命周期的第一数据。第三生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第三时长内产生的第一数据，和/或，第三生命周期的第一数据包括当前时刻之前最新产生的第三数量的第一数据。第一时长、第二时长和第三时长两两不相同，第二时长大于第三时长。第一数量、第二数量和第三数量两两不相同，第二数量大于第三数量。也就是说，电子设备可以将缓存组件存储的第一数据的生命周期调整为第三生命周期。

综上，电子设备结合数据库和缓存组件来存储数据，电子设备在缓存组件中查询数据的耗时，低于从数据库中查询数据的耗时，可以提高数据查询的效率。进一步，在第一时间区间内，缓存组件存储第一生命周期的第一数据，在第二时间区间内缓存组件存储第三生命周期的第一数据，实现缓存组件中存储数据的生命周期的动态变化。示例性的，电子设备分析查询请求，根据分析结果调整缓存组件中缓存数据的生命周期，使得变化后的生命周期参数可以满足查询请求的查询条件，电子设备可以直接在缓存组件中查询到数据。

在一种具体的实现方式中，第二时间区间位于第一时间区间之后。在第一时间区间内，从缓存组件中未查询到目标生命周期内的第一数据，从数据库中查询到目标生命周期内的第一数据。在第二时间区间内，从缓存组件中查询到目标生命周期内的第一数据。其中，第一时间区间内查询到目标生命周期内的第一数据的耗时，长于第二时间区间内查询到目标生命周期内的第一数据的耗时。

电子设备采用更新缓存组件存储数据的生命周期的方式，使得电子设备可以从缓存组件中查询到目标生命周期内的第一数据，且从缓存组件中查询到目标生命周期内的第一数据的耗时比从数据库查询要短，提高了数据查询效率。

在一种具体的实现方式中，第二时间区间位于第一时间区间之后。在第二时间区间内，在缓存组件中存储第三生命周期的第一数据之前，电子设备需要获取第二时间区间之前的多条目标查询请求，每条目标查询请求用于查询第一数据。然后解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件，基于多组查询条件确定第三生命周期。

电子设备分析第二时间区间之前的多条目标查询请求，根据多条目标查询请求中的多组查询条件确定第三生命周期参数，可以得到更能满足查询请求中查询条件的第三生命周期参数。电子设备将缓存组件中存储数据的生命周期调整为第三生命周期，使得电子设备可以在缓存组件存储的第三生命周期的数据中，查询到满足查询请求中查询条件的数据。

在一种具体的实现方式中，每组查询条件包括查询时间范围和/或查询数量范围。对应的，基于多组查询条件确定第三生命周期，包括基于多个查询时间范围中的目标时间范围确定第三时长，和/或，基于多个查询数量范围中的目标数量范围确定第三数量。

在一些应用场景中，目标时间范围可以包括长度最长的查询时间范围。例如，电子设备可以在多个查询请求的多个查询时间范围中，选择长度最长的查询时间范围作为目标时间范围。

电子设备选择长度最长的查询时间范围作为目标时间范围，得到缓存组件中存储数据的第三时长，可以使大部分的查询请求的查询时间范围落在第三时长内，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询时间范围对应的数据。

在一些应用场景中，目标时间范围可以包括出现次数最多的查询时间范围。例如，电子设备可以在多个查询请求的多个查询时间范围中，选择出现次数最多的查询时间范围作为第三时长。

电子设备选择出现次数最多的查询时间范围作为目标时间范围，得到缓存组件中存储数据的第三时长，第三时长可以满足大部分的查询请求的查询时间范围，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询时间范围对应的数据。

在一些应用场景中，目标时间范围可以包括得分最高的查询时间范围。例如，电子设备可以根据每个查询时间范围的权重，加权计算得到每个查询时间范围的得分，从多个查询时间范围中选择得分最高的查询时间范围。

电子设备权衡不同查询时间范围分配不同的权重，根据查询时间范围的权重计算得到查询时间范围的得分。在多个查询请求的多个查询时间范围中，选择的得分最高的作为目标时间范围，得到缓存组件中存储数据的第三时长，第三时长可以满足大部分查询请求的查询时间范围，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询时间范围对应的数据。

在一些应用场景中，目标数量范围包括间隔数量最多的查询数量范围。例如，电子设备可以在多个查询请求的多个查询数量范围中，选择间隔数量最多的查询数量范围作为第三数量。

电子设备选择间隔数量最多的查询数量范围作为目标数量范围，得到缓存组件中存储数据的第三数量，可以使大部分的查询请求的查询数量范围落在第三数量内，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询数量范围对应的数据。

在一些应用场景中，目标数量范围包括出现次数最多的查询数量范围。例如，电子设备可以在多个查询请求的多个查询数量范围中，选择出现次数最多的查询数量范围作为第三数量。

电子设备选择出现次数最多的查询数量范围作为目标数量范围，得到缓存组件中存储数据的第三数量，第三数量可以满足大部分的查询请求的查询数量范围，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询数量范围对应的数据。

在一些应用场景中，目标数量范围包括得分最高的查询数量范围。例如，电子设备可以根据每个查询数量范围的权重，加权计算得到每个查询数量范围的得分，从多个查询数量范围中选择得分最高的查询数量范围。

电子设备权衡不同查询数量范围分配不同的权重，根据查询数量范围的权重计算得到得分。在多个查询请求的多个查询时间范围中，选择的得分最高的作为目标数量范围，得到缓存组件中存储数据的第三数量，第三数量可以满足大部分查询请求的查询数量范围，因此电子设备可以在缓存组件存储的数据中，查询到与查询请求的查询数量范围对应的数据。

在一种具体的实现方式中，查询时间范围的长度越长，查询时间范围的权重值越小。查询时间范围的得分为查询时间范围的权重值与查询时间范围的出现次数的乘积。也就是说，不同查询时间范围长度的得分不相同，长度越长的查询时间范围的得分可能越小。电子设备对长度越长的查询时间范围分配的权重值越小，根据查询时间范围的权重值和出现次数来计算得到查询时间范围的得分，从而筛选得到得分最高的查询时间范围作为第三时长，可以得到更符合查询需求的第三时长。

电子设备考虑到查询时间范围的长度越长，存储该查询时间范围的数据占用的空间越大，以及电子设备对查询时间范围的查询需求越高，查询时间范围的出现次数越多的情况。电子设备为越大的时间范围，分配更小的权重值。电子设备在根据查询时间范围的权重和出现次数计算得到的得分中，选择得分最高的查询时间范围，可以选择到更符合查询需求的第三时长。并且，电子设备将缓存组件的生命周期调整为第三时长后，可以根据第三时长在pipeline中存储占用空间更合理的时间范围的数据，减少在pipeline中存储过多不存在查询需求的数据的情况，避免存储空间的浪费。

在一种具体的实现方式中，响应于满足第一条件，电子设备解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。第一条件指示电子设备解析目标查询请求的时机。

示例性的，电子设备在达到第一时间点时，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。

电子设备只需要定期（达到第一时间点）触发分析查询请求的操作，无需额外监测拦截到的目标查询请求的数量等信息，可以节省功耗。

示例性的，电子设备在目标查询请求的数量超过第四数量时，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。

电子设备仅在目标查询请求的数量超过第四数量时，触发分析查询请求的操作，无需频繁分析拦截到的目标查询请求，可以节省功耗。

示例性的，电子设备监测到在多条目标查询请求中，从数据库中查到结果的次数超过第五数量时，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。其中，从数据库中查到结果的次数为电子设备在缓存组件中未查到结果的情况下，则从数据库中查询的次数。

电子设备仅在从数据库中查到结果的次数超过第五数量时（可以理解为，缓存组件中存储的数据无法满足电子设备的查询需求），触发分析查询请求的操作，无需频繁分析拦截到的目标查询请求。并且，电子设备可以基于分析结果确定第三生命周期，在缓存组件中存储第三生命周期的数据，电子设备可以直接在缓存组件中查询到电子设备所需要的数据，减少从数据库查询数据的次数，进一步减小查询请求的访问时延。

示例性的，第一条件可以包括多种时机的结合。例如，电子设备在达到第一时间点，且目标查询请求的数量超过第四数量时，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。

电子设备仅在达到第一时间点才触发确定查询请求数量的操作，在未达到第一时间点时，电子设备无需实时监测查询请求的数量，节省功耗。并且，电子设备仅在在达到第一时间点，且目标查询请求的数量超过第四数量时，触发分析查询请求的操作。电子设备在达到第一时间点时，目标查询请求的数量没有超过第四数量的情况下，不触发分析查询请求的操作，避免频繁分析查询请求的情况，进一步节省功耗。

例如，电子设备在达到第一时间点，且多条目标查询请求中，从数据库中查到结果的次数超过第五数量时，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。

电子设备仅在达到第一时间点才触发确定查询请求数量的操作，在未达到第一时间点时，电子设备不确定查询请求数量，也不触发分析查询请求的操作，无需额外监测查询请求的数量等信息，节省功耗。并且，电子设备仅在在达到第一时间点，且多条目标查询请求中，从数据库中查到结果的次数超过第五数量时，触发分析查询请求的操作。电子设备在达到第一时间点，多条目标查询请求中，从数据库中查到结果的次数没有超过第五数量的情况下，不触发分析查询请求的操作，避免频繁分析查询请求的情况，进一步节省功耗。

在一种具体的实现方式中，电子设备在缓存组件和/或数据库中存储的第一数据包括以下至少一项：应用程序的开启数据、电子设备的Wi-Fi状态数据和电子设备的运动状态数据。电子设备在目标查询请求有需要的时候，通过缓存组件和/或数据库查询存储的数据。

在一种具体的实现方式中，电子设备还包括***、查询引擎和缓存管理服务。其中，***可以获取第二时间区间之前的多条目标查询请求。

查询引擎从***读取多条目标查询请求，解析每条目标查询请求中第一数据的一组查询条件，得到多组查询条件。进一步，查询引擎基于多组查询条件确定第三生命周期。

在一种具体的实现方式中，在查询引擎基于多组查询条件确定第三生命周期之后，查询引擎还可以向缓存管理服务发送第三生命周期。

在第二时间区间内，缓存管理服务基于第三生命周期控制在缓存组件中存储第三生命周期的第一数据。

电子设备中查询引擎分析***拦截的目标查询请求，确定出第三生命周期，并通过缓存管理服务基于第三生命周期控制在缓存组件中存储第三生命周期的第一数据，实现基于查询请求动态调整缓存组件中存储数据的生命周期，可以节省电子设备查询数据的耗时。

第二方面，本申请提供一种电子设备，电子设备包括处理器和用于存储所述处理器可执行指令的存储器，当所述处理器被配置为执行所述指令时，使得所述电子设备实现如第一方面及其任一种可能的设计方式所述的方法。

第三方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如第一方面及其任一种可能的设计方式所述的方法。

第四方面，本申请提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行如第一方面及其任一种可能的设计方式所述的方法。

可以理解地，上述提供的第二方面所述的电子设备，第三方面所述的计算机可读存储介质，第四方面所述的计算机程序产品所能达到的有益效果，可参考第一方面及其任一种可能的设计方式中的有益效果，此处不再赘述。

附图说明

图1为本申请实施例提供的一种电子设备的服务界面示意图；

图2为本申请实施例提供的一种数据请求的处理流程示意图；

图3为本申请实施例提供的一种数据查询流程的示意图；

图4为本申请实施例提供的一种查询请求的场景示意图一；

图5为本申请实施例提供的一种查询请求的场景示意图二；

图6为本申请实施例提供的一种手机的硬件结构示意图；

图7为本申请实施例提供的一种手机的软件架构示意图；

图8为本申请实施例提供的一种pipeline（管道）的缓存队列示意图；

图9为本申请实施例提供的一种查询请求解析示意图；

图10为本申请实施例提供的一种数据存储方法的应用场景示意图；

图11为本申请实施例提供的一种数据中台的结构示意图；

图12为本申请实施例提供的一种数据中台的模块交互示意图；

图13为本申请实施例提供的一种自适应存储参数方法的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。其中，在本申请的描述中，除非另有说明，“/”表示或的意思，例如，A/B可以表示A或B；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

另外，为了便于清楚描述本申请实施例的技术方案，在本申请的实施例中，采用了“第一”、“第二”等字样对功能和作用基本相同的相同项或相似项进行区分。本领域技术人员可以理解“第一”、“第二”等字样仅用于描述目的，并不对数量和执行次序进行限定，也不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。并且“第一”、“第二”等字样也并不限定一定不同。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个该特征。在本实施例的描述中，除非另有说明，“至少一个”是指一个或多个，“多个”的含义是两个或两个以上。

在本申请实施例中，“示例性地”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性地”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性地”或者“例如”等词旨在以具体方式呈现相关概念。

在电子设备的使用过程中，电子设备可以采集数据并存储。电子设备在有需要的时候可以通过查询存储的数据，并基于查询结果为用户提供服务。应理解，电子设备可以直接存储未经处理的原始数据（Raw），或者存储处理后的数据。

其中，电子设备采集的数据包括电子设备的状态数据，如位置（location）数据、Wi-Fi状态数据（Wi-FiStatus）、设备连接断开（DeviceAround）数据、所处环境的环境光数据、电池状态数据等。电子设备采集的数据还可以包括用户的行为数据，如对应用程序（application，APP）的使用（开启、关闭、使用时长）数据、运动状态（MSDPMovement）数据、亮灭屏数据、备忘录数据、以及天气（Weather）数据等。为了便于说明，上述电子设备采集的数据也可称为第一数据。

以及，电子设备中的意图推荐业务、数据分析业务、状态控制业务、计划提示业务等业务都有查询需求。其中，意图推荐业务用于预测用户的意图并推荐相应的服务。一种典型的意图推荐业务包括卡片推荐业务，如YOYO卡片。数据分析业务用于分析电子设备的使用情况。示例性的，数据分析业务包括屏幕使用时长分析业务、电池健康状态分析业务以及电池使用时长分析业务等。状态控制业务用于控制电子设备的状态。示例性的，状态控制业务包括待机省电业务，用于控制电子设备进入待机状态以达到省电的目的。计划提示业务用于根据用户预设的提示数据向用户提示计划。示例性的，计划提示业务包括提醒事项提示业务、闹钟提示业务、日程提示业务等。

以电子设备为手机为例，在手机的使用过程中，手机可以采集用户对手机中安装的各个APP的开启数据（APPOpen数据）并存储。后续，手机通过查询存储的APPOpen数据，可以得到用户近期常使用的APP，并向用户推荐。例如，在得到用户近期常使用的是音乐APP之后，手机可以显示图1所示的界面101，界面101是手机的负一屏，界面101中包括 “YOYO”卡片的推送区域1011。推送区域1011中包括音乐APP的应用图标。

在一些实现方式中，如图2所示，电子设备采集的上述数据存储在数据库中，且数据库通常设置于电子设备的磁盘中。相应的，电子设备中的业务则需要从磁盘查询数据，这就会使得查询耗时长，无法及时获得查询结果。

基于上述问题，本申请提出了DRAM和NVM结合存储的思想。其中，DRAM可以包含用于缓存近期采集的数据的缓存组件。数据库可用于存储更长的时间周期内采集到的数据。

在一种具体的实现方式中，DRAM中的缓存组件可以为pipeline（管道）形式。下文中，将主要以该实现方式，即DRAM中的pipeline和NVM中的数据库结合存储数据的方式，说明本方案。

采用pipeline和数据库结合存储数据，如图3所示，电子设备中的业务可以向pipeline发送查询请求，即先从pipeline中查询数据；如果在pipeline中查询到结果，业务则无需从数据库中查询数据；如果在pipeline中未查询到结果，业务才需要进一步从数据库中查询数据。

其中，DRAM的读取效率高于NVM的读取效率，相应的，从pipeline中查询数据的耗时，低于从数据库中查询数据的耗时。可见，采用pipeline和数据库结合存储数据，有些情况下可以直接从pipeline得到查询结果，而无需访问数据库，从而可以减少查询耗时。

以电子设备中的待机省电业务为例，待机省电业务可以从pipeline中查询到近期的亮灭屏数据和APPOpen数据，并用于控制电子设备进入待机状态。这样，待机省电业务可以快速查询到所需的数据，从而及时控制电子设备的状态。

以电子设备中的意图推荐业务为例，意图推荐业务可以从pipeline查询到近期的运动状态数据、 Wi-Fi状态数据、设备连接断开数据以及天气数据，并用于预测用户的意图确定可以推荐的服务。依此，意图决策多意图推理业务可以快速查询到所需的数据，从而及时向用户推荐相应的服务。

以屏幕使用时长分析业务为例，屏幕使用时长分析业务可以从pipeline查询到近期的APP的使用（开启、关闭、使用时长）数据、亮灭屏数据等，分析用户通过屏幕使用各个APP的时长，得到屏幕使用时长分析结果。依此，屏幕使用时长分析业务可以快速查询到所需的数据，从而及时向用户展示屏幕使用时长分析结果。

以计划提示业务为例，计划提示业务可以从pipeline中查询到近期的备忘录数据，向用户提示用户的备忘录事项。

然而，在上述采用pipeline和数据库结合存储数据的方案中，pipeline中存储的是初始配置的固定数量范围和/或固定时间范围的数据。例如，固定数量范围为最近10条、最近8条等，固定时间范围为最近30分钟、最近1小时等。这就导致当有业务从pipeline中查询数据时，可能出现以下问题：

问题1， pipeline内存储的数据量过小，业务在pipeline内难以查询到所需的数据，从而只能进一步去数据库查询数据，还是会导致查询耗时长的问题。

以图4所示的查询请求1为例，查询请求1需要查询最近60分钟、最近100条数据，而pipeline内初始配置的固定数量范围是最近50条，固定时间范围为最近30分钟。因此，pipeline中存储的数据无法满足查询请求1的查询需求，则业务只能进一步从数据库中查询数据，导致查询耗时长。

问题2， pipeline内存储的数据量过大，业务所需的数据只占pipeline中存储的数据的极小一部分，使得pipeline中不被业务所需要的数据，占用过多的存储空间；并且，业务需要在pipeline内存储的数据中查询极小一部分数据，在一定程度上也会导致查询耗时长的问题。

以图5所示的查询请求2为例，查询请求2需要查询最近2分钟、最近5条数据。而pipeline内初始配置的固定数量范围是最近50条，固定时间范围为最近30分钟。因此，pipeline中存储了大量不被查询请求2所需的数据，这些不被需要的数据占用了存储空间。并且，业务需要在最近30分钟的最近50条数据中查询最近2分钟的最近5条数据，在一定程度上也会导致查询耗时长的问题。

为了解决上述问题1和问题2，本申请提出一种数据存储方法，可以应用于电子设备。电子设备可以动态调整pipeline中存储数据的存储参数（包括存储时间范围和/或存储数量范围），如不同时间区间内pipeline中存储数据的存储参数不同。与此同时，数据库的存储参数可以维持不变。

以电子设备根据历史的查询请求调整pipeline中存储数据的存储参数为例，电子设备分析接收到的历史的查询请求，基于历史的查询请求的分析结果动态调节pipeline中存储数据的存储时间范围和/或存储数量范围，而不再始终是固定时间范围和/或固定数量范围。

其中，历史的查询请求可以反映业务的查询需求，因此，电子设备基于对历史的查询请求的分析结果调节pipeline中存储数据的存储时间范围和/或存储数量范围，可以使得pipeline中存储的数据与业务的需求相匹配，而既不会太多、也不会太少。

示例性的，电子设备可以每周结束后，分析本周内的查询请求，如果本周内查询的都是最近20分钟、最近10条的数据，电子设备可以调节pipeline中的数据的存储时间范围为最近20分钟，存储数量范围为最近10条。那么，在下一周内，pipeline中存储的数据为最近20分钟的最近10条数据。

可以理解的是，pipeline中数据的存储时间范围和/或存储数量范围，本质就是用于衡量数据的生命周期的。如果数据在该存储时间范围和存储数量范围内，则认为是有效数据，可以存储在pipeline内；如果数据超出该存储时间范围或者存储数量范围，则认为是无效数据，可以从pipeline中剔除。因此，在存储时间范围和/或存储数量范围内，也可以理解为在生命周期内。

本文中，为了便于说明，可以将调整前的pipeline中的数据称为第一生命周期的数据，将调整后的pipeline中的数据称为第三生命周期的数据。进一步的，调整前pipeline中数据的存储时间范围也可以称为第一时长，调整后pipeline中数据的存储数量范围也可以称为第一数量。数据库的存储参数可以维持不变，也就是说，数据库可以存储一个固定生命周期的数据，例如，数据库可以存储第二生命周期的数据。

示例性的，上述电子设备可以包括手机、平板电脑、笔记本电脑、个人计算机（Personal Computer，PC）、人工智能(Artificial Intelligence，AI)设备、可穿戴式设备、车载设备、智能家居设备等具有数据存储功能的设备。本申请实施例对该电子设备100的具体类型不作特殊限制。下文中，以电子设备为手机为例，对本申请做具体说明。

图6示例性地示出了一种手机100的硬件结构示意图。手机100可以包括处理器110，外部存储器接口120，内部存储器121，通用串行总线(universal serial bus，USB)接头130，充电管理模块140，电源管理模块141，电池142，天线1，天线2，移动通信模块150，无线通信模块160，音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D，传感器模块180，按键190，摄像模组191，显示屏192，以及用户标识模块(SubscriberIdentification Module，SIM)卡接口193等。

在一些实施例中，处理器110可以包括一个或多个接口。处理器110可以通过以上至少一种接口连接触摸传感器、音频模块、无线通信模块、显示器、摄像头等模块。

可以理解的是，本申请实施例示意的各模块间的接口连接关系，只是示意性说明，并不构成对手机100的结构限定。

在本申请另一些实施例中，手机100也可以采用上述实施例中不同的接口连接方式，或多种接口连接方式的组合。

手机100可以通过GPU，显示屏192，以及应用处理器等实现显示功能。在一些实施例中，显示屏192可以用于显示意图推荐业务、数据分析业务、计划提示业务等业务的界面。以意图推荐业务是YOYO卡片为例，显示屏192可以通过前述图1所示的界面101显示YOYO 卡片的推荐结果，即音乐APP。

外部存储器接口120可以用于连接外部存储卡，例如Micro SD卡，实现扩展手机100的存储能力。外部存储卡通过外部存储器接口120与处理器110通信，实现数据存储功能。例如将音乐，视频等文件保存在外部存储卡中。或将音乐，视频等文件从手机传输至外部存储卡中。

内部存储器121可以用于存储计算机可执行程序代码，该可执行程序代码包括指令。内部存储器121可以包括存储程序区和存储数据区。其中，存储程序区可存储操作***，至少一个功能所需的APP(比如声音播放功能，图像播放功能等)等。存储数据区可存储手机100使用过程中所创建的数据(比如音频数据，电话本等)等。此外，内部存储器121可以包括高速随机存取存储器，还可以包括NVM，例如至少一个磁盘存储器件，闪存器件，通用闪存存储器(Universal Flash Storage，UFS)等。

在一些实施例中，高速随机存取存储器（如上述的DRAM）中包括pipeline，NVM（如磁盘）中包括数据库。

处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器110中的存储器的指令，执行手机100的各种功能方法或数据处理。在一些实施例中，处理器110通过运行存储在内部存储器121的指令，和/或存储在设置于处理器110中的存储器的指令，可以执行本方案中的数据存储方法。

手机100可以通过音频模块170，扬声器170A，受话器170B，麦克风170C，耳机接口170D等实现音频数据的采集或播放功能。

传感器模块180用于采集设备数据或经用户授权后采集用户的行为数据。采集的数据可以参照前文描述，在此不再赘述。

按键190可以包括开机键，音量键等。按键190可以是机械按键。也可以是触摸式按键。

可以理解的是，本申请实施例示意的结构并不构成对手机100的具体限定。上述对手机中各组件的介绍仅为示例性地，在本申请另一些实施例中，手机100可以包括比图示更多或更少的部件，或者组合某些部件，或者拆分某些部件，或者不同的部件布置，同时可以实现更多功能。图示的部件可以以硬件，软件或软件和硬件的组合实现。本申请实施例对此不作具体限定。

上述手机中的软件***可以采用分层架构，事件驱动架构或云架构。本申请实施例以手机为分层架构的Android™***为例，示例性说明手机的软件结构。

参照图7，为本申请实施例提供的手机的一种软件架构图。如图7所示，分层架构可将手机的软件分成若干个层，每一层都有清晰的角色和分工。层与层之间通过软件接口通信。在一些实施例中，将Android™***分为四层，从上至下分别为应用程序层（Application layer）、应用程序框架层、***库和内核层。

其中，应用程序层可以包括多种应用程序包，如通话、短信和图库等。

在一些实施例中，应用程序包还可以包括具有数据查询功能的应用，如YOYO卡片、音频播放器、电池健康状态分析、屏幕使用分析、视频播放器、备忘录等。

其中，YOYO卡片、音频播放器、视频播放器等应用均可以作为意图推荐业务，从pipeline和/或数据库中查询数据，基于查询结果预测用户的意图并推荐相应的服务。以YOYO卡片为例，YOYO卡片可以从pipeline和/或数据库中查询用户对各个APP的使用数据向用户推荐APP。以视频播放器为例，视频播放器可以从pipeline和/或数据库中查询用户的历史播放数据，根据历史播放数据向用户推送相关的视频数据并播放。

电池健康状态分析、屏幕使用分析等应用均可以作为数据分析业务，从pipeline和/或数据库中查询数据，基于查询结果分析手机的状况。以电池健康状态分析为例，电池健康状态分析可以从pipeline和/或数据库中查询电池使用的时间、电池使用频率以及电池剩余电量等数据，分析电池的健康状态。以屏幕使用分析为例，屏幕使用分析可以从pipeline和/或数据库中查询用户对各个APP的使用（开启、关闭、使用时长）数据、亮灭屏数据，分析用户通过屏幕使用各个APP的时长。

在一些实施例中，备忘录等应用可以作为计划提示业务，从pipeline和/或数据库中查询数据，向用户提示计划。以备忘录为例，备忘录可以从pipeline和/或数据库中查询用户预先输入的备忘录数据，向用户提示用户的备忘录事项。

应用程序框架层为应用程序层的APP提供应用编程接口(applicationprogramming interface，API)和编程框架。应用程序框架层包括一些预先定义的函数。示例性的，应用程序框架层可以包括窗口管理器，资源管理器等。

***库可以包括多个功能模块，如三维图形处理库(如OpenGL ES)和媒体库(Media Libraries)等。

在一些实施例中，***库中还包括数据中台。数据中台的作用包括：用于采集数据，如采集前文所述的APP的使用数据、用户的行为数据等，存储采集的数据；用于接收APP的查询请求，基于查询请求从pipeline和/或数据库中查询数据并将查询结果反馈至APP；以及，还用于分析历史的查询请求，基于分析结果动态调节pipeline中数据的存储时间范围和/或存储数量范围。可以理解的是，在调节pipeline中数据的存储时间范围和/或存储数量范围后，数据中台则可以基于调节后的存储时间范围和/或存储数量范围存储采集的数据。

内核层是硬件和软件之间的层。内核层可以包含显示驱动、摄像头驱动、音频驱动等各种硬件驱动，用于驱动相应的硬件工作。

应理解，图7所示，软件架构的分层仅为示例性的，软件架构可以包括更多或者更少的软件层。

本申请提供的数据存储方法可以在包含上述硬件及软件结构的手机上执行，下面结合附图说明本申请实施例的方法。

本申请提供了pipeline和数据库结合存储的方式。pipeline中的数据可以按照数据项存储。具体的，pipeline中包括一个或多个（指两个及以上）缓存队列，每个缓存队列用于存储一个数据项。

参见图8，pipeline中包括3个缓存队列，分别为缓存队列1、缓存队列2和缓存队列3。其中，缓存队列1用于存储APP开启数据，缓存队列2用于存储运动状态数据，以及，缓存队列3用于存储Wi-Fi状态数据。

应注意，上述图8所示3个缓存队列中的黑色方块表示存储有数据的区域，白色方块表示未存储数据的区域。另外，图8所示3个缓存队列的长度相同，实际并不以此为限。即，不同的缓存队列的长度可以相同，也可以不同。

手机在得到大量的历史的查询请求后，可以对历史的查询请求分析。具体的，手机可以从历史的查询请求中获得待查询的数据项，以及获得数据项的查询条件。其中，查询条件通常包括查询时间范围和/或查询数量范围。然后，手机可以基于数据项及其查询条件调节pipeline对应数据项的存储时间范围和/或存储数量范围。下文中，以调节存储时间范围和存储数量范围为例说明，相应的，手机则需要获得查询时间范围和查询数量范围。

其中，查询时间范围包括起始时间和结束时间。查询请求中的查询时间范围表示查询起始时间至结束时间之前的数据。通常情况下，结束时间为当前时刻，即查询当前时刻之前、起始时间以内的数据。

查询数量范围包括起始数量和结束数量。查询请求中的查询数量范围表示查询起始数量至结束数量之间的数据。通常情况下，起始数量为1，即查询最近的1到结束数量之间的数据。

下面结合图9对历史的查询请求的分析过程进行说明。

基于前文说明可知，APP可以从pipeline中查询数据，相应的，查询请求可以是领域特定语言（Domain Specific Language，DSL），下文中将DSL查询语言的查询请求简称为DSL查询请求。手机可以分析DSL查询请求，获得DSL查询请求中的数据项和查询条件。

其中，在分析DSL查询请求时，手机可以从DSL查询请求中获得查询事件的参数，得到待查询的数据项。

在一种具体的实现方式中，在DSL查询请求中，查询事件的关键字为EVENT（事件），查询事件的参数跟在EVENT后面的括号中。示例性的，查询事件的格式为：EVENT(数据项)。因此，手机通过定位DSL查询请求中的EVENT，从EVENT后的括号内可以获得查询事件的参数。

示例性的，DSL查询请求为：SELECT EVENT(RawAppOpen).PROPERTY(timestamp,packageName).where(timestamp>=起始时间AND timestamp<= 结束时间)[起始数量, 结束数量]。手机从EVENT后的括号内，可以获得待查询的数据项为AppOpen数据。

以及，在分析DSL查询请求时，手机可以从DSL查询请求中获得查询时间范围和查询数量范围，从而得到查询条件。

在一种具体的实现方式中，在DSL查询请求中，查询条件的关键字为where(哪里)，查询时间范围和查询数量范围跟在where后面。示例性的，查询时间范围跟在where后面的小括号内，查询数量范围跟在where后面的中括号内，相应的，查询条件的格式为：where(查询时间范围)[查询数量范围]。因此，手机通过定位DSL查询请求中的where，从where后的内容中可以获得查询时间范围和查询数量范围。

示例性的，DSL查询请求为：SELECT EVENT(RawAppOpen ).PROPERTY(timestamp,packageName).where(timestamp>=a AND timestamp<= b)[c, d]。手机从where后的小括号内，可以获得查询时间范围为时刻a至时刻b。以及，手机从where后面的中括号内，可以获得查询数量范围为数量c到数量d。

基于前文说明可知，APP也可以直接从数据库中查询数据。相应的，查询请求可以是SQL查询语言，下文中将SQL查询语言的查询请求简称为SQL查询请求。需要说明的是：直接从数据库中查询的方式，虽然不涉及pipeline，但是，手机通过分析SQL查询请求，获得SQL查询请求中的数据项和查询条件，如果从SQL查询请求中获得的目标数据项与pipeline中存储的数据项匹配，即pipeline中存储有目标数据项的数据，手机也可以根据SQL查询请求所要查询的目标数据项和查询条件调节pipeline中目标数据项的存储时间范围和存储数量范围，使得pipeline中存储的目标数据项的数据可以满足部分SQL查询请求的需求。后续，在产生对目标数据项的SQL查询请求后，手机可以转化为DSL查询请求，然后从pipeline中查询，在pipeline中未查询到结果的情况，再通过SQL查询请求去数据库查询，从而减少对数据库的访问，提高查询效率。

其中，在分析SQL查询请求时，手机可以从SQL查询请求中获得查询事件的参数，得到待查询的数据项。

在一种具体的实现方式中，在SQL查询请求中，查询事件的关键字为from（从），查询事件的参数跟在from后面的括号中。示例性的，查询事件的格式为from（数据项）。因此手机通过定位SQL查询请求中的from，从from后的括号内可以获得查询事件的参数。

示例性的，SQL的查询请求为：select timestamp,eventType,status fromcollectEncrypt.RawMSDPMovement where timestamp>= 起始时间 AND timestamp<= 结束时间 AND status in (起始数量,结束数量) order by timestamp desc。手机从from后的括号内，可以获得待查询的数据项为MSDPMovement数据。

以及，在分析SQL查询请求时，手机可以从SQL查询请求中获得查询时间范围和查询数量范围，从而得到查询条件。

在一种具体的实现方式中，在SQL查询请求中，查询条件的关键字为where（哪里），查询时间范围和查询数量范围跟在where后面。示例性的，查询时间范围跟在where后面，查询数量范围跟在查询时间范围后面。相应的，查询条件的格式为：where 查询时间范围 查询数量范围。因此，手机通过定位SQL查询请求中的where，从where后的内容中可以获得查询时间范围和查询数量范围。

示例性的，SQL查询请求为：select timestamp,eventType,status fromcollectEncrypt.RawMSDPMovement where timestamp>= e AND timestamp<= f ANDstatus in (g,h) order by timestamp desc。手机从where后可以获得查询时间范围为时刻e至时刻f。以及，手机可以从查询时间范围后面获得查询数量范围为数量g到数量h。

可以理解的是，手机分析大量的历史查询请求，可以得到大量的分析结果构成的数据项集，数据项集包括至少一个数据项以及每个数据项的查询条件。

示例性的，手机可以得到如下表1所示的数据项集：

表1

上表1中，手机分析了7条查询请求，共涉及APPOpen数据、MSDPMovement数据、Wi-Fi状态数据、Weather数据以及Location数据共5个数据项及其对应的查询条件。

手机可以根据数据项集中每个数据项的查询条件，确定该数据项的存储参数（包括存储时间范围和存储数量范围）。其中，手机可以根据该数据项的查询条件中的查询时间范围，确定出一个目标时间范围，作为该数据项在pipeline中的存储时间范围；以及，手机可以根据该数据项的查询条件中的查询数量范围，确定出一个目标数量范围，作为该数据项在pipeline中的存储数量范围。

以上表1中的APPOpen数据为例，上表1所示的数据项集中APPOpen数据的查询时间范围和查询数量范围如下表2所示：

表2

手机可以根据上表2中的5个查询时间范围确定出APPOpen数据的存储时间范围；以及，手机可以根据上表2中5个查询数量范围确定出APPOpen数据的存储数量范围。

下面分别说明一个数据项的存储时间范围和存储数量范围的确定过程：

第一，存储时间范围的确定。

在一些实施例中，手机可以根据出现次数最多的查询时间范围确定存储时间范围。

具体地，手机可以确定数据项中每个查询时间范围的概率（可以理解为相同的查询时间范围出现的次数占所有查询时间范围的比例）。手机根据概率，筛选出数据项的所有查询时间范围中满足第一预设条件的目标时间范围，将目标时间范围作为数据项的存储时间范围。

可以理解的是，手机可以选择概率最大的查询时间范围作为目标时间范围，使得手机按照概率最大的查询时间范围（可以理解为出现次数最多）在pipeline存储的数据，可以满足大部分（或全部）查询请求的查询时间范围。

APPOpen数据的查询时间范围如表2所示，APPOpen数据有5个查询时间范围，分别为最近10分钟，最近20分钟，最近30分钟，最近 60分钟，最近10分钟。手机计算得到查询时间范围为最近10分钟的概率为0.4，查询时间范围为最近20分钟的概率为0.2，查询时间范围为最近30分钟的概率为0.2，查询时间范围为最近60分钟的概率为0.2。手机可以根据概率，选择概率最大的最近10分钟作为APPOpen数据的目标时间范围，将pipeline中的存储时间范围更新为最近10分钟。

本实施例，手机选择出现次数最多的查询时间范围，更新pipeline中数据项的存储时间范围，可以使得更新后的存储时间范围可以满足大部分（或全部）查询请求的查询时间范围，手机可以直接在pipeline存储的数据中查询与查询请求的查询时间范围所对应的数据，不需要去数据库中查询，降低查询请求访问的时延。

在一些实施例中，手机可以根据长度最长的查询时间范围确定存储时间范围。

具体地，手机可以确定数据项中每个查询时间范围的数值大小。手机根据数值大小，筛选所有查询时间范围中满足第二预设条件的目标时间范围，将目标时间范围作为数据项的存储时间范围。

可以理解的是，手机可以选择长度最长的查询时间范围作为目标时间范围，使得手机按照长度最长的查询时间范围在pipeline中存储的数据，可以满足大部分（或全部）查询请求的查询时间范围。

APPOpen数据的查询时间范围如表2所示，APPOpen数据有5个查询时间范围，分别为最近10分钟，最近20分钟，最近30分钟，最近 60分钟，最近10分钟。为选取目标时间范围，手机可以先按照数值大小对APPOpen数据的查询时间范围排序，得到APPOpen数据的查询时间范围的序列为最近 60分钟>最近30分钟>最近20分钟>最近10分钟。手机可以从序列中筛选最近60分钟，作为APPOpen数据的目标时间范围，将pipeline中的存储时间范围更新为最近60分钟。

本实施例，手机选择长度最长的查询时间范围更新pipeline中数据项的存储时间范围，可以让大部分（或全部）的查询请求的查询时间范围都落在更新后存储时间范围内，使得手机可以直接在pipeline存储的数据中查询与查询请求的查询时间范围所对应的数据，不需要去数据库中查询，降低查询请求访问的时延。

在一些实施例中，手机可以计算各个查询时间范围的得分，根据得分最高的查询时间范围确定存储时间范围。

其中，任一查询时间范围的得分为该查询时间范围的权重值和出现次数的乘积。查询时间范围的长度越长，存储该查询时间范围的数据所需的存储空间越大，越占用存储空间，手机可以分配更小的权重值；查询时间范围的长度越短，存储该查询时间范围的数据所需的存储空间越小，越节省存储空间，手机可以分配更小的权重值。即，查询时间范围的权重值与查询时间范围的长度呈反相关关系。这样，手机可以为更节约存储空间的查询时间范围赋予更高的权重。在此基础上，手机基于权重和出现次数计算出查询时间范围的得分，可以同时衡量手机对查询时间范围的需求，以及存储查询时间范围的数据所占用的空间的大小两个方面的因素，使得手机基于得分筛选确定的存储时间范围，在满足手机的查询需求方面和数据占用空间方面都更合理。

具体地，手机可以确定每个查询时间范围的权重和出现次数。手机根据权重和出现次数计算出查询时间范围的得分，根据得分，筛选所有查询时间范围中满足第三预设条件的目标时间范围，将目标时间范围作为存储时间范围。

在一些应用场景中，部分查询请求的查询时间范围可能比较大，手机根据查询请求更新pipeline的存储参数时，需要权衡所有分析结果中的查询时间范围，通过加权计算得到各查询时间范围的得分，筛选得分最高的查询时间范围作为目标时间范围，将目标时间范围作为存储时间范围，使得存储时间范围可以满足大部分的查询请求的查询时间范围。

例如，APPOpen数据的查询时间范围为如表2所示，APPOpen数据的查询时间范围分别为最近10分钟，最近20分钟，最近30分钟和最近60分钟。各查询时间范围的权重分别为0.4，0.3，0.2，0.1，各查询时间范围出现的次数分别为2次，1次，1次，1次。手机通过加权计算得到各查询时间范围的得分分别为2*0.4=0.8，1*0.3=0.3，1*0.2=0.2，1*0.1=0.1。手机可以选择得分最高的最近10分钟作为APPOpen数据的目标时间范围，并将pipeline中APPOpen数据的存储时间范围更新为10分钟，从而使得手机按照更新后的存储参数，在pipeline中存储的APPOpen数据可以满足所有查询时间范围在最近10分钟以内的查询请求。

手机考虑到查询时间范围的长度越大，存储查询时间范围的数据占用的空间越大，以及手机对查询时间范围的需求越高，查询时间范围的出现次数越多的情况。手机为越大的查询时间范围，分配更小的权重值。然后手机在根据查询时间范围的权重和出现次数计算得到的得分中之后，选择得分最高的时间范围，因此可以选择到更符合查询请求需求的目标时间范围。并且，手机根据该目标时间范围调整的pipeline的存储时间范围后，按照调整后的存储时间范围在pipeline中存储数据的时间范围长度更合理，可以避免在pipeline中存储过大时间范围的数据，减少存储空间的占用。

在前文关于确定存储时间范围的实施例中，都是以手机将目标时间范围作为存储时间范围为例说明的。但是，在实际应用中，并不以此为例。示例性的，手机还可以在选择出目标时间范围之后，增加目标时间范围的长度，得到存储时间范围。

仍以上述表2所示的APPOpen数据为例，手机可以筛选出概率最大的查询时间范围为最近10分钟，在此基础上，手机可以增加目标时间范围的长度到最近15分钟，设定最近15分钟为pipeline中APPOpen数据的存储时间范围。

手机在基于多个查询时间范围筛选出目标时间范围的基础上，再增加目标时间范围的长度，作为pipeline中数据的存储时间范围，可以使得存储时间范围满足更多查询请求中的查询时间范围，提高了手机在pipeline中查询到查询请求所需要的数据的概率，减少查询请求访问数据库的次数，进而提高数据查询效率。

第二，存储数量范围的确定。

在一些实施例中，手机可以根据出现次数最多查询数量范围确定存储数量范围。

APPOpen数据的查询数量范围如表2所示，APPOpen数据有5个查询数量范围，分别为最近10条，最近30条，最近100条，最近 5条，最近30条。手机计算得到查询数量范围为最近10分钟的概率为0.2，查询数量范围为最近30条的概率为0.4，查询数量范围为最近5条的概率为0.2，查询数量范围为最近100条的概率为0.2。根据概率，手机可以选择最近30条为目标数量范围，也即作为APPOpen数据的存储数量范围，将pipeline中的存储数量范围更新为最近30条。

关于根据出现次数最多的查询数量范围确定存储数量范围的实施例中未详细说明的部分，可以参见“手机可以根据出现次数最多的查询时间范围确定存储时间范围”实施例的说明，此处不再赘述。

在一些实施例中，手机可以根据间隔数量最多的查询数量范围确定存储数量范围。

具体地，基于前述内容可知，查询请求中的查询数量范围表示查询起始数量至结束数量之间的范围。因此，查询请求所需查询数据的间隔数量，可以根据查询请求的起始数量和结束数量之间的间隔长度确定。查询请求的起始数量和结束数量之间的间隔长度越大，查询请求所要查询数据的间隔数量就越多。因此，间隔数量最多的查询数量范围可以理解为从起始数量至结束数量之间的间隔长度最大的查询数量范围。

例如，查询请求的起始数量为1，结束数量为30，则查询请求的查询数量范围为最近30条，查询请求的查询数量范围的间隔数量即为30。

APPOpen数据的查询数量范围如表2所示，APPOpen数据有5个查询数量范围，分别为最近10条，最近30条，最近100条，最近 5条，最近30条。APPOpen数据有5个查询数量范围的间隔数量分别为10，30，100，5，30。手机可以先按照间隔数量的大小顺序100>30>10>5，对APPOpen数据的查询数量范围排序，得到APPOpen数据的查询数量范围的序列为最近 100条>最近30条>最近10条>最近5条。手机可以从序列中筛选间隔数量最多的最近100条，作为目标数量范围，也即作为APPOpen数据的存储数量范围，将pipeline中的存储数量范围更新为最近100条。

关于根据间隔数量最多的查询数量范围确定存储数量范围的实施例中未详细说明的部分，可以参见“手机可以根据长度最长的查询时间范围确定存储时间范围”实施例的说明，此处不再赘述。

在一些实施例中，手机可以计算各个查询数量范围的得分，根据得分最高的查询数量范围确定存储数量范围。

其中，任一查询数量范围的得分为该查询数量范围的权重值和出现次数的乘积。查询数量范围越大，存储该查询数量范围的数据所需的存储空间越大，越占用存储空间，手机可以分配更小的权重值；查询数量范围越小，存储该查询数量范围的数据所需的存储空间越小，越节省存储空间，手机可以分配更小的权重值。即，查询数量范围的权重值与查询数量范围的大小呈反相关关系。这样，手机可以为更节约存储空间的查询数量范围赋予更高的权重。

具体地，手机可以确定每个查询数量范围的权重和出现的次数。手机根据权重和出现的次数计算出查询数量范围的得分，根据得分，在所有查询时间范围中筛选出目标时间范围，根据目标数量范围确定出存储数量范围。

在一些应用场景中，部分查询请求的查询数量范围可能比较大，手机根据查询请求更新pipeline的存储参数时，需要权衡所有分析结果中的查询数量范围，通过加权计算得到各查询数量范围的得分，筛选得分最高的查询数量范围作为目标数量范围，可以满足大部分的查询请求的查询数量范围。

例如，APPOpen数据的查询数量范围为如表2所示的最近10条，最近30条，最近100条和最近5条。各查询数量范围的权重分别为0.3，0.2，0.15，0.35，各查询数量范围的权重分别为1次，2次，1次，1次。手机通过加权计算得到各查询数量范围的得分分别为1*0.3=0.3，2*0.2=0.4，1*0.15=0.15，1*0.35=0.35。手机根据得分可以选择得分最高的最近30条为目标数量范围，也即作为APPOpen数据的存储数量范围，并将pipeline中APPOpen数据的存储数量范围更新为30条，从而使得手机按照更新后的存储参数，在pipeline中存储的APPOpen数据可以满足所有查询数量范围在30条以内的查询请求。

关于计算各个查询数量范围的得分，根据得分最高的查询数量范围确定存储数量范围的实施例中未详细说明的部分，可以参见“手机可以计算各个查询时间范围的得分，根据得分最高的查询时间范围确定存储时间范围”实施例的说明，此处不再赘述。

在前文关于确定存储时间范围的实施例中，都是以手机直接将目标数量范围作为存储数量范围为例进行说明的。但是在实际应用中，并不以此为例。示例性的，手机还可以在选择出目标数量范围之后，增大目标数量范围（可以理解为扩大起始数量和结束数量之间的间隔长度），得到存储数量范围。

仍以上述表2所示的APPOpen数据为例，手机可以筛选出的概率最大的查询数量范围为最近100条，在此基础上，手机可以增大目标数量范围到最近120条，设定最近120条为pipeline中APPOpen数据的存储数量范围。

手机在基于多个查询数量范围筛选出目标数量范围的基础上，再增大目标数量范围，作为pipeline中数据的存储数量范围，可以使得存储数量范围满足更多查询请求中的查询数量范围，提高了手机在pipeline中查询到查询请求所需要的数据的概率，减少查询请求访问数据库的次数，进而提高数据查询效率。

至此，手机则确定出了一个数据项的存储时间范围和存储数量范围。

手机可以根据该数据项的存储时间范围和存储数量范围在pipeline中存储该数据项的数据。具体的，针对任一数据项，如果该数据项的数据在对应的存储时间范围和存储数量范围内，手机则在pipeline中存储该数据；如果该数据项的数据超出对应的存储时间范围和/或存储数量范围，手机则从pipeline中剔除该数据。也就是说，pipeline中数据的存储参数发生了更新。

在一些应用场景中，手机可能需要查询一些pipeline中未存储的数据项，手机分析查询请求后，得到的存储参数会包括pipeline中未存储数据项的存储参数。因此，手机在根据存储参数更新初始配置的参数时，可能在pipeline中无法匹配到对应的数据项。因此，手机可以在pipeline中新增该数据项的存储参数。

新增后pipeline的存储参数表如表3所示。

表3

如表3所示的pipeline初始配置的存储参数中不包括APPOpen数据的存储参数。此种情况下，查询请求查询APPOpen数据时，手机无法在pipeline中查询到APPOpen数据，因此需要从数据库中查询。

在第一次更新过程中，手机分析一个或多个查询请求，根据查询请求得到APPOpen数据的查询条件，并根据APPOpen数据的查询条件得到APPOpen数据的目标时间范围和目标数量范围。

手机在根据分析结果更新pipeline初始配置的参数时，无法在pipeline中匹配到APPOpen数据。因此，手机可以根据APPOpen数据的目标时间范围和目标数量范围，在pipeline中新增APPOpen数据的存储参数，并在后续每次更新过程中持续分析、更新pipeline中APPOpen数据的存储参数。

手机经过动态更新pipeline的存储参数后，根据更新后的存储参数在pipeline中存储APPOpen数据。因此，手机可以直接在pipeline中查询APPOpen数据，而不需要去数据库查询，减小了查询请求访问的时延。

手机根据更新后的存储参数在pipeline中存储对应数据项后，pipeline中存储的数据在存储时间范围/存储数量范围上可以满足大部分（或全部）查询请求的查询条件。因此手机可以直接在pipeline中查询数据项，而不需要访问数据库，从而减小了访问时延，同时降低了访问数据库所带来的内存增长。

下面以图10所示3个查询请求（即查询请求8、查询请求9和查询请求10）为例，说明更新存储参数后，手机采用pipeline和数据库结合存储的方式可以达到的效果：

手机更新 pipeline的存储参数后，根据更新后的存储参数在pipeline中存储最近50条、最近30分钟的AppOpen数据。查询请求8，需要查询在最近30分钟、最近45条AppOpen数据。手机可以直接在pipeline中的最近30分钟内的最近50条AppOpen数据中，查询得到该查询请求所需的最近45条AppOpen数据。一方面，手机可以在pipeline中查询数据，而无需进一步从数据库中查询数据，可以降低查询耗时；另一方面，手机从pipeline中存储的最近50条AppOpen数据中，查询最近45条AppOpen数据，可见pipeline中并未存储大量冗余的数据，节省存储空间。

手机更新 pipeline的存储参数后，根据更新后的存储参数在pipeline中存储最近1条、最近15分钟内的MSDPMovement数据。手机接收到的查询请求9需要查询在最近15分钟内、最近1条MSDPMovement数据。手机可以直接在pipeline中查询得到最近15分钟内的最近1条MSDPMovement数据，而不需要从数据库中查询数据。并且pipeline中存储的数据正好满足查询请求9， pipeline中没有存储过多冗余数据来占用过多的内存空间。

手机更新 pipeline的存储参数后，根据更新后的存储参数在pipeline中存储最近10条、最近20分钟内的Wi-Fi状态数据。手机接收到的查询请求10需要查询在最近10条、最近18分钟内的Wi-Fi状态数据。pipeline中数据的存储时间范围和存储数量范围均能满足查询请求10，因此手机可以直接在pipeline中的最近10条、最近20分钟内的Wi-Fi状态数据中，查询得到查询请求10所需的最近10条、最近18分钟内的Wi-Fi状态数据，而不需要从数据库中查询。

需要说明的是，本申请对手机确定存储时间范围和存储数量范围的时机不作具体限定，下面仅列举几种可能的时机：

时机一，手机可以周期性的确定存储时间范围和存储数量范围。

其中，周期可以根据实际需求设定。例如，周期为24小时、5天、7天、半个月等。以周期为24小时为例，手机每隔24小时，分析前一个24小时内的历史查询请求，确定出存储时间范围和存储数量范围并更新pipeline的存储参数。在接下来的24小时内，手机就可以基于新的存储参数在pipeline中存储数据。这样，手机可以基于已经结束的周期内的查询请求确定出下一个周期内的存储时间范围和存储数量范围，从而实现周期性的优化pipeline的存储参数。为了便于说明，上述周期结束的时间点可以称为第一时间点。

在一种具体的实现方式中，手机可以拦截查询请求。在一个周期结束后，手机可以分析该周期内拦截到的历史查询请求，确定存储时间范围和存储数量范围。这样，手机只需要定期触发分析即可，无需额外监测拦截到的历史查询请求的数量等信息，可以节省功耗。

时机二，手机可以在拦截到的历史查询请求超过第四数量之后，确定存储时间范围和存储数量范围。

其中，第四数量可以根据实际需求设定。例如，第四数量为30条、50条、100条等。

以第四数量为50条为例，手机在查询请求的数量超过50条时，分析该数量的查询请求，确定出存储时间范围和存储数量范围，并更新pipeline的存储参数。手机在pipeline中存储上述存储时间范围和存储数量范围的数据。这样，手机可以基于超过50条的查询请求来确定出pipeline中新的存储时间范围和存储数量范围，从而实现基于固定数量（50条）查询请求来动态优化pipeline的存储参数。

手机仅在查询请求的数量达到固定数量（如50条）时才触发分析查询请求的操作，更新存储参数，而不需要频繁分析查询请求，节省功耗。同时，手机按定量的查询请求动态调整pipeline的存储参数，减少后续出现手机无法在pipeline内查询到查询请求所需数据的情况，提高查询请求的访问效率。

时机三，手机可以在pipeline中未查到结果而进一步从数据库查询数据的次数超过第五数量之后，确定存储时间范围和存储数量范围。

其中，第五数量可以根据实际需求设定，例如，第五数量为30次，50次，100次等。

以第五数量为100次为例，手机在每检测到一次查询请求访问数据库时，标记数据库访问次数加一。手机在数据库访问次数达到100次时，分析接收到的数据库访问次数达到100次之前的所有查询请求，确定出存储时间范围和存储数量范围，并动态的更新pipeline中的存储参数。然后手机可以基于新的存储参数在pipeline中存储数据。这样，手机可以基于数据库访问次数超过100次时，分析查询请求来确定出pipeline中新的存储时间范围和存储数量范围，从而实现基于固定数据库访问次数（100次），来分析查询请求，动态优化pipeline的存储参数。

手机仅在从数据库查询数据的次数超过第五数量时，确定当前pipeline中存储的数据没有能够满足查询请求的查询条件时，根据接收到的查询请求动态更新pipeline中存储参数，而不需要频繁分析查询请求，节省功耗。这样，手机可以基于新的存储参数在pipeline中存储数据，然后直接从pipeline中查询数据，减少从数据库查询数据的次数，进一步减小查询请求的访问时延。

时机四，手机可以基于更新指令确定存储时间范围和存储数量范围。

在一些应用场景中，手机可以接收存储参数更新指令。

其中，存储参数更新指令为更新指定数据项的存储时间范围和/或存储数量范围的指令。

以存储参数更新指令更新APPOpen数据为例，手机在接收到存储参数更新指令时，分析存储参数更新指令得到APPOpen数据的存储时间范围为最近30分钟，存储数量范围为最近100条，从而将pipeline中的存储时间范围更新为最近30分钟，存储数量范围更新为最近100条，手机根据更新后的存储参数在pipeline中存储最近30分钟，最近100条的APPOpen数据。

本实施例可以实现针对性地更新pipeline中部分数据项的存储参数，以便pipeline可以满足具有针对性查询部分数据项需求的查询请求。

可以理解的是，上述时机一和时机四中的至少两种时机可以结合。下面以两种结合方式进行说明：

结合方式一，时机一和时机二结合。即，手机可以在一个周期结束，且历史查询请求的数量达到第四数量之后，确定存储时间范围和存储数量范围。

以周期为24小时、第四数量为60条为例，手机每隔24小时，确定该24小时内的查询请求的数量，在该24小时内查询请求的数量达到60条时，手机分析该24小时内的查询请求，确定出存储时间范围和存储数量范围，来动态的更新pipeline中的存储参数。

应理解，在该24小时内查询请求的数量未达到60条时，手机不分析该24内查询请求。

手机仅在周期结束时才确定查询请求数量，在周期内查询请求数量没有达到第四数量时，手机不需要确定查询请求数量，可以节省功耗。并且，手机仅在检测到周期内的查询请求数量达到第四数量时，才触发分析周期内的查询请求的操作，避免频繁的分析查询请求的操作，进一步节省功耗。并且，手机可以根据分析结果动态更新pipeline的存储参数，使得手机更新后的存储参数，在pipeline中存储的数据可以满足下一周期内大部分查询请求的需求，手机可以直接从pipeline中查询数据，提高下一周期内数据查询的效率。

结合方式二，时机一和时机三结合。即，手机可以在一个周期结束，且在pipeline中未查到结果而进一步从数据库查询数据的次数超过第五数量之后，确定存储时间范围和存储数量范围。

以周期为24小时、第五数量为30次为例，手机每隔24小时，确定该24内的查询请求访问数据库的次数，手机在该24小时内的查询请求访问数据库的次数达到30次时，分析该24小时内的查询请求，确定出存储时间范围和存储数量范围，并动态的更新pipeline中的存储参数。这样手机就可以基于新的存储参数在pipeline中存储数据，手机下一周期内可以直接在pipeline中查询到对应数据，减少下一周期内查询请求访问数据库的次数，从而减小查询请求的访问时延。

应理解，手机在周期内的查询请求访问数据库的次数未达到第四预设阈值时，不分析周期内查询请求。

手机仅在周期结束时才确定查询请求访问数据库的次数，无需实时确定查询请求的访问数据库的次数，节省功耗。并且，手机仅在周期内查询请求访问数据库的次数超过第五数量，认为周期内pipeline中的缓存数据无法满足周期的查询请求时，才分析周期内的查询请求，以及时更新pipeline中的存储参数，避免频繁分析查询请求的情况，进一步节省功耗。并且，这样手机可以基于新的存储参数在pipeline中存储数据，使得手机按照更新后的存储参数，在pipeline中存储的数据可以满足下一周期的大部分查询请求，提高了手机在下一周期从pipeline中查询到数据的概率，减少下一周期查询请求访问数据库的次数，从而提高数据访问效率。

每当满足上述时机后，手机则可以确定新的存储时间范围和存储数量范围，从而可以持续的优化存储时间范围和存储数量范围。示例性的，持续优化的结果如下表4所示：

表4

MSDPMovement数据的存储参数如表4所示，手机中pipeline初始存储最近50条、最近30分钟的MSDPMovement数据。手机在第一次动态更新之后，在pipeline中存储最近500条、最近30分钟的MSDPMovement数据。手机在第二次动态更新之后，在pipeline中存储最近100条、最近60分钟的MSDPMovement数据。手机在第三次动态更新之后，在pipeline中存储最近100条、最近60分钟的MSDPMovement数据。

可以看出的是，pipeline中初始配置的存储参数存在MSDPMovement数据的存储时间范围的长度较短、存储数量范围的数量较少的问题，会导致手机在pipeline中查询数据时，无法查询到足够的MSDPMovement数据，需要去数据库中查询相对应的数据。而手机在动态更新后的pipeline中增加了MSDPMovement数据的存储时间范围和缓存数量范围，可以直接在pipeline中查询MSDPMovement数据，减少查询请求访问数据库的次数，提高了数据访问效率。

Wi-Fi状态数据的存储参数如表4所示，手机中的pipeline初始存储最近50条、最近30分钟的Wi-Fi状态数据。手机在第一次动态更新之后，在pipeline中存储最近1条、最近30分钟的Wi-Fi状态数据。手机在第二次动态更新之后，在pipeline中存储最近1条、最近30分钟的Wi-Fi状态数据。手机第三次动态更新之后，在pipeline中存储最近1条、最近30分钟的Wi-Fi状态数据。

可以看出的是，pipeline根据初始配置的存储参数存储的数据，包括大量不被查询请求需要的Wi-Fi状态数据的问题，占用了大量内存，因此手机需要在大量的Wi-Fi状态数据中，查询出与查询请求的查询条件对应的数据，增加了数据查询的耗时，降低了数据访问效率。而手机在动态更新后的pipeline中，减少了pipeline中存储Wi-Fi状态数据的存储数量范围，避免了内存空间的浪费。

location数据的存储参数如表4所示，手机中pipeline初始存储最近50条、最近30分钟的location数据。在第一次动态更新之后，手机在pipeline中存储最近100条、最近30分钟的location数据。在第二次动态更新之后，手机在pipeline中存储最近100条、最近30分钟的location数据。在第三次动态更新之后，手机在pipeline中存储最近100条、最近30分钟的location数据。

可以看出的是，pipeline初始配置的存储参数表存在location数据的存储数量范围的数量较少的问题，会导致手机在pipeline中，无法查询到足够的location数据，需要去数据库中查询相对应的数据，降低了数据访问效率。而手机在动态更新后的pipeline中，增加了location数据的存储数量范围，使得手机可以在pipeline中查询到查询请求需要的location数据，减少访问数据库的次数，提高了数据访问效率。

以及，根据表4可以看出，pipeline在经过2次动态更新之后，pipeline中各数据项的存储参数已经可以满足查询请求的查询条件。因此，第3次动态更新操作中手机没有更新pipeline中各数据项的存储参数。

前文以手机为例，说明了数据存储方法的实施过程。实际应用中，上述数据存储方法具体可以由手机中的数据中台来实现。

参见图11，数据中台进一步包括：北向API层、业务层和业务组件层。

北向API层用于提供数据中台的接口服务，北向API层包括数据接入API和数据读取API。

其中，数据接入API可以接收APP采集的数据，具体采集的数据可以参见前文，在此不再赘述。

数据读取API提供数据查询服务，数据读取API可以接收业务的查询请求，将查询请求的查询结果反馈到APP。

例如，数据读取API可以接收YOYO卡片的查询请求，该查询请求用于查询APPOpen数据，数据读取API可以将查询到的APPOpen数据反馈到APP。

应用程序层中的APP（如YOYO卡片）查询数据的方式包括两种：第一种，直接从数据库查询。这种查询方式主要适用于查询大量数据的场景，如查询近7天的数据的场景。第二种，从pipeline中查询，pipeline未查询到结果，则进一步从数据库查询。这种查询方式主要适用于查询近期数据的场景，如查询近30分钟、1小时内的数据的场景。

业务层提供查询管理服务。

查询管理服务提供解析查询请求服务，查询管理服务可以解析查询请求服务，获得待查询的数据项，以及获得数据项的查询条件。根据数据项和查询条件从pipeline和/或数据库中查询数据，并将查询到的数据发送至数据读取API。其中，查询条件用于表示查询请求查询的数据应满足的条件。

查询管理服务还可以提供拦截并分析历史的查询请求的服务，查询管理服务可以拦截并分析历史的查询请求，基于分析结果确定pipeline中存储的数据的存储时间范围和/或存储数量范围。

在一些实施例中，查询管理服务可以包括***、DSL/RawSQL模块和查询引擎。查询引擎包括DSL引擎和SQL引擎。

其中，***可以提供历史的查询请求的拦截服务。

DSL/RawSQL模块，用于确定数据的查询方式。例如，采用DSL查询语言构成的查询请求查询数据（对应图11中的DSL引擎），采用RawSQL查询语言（或称原始的SQL查询语言）构成的SQL查询请求查询数据（对应图11中的SQL引擎）。

查询引擎可以提供从***读取查询请求，解析查询请求的查询条件，根据查询条件确定pipeline存储参数的服务。

DSL引擎可以提供从***读取DSL查询语言构成的查询请求，解析DSL查询语言构成的查询请求的服务。DSL引擎可以解析DSL查询语言构成的查询请求，获得待查询的数据项，以及获得数据项的查询条件从pipeline中查询数据。以及，DSL引擎可以分析DSL查询语言构成的历史的查询请求，基于分析结果确定pipeline中存储的数据的存储时间范围和/或存储数量范围。DSL引擎还可以向缓存管理服务发送存储时间范围和/或存储数量范围。

SQL引擎可以提供从***读取SQL查询语言构成的查询请求，解析SQL查询语言构成的查询请求的服务。SQL引擎可以解析SQL查询语言构成的查询请求，获得待查询的数据项，以及获得数据项的查询条件。根据待查询的数据项，以及获得数据项的查询条件从数据库中查询数据。以及，SQL引擎分析SQL查询语言构成的历史的查询请求，基于分析结果确定pipeline中存储的数据的存储时间范围和/或存储数量范围。SQL引擎还可以向缓存管理服务发送存储时间范围和/或存储数量范围。

业务组件层提供缓存管理服务和持久化管理服务。缓存管理服务用于控制pipeline中数据的存储，持久化管理服务用于控制数据库中数据的存储。

在一些实施例中，缓存管理服务可以基于查询管理服务确定的存储时间范围和/或存储数量范围控制pipeline中数据的存储，如控制pipeline中仅存储查询管理服务确定的存储时间范围和/或存储数量范围内的数据。

缓存管理服务还可以基于查询管理服务对查询请求的解析结果，从pipeline中查询数据，并将查询结果反馈给查询管理服务。

本申请实施例这里将结合上述图11所示数据中台的构成，以时机为时机一为例，进一步的说明本申请提供的数据存储方法的流程。

如图12所示，所述方法包括：

S1201、业务将查询请求发送至数据中台的北向API。

S1202、数据中台的北向API接收业务发送的查询请求。

S1203、数据中台的***拦截北向API接收到的查询请求。

S1204，数据中台的***将拦截到的查询请求存储在内存中。

S1201-S1204中的具体实现方式，可以参见前文“结合图11说明数据中台的结构及功能”实施例中关于北向API、***的功能的相关描述，在此不再赘述。

数据中台需要对拦截到的查询请求进行分析，确定新的pipeline的存储参数，包括：

S12051、在周期结束时，DSL引擎从内存中读取DSL查询请求；

S12061、DSL引擎分析DSL查询请求，得到DSL查询请求的数据项和查询条件。

其中，DSL查询请求为DSL引擎从内存中读取的，由***标注为由DSL查询语言构成的查询请求。

DSL引擎分析DSL查询请求的过程可以参见前文“结合图9说明历史的查询请求的分析过程”实施例中手机分析DSL查询请求的内容，在此不再赘述。

查询请求也可以是SQL构成的查询请求。因此，上述数据中台确定新的pipeline的存储参数的操作，还包括：

S12052、在周期结束时，SQL引擎从内存中读取SQL查询请求。

其中，SQL查询请求为SQL引擎从内存中读取的，由***标注为由SQL查询语言构成的查询请求。

S12062、SQL引擎分析SQL查询请求，得到SQL查询请求的数据项和查询条件。

S1207、SQL引擎将数据项和查询条件发送给DSL引擎。

SQL引擎分析SQL查询请求的过程，可以参见前文“结合图9说明历史的查询请求的分析过程”实施例中手机分析SQL查询请求的内容，在此不再赘述。

S1208、DSL引擎分析数据项和查询条件，确定数据项的存储时间范围和/或存储数量范围。

S1209、DSL引擎根据数据项的存储时间范围和/或存储数量范围，更新缓存管理服务内pipeline中数据项的存储参数。

DSL引擎分析数据项和查询条件，确定数据项的存储时间范围和/或存储数量范围的具体过程，可以参见前文“存储时间范围和存储数量范围的确定过程”实施例的描述，在此不再赘述。

应理解，上述分析数据项和查询条件，确定数据项的存储时间范围和/或存储数量范围的具体实施方式，也可以由SQL引擎来实现。

在这种情况下，DSL引擎将数据项和查询条件发送给SQL引擎。

SQL引擎分析数据项和查询条件，确定数据项的存储时间范围和/或存储数量范围。

SQL引擎根据数据项的存储时间范围和/或存储数量范围，更新缓存管理服务内pipeline中数据项的存储参数。

数据中台在更新缓存管理服务内pipeline中数据项的存储参数之后，执行S1210。

S1210、缓存管理服务根据更新后的存储参数控制pipeline中存储的数据项。

缓存管理服务控制pipeline中存储的数据项的具体过程，可以参见前文中“结合图11说明数据中台的结构及功能”实施例中，关于缓存管理服务的功能的相关描述，在此不再赘述。

本申请实施例这里将结合图13，进一步对本申请实施例提供的数据存储方法进行完整的说明：

参见图13， pipeline（管道）中存储的数据包括APP开启数据、运动状态数据和Wi-Fi状态数据。

手机的接口（如北向API）接收到查询请求后，手机在pipeline或数据库中查询数据，得到对应的查询结果（如通过数据中台中的DSL引擎或SQL引擎）。在一些实施例中，每个数据项均具有唯一的标识，如具有唯一的数据项ID。

对应的，手机根据数据项ID在pipeline或数据库中匹配对应的数据项，基于匹配的数据项查询满足查询条件的数据，得到对应的查询结果。

手机拦截（如通过数据中台中的***拦截）查询请求，并存储（例如，可以写入数据中台目录下的文件中）。

示例性的，存储查询请求具体包括存储查询请求所需查询的数据项ID+查询条件（包括查询时间、查询数量）。

在时机（如前文时机一到时机四或者其结合）到达之后，手机分析每个查询请求（例如，可以通过SQL引擎、DSL引擎或查询参数解析器（ReqParams）分析查询请求），得到查询请求所需查询的数据项和查询条件（包括查询时间、查询数量）。

手机（如数据中台中的DSL引擎）在确定数据项的存储参数后，根据数据项ID在pipeline中匹配对应的数据项，然后根据数据项的存储参数更新pipeline中预先配置好的，与之匹配的数据项的参数。

本申请另一些实施例提供了一种电子设备，该电子设备可以包括：存储器和一个或多个处理器。该存储器和处理器耦合。该存储器用于存储计算机程序代码，该计算机程序代码包括计算机指令。当处理器执行计算机指令时，电子设备可执行上述方法实施例中的各个步骤。该电子设备的结构可以参考图7所示的结构。

本申请实施例还提供一种计算机可读存储介质，该计算机可读存储介质包括计算机指令，当所述计算机指令在上述电子设备上运行时，使得该电子设备执行上述方法实施例中的各个步骤。

本申请实施例还提供一种计算机程序产品，当所述计算机程序产品在计算机上运行时，使得所述计算机执行上述方法实施例中的各个步骤。

通过以上实施方式的描述，所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块或单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个装置，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是一个物理单元或多个物理单元，即可以位于一个地方，或者也可以分布到多个不同地方。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该软件产品存储在一个存储介质中，包括若干指令用以使得一个设备（可以是单片机，芯片等）或处理器（processor）执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（read only memory，ROM）、随机存取存储器（random access memory，RAM）、磁碟或者光盘等各种可以存储程序代码的介质。

以上内容，仅为本申请的具体实施方式，但本申请的保护范围并不局限于此，任何在本申请揭露的技术范围内的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种数据存储方法，其特征在于，应用于电子设备，所述电子设备中包括动态随机存取存储器DRAM和非易失性存储器NVM，所述DRAM中包括缓存组件，所述NVM中包括数据库，所述缓存组件和所述数据库用于存储数据，所述方法包括：

在第一时间区间内，在所述缓存组件中存储第一生命周期的第一数据，在所述数据库中存储第二生命周期的所述第一数据；其中，所述第一数据包括一个或多个数据项；

获取第二时间区间之前的多条目标查询请求，每条所述目标查询请求用于查询所述第一数据中的一个或多个数据项；

解析每条所述目标查询请求中每个待查询数据项的一组查询条件，得到多组待查询数据项的查询条件；

基于所述多组待查询数据项的查询条件确定每个所述待查询数据项的第三生命周期；

在第二时间区间内，在所述缓存组件中存储第三生命周期的待查询数据项，在所述数据库中存储第二生命周期的所述第一数据；第二时间区间位于所述第一时间区间之后；

其中，所述第一生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第一时长内产生的所述第一数据，所述第二生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第二时长内产生的所述第一数据，所述第三生命周期的第一数据包括当前时刻之前、且与当前时刻的距离为第三时长内产生的所述第一数据，所述第一时长、所述第二时长和所述第三时长两两不相同，所述第二时长大于所述第一时长和所述第三时长；和/或，所述第一生命周期的第一数据包括当前时刻之前最新产生的第一数量的所述第一数据，所述第二生命周期的第一数据包括当前时刻之前最新产生的第二数量的所述第一数据，所述第三生命周期的第一数据包括当前时刻之前最新产生的第三数量的所述第一数据，所述第一数量、所述第二数量和所述第三数量两两不相同，所述第二数量大于所述第一数量和所述第三数量。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第一时间区间内，从所述缓存组件中未查询到目标生命周期内的第一数据，从所述数据库中查询到所述目标生命周期内的第一数据；

在所述第二时间区间内，从所述缓存组件中查询到所述目标生命周期内的第一数据；

其中，所述第一时间区间内查询到所述目标生命周期内的第一数据的耗时，长于所述第二时间区间内查询到所述目标生命周期内的第一数据的耗时。

3.根据权利要求1所述的方法，其特征在于，每组查询条件包括查询时间范围和/或查询数量范围；

所述基于所述多组待查询数据项的查询条件确定每个所述待查询数据项的第三生命周期，包括：

基于多个查询时间范围中的目标时间范围确定所述第三时长，和/或，基于多个查询数量范围中的目标数量范围确定所述第三数量；

其中，所述目标时间范围包括：长度最长的查询时间范围、出现次数最多的查询时间范围或者得分最高的查询时间范围；所述目标数量范围包括：间隔数量最多的查询数量范围、出现次数最多的查询数量范围或者得分最高的查询数量范围。

4.根据权利要求3所述的方法，其特征在于，查询时间范围的得分为查询时间范围的权重值与查询时间范围的出现次数的乘积；其中，查询时间范围的长度越长，查询时间范围的权重值越小；

查询数量范围的得分为查询数量范围的权重值与查询数量范围的出现次数的乘积；其中，查询数量范围的间隔数量越多，查询数量范围的权重值越小。

5.根据权利要求1所述的方法，其特征在于，所述解析每条所述目标查询请求中每个待查询数据项的一组查询条件，得到多组待查询数据项的查询条件，包括：

响应于满足第一条件，解析每条所述目标查询请求中每个待查询数据项的一组查询条件，得到多组待查询数据项的查询条件；

其中，所述第一条件包括以下至少一项：

达到第一时间点；

目标查询请求的数量超过第四数量；

以及，所述多条目标查询请求中，从所述数据库中查到结果的次数超过第五数量；其中，在所述缓存组件中未查到结果的情况下，则从所述数据库中查询。

6.根据权利要求1所述的方法，其特征在于，所述第一数据包括以下至少一项：应用程序的开启数据、所述电子设备的Wi-Fi状态数据和所述电子设备的运动状态数据。

7.根据权利要求1所述的方法，其特征在于，所述电子设备还包括***、查询引擎和缓存管理服务；

所述获取第二时间区间之前的多条目标查询请求，包括：

所述***获取所述第二时间区间之前的所述多条目标查询请求；

所述解析每条所述目标查询请求中每个待查询数据项的一组查询条件，得到多组待查询数据项的查询条件，包括：

所述查询引擎从所述***读取所述多条目标查询请求，解析每条所述目标查询请求中每个待查询数据项的一组查询条件，得到多组待查询数据项的查询条件；

所述基于所述多组待查询数据项的查询条件确定每个所述待查询数据项的第三生命周期，包括：

所述查询引擎基于所述多组待查询数据项的查询条件确定每个所述待查询数据项的第三生命周期。

8.根据权利要求7所述的方法，其特征在于，在所述查询引擎基于所述多组查询条件确定所述第三生命周期之后，所述方法还包括：

所述查询引擎向所述缓存管理服务发送所述第三生命周期；

所述在第二时间区间内，在所述缓存组件中存储第三生命周期的第一数据，包括：

在所述第二时间区间内，所述缓存管理服务基于所述第三生命周期控制在所述缓存组件中存储第三生命周期的所述第一数据。

9.一种电子设备，其特征在于，包括：处理器和用于存储所述处理器可执行指令的存储器，所述处理器被配置为执行所述指令时，使得所述电子设备实现如权利要求1-8中任一项所述的方法。

10.一种计算机可读存储介质，其特征在于，包括计算机指令，当所述计算机指令在电子设备上运行时，使得所述电子设备执行如权利要求1-8中任一项所述的方法。