Vector database management method and vector database management system

Abstract

The embodiment of the invention provides a vector database management method and a vector database management system. The vector database management method comprises the steps that a request message sent by a service end is received through a proxy service module, when the request message is a write-in message, the request message is written into a message system of a message module, and the request message comprises target data to be stored; the message module comprises a message system and a plurality of subscription groups in one-to-one correspondence with the vector databases, and each subscription group comprises at least one consumer; and consuming the target data of the request message from the message system by using the consumer of each subscription group in the plurality of subscription groups, and writing the target data into the vector database corresponding to the subscription group. The message system can persistently store the request message, data loss caused by the fault of the vector database can be avoided, and the data can be recovered by using the request message stored in the message system even if the vector database fails, so that the data consistency can be effectively ensured.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a method for managing a vector database and a management system for a vector database. Background Technology

[0002] With the development of science and technology, large-scale model technology has been widely applied. However, when traditional large-scale models are applied in practice, firstly, their knowledge is limited by the training data, resulting in a significant lag; secondly, when facing highly specialized or vertical domain-specific deep knowledge question answering, their answers often lack sufficient accuracy and depth; and thirdly, the model illusion problem frequently occurs, generating seemingly reasonable but actually erroneous or fabricated information. To overcome these bottlenecks, Retrieval-Augmented Generation (RAG) technology has emerged. By combining the powerful generation capabilities of large-scale models with dynamic retrieval from external knowledge bases, when a user asks a question, relevant data is first retrieved in real time from a vector database (e.g., Qdrant), and then this data is provided to the large-scale model to generate more timely, accurate, and factually grounded answers. The high availability of the vector database determines whether the response speed and accuracy of the large-scale model can be guaranteed, as well as whether the client interface can maintain high availability.

[0003] However, among related technologies, vector databases have poor high availability. When a failure occurs, data being written or waiting to be written will be permanently lost, affecting data consistency. Summary of the Invention

[0004] The present invention was proposed in view of the above-mentioned problems.

[0005] According to one aspect of the present invention, a method for managing a vector database is provided. The method for managing a vector database includes: The proxy service module receives request messages sent by the business side. When the request message is a write message, it writes the request message to the message system of the message module. The request message includes the target data to be stored. The message module includes the message system and multiple subscription groups that correspond one-to-one with multiple vector databases. Each subscription group includes at least one consumer. By utilizing the consumer of each of the multiple subscription groups, the target data of the requested message is consumed from the messaging system, and the target data is written to the vector database corresponding to that subscription group.

[0006] For example, the request message also includes the set name of the target data, which is the name of the vector set of the target data to be stored in multiple vector databases. The message system includes multiple partitions. Writing the request message to the message module of the message system includes: extracting the set name of the target data in the request message; using the set name as the first identifier key for writing the request message to the message system; determining the target partition of the request message in the message system according to the first identifier key; and writing the request message to the target partition.

[0007] For example, determining the target partition of the request message in the messaging system based on the first identifier key includes: calculating the hash value of the first identifier key, performing a modulo operation on the hash value using the number of multiple partitions, and obtaining a partition identifier, which is used to represent the target partition.

[0008] For example, for each of a plurality of subscription groups, each consumer in at least one consumer in the subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in the subscription group. Using the consumer of each of the plurality of subscription groups, the target data of the request message is consumed from the message system, and the target data is written to the vector database corresponding to the subscription group. This includes: for each of the plurality of subscription groups, using the set name as the second identifier key, determining the target consumer in the subscription group, using the target consumer to consume the target data from the message system, and writing the target data to the vector database corresponding to the subscription group, wherein the target consumer is the consumer corresponding to the second identifier key corresponding to the set name.

[0009] For example, writing a request message into a message system of a message module includes: formatting the request message based on a preset data serialization protocol, and writing the processed request message into the message system, wherein the preset data serialization protocol is a data protocol supported by the vector database.

[0010] For example, the business terminal has a preset protocol packet, which is generated based on a preset data serialization protocol file of the vector database source code, and the business terminal sends request messages based on the preset protocol packet.

[0011] For example, each of the multiple vector databases has a storage unit group, which includes a primary storage unit and at least one secondary storage unit. Writing target data to the vector database corresponding to the subscription group includes: writing the target data to the primary storage unit of the vector database corresponding to the subscription group, and synchronizing the target data to each secondary storage unit in the at least one secondary storage unit.

[0012] For example, the request message also includes the name of the target data set, which is the name of the vector set to be stored in multiple vector databases. The vector set corresponds to one or more main storage units, and each main storage unit corresponds to at least one secondary storage unit. Writing the target data to the main storage unit of the vector database corresponding to the subscription group and synchronizing the target data to each of the at least one secondary storage unit includes: writing the target data to a single main storage unit of the vector set indicated by the name of the target data set in the vector database corresponding to the subscription group, and synchronizing the target data to each secondary storage unit corresponding to the main storage unit.

[0013] For example, each of the multiple vector databases has a corresponding load balancing module. The load balancing module proxies multiple nodes of the corresponding vector database and writes the target data into the vector database corresponding to the subscription group. This includes: using the load balancing module of the vector database corresponding to the subscription group to determine the target node among the multiple nodes of the vector database corresponding to the subscription group, and using the target node to write the target data into the vector database corresponding to the subscription group.

[0014] For example, after receiving the request message sent by the business terminal using the proxy service module, the method further includes: when the request message is a read message, sending the request message to the read module; using the read module, sending a read request to a target vector database in multiple vector databases according to the request message; if a read result of the target vector database is received within a preset time, then the read result is taken as the target read result; if a read result of the target vector database is not received within the preset time, then performing one or more request sending operations until the target read result is obtained or read requests are sent to multiple vector databases, wherein the request sending operation includes: sending a read request to one of the vector databases in multiple vector databases for which no read request has been sent, wherein the target read result is the first read result received by the read module from the multiple vector databases.

[0015] According to another aspect of the present invention, a management system for a vector database is also provided. The management system for the vector database includes: a proxy service module and a message module. The message module includes a message system and multiple subscription groups corresponding one-to-one with multiple vector databases. Each subscription group includes at least one consumer. The proxy service module is used to receive request messages sent by a business terminal. When the request message is a write message, it writes the request message into the message system of the message module, wherein the request message includes target data to be stored. The consumer of each subscription group in the multiple subscription groups of the message module is used to consume the target data of the request message from the message system and write the target data into the vector database corresponding to that subscription group.

