1.本技术涉及计算机
技术领域：
：，特别涉及一种数据存储方法、可读介质和电子设备。
背景技术：
：：2.随着人工智能(artificialintelligence，ai)技术的快速发展，ai应用的大规模快速普及，一套ai系统需要应对的业务数据量呈几何级数增长。这其中以图形、视频、音频为代表的非结构化数据为主。目前业务处理这类非结构化数据的主流的做法是将数据通过算法先转化成向量(embeddingvector)，之后通过向量数据库系统，例如milvus系统(一种向量数据库系统)，进行向量近似性搜索，以实现对这些数据的搜索查询等需求。3.然而目前用户在向向量数据库系统存储大批量数据时，数据存储的效率低，时延高，用户体验不佳。技术实现要素：4.有鉴于此，本技术实施例提供了一种数据存储方法、可读介质和电子设备。本技术技术方案通过客户端接收用户的数据存储请求，数据存储请求中携带有待存储数据的属性信息；客户端根据待存储数据的属性信息，确定出需要对待存储数据通过第一存储方式进行存储；客户端获取待存储数据的基本参数，并且将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点；数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点。由于采用第一存储方式时，只需要在上述各节点中传递待存储数据的基本参数，通常这些基本参数的数据量较小，传输时占用带宽较低，传输速度快。可以实现数据的快速存储，有助于提升用户体验。5.本技术的第一方面提供了一种数据存储方法，用于数据库系统，数据库系统包括作为客户端、代理节点、协调服务节点、数据节点和存储服务节点的电子设备，该方法包括：6.客户端接收用户的数据存储请求，数据存储请求中携带有待存储数据的属性信息；客户端根据待存储数据的属性信息，确定出需要对待存储数据通过第一存储方式进行存储；客户端获取待存储数据的基本参数，并且将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点，其中，基本参数用于确定获取待存储数据的路径；数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点。7.由于采用第一存储方式时，只需要在上述各节点中传递待存储数据的基本参数，通常这些基本参数的数据量较小，传输时占用带宽较低，传输速度快。相对于动辄数百兆的传输量几乎可以忽略不计。用户虽然也要上传数据文件，但是只需要把待存储的数据文件上传至存储服务节点，由数据节点直接读取，这样就可以绕过存储服务节点。整个过程只涉及对待存储数据的一次网络传输，无需在多个节点间传输待存储数据。可以实现数据的快速存储，减少数据在节点间大量传输，避免数据的多次打包拆包以及拷贝。有助于提升用户体验。8.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的基本参数包括：待存储数据的路径信息。以供数据节点根据待存储数据的路径信息获取到未解析的待存储数据。9.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的基本参数进一步包括：待存储数据的格式信息和/或待存储数据的解析方式。10.在上述第一方面的一种可能的实现中，该数据存储方法中，将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点，包括：客户端将待存储数据的基本参数转换成json文本；将json文本依次经由代理节点、协调服务节点传送至数据节点。11.基于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。12.在上述第一方面的一种可能的实现中，该数据存储方法中，数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点，包括：13.数据节点根据接收到的基本参数确定出待存储数据的路径信息、格式信息以及解析方式；数据节点根据确定出的路径信息获取到未解析的待存储数据；数据节点根据格式信息以及解析方式，对未解析的待存储数据进行解析，得到解析后的待存储数据，并且将解析后的待存储数据存储至存储服务节点。14.在上述第一方面的一种可能的实现中，该数据存储方法中，数据库系统还包括消息存储节点，并且方法还包括：客户端根据待存储数据的属性信息确定出需要对待存储数据通过第二存储方式进行存储，客户端获取待存储数据，并且将待存储数据依次经由代理节点、消息存储节点、传送至数据节点；数据节点将接收到的待存储数据存储至存储服务节点。15.由于待存储数据文件会传送至消息存储节点，由于该节点可以用于维护“日志序列”，记录数据库中所有的关于数据增删改的操作，因此第二存储方式具有数据回滚功能。例如，在时间点t1，用户通过客户端向数据库存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将数据库的数据恢复成t1之前的状态，则用户可以通过客户端向数据库输入相应的数据恢复请求，则数据库可以基于消息存储节点维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。16.因此，综上所述，本技术技术方案为用户提供了“常规”存储方式(第二存储方式)以及“快速”存储方式(第一存储方式)，用户可以自主选择通过这两种存储方式中的其中一种进行数据存储，或者客户端可以自动判断通过这两种存储方式中的其中一种进行数据存储。可以满足不用应用场景下的不同应用需求，应用范围广。17.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的属性信息包括待存储数据的源存储位置、目标存储位置、数据量中的一种或者多种。18.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的存储格式包括json格式、numpy格式、csv格式、parquet格式、faiss格式中的任意一种。19.由于在上述第一存储方式(也即“快速”存储方式)中，只需要在多个节点中传递待存储数据的基本参数。并且将这些基本参数以json文本的形式传递，基于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。20.在上述第一方面的一种可能的实现中，该数据存储方法中，数据库系统为向量数据库系统。21.本技术的第二方面提供了一种可读介质，可读介质上存储有指令，指令在电子设备上执行时使电子设备实现上述第一方面以及第一方面的任意一种可能的实现中的数据存储方法。22.本技术的第三方面提供了一种电子设备，包括：23.存储器，用于存储由电子设备的一个或多个处理器执行的指令；24.以及处理器，是电子设备的处理器之一，用于执行存储器中存储的指令以实现上述第一方面以及第一方面的任意一种可能的实现中的数据存储方法。附图说明25.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。26.图1为本技术实施例示出的一种数据存储的应用场景；27.图2为本技术实施例示出的一种向量数据库20的简要系统架构；28.图3为本技术实施例示出的一种通过图1所示的客户端10向向量数据库20导入数据的数据流向示意图；29.图4为本技术实施例示出的另一种通过图1所示的客户端10向向量数据库20导入数据的数据流向示意图；30.图5为本技术实施例示出的一种对应于图3所示实施例中各节点之间的交互图；31.图6为本技术实施例示出的一种对应于图4所示实施例中各节点之间的交互图；32.图7为本技术实施例示出的一种数据存储方法的流程图；33.图8为本技术实施例示出的一种电子设备的硬件结构框图。具体实施方式34.本技术的说明性实施例包括但不限于一种数据存储方法、可读介质和电子设备。35.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。36.为了便于理解本技术的技术方案，下面首先结合图1介绍本技术技术方案适用的一种数据存储的应用场景。如图1所示的应用场景中包括用户、客户端10以及向量数据库平台20，客户端10可以调用向量数据库平台20的应用程序编程接口(applicationprograminterface，api)，进行数据的插入、删除、查询等操作。用户可以通过客户端10访问向量数据库平台20，例如用户通过操作客户端10，将大量的图像、视频、音频等的向量数据存入向量数据库平台20；又如用户通过操作客户端10，利用待搜索的特征向量，在向量数据库平台20中进行向量的近似性搜索。从而用户可以使用向量数据库平台20搜索出的相似向量，在用户的图片检索系统、视频检索系统、音频检索系统、电商购物平台等中，进行以图搜图、视频相似视频、实时视频推荐、快速检索并返回相似音频、根据用户行为及需求推荐信息或商品等操作。37.其中，客户端10可以包括但不限于：平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、台式电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、上网本，以及手机、蜂窝电话、个人数字助理(personaldigitalassistant，pda)、增强现实(augmentedreality，ar)\虚拟现实(virtualreality，vr)设备、媒体播放器、智能电视、智能音箱、智能手表等。向量数据库平台20可以是由多台服务器构成的服务器集群。38.下面将结合图2对图1所示的应用场景中涉及的向量数据库平台20的系统架构进行进一步详细说明。为了便于说明，以下将结合具体的示例解释根据本技术的向量数据库平台20，说明本技术的技术方案。39.图2示出了一种向量数据库20的简要系统架构。参考图2，向量数据库20包括代理节点(proxy)21、消息存储节点(pulsar)22、协调服务(coordinator)23、数据节点(datanode)24、查询节点(querynode)25、索引节点(indexnode)26、以及存储服务节点(minio/s3)27。其中，数据节点(datanode)24、查询节点(querynode)25、索引节点(indexnode)26为向量数据库20的执行节点。40.此外，代理节点21为向量数据库20的接入层，可以对外提供统一的访问地址并提供服务。在一种可能的实现中，代理节点21用于接收客户端10发送的数据存储、数据查询等请求。在一种可能的实现中，代理节点21还可以将客户端10发送的待存储/待查询的数据、与待存储/待查询的数据相关的参数等转发给其他节点。在一种可能的实现中，代理节点21还可以将客户端10发送的待存储的数据进行切分，并将切分后的数据打包成多个消息包，再将这些消息包发送给消息存储节点22。41.消息存储节点22为第三方服务，用于维护“日志序列”，记录向量数据库20中所有的关于数据增删改的操作。在一种可能的实现中，消息存储节点22可以根据待存储数据写入的时间，将待存储数据进行切分，并维护了一条时间轴便于用户基于时间信息进行数据恢复等操作。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。42.协调服务节点23可以用于向数据节点24、查询节点25、索引节点26等执行节点分配任务。这些任务包括集群拓扑节点管理、负载均衡、时间戳生成、数据声明和数据管理等。协调服务节点23包括数据协调服务(datacoord)、查询协调服务(querycoord)、根协调服务(rootcoord)、索引协调服务(indexcoord)，其中，数据协调服务可以用于负责管理数据节点24的拓扑结构，维护数据的元信息等；查询协调服务可以用于负责管查询节点25的拓扑结构和负载均衡等；根协调服务可以用于负责处理数据定义语言(ddl)和数据控制语言(dcl)请求，比如创建或删除索引等；索引协调服务可以用于负责管理索引节点26的拓扑结构，构建索引和维护索引元信息。43.在一种可能的实现中，协调服务节点23用于将从代理节点21接收的待存储的数据的路径信息以及待存储数据的格式、解析方式等基本参数发送给数据节点24。44.数据节点24可以用于将待存储数据通过存储服务节点27实现持久化存储。还可以通过订阅消息存储节点22获取增量日志数据，处理数据更改请求，并将日志数据打包存储在存储服务节点27上实现日志的持久化存储。数据节点24可以包括多个物理节点，例如这些数据节点可以分别记为：数据节点241至数据节点24n，其中，n为大于等于1的正整数。在一种可能的实现中，数据节点24用于从消息存储节点22接收消息包，并且将消息包拆封后得到的数据保存至存储服务节点27中。在一种可能的实现中，数据节点24还可以用于从协调服务节点23接收待存储的数据的路径信息以及基本参数，并且根据接收的路径信息从存储服务节点27中获取相应的待存储数据，并且根据该数据对应的基本参数解析获取的待存储数据，然后将解析出来的数据分片存储至存储服务节点27。45.查询节点25可以用于响应于查询指令，根据待查询数据对应的索引信息，在存储服务节点27中进行数据查询。例如，待查询数据为一张图像的特征向量，则查询节点25可以根据该图像的特征向量所对应的索引信息，在存储服务节点27中查询到相似的特征向量，从而查找到和该图像相似的图像，实现以图搜图的功能。查询节点25也可以包括多个物理节点，例如这些查询节点可以分别记为：查询节点251至查询节点25m，其中，m为大于1的正整数。46.索引节点26可以用于对存储服务节点27存储的数据，例如标量和向量数据，进行数据分片，将各个数据分片(segment)构建索引，得到索引文件，并将索引文件再保存到存储服务节点27中进行持久化存储。索引节点26也可以包括多个物理节点，例如这些索引节点可以分别记为：索引节点261至索引节点26f，其中，f为大于1的正整数。47.存储服务节点27可以用于实现对数据的持久化存储，例如对用户通过客户端10存储的标量/向量数据、由索引节点26创建的索引文件、由消息存储节点22生成的日志进行持久化存储。存储服务节点27也可以包括多个物理节点，例如这些存储服务节点可以分别记为：存储服务节点271至存储服务节点27g，其中，g为大于1的正整数。在一种可能的实现中，存储服务节点27用于存储用户通过客户端10存储的图形、视频、音频等非结构化数据对应的特征向量。由于存储服务节点27包括多个存储服务节点，则各存储服务节点还可以存储从其他存储服务节点中获取的数据，例如存储服务节点272可以存储从存储服务节点271获取的数据。通常存储服务节点27为第三方服务。48.可以理解的是，图2示意的结构并不构成对本技术技术方案适用的向量数据库平台20的具体限定，在本技术另一些实施例中，向量数据库平台20可以包括比图示更多或更少的节点，或者组合某些节点，或者拆分某些节点，或者不同的节点布置。图2所示的节点可以以硬件，软件或软件和硬件的组合实现。49.如
背景技术：
：所述，图2所示的向量数据库20中，存在这样的情形，当用户在存储大批量数据时，数据存储的效率低，时延高，因此用户体验不佳。50.为此，本技术提供了一种数据存储方法，以下结合图2所示的架构进行解释。首先通过客户端10接收用户的数据存储请求，其中该数据存储请求中携带有待存储数据的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小等。此外，该数据请求中还可以携带有用户输入的存储选项信息等。通过调用向量数据库20的第一存储接口，例如import()接口，将待存储数据的路径信息、格式、解析方式等基本参数以文本的形式，依次经过上述向量数据库20的代理节点21、协调服务节点23传输至数据节点24，由数据节点24基于存储路径获取到待存储数据后基于基本参数进行解析，并将解析后的数据存储至存储服务节点27。从而可以实现对大批量数据的快速存储，数据存储效率高，时延小，有助于提升用户体验。51.在一些实施例中，客户端10可以动态地在上述数据存储方式和常规的数据存储方式间切换。基于上述数据存储请求判断出待存储数据的具体存储方式，例如基于该数据存储请求中携带的待存储数据的数据量大小或者用户输入的存储选项信息，选择不同的存储方式进行数据存储。52.例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式，调用向量数据库20的第一存储接口，例如import()接口，将待存储数据的路径信息、格式、解析方式等基本参数以文本的形式，依次经过上述向量数据库20的代理节点21、协调服务节点23传输至数据节点24，由数据节点24基于存储路径获取到待存储数据后基于基本参数进行解析，并将解析后的数据存储至存储服务节点27。又如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式，通过调用向量数据库20的第二存储接口，例如insert()接口，将待存储数据依次经过上述向量数据库20的代理节点21、消息存储节点22传输至数据节点24，由数据节点24将接收的待存储数据存储至存储服务节点27。53.通过以上方式动态地在上述“快速”数据存储方式和“常规”数据存储方式间切换，从而可以满足用户不同的数据存储需求，兼顾了“快速”数据存储方式的高效性和“常规”数据存储方式可以进行数据回滚的稳定性，应用范围广。54.下面为了便于说明，以向量数据库20具有两个数据节点以及两个存储服务节点，客户端10将其中一个存储服务节点存储的数据文件存储至另一个存储服务节点为例，分别结合图3和图4所示的数据流向图，对本技术实施例提供的两种数据存储方式分别进行大致介绍。55.首先结合图3介绍客户端10选择第一存储方式实现对待存储数据的“快速”存储的大致过程。56.假设客户端10接收到将存储服务节点271中存储的数据文件file1和数据文件file2存储至存储服务节点272中的数据存储请求，并且客户端10基于该请求确定出采用第一存储方式存储数据文件file1和数据文件file2。则客户端10可以将数据文件file1和数据文件file2的路径信息、格式、解析方式等基本参数(options)以json格式文本的形式，传送给代理节点21。代理节点21再将接收到的json文本转发给协调服务节点23(这里是指datacoord节点)。协调服务节点23将json文本中file1和file2的基本参数进行拆分，得到只包括file1的基本参数的json文本option1以及只包括file2的基本参数的json文本option2，然后再将option1发送至数据节点241，将option2发送至数据节点242。数据节点241根据option1，确定出file1的源存储位置为存储服务节点271，目标存储位置为存储服务节点272，则数据节点241从存储服务节点271中读取file1，并基于option1中描述的解析方法对file1进行解析后，将file1的数据存储至存储服务节点272中。类似地，数据节点242根据option2，确定出file2的源存储位置为存储服务节点271，目标存储位置为存储服务节点272，则数据节点242从存储服务节点271中读取file2，并基于option2中描述的解析方法对file2进行解析后，将file2的数据存储至存储服务节点272中。57.从上述关于图3所示的信号流向图的描述中可以看出，图3所示的存储方式中，客户端10只需要将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点241/242，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别，相对于动辄数百兆的传输量几乎可以忽略不计。用户虽然也要上传数据文件，但是只需要把待存储的数据文件上传至存储服务节点，由数据节点直接读取，这样就可以绕过存储服务节点。整个过程只涉及对待存储数据的一次网络传输，无需在多个节点间传输待存储数据。可以实现数据的快速存储，减少数据在节点间大量传输，避免数据的多次打包拆包以及拷贝，避免数据在多节点间传输浪费带宽，大幅提高导入数据性能，数据存储效率高，时延低，有助于提升用户体验。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，基于json格式文本的灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。58.下面结合图4介绍客户端10选择第二存储方式实现对待存储数据的“常规”存储的大致过程。59.假设客户端10接收到将存储服务节点271中存储的数据文件file3存储至存储服务节点272中的数据存储请求，并且客户端10基于该请求确定出采用第二存储方式存储数据文件file3。则客户端10可以将数据文件file3传送给代理节点21。代理节点21接收到数据文件file3之后，将数据文件file3进行切分，并对切分后得到的各子数据文件打包成消息包，然后将各消息包转发给消息存储节点22。消息存储节点22将接收到的消息包shard_1发送给数据节点241，将消息包shard_2发送给数据节点242，数据节点241和数据节点242分别将各自接收到的消息包拆封后得到数据分片segment_1和segment_2，并且将数据分片segment_1和segment_2存入存储服务节点272。60.从上述关于图4所示的信号流向图的描述中可以看出，图4所示的存储方式中，客户端10需要存储的数据需要经过消息存储节点22，由于消息存储节点22可以具有日志管理功能，因此，图4所示的存储方式中，可以实现数据的回滚。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。61.下面将简要介绍下客户端10根据接收到的数据存储请求，判断选择上述“快速”存储方式或者“常规”存储方式的大致过程：62.在一些实施例中，上述数据存储请求中携带有待存储数据的属性信息，例如待存储数据的数据量大小，则客户端10可以根据待存储数据文件的数据量与预设的数据量阈值的大小关系，确定选择上述“快速”存储方式或者“常规”存储方式。63.例如，客户端10接收到关于待存储数据文件file1和数据文件file2的数据存储请求，并且客户端10确定出该请求中携带的待存储的数据文件file1和数据文件file2的数据总量为100mb(兆字节)，假设数据量阈值为50mb，由于数据文件file1和数据文件file2的数据总量大于数据量阈值，则客户端10可以确定出需要通过上述“快速”存储方式存储数据文件file1。64.又如，客户端10接收到关于待存储数据文件file3的数据存储请求，并确定出该请求中携带的待存储数据文件file3的数据量为1mb(兆字节)，数据量阈值为50mb，由于file3的数据量小于数据量阈值，则客户端10可以确定出需要通过上述“常规”存储方式存储数据文件file3。65.需要说明的是，上述数据量阈值的数值只是一种示例，在实际应用中，数据量阈值的具体数值可以根据需要设置，本技术对此不做限定。下面将结合图5，对图3所示的第一存储方式的信号流向图中的客户端10以及向量数据库20中的一些节点之间具体的交互过程进行详细说明。66.图3所示的实施例中，只示意了两个数据节点以及两个存储服务节点，对应于图3，图5所示的交互图中也是为了方便说明，只示意出了两个数据节点以及两个存储服务节点。应当理解的是，图3和图5所示的实施例，只是为了便于说明本技术技术方案的一些示例，在实际应用中向量数据库20包含的数据节点以及存储服务节点的数量较多，本技术对此不做限定。67.具体地，图5所示的交互图包括以下内容：68.s501：客户端10接收用户的数据存储请求。69.其中该数据存储请求中携带有待存储数据的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。70.s502：客户端10根据上述存储请求，确定出选择“快速”存储方式。71.客户端10基于上述存储请求判断出待存储数据的具体存储方式，例如，客户端10接收到关于待存储数据文件file1和数据文件file2的数据存储请求，并且客户端10确定出该请求中携带的待存储的数据文件file1和数据文件file2的数据总量为100mb(兆字节)，假设数据量阈值为50mb，由于数据文件file1和数据文件file2的数据总量大于数据量阈值，则客户端10可以确定出需要通过上述“快速”存储方式存储数据文件file1。72.s503：客户端10生成包含待存储数据的基本参数的json文本。73.也即，在客户端10确定出选择“快速”存储方式向向量数据库20存储待存储数据时，调用向量数据库20的第一存储接口，例如import()接口，生成包含待存储数据的路径信息、格式、解析方式等基本参数的json文本。由于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广。74.在一些实施例中，待存储数据的格式可以为json格式，numpy格式、csv格式、parquet格式、faiss格式等多种文件格式。例如，待存储数据中的标量数据(也即非向量数据)用json格式的文件存储、向量数据用numpy格式、parquet格式、faiss格式的文件存储。又如，直接将待存储数据中的标量数据和向量数据均用json格式的文件存储。75.例如，对于表1所示的一张数据表(也即待存储数据)，包括三个字段，分别是id，year，vector，其中vector是一个向量字段。76.表177.idyearvector12020[1.0,1.1,1.2]22021[2.0,2.1,2.2]32022[3.0,3.1,3.2][0078]如果将表1所示的数据写在json格式的文件中，可以有两种写法，一种是按行写入的行模式(row-based)，另一种是按列写入的列模式(column-based)。[0079]假设将上表1中所示的数据写在json格式的文件中，并且是采用按行写入的行模式，则得到的json格式的数据文件中，可以包括表1的名称、写入的方式、以及表1中的3行数据。例如，该json格式的文件中，用"table1"表示一个数据表，也即上表1；用"rows"表示按行写入；用{"id":1,"year":2020,"vector":[1.0,1.1,1.2]}表示表1中的第一行数据；用{"id":2,"year":2021,"vector":[2.0,2.1,2.2]}表示表1中的第二行数据；用{"id":3,"year":2022,"vector":[3.0,3.1,3.2]}表示表1中的第三行数据。[0080]假设将上表1中所示的数据写在json格式的文件中，并且是采用按列写入的列模式，则得到的json格式的数据文件中，可以包括表1的名称、写入的方式、以及表1中的3列数据。例如，该json格式的文件中，用"table1"表示一个数据表，也即上表1；用"columns"表示按列写入；用"id":[1,2,3]表示表1中的第一列数据；用"year":[2020,2021,2022]表示表1中的第二列数据；用"vector":[[1.0,1.1,1.2],[2.0,2.1,2.2],[3.0,3.1,3.2]]表示表1中的第三列数据。[0081]通过在上述json文本中记录上表1的数据写入模式(行模式(row-based)或者列模式(column-based))，可以使得数据节点24在接收到该json文本之后，可以根据该json文本中记录的数据写入模式，解析出待存储的数据表1中的数据，从而将解析出的数据通过存储服务节点27实现持久化存储。[0082]如果将表1所示的数据写在csv格式的文件中，可以以逗号或者竖线作为分隔符，例如，假设将上表1所示的数据表示成用逗号作为分隔符csv格式的文件，则该csv格式的文件中可以用plaintext表明将表1中的数据用纯本文表示；用id,year,vector表示表1中包含的三个字段；用1,2020,"1.0,1.1,1.2"表示表1中第一行数据，用2,2021,"2.0,2.1,2.2"表示表1中的第二行数据；用3,2022,"3.0,3.1,3.2"表示表1中的第三行数据。[0083]在一些实施例中，待存储数据的路径信息包括待存储数据来源于哪种存储服务、在该存储服务中的相对地址、访问该存储服务的账号密码以及要导入向量数据库20的哪个数据表中等信息。[0084]在一些实施例中，待存储数据的解析方式也即待存储数据的写入方式，例如待存储数据是json文件，则该json文件的解析方式可以为按行解析，或者按列解析。[0085]示例性地，假设待存储数据来源于上述存储服务节点271，存储服务节点271的地址为localhost:9000，类型为minio，账号为minioadmin，密码为minioadmin；待存储数据是json格式的文件，且是按行写入的，需要将待存储数据导入具有uid、year、vector这三个字段的milvus数据表(存储在存储服务节点272中)。则针对该待存储数据的上述基本参数，所生成的json文本中可以用"data_source"表示待存储数据的数据来源，具体地，用"type":"minio"表示待存储数据来源于minio这种存储服务；用"address":"localhost:9000"表示待存储数据文件来源于地址为"localhost:9000"的存储服务节点；用"accesskey_id":"minioadmin"表示访问该存储服务的账号；用"accesskey_secret":"minioadmin",表示访问该存储服务的密码；用"bucket_name":"aaa"表示待存储数据文件来自于存储服务的哪个根目录。[0086]在上述json文本中，还可以用"target_collection":"xxx",表示带存储数据文件要导入到哪个向量数据表中；用"files"表示带存储数据文件列表；用"path":"xxxx/xx.json",表示该待存储数据文件来源于存储服务节点中哪个文件，该路径为相对于上述根目录的路径；用"type":"row_based",表示待存储数据文件为行模式的json文件；用"from":0,表示向量数据表的第0行开始导入；用"to":1000,表示导入到向量数据表的第1000行截止。[0087]在上述json文本中，还可以用"fields_mapping"来表示待存储的数据文件中的字段名和要导入的向量数据表中的字段名的映射关系。具体地，例如，用"table.rows.id":"uid",表示将json格式的待存储数据文件中的id字段映射到要导入的向量数据表中的uid字段；用"table.rows.year":"year",表示将json格式的待存储数据文件中的year字段映射到要导入的向量数据表中的year字段；用"table.rows.vector":"vector"表示将json格式的待存储数据文件中的vector字段映射到要导入的向量数据表的vector字段。此外，在上述json文本中还可以添加一些默认值，例如用"default_fields"表示默认值。在一些实施例中，如果要导入的向量数据表中还有一些字段，例如age字段，但是待存储的数据文件中没有这些字段，则可以将要导入的向量数据表中的这些字段用0作为默认值填充。[0088]需要说明的是，客户端10生成包含待存储数据的基本参数的json文本中的具体内容可以视实际情况而定。本技术对此不作限定。例如，在一些实施例中，可以在上述示意出的json文本中同时写入多个待存储的数据文件。又如，在一些实施例中，可以在上述示意出的json文本中不指定将待存储的数据从milvus数据表的第几行开始导入，以及导入到第几行截止。[0089]在一些实施例中，还可以将待存储数据均转换成默认的格式，在待存储数据的基本参数中对应的json文本中可以写入，也可以不写入格式相关信息。[0090]在一些实施例中，还可以按照默认的解析方式解析待存储数据，在待存储数据的基本参数中对应的json文本中可以写入，也可以不写入解析方式相关信息。[0091]s504：客户端10经由代理节点21向协调服务节点23发送json文本。[0092]也即在客户端10、代理节点21、向协调服务节点23之间无需传递待存储数据本身，只需要传递基于待存储数据的基本参数(options)生成的json格式文本，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。可以避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。[0093]s505：协调服务节点23接收json文本。[0094]s506：协调服务节点23向数据节点241发送json文本中第一部分基本参数。[0095]例如，在一些实施例中，协调服务节点23接收到的json文本中包含的基本参数options涉及两个待存储数据文件file1和file2，对应于file1的基本参数为第一部分基本参数option1，option1包括file1的路径信息、格式、解析方式等参数。对应于file2的基本参数为第二部分基本参数option2，option2包括file2的路径信息、格式、解析方式等参数。且协调服务节点23确定出数据节点241和数据节点242处于空闲状态，且数据节点241和数据节点242的计算能力和存储能力较强，则协调服务节点23可以将option1传送给数据节点241，将option2传送给数据节点242。[0096]s507：协调服务节点23向数据节点242发送json文本中第二部分基本参数。[0097]例如，协调服务节点23可以将上述option2传送给数据节点242。具体过程可参考上述s506的相关描述。[0098]s508：数据节点241接收第一部分基本参数，确定出第一待存储数据的路径信息、格式、解析方式。[0099]例如，在一些实施例中，数据节点241接收到s506中对应于file1的基本参数为option1，则数据节点241根据option1中包含的对应于file1的路径信息、格式、解析方式，确定出file1存储于存储服务节点271中，file1为json格式的文件，file1是按行写入的。[0100]s509：数据节点242接收第二部分基本参数，确定出第二待存储数据的路径信息、格式、解析方式。[0101]例如，在一些实施例中，数据节点242接收到s506中对应于file2的基本参数为option2，则数据节点242根据option2中包含的对应于file2的路径信息、格式、解析方式，确定出file2存储于存储服务节点271中，file2为csv格式的文件，file2是用逗号作为分隔符的。[0102]s510：数据节点241从存储服务节点271获取第一待存储数据。[0103]例如，在一些实施例中，数据节点241从存储服务节点271获取file1。[0104]s511：数据节点242从存储服务节点271获取第二待存储数据。[0105]例如，在一些实施例中，数据节点242从存储服务节点271获取file2。[0106]s512：数据节点241解析第一待存储数据，得到数据分片。[0107]例如，在一些实施例中，数据节点241解析s510获取的file1，得到file1对应的数据分片。[0108]s513：数据节点242解析第二待存储数据，得到数据分片。[0109]例如，在一些实施例中，数据节点242解析s511获取的file2，得到file2对应的数据分片。[0110]s514：数据节点241向存储服务节点272发送数据分片。[0111]例如，在一些实施例中，数据节点241向存储服务节点272发送s512得到的file1对应的数据分片。[0112]s515：数据节点242向存储服务节点272发送数据分片。[0113]例如，在一些实施例中，数据节点242向存储服务节点272发送s513得到的file2对应的数据分片。[0114]s516：存储服务节点272存储接收到的数据分片。[0115]也即存储服务节点272存储从上述数据节点241以及数据节点242获取到的待存储数据的数据分片。例如，在一些实施例中，存储服务节点272存储接收到的file1对应的数据分片以及file2对应的数据分片。[0116]从上述关于图5所示的交互图的描述中可以看出，图5所对应的“快速”存储方式中，客户端10只需要将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点241/242、存储服务节点271/272，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。而无需传送待存储数据本身，避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，由于json格式文本兼具灵活性和可扩展性，使得本技术技术方案支持对多种格式的数据的存储，适用范围广。[0117]可以理解，上述步骤s501至步骤s516的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，例如，协调服务节点23在执行s505之后，可以同时执行s506和s507。又如，数据节点241在执行s508的同时，数据节点242在执行s509，又如数据节点241执行s508的时间节点在数据节点242执行s509的时间节点之前或之后。在此不做限定。[0118]在一些实施例中，本技术技术方案还可以将存入向量数据库20中的数据文件导出。例如，通过向量数据库20的另一api接口，例如export()接口，导出存储在存储服务节点27中的数据。在另一些实施例中，本技术技术方案还可以将从向量数据库20中导出的数据文件重新导入向量数据库20中。例如，通过向量数据库20的export()接口，导出存储在存储服务节点27中的数据之后，再将导出的数据通过上述insert()接口或者import()接口导入向量数据库20中。[0119]下面将结合图6，对图4所示的第二存储方式的数据流向图中的客户端10以及向量数据库20中的一些节点之间具体的交互过程进行详细说明。[0120]同样地，图6所示的实施例中，也只示意了两个数据节点以及两个存储服务节点，对应于图4，图6所示的交互图中也是为了方便说明，只示意出了两个数据节点以及两个存储服务节点。应当理解的是，图4和图6所示的实施例，只是为了便于说明本技术技术方案的一些示例，在实际应用中向量数据库20包含的数据节点以及存储服务节点的数量较多，本技术对此不做限定。具体地，图6所示的交互图包括以下内容：[0121]s601：客户端10接收用户的数据存储请求。[0122]其中该数据存储请求中携带有待存储数据文件file3的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。[0123]s602：客户端10根据上述存储请求，确定出选择“常规”存储方式。[0124]客户端10基于上述存储请求判断出待存储数据的具体存储方式，例如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择“常规”存储方式，则客户端10调用向量数据库20的第二存储接口，例如insert()接口，获取到待存储数据文件，并传递给向量数据库20中的部分节点。[0125]s603：客户端10从存储服务节点271获取待存储的数据文件。[0126]例如，在一些实施例中，客户端10根据接收到的用户的数据存储请求，确定出待存储数据文件file3的源存储位置为存储服务节点271的地址：localhost:9000，则客户端10从存储服务节点271获取到待存储的数据文件file3。[0127]s604：客户端10向代理节点21发送待存储的数据文件。[0128]例如，在一些实施例中，客户端10将从存储服务节点271获取的待存储的数据文件file3发送给代理节点21。[0129]s605：代理节点21切分待存储的数据文件，并将切分得到的子数据文件封装成消息包。[0130]例如，在一些实施例中，代理节点21接收到客户端10发送的数据文件file3之后，将数据文件file3进行切分，例如按照设定行(一行对应一个向量)进行切分，得到多个子数据文件，并将切分得到的子数据文件封装成消息包。[0131]s606：代理节点21向消息存储节点22发送消息包。[0132]例如，在一些实施例中，代理节点21将对通过切分上述数据文件file3得到的子数据文件进行封装得到的消息包发送给消息存储节点22。[0133]s607：消息存储节点22接收消息包。[0134]例如，在一些实施例中，消息存储节点22从代理节点21接收由上述数据文件file3切分得到的子数据文件进行封装后得到的消息包shard_1和shard_2。[0135]s608：数据节点241从消息存储节点22拉取消息包。[0136]例如，在一些实施例中，数据节点241从消息存储节点22拉取到消息包shard_1。[0137]s609：数据节点242从消息存储节点22拉取消息包。[0138]例如，在一些实施例中，数据节点242从消息存储节点22拉取到消息包shard_2。[0139]s610：数据节点241拆封消息包，得到数据分片。[0140]例如，在一些实施例中，数据节点241对从消息存储节点22拉取到消息包shard_1进行拆封，得到数据分片segment_1。[0141]s611：数据节点242拆封消息包，得到数据分片。[0142]例如，在一些实施例中，数据节点242对从消息存储节点22拉取到消息包shard_2进行拆封，得到数据分片segment_2。[0143]s612：数据节点241向存储服务节点272发送数据分片。[0144]例如，在一些实施例中，数据节点241向存储服务节点272数据分片segment_1。[0145]s613：数据节点242向存储服务节点272发送数据分片。[0146]例如，在一些实施例中，数据节点241向存储服务节点272数据分片segment_2。[0147]s614：存储服务节点272存储接收到的数据分片。[0148]例如，在一些实施例中，存储服务节点272将从数据节点241接收到的数据分片segment_1，以及从数据节点242接收到的数据分片segment_2进行持久化存储。[0149]可以理解，上述步骤s601至步骤s614的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，在此不做限定。[0150]从上述关于图6所示的交互图的描述中可以看出，图6所对应的“常规”存储方式中，客户端10需要将待存储数据文件本身，依次传送给代理节点21、消息存储节点22、数据节点241/242、存储服务节点271/272，由于待存储数据文件的数据量通常较大，因此图6对应的“常规”存储方式相对于图5所对应的“快速”存储方式数据存储效率较低，时延高。[0151]但是图6所对应的“常规”存储方式中，由于待存储数据文件会传送至消息存储节点22，由于该节点可以用于维护“日志序列”，记录向量数据库20中所有的关于数据增删改的操作，因此图6所对应的“常规”存储方式具有数据回滚功能。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。[0152]因此，综上所述，本技术技术方案为用户提供了“常规”存储方式以及“快速”存储方式，用户可以自主选择通过这两种存储方式中的其中一种进行数据存储，或者客户端10可以自动判断通过这两种存储方式中的其中一种进行数据存储。可以满足不用应用场景下的不同应用需求，应用范围广。[0153]在分别介绍完图5和图6中客户端10以及向量数据库20中的一些节点之间具体的交互过程之后，下面将结合图7对本技术实施例提供的一种数据存储方法进行介绍。具体地，图7所示的数据存储方法包括以下内容：[0154]s701：客户端10接收用户的数据存储请求，其中该数据存储请求中携带有待存储数据的属性信息。[0155]例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。[0156]s702：客户端10根据数据存储请求，判断选择第一存储方式或者第二存储方式。[0157]例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式(即“快速”存储方式)，进入s703。又如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式(即“常规”存储方式)，进入s705。[0158]s703：客户端10调用第一存储接口，将待存储数据的基本参数以json文本的形式沿着第一路径传送至向量数据库20的数据节点24。其中，第一路径可以包括代理节点21、协调服务节点23、数据节点24、存储服务节点27。[0159]例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式，调用import()接口，将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点24。然后由数据节点24根据待存储数据的基本参数，得到待存储数据。[0160]由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。而无需传送带存储数据本身，避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，由于json格式文本兼具灵活性和可扩展性，使得本技术技术方案支持对多种格式的数据的存储，适用范围广。[0161]s704：向量数据库20的数据节点24基于待存储数据的基本参数，得到待存储数据。[0162]例如，数据节点24接收到待存储数据的基本参数，根据基本参数中包含的待存储数据的路径信息从对应的存储服务节点中获取某种格式(例如json格式、csv格式等)的待存储数据，并按照基本参数中包含的解析方式，对待存储数据进行解析。例如，将按行写入的json格式的待存储数据中的id字段映射到milvus数据表中的uid字段、将按行写入的json格式的待存储数据中的year字段映射到milvus数据表中的year字段、将按行写入的json格式的待存储数据中的vector字段映射到milvus数据表中的vector字段。[0163]s705：客户端10调用第二存储接口，将待存储数据沿着第二路径存储至向量数据库20的数据节点24。其中，第二存储路径可以包括代理节点21、消息存储节点22、数据节点24、存储服务节点27。[0164]例如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式(即“常规”存储方式)，则客户端10调用向量数据库20的第二存储接口，例如insert()接口，根据存储请求中携带的待存储数据的源存储位置，从对应的存储服务节点中获取待存储数据文件。然后将待存数据文件依次传送给代理节点21、消息存储节点22、数据节点24、存储服务节点27。[0165]s706：向量数据库20的数据节点24将待存储数据存储至向量数据库20的存储服务节点27中。[0166]也就是说在向量数据库20的数据节点24从消息存储节点22中接收到的消息包中解封出来的待存储数据，或者基于从协调服务节点23中获得的基本参数得到的待存储数据，写入第三方的存储服务节点27中。[0167]可以理解，上述步骤s701至步骤s706的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，在此不做限定。[0168]图8为本技术实施例中提供的电子设备100的框图。图8示意性地示出了根据多个实施例的示例电子设备100。在一个实施例中，电子设备100可以包括一个或多个处理器104，与处理器104中的至少一个连接的系统控制逻辑108，与系统控制逻辑108连接的系统内存112，与系统控制逻辑108连接的非易失性存储器(nvm)116，以及与系统控制逻辑108连接的网络接口120。[0169]在一些实施例中，处理器104可以包括一个或多个单核或多核处理器。在一些实施例中，处理器104可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在电子设备100采用enb(evolvednodeb，增强型基站)101或ran(radioaccessnetwork，无线接入网)控制器102的实施例中，处理器104可以被配置为执行各种符合的实施例。可以理解，本技术实施例中，处理器104可以用于执行本技术实施例中提供的数据存储方法。[0170]在一些实施例中，系统控制逻辑108可以包括任意合适的接口控制器，以向处理器104中的至少一个和/或与系统控制逻辑108通信的任意合适的设备或组件提供任意合适的接口。[0171]在一些实施例中，系统控制逻辑108可以包括一个或多个存储器控制器，以提供连接到系统内存112的接口。系统内存112可以用于加载以及存储数据和/或指令。在一些实施例中电子设备100的内存112可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(dram)。[0172]nvm/存储器116可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，nvm/存储器116可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如hdd(harddiskdrive，硬盘驱动器)，cd(compactdisc，光盘)驱动器，dvd(digitalversatiledisc，数字通用光盘)驱动器中的至少一个。[0173]nvm/存储器116可以包括安装电子设备100的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口120通过网络访问nvm/存储116。[0174]特别地，系统内存112和nvm/存储器116可以分别包括：指令124的暂时副本和永久副本。指令124可以包括：由处理器104中的至少一个执行时导致电子设备100实施本技术实施例中提及的数据存储方法的指令。在一些实施例中，指令124、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑108，网络接口120和/或处理器104中。[0175]网络接口120可以包括收发器，用于为电子设备100提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口120可以集成于电子设备100的其他组件。例如，网络接口120可以集成于处理器104的，系统内存112，nvm/存储器116，和具有指令的固件设备(未示出)中的至少一种，当处理器104中的至少一个执行所述指令时，电子设备100实现本技术实施例中提及的数据存储方法。[0176]网络接口120可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口120可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。[0177]在一个实施例中，处理器104中的至少一个可以与用于系统控制逻辑108的一个或多个控制器的逻辑封装在一起，以形成系统封装(sip)。在一个实施例中，处理器104中的至少一个可以与用于系统控制逻辑108的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(soc)。[0178]电子设备100可以进一步包括：输入/输出(i/o)设备132。i/o设备132可以包括用户界面，使得用户能够与电子设备100进行交互；外围组件接口的设计使得外围组件也能够与电子设备100交互。[0179]本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。[0180]本技术实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。[0181]本技术公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本技术的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。[0182]可将程序代码应用于输入指令，以执行本技术描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本技术的目的，处理系统包括具有诸如例如数字信号处理器(digitalsignalprocessor，dsp)、微控制器、专用集成电路(applicationspecificintegratedcircuit，asic)或微处理器之类的处理器的任何系统。[0183]程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本技术中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。[0184]在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、只读存储器(cd-roms)、磁光盘、只读存储器(readonlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、可擦除可编程只读存储器(erasableprogrammablereadonlymemory，eprom)、电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。[0185]在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。[0186]需要说明的是，本技术各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本技术所提出的技术问题的关键。此外，为了突出本技术的创新部分，本技术上述各设备实施例并没有将与解决本技术所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。[0187]需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。[0188]虽然通过参照本技术的某些优选实施例，已经对本技术进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
技术领域：
：，特别涉及一种数据存储方法、可读介质和电子设备。
背景技术：
：：2.随着人工智能(artificialintelligence，ai)技术的快速发展，ai应用的大规模快速普及，一套ai系统需要应对的业务数据量呈几何级数增长。这其中以图形、视频、音频为代表的非结构化数据为主。目前业务处理这类非结构化数据的主流的做法是将数据通过算法先转化成向量(embeddingvector)，之后通过向量数据库系统，例如milvus系统(一种向量数据库系统)，进行向量近似性搜索，以实现对这些数据的搜索查询等需求。3.然而目前用户在向向量数据库系统存储大批量数据时，数据存储的效率低，时延高，用户体验不佳。技术实现要素：4.有鉴于此，本技术实施例提供了一种数据存储方法、可读介质和电子设备。本技术技术方案通过客户端接收用户的数据存储请求，数据存储请求中携带有待存储数据的属性信息；客户端根据待存储数据的属性信息，确定出需要对待存储数据通过第一存储方式进行存储；客户端获取待存储数据的基本参数，并且将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点；数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点。由于采用第一存储方式时，只需要在上述各节点中传递待存储数据的基本参数，通常这些基本参数的数据量较小，传输时占用带宽较低，传输速度快。可以实现数据的快速存储，有助于提升用户体验。5.本技术的第一方面提供了一种数据存储方法，用于数据库系统，数据库系统包括作为客户端、代理节点、协调服务节点、数据节点和存储服务节点的电子设备，该方法包括：6.客户端接收用户的数据存储请求，数据存储请求中携带有待存储数据的属性信息；客户端根据待存储数据的属性信息，确定出需要对待存储数据通过第一存储方式进行存储；客户端获取待存储数据的基本参数，并且将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点，其中，基本参数用于确定获取待存储数据的路径；数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点。7.由于采用第一存储方式时，只需要在上述各节点中传递待存储数据的基本参数，通常这些基本参数的数据量较小，传输时占用带宽较低，传输速度快。相对于动辄数百兆的传输量几乎可以忽略不计。用户虽然也要上传数据文件，但是只需要把待存储的数据文件上传至存储服务节点，由数据节点直接读取，这样就可以绕过存储服务节点。整个过程只涉及对待存储数据的一次网络传输，无需在多个节点间传输待存储数据。可以实现数据的快速存储，减少数据在节点间大量传输，避免数据的多次打包拆包以及拷贝。有助于提升用户体验。8.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的基本参数包括：待存储数据的路径信息。以供数据节点根据待存储数据的路径信息获取到未解析的待存储数据。9.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的基本参数进一步包括：待存储数据的格式信息和/或待存储数据的解析方式。10.在上述第一方面的一种可能的实现中，该数据存储方法中，将待存储数据的基本参数依次经由代理节点、协调服务节点传送至数据节点，包括：客户端将待存储数据的基本参数转换成json文本；将json文本依次经由代理节点、协调服务节点传送至数据节点。11.基于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。12.在上述第一方面的一种可能的实现中，该数据存储方法中，数据节点根据接收到的基本参数得到待存储数据，并且将待存储数据存储至存储服务节点，包括：13.数据节点根据接收到的基本参数确定出待存储数据的路径信息、格式信息以及解析方式；数据节点根据确定出的路径信息获取到未解析的待存储数据；数据节点根据格式信息以及解析方式，对未解析的待存储数据进行解析，得到解析后的待存储数据，并且将解析后的待存储数据存储至存储服务节点。14.在上述第一方面的一种可能的实现中，该数据存储方法中，数据库系统还包括消息存储节点，并且方法还包括：客户端根据待存储数据的属性信息确定出需要对待存储数据通过第二存储方式进行存储，客户端获取待存储数据，并且将待存储数据依次经由代理节点、消息存储节点、传送至数据节点；数据节点将接收到的待存储数据存储至存储服务节点。15.由于待存储数据文件会传送至消息存储节点，由于该节点可以用于维护“日志序列”，记录数据库中所有的关于数据增删改的操作，因此第二存储方式具有数据回滚功能。例如，在时间点t1，用户通过客户端向数据库存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将数据库的数据恢复成t1之前的状态，则用户可以通过客户端向数据库输入相应的数据恢复请求，则数据库可以基于消息存储节点维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。16.因此，综上所述，本技术技术方案为用户提供了“常规”存储方式(第二存储方式)以及“快速”存储方式(第一存储方式)，用户可以自主选择通过这两种存储方式中的其中一种进行数据存储，或者客户端可以自动判断通过这两种存储方式中的其中一种进行数据存储。可以满足不用应用场景下的不同应用需求，应用范围广。17.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的属性信息包括待存储数据的源存储位置、目标存储位置、数据量中的一种或者多种。18.在上述第一方面的一种可能的实现中，该数据存储方法中，待存储数据的存储格式包括json格式、numpy格式、csv格式、parquet格式、faiss格式中的任意一种。19.由于在上述第一存储方式(也即“快速”存储方式)中，只需要在多个节点中传递待存储数据的基本参数。并且将这些基本参数以json文本的形式传递，基于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。20.在上述第一方面的一种可能的实现中，该数据存储方法中，数据库系统为向量数据库系统。21.本技术的第二方面提供了一种可读介质，可读介质上存储有指令，指令在电子设备上执行时使电子设备实现上述第一方面以及第一方面的任意一种可能的实现中的数据存储方法。22.本技术的第三方面提供了一种电子设备，包括：23.存储器，用于存储由电子设备的一个或多个处理器执行的指令；24.以及处理器，是电子设备的处理器之一，用于执行存储器中存储的指令以实现上述第一方面以及第一方面的任意一种可能的实现中的数据存储方法。附图说明25.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。26.图1为本技术实施例示出的一种数据存储的应用场景；27.图2为本技术实施例示出的一种向量数据库20的简要系统架构；28.图3为本技术实施例示出的一种通过图1所示的客户端10向向量数据库20导入数据的数据流向示意图；29.图4为本技术实施例示出的另一种通过图1所示的客户端10向向量数据库20导入数据的数据流向示意图；30.图5为本技术实施例示出的一种对应于图3所示实施例中各节点之间的交互图；31.图6为本技术实施例示出的一种对应于图4所示实施例中各节点之间的交互图；32.图7为本技术实施例示出的一种数据存储方法的流程图；33.图8为本技术实施例示出的一种电子设备的硬件结构框图。具体实施方式34.本技术的说明性实施例包括但不限于一种数据存储方法、可读介质和电子设备。35.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。36.为了便于理解本技术的技术方案，下面首先结合图1介绍本技术技术方案适用的一种数据存储的应用场景。如图1所示的应用场景中包括用户、客户端10以及向量数据库平台20，客户端10可以调用向量数据库平台20的应用程序编程接口(applicationprograminterface，api)，进行数据的插入、删除、查询等操作。用户可以通过客户端10访问向量数据库平台20，例如用户通过操作客户端10，将大量的图像、视频、音频等的向量数据存入向量数据库平台20；又如用户通过操作客户端10，利用待搜索的特征向量，在向量数据库平台20中进行向量的近似性搜索。从而用户可以使用向量数据库平台20搜索出的相似向量，在用户的图片检索系统、视频检索系统、音频检索系统、电商购物平台等中，进行以图搜图、视频相似视频、实时视频推荐、快速检索并返回相似音频、根据用户行为及需求推荐信息或商品等操作。37.其中，客户端10可以包括但不限于：平板电脑、桌面型计算机、膝上型计算机、手持计算机、笔记本电脑、台式电脑、超级移动个人计算机(ultra-mobilepersonalcomputer，umpc)、上网本，以及手机、蜂窝电话、个人数字助理(personaldigitalassistant，pda)、增强现实(augmentedreality，ar)\虚拟现实(virtualreality，vr)设备、媒体播放器、智能电视、智能音箱、智能手表等。向量数据库平台20可以是由多台服务器构成的服务器集群。38.下面将结合图2对图1所示的应用场景中涉及的向量数据库平台20的系统架构进行进一步详细说明。为了便于说明，以下将结合具体的示例解释根据本技术的向量数据库平台20，说明本技术的技术方案。39.图2示出了一种向量数据库20的简要系统架构。参考图2，向量数据库20包括代理节点(proxy)21、消息存储节点(pulsar)22、协调服务(coordinator)23、数据节点(datanode)24、查询节点(querynode)25、索引节点(indexnode)26、以及存储服务节点(minio/s3)27。其中，数据节点(datanode)24、查询节点(querynode)25、索引节点(indexnode)26为向量数据库20的执行节点。40.此外，代理节点21为向量数据库20的接入层，可以对外提供统一的访问地址并提供服务。在一种可能的实现中，代理节点21用于接收客户端10发送的数据存储、数据查询等请求。在一种可能的实现中，代理节点21还可以将客户端10发送的待存储/待查询的数据、与待存储/待查询的数据相关的参数等转发给其他节点。在一种可能的实现中，代理节点21还可以将客户端10发送的待存储的数据进行切分，并将切分后的数据打包成多个消息包，再将这些消息包发送给消息存储节点22。41.消息存储节点22为第三方服务，用于维护“日志序列”，记录向量数据库20中所有的关于数据增删改的操作。在一种可能的实现中，消息存储节点22可以根据待存储数据写入的时间，将待存储数据进行切分，并维护了一条时间轴便于用户基于时间信息进行数据恢复等操作。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。42.协调服务节点23可以用于向数据节点24、查询节点25、索引节点26等执行节点分配任务。这些任务包括集群拓扑节点管理、负载均衡、时间戳生成、数据声明和数据管理等。协调服务节点23包括数据协调服务(datacoord)、查询协调服务(querycoord)、根协调服务(rootcoord)、索引协调服务(indexcoord)，其中，数据协调服务可以用于负责管理数据节点24的拓扑结构，维护数据的元信息等；查询协调服务可以用于负责管查询节点25的拓扑结构和负载均衡等；根协调服务可以用于负责处理数据定义语言(ddl)和数据控制语言(dcl)请求，比如创建或删除索引等；索引协调服务可以用于负责管理索引节点26的拓扑结构，构建索引和维护索引元信息。43.在一种可能的实现中，协调服务节点23用于将从代理节点21接收的待存储的数据的路径信息以及待存储数据的格式、解析方式等基本参数发送给数据节点24。44.数据节点24可以用于将待存储数据通过存储服务节点27实现持久化存储。还可以通过订阅消息存储节点22获取增量日志数据，处理数据更改请求，并将日志数据打包存储在存储服务节点27上实现日志的持久化存储。数据节点24可以包括多个物理节点，例如这些数据节点可以分别记为：数据节点241至数据节点24n，其中，n为大于等于1的正整数。在一种可能的实现中，数据节点24用于从消息存储节点22接收消息包，并且将消息包拆封后得到的数据保存至存储服务节点27中。在一种可能的实现中，数据节点24还可以用于从协调服务节点23接收待存储的数据的路径信息以及基本参数，并且根据接收的路径信息从存储服务节点27中获取相应的待存储数据，并且根据该数据对应的基本参数解析获取的待存储数据，然后将解析出来的数据分片存储至存储服务节点27。45.查询节点25可以用于响应于查询指令，根据待查询数据对应的索引信息，在存储服务节点27中进行数据查询。例如，待查询数据为一张图像的特征向量，则查询节点25可以根据该图像的特征向量所对应的索引信息，在存储服务节点27中查询到相似的特征向量，从而查找到和该图像相似的图像，实现以图搜图的功能。查询节点25也可以包括多个物理节点，例如这些查询节点可以分别记为：查询节点251至查询节点25m，其中，m为大于1的正整数。46.索引节点26可以用于对存储服务节点27存储的数据，例如标量和向量数据，进行数据分片，将各个数据分片(segment)构建索引，得到索引文件，并将索引文件再保存到存储服务节点27中进行持久化存储。索引节点26也可以包括多个物理节点，例如这些索引节点可以分别记为：索引节点261至索引节点26f，其中，f为大于1的正整数。47.存储服务节点27可以用于实现对数据的持久化存储，例如对用户通过客户端10存储的标量/向量数据、由索引节点26创建的索引文件、由消息存储节点22生成的日志进行持久化存储。存储服务节点27也可以包括多个物理节点，例如这些存储服务节点可以分别记为：存储服务节点271至存储服务节点27g，其中，g为大于1的正整数。在一种可能的实现中，存储服务节点27用于存储用户通过客户端10存储的图形、视频、音频等非结构化数据对应的特征向量。由于存储服务节点27包括多个存储服务节点，则各存储服务节点还可以存储从其他存储服务节点中获取的数据，例如存储服务节点272可以存储从存储服务节点271获取的数据。通常存储服务节点27为第三方服务。48.可以理解的是，图2示意的结构并不构成对本技术技术方案适用的向量数据库平台20的具体限定，在本技术另一些实施例中，向量数据库平台20可以包括比图示更多或更少的节点，或者组合某些节点，或者拆分某些节点，或者不同的节点布置。图2所示的节点可以以硬件，软件或软件和硬件的组合实现。49.如
背景技术：
：所述，图2所示的向量数据库20中，存在这样的情形，当用户在存储大批量数据时，数据存储的效率低，时延高，因此用户体验不佳。50.为此，本技术提供了一种数据存储方法，以下结合图2所示的架构进行解释。首先通过客户端10接收用户的数据存储请求，其中该数据存储请求中携带有待存储数据的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小等。此外，该数据请求中还可以携带有用户输入的存储选项信息等。通过调用向量数据库20的第一存储接口，例如import()接口，将待存储数据的路径信息、格式、解析方式等基本参数以文本的形式，依次经过上述向量数据库20的代理节点21、协调服务节点23传输至数据节点24，由数据节点24基于存储路径获取到待存储数据后基于基本参数进行解析，并将解析后的数据存储至存储服务节点27。从而可以实现对大批量数据的快速存储，数据存储效率高，时延小，有助于提升用户体验。51.在一些实施例中，客户端10可以动态地在上述数据存储方式和常规的数据存储方式间切换。基于上述数据存储请求判断出待存储数据的具体存储方式，例如基于该数据存储请求中携带的待存储数据的数据量大小或者用户输入的存储选项信息，选择不同的存储方式进行数据存储。52.例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式，调用向量数据库20的第一存储接口，例如import()接口，将待存储数据的路径信息、格式、解析方式等基本参数以文本的形式，依次经过上述向量数据库20的代理节点21、协调服务节点23传输至数据节点24，由数据节点24基于存储路径获取到待存储数据后基于基本参数进行解析，并将解析后的数据存储至存储服务节点27。又如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式，通过调用向量数据库20的第二存储接口，例如insert()接口，将待存储数据依次经过上述向量数据库20的代理节点21、消息存储节点22传输至数据节点24，由数据节点24将接收的待存储数据存储至存储服务节点27。53.通过以上方式动态地在上述“快速”数据存储方式和“常规”数据存储方式间切换，从而可以满足用户不同的数据存储需求，兼顾了“快速”数据存储方式的高效性和“常规”数据存储方式可以进行数据回滚的稳定性，应用范围广。54.下面为了便于说明，以向量数据库20具有两个数据节点以及两个存储服务节点，客户端10将其中一个存储服务节点存储的数据文件存储至另一个存储服务节点为例，分别结合图3和图4所示的数据流向图，对本技术实施例提供的两种数据存储方式分别进行大致介绍。55.首先结合图3介绍客户端10选择第一存储方式实现对待存储数据的“快速”存储的大致过程。56.假设客户端10接收到将存储服务节点271中存储的数据文件file1和数据文件file2存储至存储服务节点272中的数据存储请求，并且客户端10基于该请求确定出采用第一存储方式存储数据文件file1和数据文件file2。则客户端10可以将数据文件file1和数据文件file2的路径信息、格式、解析方式等基本参数(options)以json格式文本的形式，传送给代理节点21。代理节点21再将接收到的json文本转发给协调服务节点23(这里是指datacoord节点)。协调服务节点23将json文本中file1和file2的基本参数进行拆分，得到只包括file1的基本参数的json文本option1以及只包括file2的基本参数的json文本option2，然后再将option1发送至数据节点241，将option2发送至数据节点242。数据节点241根据option1，确定出file1的源存储位置为存储服务节点271，目标存储位置为存储服务节点272，则数据节点241从存储服务节点271中读取file1，并基于option1中描述的解析方法对file1进行解析后，将file1的数据存储至存储服务节点272中。类似地，数据节点242根据option2，确定出file2的源存储位置为存储服务节点271，目标存储位置为存储服务节点272，则数据节点242从存储服务节点271中读取file2，并基于option2中描述的解析方法对file2进行解析后，将file2的数据存储至存储服务节点272中。57.从上述关于图3所示的信号流向图的描述中可以看出，图3所示的存储方式中，客户端10只需要将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点241/242，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别，相对于动辄数百兆的传输量几乎可以忽略不计。用户虽然也要上传数据文件，但是只需要把待存储的数据文件上传至存储服务节点，由数据节点直接读取，这样就可以绕过存储服务节点。整个过程只涉及对待存储数据的一次网络传输，无需在多个节点间传输待存储数据。可以实现数据的快速存储，减少数据在节点间大量传输，避免数据的多次打包拆包以及拷贝，避免数据在多节点间传输浪费带宽，大幅提高导入数据性能，数据存储效率高，时延低，有助于提升用户体验。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，基于json格式文本的灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广，并且可在不改变接口定义的条件下可以扩展支持任意不同类型的数据文件。58.下面结合图4介绍客户端10选择第二存储方式实现对待存储数据的“常规”存储的大致过程。59.假设客户端10接收到将存储服务节点271中存储的数据文件file3存储至存储服务节点272中的数据存储请求，并且客户端10基于该请求确定出采用第二存储方式存储数据文件file3。则客户端10可以将数据文件file3传送给代理节点21。代理节点21接收到数据文件file3之后，将数据文件file3进行切分，并对切分后得到的各子数据文件打包成消息包，然后将各消息包转发给消息存储节点22。消息存储节点22将接收到的消息包shard_1发送给数据节点241，将消息包shard_2发送给数据节点242，数据节点241和数据节点242分别将各自接收到的消息包拆封后得到数据分片segment_1和segment_2，并且将数据分片segment_1和segment_2存入存储服务节点272。60.从上述关于图4所示的信号流向图的描述中可以看出，图4所示的存储方式中，客户端10需要存储的数据需要经过消息存储节点22，由于消息存储节点22可以具有日志管理功能，因此，图4所示的存储方式中，可以实现数据的回滚。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。61.下面将简要介绍下客户端10根据接收到的数据存储请求，判断选择上述“快速”存储方式或者“常规”存储方式的大致过程：62.在一些实施例中，上述数据存储请求中携带有待存储数据的属性信息，例如待存储数据的数据量大小，则客户端10可以根据待存储数据文件的数据量与预设的数据量阈值的大小关系，确定选择上述“快速”存储方式或者“常规”存储方式。63.例如，客户端10接收到关于待存储数据文件file1和数据文件file2的数据存储请求，并且客户端10确定出该请求中携带的待存储的数据文件file1和数据文件file2的数据总量为100mb(兆字节)，假设数据量阈值为50mb，由于数据文件file1和数据文件file2的数据总量大于数据量阈值，则客户端10可以确定出需要通过上述“快速”存储方式存储数据文件file1。64.又如，客户端10接收到关于待存储数据文件file3的数据存储请求，并确定出该请求中携带的待存储数据文件file3的数据量为1mb(兆字节)，数据量阈值为50mb，由于file3的数据量小于数据量阈值，则客户端10可以确定出需要通过上述“常规”存储方式存储数据文件file3。65.需要说明的是，上述数据量阈值的数值只是一种示例，在实际应用中，数据量阈值的具体数值可以根据需要设置，本技术对此不做限定。下面将结合图5，对图3所示的第一存储方式的信号流向图中的客户端10以及向量数据库20中的一些节点之间具体的交互过程进行详细说明。66.图3所示的实施例中，只示意了两个数据节点以及两个存储服务节点，对应于图3，图5所示的交互图中也是为了方便说明，只示意出了两个数据节点以及两个存储服务节点。应当理解的是，图3和图5所示的实施例，只是为了便于说明本技术技术方案的一些示例，在实际应用中向量数据库20包含的数据节点以及存储服务节点的数量较多，本技术对此不做限定。67.具体地，图5所示的交互图包括以下内容：68.s501：客户端10接收用户的数据存储请求。69.其中该数据存储请求中携带有待存储数据的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。70.s502：客户端10根据上述存储请求，确定出选择“快速”存储方式。71.客户端10基于上述存储请求判断出待存储数据的具体存储方式，例如，客户端10接收到关于待存储数据文件file1和数据文件file2的数据存储请求，并且客户端10确定出该请求中携带的待存储的数据文件file1和数据文件file2的数据总量为100mb(兆字节)，假设数据量阈值为50mb，由于数据文件file1和数据文件file2的数据总量大于数据量阈值，则客户端10可以确定出需要通过上述“快速”存储方式存储数据文件file1。72.s503：客户端10生成包含待存储数据的基本参数的json文本。73.也即，在客户端10确定出选择“快速”存储方式向向量数据库20存储待存储数据时，调用向量数据库20的第一存储接口，例如import()接口，生成包含待存储数据的路径信息、格式、解析方式等基本参数的json文本。由于json格式的文本兼具灵活性和可扩展性，使得本技术技术方案可以支持对多种格式的数据的存储，适用范围广。74.在一些实施例中，待存储数据的格式可以为json格式，numpy格式、csv格式、parquet格式、faiss格式等多种文件格式。例如，待存储数据中的标量数据(也即非向量数据)用json格式的文件存储、向量数据用numpy格式、parquet格式、faiss格式的文件存储。又如，直接将待存储数据中的标量数据和向量数据均用json格式的文件存储。75.例如，对于表1所示的一张数据表(也即待存储数据)，包括三个字段，分别是id，year，vector，其中vector是一个向量字段。76.表177.idyearvector12020[1.0,1.1,1.2]22021[2.0,2.1,2.2]32022[3.0,3.1,3.2][0078]如果将表1所示的数据写在json格式的文件中，可以有两种写法，一种是按行写入的行模式(row-based)，另一种是按列写入的列模式(column-based)。[0079]假设将上表1中所示的数据写在json格式的文件中，并且是采用按行写入的行模式，则得到的json格式的数据文件中，可以包括表1的名称、写入的方式、以及表1中的3行数据。例如，该json格式的文件中，用"table1"表示一个数据表，也即上表1；用"rows"表示按行写入；用{"id":1,"year":2020,"vector":[1.0,1.1,1.2]}表示表1中的第一行数据；用{"id":2,"year":2021,"vector":[2.0,2.1,2.2]}表示表1中的第二行数据；用{"id":3,"year":2022,"vector":[3.0,3.1,3.2]}表示表1中的第三行数据。[0080]假设将上表1中所示的数据写在json格式的文件中，并且是采用按列写入的列模式，则得到的json格式的数据文件中，可以包括表1的名称、写入的方式、以及表1中的3列数据。例如，该json格式的文件中，用"table1"表示一个数据表，也即上表1；用"columns"表示按列写入；用"id":[1,2,3]表示表1中的第一列数据；用"year":[2020,2021,2022]表示表1中的第二列数据；用"vector":[[1.0,1.1,1.2],[2.0,2.1,2.2],[3.0,3.1,3.2]]表示表1中的第三列数据。[0081]通过在上述json文本中记录上表1的数据写入模式(行模式(row-based)或者列模式(column-based))，可以使得数据节点24在接收到该json文本之后，可以根据该json文本中记录的数据写入模式，解析出待存储的数据表1中的数据，从而将解析出的数据通过存储服务节点27实现持久化存储。[0082]如果将表1所示的数据写在csv格式的文件中，可以以逗号或者竖线作为分隔符，例如，假设将上表1所示的数据表示成用逗号作为分隔符csv格式的文件，则该csv格式的文件中可以用plaintext表明将表1中的数据用纯本文表示；用id,year,vector表示表1中包含的三个字段；用1,2020,"1.0,1.1,1.2"表示表1中第一行数据，用2,2021,"2.0,2.1,2.2"表示表1中的第二行数据；用3,2022,"3.0,3.1,3.2"表示表1中的第三行数据。[0083]在一些实施例中，待存储数据的路径信息包括待存储数据来源于哪种存储服务、在该存储服务中的相对地址、访问该存储服务的账号密码以及要导入向量数据库20的哪个数据表中等信息。[0084]在一些实施例中，待存储数据的解析方式也即待存储数据的写入方式，例如待存储数据是json文件，则该json文件的解析方式可以为按行解析，或者按列解析。[0085]示例性地，假设待存储数据来源于上述存储服务节点271，存储服务节点271的地址为localhost:9000，类型为minio，账号为minioadmin，密码为minioadmin；待存储数据是json格式的文件，且是按行写入的，需要将待存储数据导入具有uid、year、vector这三个字段的milvus数据表(存储在存储服务节点272中)。则针对该待存储数据的上述基本参数，所生成的json文本中可以用"data_source"表示待存储数据的数据来源，具体地，用"type":"minio"表示待存储数据来源于minio这种存储服务；用"address":"localhost:9000"表示待存储数据文件来源于地址为"localhost:9000"的存储服务节点；用"accesskey_id":"minioadmin"表示访问该存储服务的账号；用"accesskey_secret":"minioadmin",表示访问该存储服务的密码；用"bucket_name":"aaa"表示待存储数据文件来自于存储服务的哪个根目录。[0086]在上述json文本中，还可以用"target_collection":"xxx",表示带存储数据文件要导入到哪个向量数据表中；用"files"表示带存储数据文件列表；用"path":"xxxx/xx.json",表示该待存储数据文件来源于存储服务节点中哪个文件，该路径为相对于上述根目录的路径；用"type":"row_based",表示待存储数据文件为行模式的json文件；用"from":0,表示向量数据表的第0行开始导入；用"to":1000,表示导入到向量数据表的第1000行截止。[0087]在上述json文本中，还可以用"fields_mapping"来表示待存储的数据文件中的字段名和要导入的向量数据表中的字段名的映射关系。具体地，例如，用"table.rows.id":"uid",表示将json格式的待存储数据文件中的id字段映射到要导入的向量数据表中的uid字段；用"table.rows.year":"year",表示将json格式的待存储数据文件中的year字段映射到要导入的向量数据表中的year字段；用"table.rows.vector":"vector"表示将json格式的待存储数据文件中的vector字段映射到要导入的向量数据表的vector字段。此外，在上述json文本中还可以添加一些默认值，例如用"default_fields"表示默认值。在一些实施例中，如果要导入的向量数据表中还有一些字段，例如age字段，但是待存储的数据文件中没有这些字段，则可以将要导入的向量数据表中的这些字段用0作为默认值填充。[0088]需要说明的是，客户端10生成包含待存储数据的基本参数的json文本中的具体内容可以视实际情况而定。本技术对此不作限定。例如，在一些实施例中，可以在上述示意出的json文本中同时写入多个待存储的数据文件。又如，在一些实施例中，可以在上述示意出的json文本中不指定将待存储的数据从milvus数据表的第几行开始导入，以及导入到第几行截止。[0089]在一些实施例中，还可以将待存储数据均转换成默认的格式，在待存储数据的基本参数中对应的json文本中可以写入，也可以不写入格式相关信息。[0090]在一些实施例中，还可以按照默认的解析方式解析待存储数据，在待存储数据的基本参数中对应的json文本中可以写入，也可以不写入解析方式相关信息。[0091]s504：客户端10经由代理节点21向协调服务节点23发送json文本。[0092]也即在客户端10、代理节点21、向协调服务节点23之间无需传递待存储数据本身，只需要传递基于待存储数据的基本参数(options)生成的json格式文本，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。可以避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。[0093]s505：协调服务节点23接收json文本。[0094]s506：协调服务节点23向数据节点241发送json文本中第一部分基本参数。[0095]例如，在一些实施例中，协调服务节点23接收到的json文本中包含的基本参数options涉及两个待存储数据文件file1和file2，对应于file1的基本参数为第一部分基本参数option1，option1包括file1的路径信息、格式、解析方式等参数。对应于file2的基本参数为第二部分基本参数option2，option2包括file2的路径信息、格式、解析方式等参数。且协调服务节点23确定出数据节点241和数据节点242处于空闲状态，且数据节点241和数据节点242的计算能力和存储能力较强，则协调服务节点23可以将option1传送给数据节点241，将option2传送给数据节点242。[0096]s507：协调服务节点23向数据节点242发送json文本中第二部分基本参数。[0097]例如，协调服务节点23可以将上述option2传送给数据节点242。具体过程可参考上述s506的相关描述。[0098]s508：数据节点241接收第一部分基本参数，确定出第一待存储数据的路径信息、格式、解析方式。[0099]例如，在一些实施例中，数据节点241接收到s506中对应于file1的基本参数为option1，则数据节点241根据option1中包含的对应于file1的路径信息、格式、解析方式，确定出file1存储于存储服务节点271中，file1为json格式的文件，file1是按行写入的。[0100]s509：数据节点242接收第二部分基本参数，确定出第二待存储数据的路径信息、格式、解析方式。[0101]例如，在一些实施例中，数据节点242接收到s506中对应于file2的基本参数为option2，则数据节点242根据option2中包含的对应于file2的路径信息、格式、解析方式，确定出file2存储于存储服务节点271中，file2为csv格式的文件，file2是用逗号作为分隔符的。[0102]s510：数据节点241从存储服务节点271获取第一待存储数据。[0103]例如，在一些实施例中，数据节点241从存储服务节点271获取file1。[0104]s511：数据节点242从存储服务节点271获取第二待存储数据。[0105]例如，在一些实施例中，数据节点242从存储服务节点271获取file2。[0106]s512：数据节点241解析第一待存储数据，得到数据分片。[0107]例如，在一些实施例中，数据节点241解析s510获取的file1，得到file1对应的数据分片。[0108]s513：数据节点242解析第二待存储数据，得到数据分片。[0109]例如，在一些实施例中，数据节点242解析s511获取的file2，得到file2对应的数据分片。[0110]s514：数据节点241向存储服务节点272发送数据分片。[0111]例如，在一些实施例中，数据节点241向存储服务节点272发送s512得到的file1对应的数据分片。[0112]s515：数据节点242向存储服务节点272发送数据分片。[0113]例如，在一些实施例中，数据节点242向存储服务节点272发送s513得到的file2对应的数据分片。[0114]s516：存储服务节点272存储接收到的数据分片。[0115]也即存储服务节点272存储从上述数据节点241以及数据节点242获取到的待存储数据的数据分片。例如，在一些实施例中，存储服务节点272存储接收到的file1对应的数据分片以及file2对应的数据分片。[0116]从上述关于图5所示的交互图的描述中可以看出，图5所对应的“快速”存储方式中，客户端10只需要将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点241/242、存储服务节点271/272，由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。而无需传送待存储数据本身，避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，由于json格式文本兼具灵活性和可扩展性，使得本技术技术方案支持对多种格式的数据的存储，适用范围广。[0117]可以理解，上述步骤s501至步骤s516的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，例如，协调服务节点23在执行s505之后，可以同时执行s506和s507。又如，数据节点241在执行s508的同时，数据节点242在执行s509，又如数据节点241执行s508的时间节点在数据节点242执行s509的时间节点之前或之后。在此不做限定。[0118]在一些实施例中，本技术技术方案还可以将存入向量数据库20中的数据文件导出。例如，通过向量数据库20的另一api接口，例如export()接口，导出存储在存储服务节点27中的数据。在另一些实施例中，本技术技术方案还可以将从向量数据库20中导出的数据文件重新导入向量数据库20中。例如，通过向量数据库20的export()接口，导出存储在存储服务节点27中的数据之后，再将导出的数据通过上述insert()接口或者import()接口导入向量数据库20中。[0119]下面将结合图6，对图4所示的第二存储方式的数据流向图中的客户端10以及向量数据库20中的一些节点之间具体的交互过程进行详细说明。[0120]同样地，图6所示的实施例中，也只示意了两个数据节点以及两个存储服务节点，对应于图4，图6所示的交互图中也是为了方便说明，只示意出了两个数据节点以及两个存储服务节点。应当理解的是，图4和图6所示的实施例，只是为了便于说明本技术技术方案的一些示例，在实际应用中向量数据库20包含的数据节点以及存储服务节点的数量较多，本技术对此不做限定。具体地，图6所示的交互图包括以下内容：[0121]s601：客户端10接收用户的数据存储请求。[0122]其中该数据存储请求中携带有待存储数据文件file3的属性信息，例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。[0123]s602：客户端10根据上述存储请求，确定出选择“常规”存储方式。[0124]客户端10基于上述存储请求判断出待存储数据的具体存储方式，例如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择“常规”存储方式，则客户端10调用向量数据库20的第二存储接口，例如insert()接口，获取到待存储数据文件，并传递给向量数据库20中的部分节点。[0125]s603：客户端10从存储服务节点271获取待存储的数据文件。[0126]例如，在一些实施例中，客户端10根据接收到的用户的数据存储请求，确定出待存储数据文件file3的源存储位置为存储服务节点271的地址：localhost:9000，则客户端10从存储服务节点271获取到待存储的数据文件file3。[0127]s604：客户端10向代理节点21发送待存储的数据文件。[0128]例如，在一些实施例中，客户端10将从存储服务节点271获取的待存储的数据文件file3发送给代理节点21。[0129]s605：代理节点21切分待存储的数据文件，并将切分得到的子数据文件封装成消息包。[0130]例如，在一些实施例中，代理节点21接收到客户端10发送的数据文件file3之后，将数据文件file3进行切分，例如按照设定行(一行对应一个向量)进行切分，得到多个子数据文件，并将切分得到的子数据文件封装成消息包。[0131]s606：代理节点21向消息存储节点22发送消息包。[0132]例如，在一些实施例中，代理节点21将对通过切分上述数据文件file3得到的子数据文件进行封装得到的消息包发送给消息存储节点22。[0133]s607：消息存储节点22接收消息包。[0134]例如，在一些实施例中，消息存储节点22从代理节点21接收由上述数据文件file3切分得到的子数据文件进行封装后得到的消息包shard_1和shard_2。[0135]s608：数据节点241从消息存储节点22拉取消息包。[0136]例如，在一些实施例中，数据节点241从消息存储节点22拉取到消息包shard_1。[0137]s609：数据节点242从消息存储节点22拉取消息包。[0138]例如，在一些实施例中，数据节点242从消息存储节点22拉取到消息包shard_2。[0139]s610：数据节点241拆封消息包，得到数据分片。[0140]例如，在一些实施例中，数据节点241对从消息存储节点22拉取到消息包shard_1进行拆封，得到数据分片segment_1。[0141]s611：数据节点242拆封消息包，得到数据分片。[0142]例如，在一些实施例中，数据节点242对从消息存储节点22拉取到消息包shard_2进行拆封，得到数据分片segment_2。[0143]s612：数据节点241向存储服务节点272发送数据分片。[0144]例如，在一些实施例中，数据节点241向存储服务节点272数据分片segment_1。[0145]s613：数据节点242向存储服务节点272发送数据分片。[0146]例如，在一些实施例中，数据节点241向存储服务节点272数据分片segment_2。[0147]s614：存储服务节点272存储接收到的数据分片。[0148]例如，在一些实施例中，存储服务节点272将从数据节点241接收到的数据分片segment_1，以及从数据节点242接收到的数据分片segment_2进行持久化存储。[0149]可以理解，上述步骤s601至步骤s614的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，在此不做限定。[0150]从上述关于图6所示的交互图的描述中可以看出，图6所对应的“常规”存储方式中，客户端10需要将待存储数据文件本身，依次传送给代理节点21、消息存储节点22、数据节点241/242、存储服务节点271/272，由于待存储数据文件的数据量通常较大，因此图6对应的“常规”存储方式相对于图5所对应的“快速”存储方式数据存储效率较低，时延高。[0151]但是图6所对应的“常规”存储方式中，由于待存储数据文件会传送至消息存储节点22，由于该节点可以用于维护“日志序列”，记录向量数据库20中所有的关于数据增删改的操作，因此图6所对应的“常规”存储方式具有数据回滚功能。例如，在时间点t1，用户通过客户端10向向量数据库20存储了一批数据，之后用户发现存储的这些数据存在错误或者数据无效，想要将向量数据库20的数据恢复成t1之前的状态，则用户可以通过客户端10向向量数据库20输入相应的数据恢复请求，则向量数据库20可以基于消息存储节点22维护的时间轴，将数据库中存储的数据恢复至t1之前的状态。[0152]因此，综上所述，本技术技术方案为用户提供了“常规”存储方式以及“快速”存储方式，用户可以自主选择通过这两种存储方式中的其中一种进行数据存储，或者客户端10可以自动判断通过这两种存储方式中的其中一种进行数据存储。可以满足不用应用场景下的不同应用需求，应用范围广。[0153]在分别介绍完图5和图6中客户端10以及向量数据库20中的一些节点之间具体的交互过程之后，下面将结合图7对本技术实施例提供的一种数据存储方法进行介绍。具体地，图7所示的数据存储方法包括以下内容：[0154]s701：客户端10接收用户的数据存储请求，其中该数据存储请求中携带有待存储数据的属性信息。[0155]例如待存储数据的源存储位置、目标存储位置、待存储数据的数据量大小、用户输入的存储选项信息等。[0156]s702：客户端10根据数据存储请求，判断选择第一存储方式或者第二存储方式。[0157]例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式(即“快速”存储方式)，进入s703。又如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式(即“常规”存储方式)，进入s705。[0158]s703：客户端10调用第一存储接口，将待存储数据的基本参数以json文本的形式沿着第一路径传送至向量数据库20的数据节点24。其中，第一路径可以包括代理节点21、协调服务节点23、数据节点24、存储服务节点27。[0159]例如，客户端10在确定出待存储数据的数据量大于或等于设定阈值时，或者确定出用户输入的存储选项信息指示“快速”存储时，选择第一存储方式，调用import()接口，将待存储数据的基本参数(options)以json格式文本的形式，依次传送给代理节点21、协调服务节点23、数据节点24。然后由数据节点24根据待存储数据的基本参数，得到待存储数据。[0160]由于待存储数据的基本参数数据量较小，通常为kb(千字节)级别。而无需传送带存储数据本身，避免数据在多节点间传输浪费带宽，数据存储效率高，时延低。并且将待存储数据的基本参数以json格式文本的形式在节点之间传输，由于json格式文本兼具灵活性和可扩展性，使得本技术技术方案支持对多种格式的数据的存储，适用范围广。[0161]s704：向量数据库20的数据节点24基于待存储数据的基本参数，得到待存储数据。[0162]例如，数据节点24接收到待存储数据的基本参数，根据基本参数中包含的待存储数据的路径信息从对应的存储服务节点中获取某种格式(例如json格式、csv格式等)的待存储数据，并按照基本参数中包含的解析方式，对待存储数据进行解析。例如，将按行写入的json格式的待存储数据中的id字段映射到milvus数据表中的uid字段、将按行写入的json格式的待存储数据中的year字段映射到milvus数据表中的year字段、将按行写入的json格式的待存储数据中的vector字段映射到milvus数据表中的vector字段。[0163]s705：客户端10调用第二存储接口，将待存储数据沿着第二路径存储至向量数据库20的数据节点24。其中，第二存储路径可以包括代理节点21、消息存储节点22、数据节点24、存储服务节点27。[0164]例如，客户端10在确定出待存储数据的数据量小于设定阈值时，或者确定出用户输入的存储选项信息指示“常规”存储时，选择第二存储方式(即“常规”存储方式)，则客户端10调用向量数据库20的第二存储接口，例如insert()接口，根据存储请求中携带的待存储数据的源存储位置，从对应的存储服务节点中获取待存储数据文件。然后将待存数据文件依次传送给代理节点21、消息存储节点22、数据节点24、存储服务节点27。[0165]s706：向量数据库20的数据节点24将待存储数据存储至向量数据库20的存储服务节点27中。[0166]也就是说在向量数据库20的数据节点24从消息存储节点22中接收到的消息包中解封出来的待存储数据，或者基于从协调服务节点23中获得的基本参数得到的待存储数据，写入第三方的存储服务节点27中。[0167]可以理解，上述步骤s701至步骤s706的执行顺序只是一种示意，在另一些实施例中，也可以采用其他执行顺序，还可以拆分或合并部分步骤，在此不做限定。[0168]图8为本技术实施例中提供的电子设备100的框图。图8示意性地示出了根据多个实施例的示例电子设备100。在一个实施例中，电子设备100可以包括一个或多个处理器104，与处理器104中的至少一个连接的系统控制逻辑108，与系统控制逻辑108连接的系统内存112，与系统控制逻辑108连接的非易失性存储器(nvm)116，以及与系统控制逻辑108连接的网络接口120。[0169]在一些实施例中，处理器104可以包括一个或多个单核或多核处理器。在一些实施例中，处理器104可以包括通用处理器和专用处理器(例如，图形处理器，应用处理器，基带处理器等)的任意组合。在电子设备100采用enb(evolvednodeb，增强型基站)101或ran(radioaccessnetwork，无线接入网)控制器102的实施例中，处理器104可以被配置为执行各种符合的实施例。可以理解，本技术实施例中，处理器104可以用于执行本技术实施例中提供的数据存储方法。[0170]在一些实施例中，系统控制逻辑108可以包括任意合适的接口控制器，以向处理器104中的至少一个和/或与系统控制逻辑108通信的任意合适的设备或组件提供任意合适的接口。[0171]在一些实施例中，系统控制逻辑108可以包括一个或多个存储器控制器，以提供连接到系统内存112的接口。系统内存112可以用于加载以及存储数据和/或指令。在一些实施例中电子设备100的内存112可以包括任意合适的易失性存储器，例如合适的动态随机存取存储器(dram)。[0172]nvm/存储器116可以包括用于存储数据和/或指令的一个或多个有形的、非暂时性的计算机可读介质。在一些实施例中，nvm/存储器116可以包括闪存等任意合适的非易失性存储器和/或任意合适的非易失性存储设备，例如hdd(harddiskdrive，硬盘驱动器)，cd(compactdisc，光盘)驱动器，dvd(digitalversatiledisc，数字通用光盘)驱动器中的至少一个。[0173]nvm/存储器116可以包括安装电子设备100的装置上的一部分存储资源，或者它可以由设备访问，但不一定是设备的一部分。例如，可以经由网络接口120通过网络访问nvm/存储116。[0174]特别地，系统内存112和nvm/存储器116可以分别包括：指令124的暂时副本和永久副本。指令124可以包括：由处理器104中的至少一个执行时导致电子设备100实施本技术实施例中提及的数据存储方法的指令。在一些实施例中，指令124、硬件、固件和/或其软件组件可另外地/替代地置于系统控制逻辑108，网络接口120和/或处理器104中。[0175]网络接口120可以包括收发器，用于为电子设备100提供无线电接口，进而通过一个或多个网络与任意其他合适的设备(如前端模块，天线等)进行通信。在一些实施例中，网络接口120可以集成于电子设备100的其他组件。例如，网络接口120可以集成于处理器104的，系统内存112，nvm/存储器116，和具有指令的固件设备(未示出)中的至少一种，当处理器104中的至少一个执行所述指令时，电子设备100实现本技术实施例中提及的数据存储方法。[0176]网络接口120可以进一步包括任意合适的硬件和/或固件，以提供多输入多输出无线电接口。例如，网络接口120可以是网络适配器，无线网络适配器，电话调制解调器和/或无线调制解调器。[0177]在一个实施例中，处理器104中的至少一个可以与用于系统控制逻辑108的一个或多个控制器的逻辑封装在一起，以形成系统封装(sip)。在一个实施例中，处理器104中的至少一个可以与用于系统控制逻辑108的一个或多个控制器的逻辑集成在同一管芯上，以形成片上系统(soc)。[0178]电子设备100可以进一步包括：输入/输出(i/o)设备132。i/o设备132可以包括用户界面，使得用户能够与电子设备100进行交互；外围组件接口的设计使得外围组件也能够与电子设备100交互。[0179]本技术实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现可实现上述各个方法实施例中的步骤。[0180]本技术实施例提供了一种计算机程序产品，当计算机程序产品在移动终端上运行时，使得移动终端执行时实现可实现上述各个方法实施例中的步骤。[0181]本技术公开的机制的各实施例可以被实现在硬件、软件、固件或这些实现方法的组合中。本技术的实施例可实现为在可编程系统上执行的计算机程序或程序代码，该可编程系统包括至少一个处理器、存储系统(包括易失性和非易失性存储器和/或存储元件)、至少一个输入设备以及至少一个输出设备。[0182]可将程序代码应用于输入指令，以执行本技术描述的各功能并生成输出信息。可以按已知方式将输出信息应用于一个或多个输出设备。为了本技术的目的，处理系统包括具有诸如例如数字信号处理器(digitalsignalprocessor，dsp)、微控制器、专用集成电路(applicationspecificintegratedcircuit，asic)或微处理器之类的处理器的任何系统。[0183]程序代码可以用高级程序化语言或面向对象的编程语言来实现，以便与处理系统通信。在需要时，也可用汇编语言或机器语言来实现程序代码。事实上，本技术中描述的机制不限于任何特定编程语言的范围。在任一情形下，该语言可以是编译语言或解释语言。[0184]在一些情况下，所公开的实施例可以以硬件、固件、软件或其任何组合来实现。所公开的实施例还可以被实现为由一个或多个暂时或非暂时性机器可读(例如，计算机可读)存储介质承载或存储在其上的指令，其可以由一个或多个处理器读取和执行。例如，指令可以通过网络或通过其他计算机可读介质分发。因此，机器可读介质可以包括用于以机器(例如，计算机)可读的形式存储或传输信息的任何机制，包括但不限于，软盘、光盘、光碟、只读存储器(cd-roms)、磁光盘、只读存储器(readonlymemory，rom)、随机存取存储器(randomaccessmemory，ram)、可擦除可编程只读存储器(erasableprogrammablereadonlymemory，eprom)、电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、磁卡或光卡、闪存、或用于利用因特网以电、光、声或其他形式的传播信号来传输信息(例如，载波、红外信号数字信号等)的有形的机器可读存储器。因此，机器可读介质包括适合于以机器(例如计算机)可读的形式存储或传输电子指令或信息的任何类型的机器可读介质。[0185]在附图中，可以以特定布置和/或顺序示出一些结构或方法特征。然而，应该理解，可能不需要这样的特定布置和/或排序。而是，在一些实施例中，这些特征可以以不同于说明性附图中所示的方式和/或顺序来布置。另外，在特定图中包括结构或方法特征并不意味着暗示在所有实施例中都需要这样的特征，并且在一些实施例中，可以不包括这些特征或者可以与其他特征组合。[0186]需要说明的是，本技术各设备实施例中提到的各单元/模块都是逻辑单元/模块，在物理上，一个逻辑单元/模块可以是一个物理单元/模块，也可以是一个物理单元/模块的一部分，还可以以多个物理单元/模块的组合实现，这些逻辑单元/模块本身的物理实现方式并不是最重要的，这些逻辑单元/模块所实现的功能的组合才是解决本技术所提出的技术问题的关键。此外，为了突出本技术的创新部分，本技术上述各设备实施例并没有将与解决本技术所提出的技术问题关系不太密切的单元/模块引入，这并不表明上述设备实施例并不存在其它的单元/模块。[0187]需要说明的是，在本专利的示例和说明书中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。[0188]虽然通过参照本技术的某些优选实施例，已经对本技术进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