[0016] For example, the request message also includes the set name of the target data. The set name is the name of the vector set in which the target data is to be stored in multiple vector databases. The message system includes multiple partitions. The proxy service module writes the request message into the message system of the message module in the following way: extracts the set name of the target data in the request message; uses the set name as the first identifier key for writing the request message into the message system; determines the target partition of the request message in the message system according to the first identifier key; and writes the request message into the target partition.

[0017] For example, the message module is further configured to calculate the hash value of the first identifier key, perform a modulo operation on the hash value using the number of multiple partitions, obtain the partition identifier, and determine the target partition, which is the partition indicated by the partition identifier.

[0018] For example, for each of the multiple subscription groups, each consumer in the subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in the subscription group. The message module writes the target data into the vector database corresponding to the subscription group in the following manner: for each of the multiple subscription groups, the set name is used as the second identifier key to determine the target consumer in the subscription group, the target consumer consumes the target data from the message system, and the target data is written into the vector database corresponding to the subscription group, wherein the target consumer is the consumer corresponding to the second identifier key corresponding to the set name.

[0019] For example, the vector database management system also includes a load balancing module. Each vector database has a corresponding load balancing module. The load balancing module proxies multiple nodes of the corresponding vector database. The message module writes the target data to the vector database corresponding to the subscription group in the following way: using the load balancing module of the vector database corresponding to the subscription group, the target node is determined among the multiple nodes of the vector database corresponding to the subscription group, and the target data is written to the vector database corresponding to the subscription group using the target node.

[0020] For example, the vector database management system further includes a reading module, and the proxy service module is further configured to send a request message to the reading module when the request message is a reading message; the reading module is configured to send a reading request to a target vector database in multiple vector databases according to the request message; if the reading result of the target vector database is received within a preset time, the reading result is taken as the target reading result; if the reading result of the target vector database is not received within the preset time, one or more request sending operations are performed until the target reading result is obtained or the reading request is sent to multiple vector databases. The request sending operation includes: sending a reading request to one of the vector databases in multiple vector databases that has not sent a reading request, wherein the target reading result is the reading result that the reading module receives first from multiple vector databases.

[0021] In the above technical solution, a proxy service module receives request messages sent by the business end. When the request message is a write message, it is written to the message system of the message module. Consumers in each of multiple subscription groups consume the target data of the request message from the message system and write the target data to the vector database corresponding to that subscription group. The message system can persistently store request messages, avoiding data loss due to vector database failures. Even if the vector database fails, the data can be recovered using the request messages stored in the message system, thus effectively ensuring data consistency.

[0022] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0023] The above and other objects, features, and advantages of the present invention will become more apparent from the more detailed description of the embodiments of the invention in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of the invention and form part of the specification. They are used together with the embodiments of the invention to explain the invention and do not constitute a limitation thereof.

[0024] Figure 1 A schematic flowchart of a vector database management method according to an embodiment of the present invention is shown; Figure 2 A schematic diagram illustrating the relationship between the first identifier key of a request message and the partitioning of a messaging system according to an embodiment of the present invention is shown. Figure 3 A schematic diagram illustrating the relationship between the second identifier key of a request message and a consumer according to an embodiment of the present invention is shown; Figure 4A schematic block diagram of a vector database management system according to an embodiment of the present invention is shown; Figure 5 A schematic block diagram of a vector database management system according to another embodiment of the present invention is shown; Figure 6 A schematic block diagram of an electronic device according to an embodiment of the present invention is shown. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the present invention more apparent, exemplary embodiments according to the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely a subset of embodiments of the present invention.

[0026] In related technologies, when a vector database experiences a failure, for example, if one of its storage units goes down, the data to be written to that storage unit will be lost; or, for example, if a network partition occurs in the vector database and it is unable to synchronize data to the secondary storage unit, the secondary storage unit will be unable to store the corresponding data, resulting in data loss.

[0027] To at least partially solve the aforementioned technical problems, this invention provides a method for managing a vector database. This method uses a message module to store request messages and writes these messages into the vector database. Because the message module can persistently store request messages, even if the vector database fails, the request messages can still be saved in the message module until they are successfully written to the vector database. This vector database management method can be applied to any electronic device, meaning it can be executed by any electronic device. Specifically, it can be applied to the processor of any electronic device, meaning it can be executed by the processor of any electronic device. Furthermore, this vector database management method can be applied to the cloud, meaning it can be executed by a cloud server.

[0028] For example, Figure 1 A schematic flowchart illustrating a method for managing a vector database according to an embodiment of the present invention is shown. Figure 1 As shown, the management method of the vector database includes steps S1100 and S1200.

[0029] In step S1100, the proxy service module receives a request message sent by the business terminal. If the request message is a write message, it is written to the message system of the message module. The request message includes the target data to be stored. The message module includes a message system and multiple subscription groups corresponding one-to-one with multiple vector databases. Each subscription group includes at least one consumer.

[0030] The business side can include any client initiating a data request; for example, it can include a RAG system, artificial intelligence applications, etc. The business side sends request messages to the proxy service module to write or read data from the vector database. The request messages sent by the business side can include write and / or read messages. Request messages of type write can include the target data to be stored. The proxy service module can be deployed between the business side and the message module. The proxy service module communicates with the business side using a Remote Procedure Call (RPC) framework, such as gRPC or Dubbo. The proxy service module can receive, parse, and route request messages. The message module includes a message system and multiple subscription groups corresponding one-to-one with multiple vector databases. Each subscription group includes at least one consumer. The message module can be implemented based on a distributed message system, such as Pulsar or Kafka. The message system can persistently store request messages, ensuring no message loss, i.e., ensuring no loss of target data. Each subscription group corresponds to one vector database and contains at least one consumer. Consumers are independent background processes or threads responsible for consuming request messages from the messaging system and performing write operations. Vector databases can be used to store unstructured data vectors. Each vector database is deployed independently and can be located in different physical clusters or geographical regions (such as a multi-site active-active architecture) to provide disaster recovery capabilities. The vector database described in this article can be any existing or future vector database, such as Qdrant, Milvus, etc.

[0031] The proxy service module can be used to receive request messages sent by the business side. After receiving a request message, the proxy service module can determine the type of the request message. If the request message is a write message, it will write the request message to the message system of the message module. For example, the proxy service module can use serialization operations to convert the request message into a message system-compatible format and publish it in the message system's topic. The message system will then persistently store the request message.

[0032] In step S1200, the consumer of each of the multiple subscription groups consumes the target data of the request message from the message system and writes the target data into the vector database corresponding to the subscription group.

[0033] Consumers in multiple subscription groups can continuously listen to topics in the messaging system to retrieve request messages. Each subscription group can operate independently, meaning the same request message can be consumed by consumers in all subscription groups. Consumers can parse the message and call the write interface of the corresponding vector database to write the target data corresponding to the request message into the vector database of that subscription group. Writing to the corresponding vector database can include inserting, updating, or deleting target data. For example, after successfully writing the target data, the consumer can send an acknowledgment character to the messaging system. The messaging system can continue to store the request message until it receives acknowledgment characters from consumers in each subscription group. For example, consider two vector databases, A and B. Database A corresponds to subscription group A, and database B corresponds to subscription group B. Each subscription group includes two consumers. Subscription groups A and B can jointly subscribe to the same topic in the messaging system. When request message 1 is written to the messaging system, both consumer 1 in subscription group A and consumer 1 in subscription group B can consume request message 1. Consumer 1 in subscription group A writes the target data corresponding to request message 1 to vector database A, and consumer 1 in subscription group B writes the target data corresponding to request message 1 to vector database B.

[0034] In the above technical solution, a proxy service module receives request messages sent by the business end. When the request message is a write message, it is written to the message system of the message module. Consumers in each of multiple subscription groups consume the target data of the request message from the message system and write the target data to the vector database corresponding to that subscription group. The message system can persistently store request messages, avoiding data loss due to vector database failures. Even if the vector database fails, the data can be recovered using the request messages stored in the message system, thus effectively ensuring data consistency.

[0035] For example, the request message also includes the name of the target data collection, which is the name of the vector collection in which the target data is to be stored in multiple vector databases. The message system includes multiple partitions. The vector databases store data in different vector collections, which store data of the same dimension. The target data should be stored in the target vector collection of the vector database. The request message can include the name of the target data collection, i.e., the name of the target vector collection. The message module can be implemented using the Pulsar message component. The message system can include multiple partitions, i.e., the topic of the message system can be divided into multiple partitions, which can be used to store request messages.

[0036] Step S1100 involves writing the request message into the message system of the message module, including steps S1110 and S1120. In step S1110, the set name of the target data in the request message is extracted. The proxy service module can parse the received request message to determine the set name of the target data in the request message. For example, parsing the request message can obtain field data, and the set name of the target data can be obtained through the corresponding set name field.

[0037] In step S1120, the set name is used as the first identifier key for writing the request message into the message system. The target partition of the request message in the message system is determined based on the first identifier key, and the request message is written to the target partition. The proxy service module can use the set name as the first identifier key for writing the request message into the message system. The message system can adopt a preset partitioning mode. In the partitioning mode, the topic of the message system can be divided into multiple partitions. A preset partitioning routing mode can be used to route the request message to the target partition. For example, a round-robin partitioning mode, a single partitioning mode, or a custom partitioning mode can be used. Specifically, a round-robin partitioning mode can be used, and a first identifier key is provided to write the request message to the target partition. In some embodiments, the message system can calculate the first identifier key and determine the target partition of the request message in the message system based on the calculation result. In other embodiments, the message system can determine the target partition of the request message in the message system based on a preset relationship between the first identifier key and the partition. The above embodiments can ensure that all request messages with the same set name will be routed to the same target partition. When the messaging system includes a single topic, the target partition can be the partition corresponding to the first identifier key among multiple partitions of that topic. When the messaging system includes multiple topics, a single topic can be specified among multiple topics, and the target partition can be the partition corresponding to the first table identifier key among multiple partitions of that topic. After determining the target partition for the request message, the request message can be written to the target partition of the messaging system. The request message can be persistently stored in the corresponding target partition. Figure 2 A schematic diagram illustrating the relationship between the first identifier key of a request message and the partitioning of a messaging system according to an embodiment of the present invention is shown. Figure 2As shown, request message 1 corresponds to the first identifier key 1, and request message 2 corresponds to the first identifier key 2. Both request message 1 and request message 2 are stored in partition 1 of the message system, meaning that all request messages with the same collection name will be routed to the same target partition. Request message 3 corresponds to the first identifier key 2 and is stored in partition 1 of the message system, while request message 3 corresponds to the first identifier key 3 and is stored in partition 2 of the message system. This means that request messages with different first identifier keys can be stored in the same or different partitions, and users can set the first identifier key corresponding to the partition as needed.

[0038] In the above technical solution, the message system includes multiple partitions. The set name of the target data in the request message is extracted. The set name is used as the first identifier key for writing the request message into the message system. The target partition of the request message in the message system is determined according to the first identifier key, and the request message is written to the target partition. Thus, all request messages with a set name will be routed to the same target partition. Messages within the same partition are consumed in the order they were sent. Consequently, for the same vector set, consecutive operations (e.g., writing vector A first, then updating vector A) will be processed in the order they were sent, avoiding out-of-order problems that may be caused by network latency or parallel consumption. This ensures that the data state written to all vector databases is consistent, guaranteeing data ordering.

[0039] For example, step S1120, which determines the target partition of the request message in the messaging system based on the first identifier key, includes step S1121. In step S1121, the hash value of the first identifier key is calculated, and the hash value is moduloed using the number of partitions to obtain a partition identifier. The partition identifier is used to represent the target partition. The hash value of the first identifier key can be calculated, that is, the hash value of the set name of the request message can be calculated. Any existing or future-developed hash algorithm can be used to calculate the hash value of the first identifier key. Partitions in the messaging system can have partition identifiers. The partition identifier can be obtained by moduloing the hash value using the total number of partitions. The partition identifier is used to represent the target partition, and the target partition can be determined after obtaining the partition identifier. For example, if the hash value of the first identifier key of the request message is 10, the total number of partitions is 2, the identifier of partition 1 is 0, the identifier of partition 2 is 1, and the partition identifier obtained by moduloing the hash value using the number of partitions is 0 (10 ÷ 2 = 5 remainder 0), the target partition is determined to be partition 1.

[0040] In the above technical solution, the hash value of the first identifier key is calculated, and the hash value is moduloed using the number of partitions to obtain the partition identifier, which is used to represent the target partition. This ensures that all request messages with the same set name are routed to the same target partition, guarantees that operations on the same vector set are executed sequentially, ensures data consistency, and the calculation method is simple and efficient.

[0041] For example, for each of a plurality of subscription groups, each consumer in at least one consumer in the subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in the subscription group. Each subscription group may include at least one consumer, and one or more second identifier keys may be assigned to each consumer in the subscription group, and within the same subscription group, only one consumer is designated to correspond to each second identifier key.

[0042] Step S1200 utilizes the consumer of each of the multiple subscription groups to consume the target data of the request message from the message system and writes the target data into the vector database corresponding to the subscription group, including step S1210. In step S1210, for each of the multiple subscription groups, the set name is used as the second identifier key to determine the target consumer in that subscription group. The target consumer consumes the target data from the message system and writes the target data into the vector database corresponding to the subscription group. The target consumer is the consumer corresponding to the second identifier key corresponding to the set name. For a request message retrieved from the message system, the subscription group needs to determine which consumer in the subscription group will process the request message; this consumer is the target consumer. The target consumer can be the consumer corresponding to the second identifier key of the request message. The second identifier key of the request message can be the set name of the request message. In some embodiments, the consumer's identifier can also be the set name; a consumer with the same identifier as the second identifier key (set name) of the request message can be retrieved in each subscription group and used as the target consumer. In other embodiments, a hash value can be calculated based on the second identifier key of the request message, and the hash value can be moduloed according to the total number of consumers in the subscription group to obtain the consumer identifier, thereby identifying the target consumer. It is understood that request messages with the same set name are consumed by the same consumer in each of multiple subscription groups. Request messages with the same set name may have different target data; they all write data to the same vector set in the vector database, and the writing is performed by the same consumer, ensuring data order and consistency. For example, the message module can be implemented using the key-shared pattern of the Pulsar message component. Figure 3 A schematic diagram illustrating the relationship between the second identifier key of a request message and a consumer according to an embodiment of the present invention is shown. Figure 3As shown, request message 1 corresponds to second identifier key 1, and request message 5 corresponds to second identifier key 1. Request messages 1 and 5 can be consumed by consumer 1. Request message 2 corresponds to second identifier key 2, and request message 4 corresponds to second identifier key 2. Request messages 2 and 4 can be consumed by consumer 3. Request message 3 corresponds to second identifier key 3, and request message 3 can be consumed by consumer 2. Request messages with the same second identifier key can be consumed by the same consumer.

[0043] Optionally, each subscription group includes multiple consumers, each corresponding to a second identifier key. Thus, the target data for request messages with different set names can be written to the vector database by different consumers.

[0044] Once the target consumer is identified, the request message can be assigned to it. The target consumer then extracts the target data from the request message and calls the write interface of the vector database corresponding to its subscription group to write the target data into the vector database. Since all request messages for the same vector set in the vector database are processed sequentially by the same consumer, the sequentiality of write operations (such as inserting before updating) for that vector set is guaranteed.

[0045] In the above technical solution, for each subscription group among multiple subscription groups, the set name is used as the second identifier key to determine the target consumer in that subscription group. The target consumer consumes the target data from the messaging system and writes the target data into the vector database corresponding to that subscription group. Thus, the second identifier key ensures that request messages for the same vector set are processed by the same consumer, ensuring that data operations on any vector set are strictly ordered throughout the entire process from the business end to the final writing to each vector database, guaranteeing data sequence and improving data consistency.

[0046] For example, step S1100, which writes the request message to the message system of the message module, includes step S1130. In step S1130, the request message is formatted based on a preset data serialization protocol, and the processed request message is written to the message system. The preset data serialization protocol is a data protocol supported by the vector database. For example, the vector database can be a Qdrant vector database, and its supported data protocol can be Protocol Buffer, with the preset data serialization protocol being Protocol Buffer. The proxy service module can be a proxy service built according to the preset data serialization protocol. When the request message is a write message, the proxy service module can format the request message based on the preset data serialization protocol. For example, it can encode information such as the operation type, target data, and set name included in the request message according to the rules in the preset data serialization protocol to obtain a serialized binary array, i.e., the processed request message. The processed request message can then be written to the message system. Optionally, the set name of the request message can be used as an identifier key for writing the processed request message to the message system.

[0047] In the above technical solution, the request message is formatted based on a preset data serialization protocol, and the processed request message is written into the message system. The preset data serialization protocol is a data protocol supported by the vector database. Therefore, the proxy service module, built on a data protocol supported by the vector database, can better integrate with the vector database and improve overall reliability.

[0048] For example, the business terminal has a preset protocol package, which is generated based on the preset data serialization protocol file of the vector database source code. The business terminal sends request messages based on the preset protocol package. Taking the vector database as Qdrant vector database as an example, the preset data serialization protocol file of the vector database source code can include files in the vector database used to define the data structures for communication between the client and the server. For example, it can be a Protobuf definition file (.proto file). The preset data serialization protocol file of the vector database source code can be processed by the compilation tool to generate a preset protocol package for a specific language (such as Python, Java, etc.). For example, the original business terminal can be programmed based on the original protocol package provided by the vector database. The original protocol package also supports the Protobuf protocol, but it is not well compatible with the proxy service module. Therefore, the original protocol package in the business terminal can be replaced with the preset protocol package. For example, if the original business terminal is a Python-programmed client, the package name of the original protocol package in the original business terminal code can be replaced with the package name of the preset protocol package, while other logical parameter encapsulations in the original business terminal can remain unchanged. Therefore, the business side can achieve compatibility with the proxy service module through a simple packet name replacement operation. It can be understood that the preset protocol packet supports clients of any language, and clients of any language can communicate with the proxy service module based on the preset protocol packet. The business side sends request messages based on the preset protocol packet. For example, the business side can serialize the request message into binary data based on the preset protocol packet and then send it to the proxy service module. The proxy service module also supports the preset data serialization protocol, which can deserialize the binary data of the request message back into the request message.

[0049] In the above technical solution, the business end has a preset protocol packet. This preset protocol packet is generated based on a preset data serialization protocol file from the vector database source code. The business end sends request messages based on this preset protocol packet. The business end and the proxy service module can communicate using the corresponding preset data serialization protocol, reducing format conversion overhead. Furthermore, the request messages are compatible with the vector database format. The business end can achieve compatibility with the proxy service module through a simple packet name replacement operation. It also supports compatibility with clients in various languages, improving the overall compatibility and stability of this management method.

[0050] For example, each of the multiple vector databases has a storage unit group, which includes a primary storage unit and at least one secondary storage unit. The vector database can be a distributed vector database. Data in a vector set of a vector database can be distributed across one or more storage unit groups. Multiple storage units in a storage unit group can be used to store the same data. In other words, each storage unit in a storage unit group can store a complete copy of the target data for a request message. A storage unit group can include multiple storage units, and any one of these storage units can be configured as the primary storage unit. The storage units other than the primary storage unit in the storage unit group are the secondary storage units. It can be understood that the primary and secondary storage units in a storage unit group store the same data.

[0051] Step S1200 writes the target data to the vector database corresponding to the subscription group, including step S1220. In step S1220, the target data is written to the main storage unit of the vector database corresponding to the subscription group, and the target data is synchronized to each of the at least one secondary storage unit. For example, the database write order of the vector data can be set to strong consistency. Consumers in the subscription group can call the write interface of the vector database. Under strong consistency, the vector database can automatically control the writing of the target data of the request message to the main storage unit, and use the data synchronization mechanism in the vector database to synchronize the target data to all secondary storage units corresponding to the main storage unit. Consumers write target data to a specific main storage unit, and the main storage unit synchronizes the target data to the secondary storage units, ensuring the order of data and avoiding the order disorder caused by multiple storage units in a storage unit group writing data at the same time. In some embodiments, the main storage unit will wait for all secondary storage units to confirm that the write is successful before returning an acknowledgment character to the consumer, confirming the write success, which can prioritize ensuring that data is not lost. In other embodiments, the main storage unit returns an acknowledgment character to the consumer immediately after the write is successful, and then pushes the data to the secondary storage units in the background. This approach offers low latency and high write throughput, prioritizing availability.

[0052] In the above technical solution, the target data is written to the main storage unit of the vector database corresponding to the subscription group, and the target data is synchronized to each of the at least one secondary storage unit. Thus, the target data is written to the main storage unit, which then synchronizes it to all secondary storage units. The main storage unit can execute the writing of target data for multiple request messages sequentially, avoiding the order disorder caused by simultaneous writing of data to multiple storage units, ensuring the writing order. Furthermore, even if the main storage unit fails, the request messages can still be saved in the message system, and the data will not be lost.

[0053] For example, the request message also includes the name of the target data collection. The collection name is the name of the vector collection in which the target data is to be stored in multiple vector databases. Each vector collection corresponds to one or more primary storage units, and each primary storage unit corresponds to at least one secondary storage unit. A storage unit can be a storage node used to store data. A storage node can correspond to a physical device. The primary storage unit corresponding to a vector collection can be a device that stores the data of that vector collection, and the secondary storage unit corresponding to the primary storage unit can be a device that stores backup data of that vector collection. The vector database stores data in different vector collections, and each vector collection stores data of the same dimension. The target data can be stored in the target vector collection of the vector database. The request message can include the name of the vector collection used to store the target data; that is, the request message includes the collection name. A vector collection in the vector database can be divided into one or more sub-vector collections, and these sub-vector collections can correspond one-to-one with one or more primary storage units. Data in a vector collection can be distributed across multiple primary storage units and can be backed up in multiple secondary storage units. It can be understood that the data stored in each primary storage unit is different; that is, the data of the vector collection is stored separately in each primary storage unit. Each primary storage unit corresponds to at least one secondary storage unit, and the data in the primary storage unit is exactly the same as the data in the corresponding secondary storage unit.

[0054] Step S1220 involves writing the target data to the main storage unit of the vector database corresponding to the subscription group and synchronizing the target data to each of at least one secondary storage unit, including step S1221. In step S1221, the target data is written to a single main storage unit of the vector set indicated by the set name of the target data in the vector database corresponding to the subscription group, and the target data is synchronized to each secondary storage unit corresponding to that main storage unit. For example, a consumer in the subscription group can call the vector data write interface to send a request message (including target data and set name) to the vector database. The vector database can determine the vector set indicated by the set name based on the set name in the request message, and determine the target main storage unit in the main storage unit of the vector set to write the target data to that target main storage unit. The data synchronization mechanism in the vector database can be used to synchronize the target data to all secondary storage units corresponding to that main storage unit. In some embodiments, the main storage unit waits for all secondary storage units to confirm successful writing before returning an acknowledgment character to the consumer, confirming successful writing and ensuring no data loss. In other embodiments, the primary storage unit immediately returns an acknowledgment character to the consumer after a successful write, and then pushes the data to the secondary storage unit in the background. This approach offers low latency and high write throughput.

[0055] In the above technical solution, the target data is written to a single primary storage unit of the vector set indicated by the set name of the target data in the vector database corresponding to the subscription group, and the target data is synchronized to each secondary storage unit corresponding to the primary storage unit. Thus, the vector set corresponds to multiple primary storage units, and different primary storage units can process write requests for different data in parallel, improving the write throughput of a single set. Each primary storage unit can independently perform data synchronization and fault recovery, better ensuring that data is not lost.

[0056] For example, each of the multiple vector databases corresponds to a load balancing module, which proxies multiple nodes of the corresponding vector database. A vector database can have multiple nodes. Each of these nodes can be used to write target data into the vector database. Nodes can be data nodes (DNs) and / or coordinator nodes (CNs). The load balancing module can be deployed in front of the vector databases, proxies the multiple nodes of the corresponding vector databases, and coordinates task allocation for request messages. The load balancing module can be a software load balancer, such as Nginx or HAProxy. Multiple vector databases correspond one-to-one with multiple subscription groups, and multiple vector databases also correspond one-to-one with multiple load balancing modules. It can be understood that the subscription group corresponding to the vector data can use the corresponding load balancing module to determine the target node of the corresponding vector database in order to write the target data into the vector database.

[0057] Step S1200 involves writing the target data into the vector database corresponding to the subscription group, including step S1230. In step S1230, the load balancing module of the vector database corresponding to the subscription group determines the target node from among multiple nodes in the vector database, and uses the target node to write the target data into the vector database. Consumers in the subscription group do not need to directly connect to specific nodes in the vector database; instead, they send write requests to the load balancing module corresponding to the vector database. After receiving the write request from the consumer, the load balancing module determines the target node from among its proxied nodes according to a preset load balancing strategy. The load balancing strategy of the load balancing module can employ any existing or future-developed load balancing strategy, such as round-robin, weighted round-robin, or least connections. The load balancing module forwards the consumer's write request to the selected target node, which then writes the target data into the vector database corresponding to the subscription group. Optionally, the target node can write the target data into the corresponding primary storage unit, and then the primary storage unit can synchronize the target data to the corresponding secondary storage unit. After the target data is written, the vector database can send an acknowledgment character to the load balancing module, which will then forward the acknowledgment character to the corresponding consumer to confirm that the target data has been written.

[0058] In the above technical solution, the load balancing module of the vector database corresponding to the subscription group is used to determine the target node among multiple nodes in the vector database corresponding to the subscription group, and the target data is written to the vector database corresponding to the subscription group using the target node. Thus, the load balancing module proxies multiple nodes, allowing requests to be routed only to healthy nodes, avoiding request anomalies caused by single node failures or network errors, thereby ensuring high availability of the vector database.

[0059] For example, after receiving the request message sent by the business terminal using the proxy service module, the vector database management method further includes steps S1300, S1400, S1500 and S1600.

[0060] In step S1300, if the request message is a read message, the request message is sent to the read module. The read module can be an independent microservice. The read module can be used to retrieve the target read result from the vector database based on the request message. After receiving the request message, if the request message is a read message, the proxy service module can send the request message to the read module. For example, if the request message is a read message, the proxy service module can directly pass the request message through to the read module.

[0061] In step S1400, the reading module sends a read request to the target vector database among multiple vector databases based on the request message. Upon receiving the request message, the reading module can determine the data to be read and send the read request to the target vector database. The target vector database can be any one of the multiple vector databases.

[0062] In step S1500, if a read result from the target vector database is received within a preset time, the read result is taken as the target read result. After the reading module sends a read request to the target vector database, the target vector database can query vector data according to the read request and send it to the reading module as a read result. The reading module can start timing after sending a read request to the target vector database to determine whether a read result from the target vector database is received within the preset time. If a read result from the target vector database is received within the preset time, the read result is taken as the target read result. For example, if the timing time corresponding to receiving the read result from the target vector database is less than the preset time, it is determined that a read result from the target vector database was received within the preset time.

[0063] In step S1600, if no read result is received from the target vector database within a preset time, one or more request sending operations are performed until the target read result is obtained or read requests are sent to multiple vector databases. The request sending operation includes sending a read request to one of the multiple vector databases that has not sent a read request. The target read result is the first read result received by the reading module from the multiple vector databases. For example, if the timing exceeds the preset time, but the reading module has not received a read result from the target vector database (i.e., no read result is received from the target vector database within the preset time), one or more request sending operations can be performed. The request sending operation may include sending a read request to one of the multiple vector databases that has not sent a read request. In some embodiments, if no read result is received from the target vector database within the preset time, multiple request sending operations can be performed simultaneously to send read requests to each of the multiple vector databases that has not sent a read request. For example, if the multiple vector databases include vector database 1, vector database 2, and vector database 3, and the target vector database is vector database 1, then two request sending operations can be performed simultaneously to send read requests to vector database 2 and vector database 3 respectively. In other embodiments, if no read result is received from the target vector database within a preset time, a request sending operation can be performed first, and then the preset time can be waited. If no read request is received within the preset time, a request sending operation can be performed again, until the target read result is obtained or read requests are sent to multiple vector databases. For example, the multiple vector databases include vector database 1, vector database 2, and vector database 3, and the target vector database is vector database 1. A read request can be sent to vector database 2, and after waiting for a preset time, if no read result is received, a read request can be sent to vector database 3. It can be understood that after the read module sends a read request, the first read result received by the read module from multiple vector databases is the target read result. For example, if the read module sends read requests to vector database 1, vector database 2, and vector database 3, the first read result received by the read module from vector database 2 is the target read result. The read module can send the target read result to the business end through the proxy service module. It is understood that step S1600 can be executed if the reading result of the target vector database is not received within a preset time, and not executed if the reading result of the target vector database is received within a preset time.

[0064] For example, users can adjust the preset time as needed. For instance, users can determine the preset time based on the 99th percentile of the historical read response times from the vector database. This avoids misjudging database failures due to brief network fluctuations while ensuring timely request sending.

[0065] In the above technical solution, when the request message is a read message, the request message is sent to the read module. The read module sends a read request to the target vector database based on the request message. If a read result is received from the target vector database within a preset time, that read result is taken as the target read result. If no read result is received from the target vector database within the preset time, the read request is sent once or multiple times to one of the multiple vector databases that did not send the read request, until the target read result is obtained or the read request is sent to all multiple vector databases. The target read result is the first read result received by the read module from the multiple vector databases. This ensures that even if one or more vector databases experience partial failure or network partitioning, the system can still obtain data from other healthy vector databases, and the target read result is the first received read result. It automatically avoids slow-responding vector databases, always providing the fastest read result to the business end, significantly improving the user experience.

[0066] According to another aspect of the present invention, a management system for a vector database is also provided. Figure 4 A schematic block diagram of a vector database management system according to an embodiment of the present invention is shown. Figure 4 As shown, the vector database management system includes a proxy service module and a message module. The message module includes a message system and multiple subscription groups corresponding one-to-one with multiple vector databases. Each subscription group includes at least one consumer. The proxy service module receives request messages sent by the business end. When the request message is a write message, it writes the request message to the message system of the message module, where the request message includes the target data to be stored. The consumer of each subscription group in the message module consumes the target data of the request message from the message system and writes the target data to the vector database corresponding to that subscription group.

[0067] For example, the request message also includes the set name of the target data. The set name is the name of the vector set in which the target data is to be stored in multiple vector databases. The message system includes multiple partitions. The proxy service module writes the request message into the message system of the message module in the following way: extracts the set name of the target data in the request message; uses the set name as the first identifier key for writing the request message into the message system; determines the target partition of the request message in the message system according to the first identifier key; and writes the request message into the target partition.

[0068] For example, the message module is further used to calculate the hash value of the first identifier key, perform a modulo operation on the hash value using the number of multiple partitions, and obtain a partition identifier, which is used to represent the target partition.

[0069] For example, for each of the multiple subscription groups, each consumer in the at least one consumer in the subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in the subscription group. The message module writes the target data into the vector database corresponding to the subscription group in the following manner: for each of the multiple subscription groups, the set name is used as the second identifier key to determine the target consumer in the subscription group, the target consumer consumes the target data from the message system, and the target data is written into the vector database corresponding to the subscription group, wherein the target consumer is the consumer corresponding to the second identifier key corresponding to the set name.

[0070] For example, the vector database management system also includes a load balancing module. Each vector database has a corresponding load balancing module. The load balancing module proxies multiple nodes of the corresponding vector database. The message module writes the target data to the vector database corresponding to the subscription group in the following way: using the load balancing module of the vector database corresponding to the subscription group, the target node is determined among the multiple nodes of the vector database corresponding to the subscription group, and the target data is written to the vector database corresponding to the subscription group using the target node.

[0071] For example, the vector database management system further includes a reading module, and the proxy service module is further configured to send a request message to the reading module when the request message is a reading message; the reading module is configured to send a reading request to a target vector database in multiple vector databases according to the request message; if the reading result of the target vector database is received within a preset time, the reading result is taken as the target reading result; if the reading result of the target vector database is not received within the preset time, one or more request sending operations are performed until the target reading result is obtained or the reading request is sent to multiple vector databases. The request sending operation includes: sending a reading request to one of the vector databases in multiple vector databases that has not sent a reading request, wherein the target reading result is the reading result that the reading module receives first from multiple vector databases.

[0072] For example, the proxy service module is specifically used to format the request message based on a preset data serialization protocol and write the processed request message into the message system, wherein the preset data serialization protocol is a data protocol supported by the vector database.

[0073] For example, the business terminal has a preset protocol packet, which is generated based on a preset data serialization protocol file of the vector database source code, and the business terminal sends request messages based on the preset protocol packet.

[0074] For example, each of the multiple vector databases has a storage unit group, which includes a primary storage unit and at least one secondary storage unit. A consumer writes target data to the primary storage unit of the vector database corresponding to that subscription group. The vector database synchronizes the target data to each of the at least one secondary storage unit.

[0075] For example, the request message also includes the name of the target data set, which is the name of the vector set in which the target data is to be stored in multiple vector databases. Each vector set corresponds to multiple primary storage units, and each primary storage unit corresponds to at least one secondary storage unit. The consumer specifically writes the target data to a single primary storage unit of the vector set indicated by the target data set name in the vector database corresponding to the subscription group. The vector database synchronizes the target data to each secondary storage unit corresponding to that primary storage unit.

[0076] Figure 5 A schematic block diagram of a vector database management system according to another embodiment of the present invention is shown. Figure 5 As shown, the management system for this vector database includes a proxy service module, a messaging module, a load balancing module corresponding to each of the multiple vector databases, and a reading module. The messaging module includes a messaging system and multiple subscription groups corresponding to each of the multiple vector databases, with each subscription group including at least one consumer.

[0077] The proxy service module receives request messages sent by the business side. When the request message is a write message, it writes the request message into the message system of the message module. The request message includes the target data to be stored. Each consumer in the multiple subscription groups of the message module consumes the target data of the request message from the message system. Using the load balancing module of the vector database corresponding to the subscription group, it determines the target node among the multiple nodes of the vector database corresponding to the subscription group and uses the target node to write the target data into the vector database corresponding to the subscription group. The proxy service module receives request messages from the business side. When the request message is a read message, it sends the request message to the read module. The read module sends a read request to the target vector database among multiple vector databases according to the request message. If the read result of the target vector database is received within a preset time, the read result is taken as the target read result. If the read result of the target vector database is not received within the preset time, one or more request sending operations are performed until the target read result is obtained or read requests are sent to multiple vector databases. The request sending operation includes sending a read request to one of the vector databases among multiple vector databases that has not yet sent a read request. The target read result is the first read result received by the read module from the multiple vector databases.

[0078] By way of example, according to another aspect of the present invention, an electronic device is also provided. Figure 6 A schematic block diagram of an electronic device 600 according to an embodiment of the present invention is shown. The electronic device 600 includes a processor 610 and a memory 620. The memory 620 stores computer program instructions, which, when executed by the processor 610, are used to perform the vector database management method described above.

[0079] By way of example, according to another aspect of the present invention, a storage medium is also provided, on which program instructions are stored, which, when executed, are used to perform the vector database management method described above. The storage medium may, for example, include an erasable programmable read-only memory (EPROM), a portable read-only memory (CD-ROM), a USB memory, or any combination of the above storage media. The storage medium may be any combination of one or more computer-readable storage media.

[0080] By way of example, according to another aspect of the present invention, a computer program product is also provided, including computer program instructions that, when executed, are used to perform the vector database management method as described above.

[0081] Those skilled in the art can understand the specific implementation schemes and beneficial effects of the above-mentioned vector database management system, electronic device, storage medium and computer program product by reading the relevant descriptions of the vector database management method. For the sake of brevity, they will not be described in detail here.

[0082] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of this application. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of this application. All such changes and modifications are intended to be included within the scope of this application as claimed in the appended claims.

[0083] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0084] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0085] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0086] Similarly, it should be understood that, in order to streamline this application and aid in understanding one or more of the various inventive aspects, features of this application may sometimes be grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of this application. However, this approach should not be construed as reflecting an intention that the claimed application requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with features fewer than all features of a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0087] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or units of any method or apparatus so disclosed can be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0088] Furthermore, those skilled in the art will understand that although some embodiments described herein include certain features but not others included in other embodiments, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the claims, any one of the claimed embodiments can be used in any combination.

[0089] The various component embodiments of this application can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules in the vector database management system according to embodiments of this application. This application can also be implemented as an apparatus program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such an implementation of this application can be stored on a computer-readable medium, or can be in the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0090] It should be noted that the above embodiments are illustrative of this application and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. This application can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0091] The above description is merely a specific embodiment or illustration of the embodiments of this application. The scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. The scope of protection of this application shall be determined by the scope of the claims.

Claims

1. A method for managing a vector database, characterized in that, include: The proxy service module receives request messages sent by the business end. When the request message is a write message, the request message is written to the message system of the message module. The request message includes target data to be stored. The message module includes the message system and multiple subscription groups that correspond one-to-one with multiple vector databases. Each subscription group includes at least one consumer. Consumers of each of the multiple subscription groups consume the target data of the request message from the messaging system and write the target data into the vector database corresponding to that subscription group.

2. The method for managing a vector database according to claim 1, characterized in that, The request message also includes the name of the target data set, which is the name of the vector set in which the target data is to be stored in the multiple vector databases. The message system includes multiple partitions. The message system that writes the request message to the message module includes: Extract the collection name of the target data from the request message; The set name is used as the first identifier key for writing the request message into the messaging system. The target partition of the request message in the messaging system is determined based on the first identifier key, and the request message is written into the target partition.

3. The method for managing a vector database according to claim 2, characterized in that, Determining the target partition of the request message in the messaging system based on the first identifier key includes: Calculate the hash value of the first identifier key, and perform a modulo operation on the hash value using the number of the plurality of partitions to obtain the partition identifier, which is used to represent the target partition.

4. The method for managing a vector database according to claim 2, characterized in that, For each of the plurality of subscription groups, each consumer in the at least one consumer in that subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in that subscription group. The step of consuming the target data of the request message from the message system using the consumer of each of the plurality of subscription groups, and writing the target data into the vector database corresponding to that subscription group, includes: For each of the plurality of subscription groups, the set name is used as the second identifier key to determine the target consumer in the subscription group. The target consumer is used to consume the target data from the message system and write the target data into the vector database corresponding to the subscription group. The target consumer is the consumer corresponding to the second identifier key corresponding to the set name.

5. The method for managing a vector database according to claim 1, characterized in that, The message system that writes the request message to the message module includes: The request message is formatted based on a preset data serialization protocol, and the processed request message is written into the message system. The preset data serialization protocol is a data protocol supported by the vector database.

6. The method for managing a vector database according to claim 5, characterized in that, The service terminal has a preset protocol packet, which is generated based on a preset data serialization protocol file of the source code of the vector database. The service terminal sends the request message based on the preset protocol packet.

7. The method for managing a vector database according to claim 1, characterized in that, Each of the plurality of vector databases has a storage unit group, the storage unit group including a primary storage unit and at least one secondary storage unit. The step of writing the target data into the vector database corresponding to the subscription group includes: The target data is written to the main storage unit of the vector database corresponding to the subscription group, and the target data is synchronized to each of the at least one secondary storage unit.

8. The method for managing a vector database according to claim 7, characterized in that, The request message also includes the set name of the target data, which is the name of the vector set to be stored in the multiple vector databases. The vector set corresponds to one or more main storage units, and each main storage unit corresponds to at least one secondary storage unit. The step of writing the target data into the main storage unit of the vector database corresponding to the subscription group and synchronizing the target data to each of the at least one secondary storage unit includes: The target data is written to a single primary storage unit of the vector set indicated by the set name of the target data in the vector database corresponding to the subscription group, and the target data is synchronized to each secondary storage unit corresponding to the primary storage unit.

9. The method for managing a vector database according to claim 1, characterized in that, Each of the multiple vector databases corresponds to a load balancing module, and the load balancing module proxies multiple nodes of the corresponding vector database. The step of writing the target data into the vector database corresponding to the subscription group includes: Using the load balancing module of the vector database corresponding to the subscription group, a target node is determined among multiple nodes in the vector database corresponding to the subscription group, and the target data is written into the vector database corresponding to the subscription group using the target node.

10. The method for managing a vector database according to claim 1, characterized in that, After receiving the request message sent by the business terminal using the proxy service module, the method further includes: When the request message is a read message, the request message is sent to the read module; Using the reading module, a read request is sent to the target vector database in the plurality of vector databases according to the request message; If the read result of the target vector database is received within a preset time, the read result shall be taken as the target read result; If no read result is received from the target vector database within the preset time, one or more request sending operations are performed until the target read result is obtained or the read request is sent to all of the multiple vector databases. The request sending operation includes: The read request is sent to one of the multiple vector databases that has not sent the read request, wherein the target read result is the first read result received by the read module from the multiple vector databases.

11. A management system for a vector database, characterized in that, The management system for the vector database includes: a proxy service module and a message module. The message module includes a message system and multiple subscription groups corresponding one-to-one with the multiple vector databases. Each subscription group includes at least one consumer. The proxy service module is used to receive request messages sent by the business end, and when the request message is a write message, write the request message into the message system of the message module, wherein the request message includes target data to be stored; The consumer of each of the multiple subscription groups in the messaging module is used to consume the target data of the request message from the messaging system and write the target data into the vector database corresponding to the subscription group.

12. The management system for the vector database according to claim 11, characterized in that, The request message also includes the name of the target data set, which is the name of the vector set in which the target data is to be stored in the multiple vector databases. The message system includes multiple partitions. The proxy service module writes the request message into the message system of the message module in the following way: Extract the collection name of the target data from the request message; The set name is used as the first identifier key for writing the request message into the messaging system. The target partition of the request message in the messaging system is determined based on the first identifier key, and the request message is written into the target partition.

13. The management system for the vector database according to claim 12, characterized in that, The message module is further configured to calculate the hash value of the first identifier key, perform a modulo operation on the hash value using the number of the plurality of partitions, obtain a partition identifier, and determine the target partition, wherein the target partition is the partition indicated by the partition identifier.

14. The management system for the vector database according to claim 12, characterized in that, For each of the plurality of subscription groups, each consumer in the at least one consumer in that subscription group corresponds to one or more second identifier keys, and each second identifier key corresponds to a unique consumer in that subscription group. The message module writes the target data into the vector database corresponding to the subscription group in the following manner: For each of the plurality of subscription groups, the set name is used as the second identifier key to determine the target consumer in the subscription group. The target consumer is used to consume the target data from the message system and write the target data into the vector database corresponding to the subscription group. The target consumer is the consumer corresponding to the second identifier key corresponding to the set name.

Images