Object matching method based on bitmap index

Abstract

The invention discloses an object matching method and device based on bitmap indexing and a computer readable storage medium, and the method comprises the steps: obtaining multi-dimensional attribute data of a target object in response to a received matching request for the target object; converting the multi-dimensional attribute data into an index key value in an integer index space based on a preset coding mapping definition; searching in a pre-constructed rule bitmap index database by utilizing the index key value to obtain a plurality of condition bitmaps respectively corresponding to the plurality of candidate rules; performing bit logic combination operation on the condition bitmaps to generate a matching result bitmap; and determining a target rule hit by the target object according to the matching result bitmap. According to the technical scheme, millisecond-level real-time accurate matching is realized, and the storage space of the index data and the read-write performance in a high-concurrency scene are effectively optimized.

Description

Technical Field

[0001] This invention relates to the field of activity retrieval technology for pharmaceutical e-commerce platforms, and in particular to an object matching method, device, and computer-readable storage medium based on bitmap indexing. Background Technology

[0002] With the rapid development of pharmaceutical e-commerce, large B2B trading platforms face challenges such as complex activity rules, low matching efficiency, and massive data volume in the process of product promotion, marketing activities, and matching user rights.

[0003] In a typical promotional campaign system, the platform needs to dynamically determine whether an order or product meets the rules and conditions of a specific campaign based on multiple dimensions such as product, customer attributes, region, time, level, and purchase quantity. Traditional solutions generally use database condition queries (such as SQL multi-table joins) or cached condition tree matching methods. However, as the number of campaigns and the complexity of conditions increase, the computational performance drops rapidly, leading to a significant increase in matching latency and affecting the efficiency of order processing and campaign settlement.

[0004] In existing technologies, the following two technical solutions are mainly used to address this type of rule matching requirement:

[0005] (1) Rule matching based on conditional expression parsing: Rules are described using a DSL (Domain Specific Language), and then dynamically parsed and the query is executed. This method is highly flexible, but the parsing and computation overhead is large, making it difficult to support high-concurrency business scenarios.

[0006] (2) Conditional filtering method based on Bloom filter: It uses probability data structure to make quick predictions, but Bloom filter does not support efficient condition combination judgment and has a certain false judgment rate, and cannot accurately map complex business rules.

[0007] The above solutions all have the following shortcomings:

[0008] 1. Low query efficiency: Dynamic matching with multiple conditions requires frequent access to the database or cache, resulting in high CPU and I / O resource consumption;

[0009] 2. Complex rule representation: DSL parsing or tree-structured storage methods are complex, making rule maintenance difficult;

[0010] 3. Inaccurate matching results: Probabilistic structures such as Bloom filters have the risk of misjudgment and are not suitable for business scenarios that require high accuracy of rules;

[0011] 4. Poor scalability: As the number and dimensions of activity rules increase, the system matching time grows exponentially, making it difficult to meet the needs of large-scale real-time matching.

[0012] Therefore, there is an urgent need for a low-latency, high-precision, and scalable activity matching algorithm to address the high-concurrency matching problem in large-scale promotional scenarios on pharmaceutical e-commerce platforms. Summary of the Invention

[0013] This application provides an object matching method based on bitmap indexes, aiming to solve the technical problems of low computational efficiency, high resource consumption, and poor scalability of traditional database or rule engine matching methods under large-scale data and complex rules, as well as the inability of Bloom filter-based matching methods to guarantee accurate matching and not support complex logical combinations.

[0014] To achieve the above objectives, embodiments of this application provide an object matching method based on bitmap indexing, including:

[0015] In response to receiving a matching request for a target object, obtain the multidimensional attribute data of the target object;

[0016] Based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space;

[0017] Using the index key value, a search is performed in the pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules respectively;

[0018] Perform bit logic combination operations on the multiple condition bitmaps to generate a matching result bitmap;

[0019] Based on the matching result bitmap, the target rule that the target object is matched with is determined.

[0020] In one embodiment, based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space, including:

[0021] Obtain at least one continuous numerical attribute contained in the multidimensional attribute data;

[0022] Based on the preset interval discretization rules, the target numerical interval to which the continuous numerical attribute belongs is determined;

[0023] Extract the interval identifier code of the target numerical interval, and use the interval identifier code as the discrete code of the continuous numerical attribute to construct a discrete feature vector;

[0024] The discrete feature vectors are subjected to topological dimensionality reduction mapping to generate the index key values.

[0025] In one embodiment, performing topological dimensionality reduction mapping on the discrete feature vectors to generate the index key values ​​includes:

[0026] Each discrete code in the discrete feature vector is converted into a fixed-length binary bit string;

[0027] Based on the preset weight priority of each dimension, determine the positional distribution pattern of each dimension in the target index key value;

[0028] According to the bit order distribution pattern, the bit values ​​to be processed in each of the binary bit strings are extracted sequentially, and bit interleaving operation is performed to fill the extracted bit values ​​to be processed into the corresponding positions of the target binary sequence.

[0029] The filled target binary sequence is converted into a decimal integer to obtain the index key value that maintains the multidimensional spatial proximity.

[0030] In one embodiment, the rule bitmap index library includes a base bitmap layer and an incremental bitmap layer, wherein the base bitmap layer is used to store rule matching data that has been fixed in historical time, and the incremental bitmap layer is used to store rule change data that has occurred within the current time window;

[0031] A search is performed in a pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules, including:

[0032] Using the index key value, parallel searches are performed in the base bit layer and the incremental bit layer respectively to obtain multiple condition bitmaps at different levels corresponding to the index key value.

[0033] In one embodiment, the incremental bit layer includes a new bitmap for recording newly added rule matching relationships and a removed bitmap for recording removed rule matching relationships;

[0034] Using the index key value, parallel searches are performed in the base bit layer and the incremental bit layer respectively to obtain multiple condition bitmaps at different levels corresponding to the index key value, including:

[0035] Using the index key value, a baseline state bitmap is obtained in the base bit layer, and a newly added state bitmap and a removed state bitmap are obtained in the incremental bit layer, respectively.

[0036] Perform a bitwise AND-NOT operation on the reference state bitmap and the removal state bitmap to generate an intermediate bitmap that excludes failure rules;

[0037] Perform a bitwise OR operation on the intermediate bitmap and the newly added state bitmap to generate the condition bitmap that integrates real-time change data.

[0038] In one embodiment, performing bitwise logic combination operations on the plurality of condition bitmaps to generate a matching result bitmap includes:

[0039] Obtain the cardinality statistics of each of the plurality of condition bitmaps, wherein the cardinality statistics represent the number of set elements contained in the corresponding condition bitmap;

[0040] Based on the cardinality statistical characteristics, the operation priorities of the multiple condition bitmaps are sorted in ascending order to generate an execution plan sequence;

[0041] Based on the execution plan sequence, bitwise AND operations are sequentially performed on the multiple condition bitmaps to generate the matching result bitmap.

[0042] In one embodiment, the rule bitmap index library is constructed based on a compressed bitmap structure, which includes an array container for storing sparse data, a bitmap container for storing dense data, and a run-length container for storing continuous data; wherein,

[0043] The rule bitmap index library is configured to: adaptively select the run container to store continuous index key values ​​in response to the numerical continuity characteristics exhibited by the index key values ​​in the integer index space, wherein the numerical continuity characteristics are obtained by transforming the multidimensional attribute data through topological dimensionality reduction mapping.

[0044] In one embodiment, after generating the matching result bitmap, the object matching method further includes:

[0045] Generate a hash signature for the matching result bitmap;

[0046] The hash signature, the matching result bitmap, and the attribute identifier of the target object are associated and stored in the cache space, wherein the attribute identifier is parsed from the matching request;

[0047] In response to a subsequent matching request with the same attribute identifier, the cache space is retrieved based on the attribute identifier. If a corresponding target hash signature is found, the cache matching result corresponding to the target hash signature is returned directly.

[0048] To achieve the above objectives, embodiments of this application also propose a bitmap index-based object matching device, including a memory, a processor, and a bitmap index-based object matching program stored in the memory and executable on the processor. When the processor executes the bitmap index-based object matching program, it implements the bitmap index-based object matching method as described in any of the preceding claims.

[0049] To achieve the above objectives, embodiments of this application also propose a computer-readable storage medium storing a bitmap-indexed object matching program, which, when executed by a processor, implements the bitmap-indexed object matching method as described in any of the preceding claims.

[0050] The bitmap-index-based object matching method of this application has the following advantages:

[0051] 1. Ultra-fast response and linear scalability

[0052] 2. Ultimate optimization of storage space and caching efficiency

[0053] 3. Lock-free real-time updates in high-concurrency scenarios

[0054] 4. Computational pruning based on data distribution

[0055] 5. Automatic deduplication of hotspot traffic Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0057] Figure 1 This is a block structure diagram of an embodiment of the bitmap index-based object matching device of the present invention;

[0058] Figure 2 This is a flowchart illustrating an embodiment of the object matching method based on bitmap indexing of the present invention.

[0059] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0060] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are merely some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0061] It should be noted that when ordinal numbers such as "first" and "second" are mentioned in the embodiments of this application, they are only used to distinguish different objects and do not indicate a specific order or degree of importance, unless the context clearly specifies otherwise. Furthermore, the "connection" or "coupling" described in the embodiments of this application includes not only direct physical connections but also indirect connections or electrical / communication connections via an intermediate medium.

[0062] like Figure 1 As shown, Figure 1 This is a schematic diagram of the structure of the bitmap index-based object matching device 1 in the hardware operating environment involved in the embodiment of the present invention.

[0063] The bitmap-index-based object matching device 1 (hereinafter referred to as "the device") in this application embodiment can be physically manifested as, but is not limited to, a server (including cloud servers, server clusters, edge computing nodes), a high-performance workstation, a personal computer (PC), a mobile terminal, an IoT gateway, or a dedicated embedded processing device. The device is configured to execute the bitmap-index-based object matching method provided in this application embodiment.

[0064] like Figure 1 As shown, the device may include a memory 11, a processor 12, a communication interface 13, and a system bus 14.

[0065] The memory 11 is used to store computer programs (or instructions) and data required for device operation. The memory 11 includes at least one type of readable storage medium. This readable storage medium includes non-volatile memory (NVM), such as solid-state drives (SSDs), hard disk drives (HDDs), flash memory, optical discs, or other magnetic / optical storage media; it may also include volatile memory, such as random access memory (RAM) or cache. More importantly, the memory 11 stores the operating system, database, and the bitmap-indexed object matching program 10 involved in this application.

[0066] Processor 12 is the computing core and control center of the device. Specifically, processor 12 can be one or more central processing units (CPUs), microprocessors (MCUs), digital signal processors (DSPs), or field-programmable gate arrays (FPGAs). In embodiments involving artificial intelligence, big data processing, or image rendering, processor 12 may also include an artificial intelligence acceleration chip (such as an NPU, TPU) or a graphics processing unit (GPU) for performing parallel vector or tensor operations. Processor 12 uses system bus 14 to read the bitmap-index-based object matching program 10 from memory 11, and implements the various steps of the bitmap-index-based object matching method provided in this application embodiment by parsing and executing program instructions.

[0067] Communication interface 13 (or network interface) is used to enable communication and interaction between this device and other electronic devices (such as clients, third-party servers, and sensor nodes). Specifically, communication interface 13 may optionally include a wired interface (such as an Ethernet interface, fiber optic interface, or USB interface) or a wireless interface (such as a Wi-Fi module, cellular mobile communication module, Bluetooth module, or NFC module). This interface supports various standard communication protocols, including but not limited to TCP / IP, HTTP / HTTPS, UDP, MQTT, and RPC.

[0068] System bus 14 can be a Peripheral Component Interconnect Standard (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus is used to transfer instruction and data streams between processor 12, memory 11 and communication interface 13.

[0069] Optionally, the device 1 may also include a user interface (not shown) for human-computer interaction. The user interface may include a display unit (such as an LCD screen, OLED screen, or touch screen) and an input unit (such as a keyboard, mouse, or microphone).

[0070] Those skilled in the art will understand that Figure 1 The structure shown does not constitute a physical limitation on the bitmap index-based object matching device 1. Depending on the specific application scenario, the device may include fewer or more components than shown, or combine certain components, or use different component arrangements.

[0071] exist Figure 1 In the operating environment shown, processor 12 calls the bitmap-indexed object matching program 10 stored in memory 11 and is configured to perform the following operations:

[0072] In response to receiving a matching request for a target object, obtain the multidimensional attribute data of the target object;

[0073] Based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space;

[0074] Using the index key value, a search is performed in the pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules respectively;

[0075] Perform bit logic combination operations on the multiple condition bitmaps to generate a matching result bitmap;

[0076] Based on the matching result bitmap, the target rule that the target object is matched with is determined.

[0077] Furthermore, the processor 12 may also be configured to perform refinement steps of the bitmap-index-based object matching method in any of the following embodiments.

[0078] Based on the hardware architecture of the bitmap-index-based object matching device described above, an embodiment of the bitmap-index-based object matching method of the present invention is proposed. This method is applied to server-side systems that require real-time matching of massive amounts of rules, such as e-commerce promotion engines, advertising delivery platforms (DSPs), risk control decision engines, or user rights centers.

[0079] Reference Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the bitmap-indexed object matching method of the present invention. Figure 2 As shown, this bitmap-index-based object matching method includes the following steps:

[0080] S10. In response to receiving a matching request for a target object, obtain the multidimensional attribute data of the target object.

[0081] In this step, a matching request refers to an instruction initiated by an upstream business system (such as a transaction gateway, APP client, or message queue consumer) to query whether an individual matches a specific business rule. The target object is the subject of the matching, which, depending on the specific business scenario, may include, but is not limited to: "order-placing users" or "transaction orders" in e-commerce scenarios, "traffic requests" in advertising scenarios, or "payment behavior" in risk control scenarios.

[0082] Furthermore, the process of obtaining multi-dimensional attribute data typically involves parsing request messages. In specific engineering implementations, matching requests can be received via HTTP / HTTPS protocols, RPC (Remote Procedure Call) protocols, or MQ (Message Queue) message push methods. The payload of the request message is usually in a serialization format such as JSON, Protocol Buffers, or Thrift.

[0083] The key point is that the "multidimensional attribute data" contains feature values ​​describing the target object across different dimensions. To comprehensively cover complex business rules, multidimensional attribute data typically combines several data types, including:

[0084] 1. Discrete enumeration attributes: such as a user's "Membership Level (L1-L5)", "Gender (Male / Female)", "City ID (City_1001)", or "Device Type (iOS / Android)". The value range of such attributes is usually finite and enumerable.

[0085] 2. Continuous numerical attributes: such as transaction "order amount (e.g., 199.50)", "request timestamp (e.g., 1678888888)", "user's current geographic location coordinates (GPS latitude and longitude)" or "cumulative consumption frequency in the last 30 days".

[0086] S20. Based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space.

[0087] In this embodiment, step S20 normalizes the original, heterogeneous multidimensional attribute data (including continuous and discrete values) into a one-dimensional integer form to facilitate rapid bitwise operations in the bitmap index library. This conversion process is not a simple concatenation, but a topology-preserving encoding conversion achieved through the following sub-steps S21 to S24.

[0088] S21. Obtain at least one continuous numerical attribute contained in the multidimensional attribute data.

[0089] As mentioned earlier, in the context of pharmaceutical e-commerce, the attributes of the target object often include continuous values ​​such as "order amount" and "number of days since the last purchase". These values ​​are, in their original state, infinite and unenumerable floating-point numbers or high-precision integers.

[0090] S22. Based on the preset interval discretization rules, determine the target numerical interval to which the continuous numerical attribute belongs.

[0091] S23. Extract the interval identifier code of the target numerical interval, and use the interval identifier code as the discrete code of the continuous numerical attribute to construct a discrete feature vector.

[0092] To incorporate continuous values ​​into the bitmap system, this application employs a "range-based" strategy. Pre-defined discretization rules divide the numerical axis of a continuous dimension into multiple non-overlapping intervals. For example, for the "order amount" dimension, it can be divided as follows: [0, 100) for interval code 1, [100, 500) for interval code 2, and so on. The system locates the interval code (e.g., interval code 15) to which the target object belongs based on its actual value (e.g., amount 5200.00).

[0093] Subsequently, the system arranges all dimensions (including native discrete attributes and transformed continuous attribute discrete codes) according to a preset dimensional order, combining them to form a discrete feature vector. For example, a three-dimensional vector can be represented as... Each element is an integer code.

[0094] S24. Perform topological dimensionality reduction mapping on the discrete feature vector to generate the index key value.

[0095] Specifically, the implementation of step S24 (performing topological dimensionality reduction mapping on the discrete feature vector) is essentially a process of mapping coordinate points in a multidimensional space to a one-dimensional linear index (space-filling curve). This application preferably employs a weighted bit Z-order (Morton code) encoding algorithm. The process of generating the index key value specifically includes the following sub-steps S241 to S244:

[0096] S241. Convert each discrete code in the discrete feature vector into a fixed-length binary bit string.

[0097] The system first obtains the discrete feature vector generated in step S23. Assume this vector contains N dimensions, denoted as V = [v_1, v_2, ..., v_N]. The system predefines a fixed length L for the binary bit string (e.g., L = 32 bits or 64 bits). For each discrete code in the vector... It is then converted into binary form. If the converted binary number of bits is less than L, zero padding is performed on the high-order bits to ensure that the encoding length of all dimensions is consistent.

[0098] For example, let the value of dimension 1 (amount range ID) be... = 6 (binary 110), set length L = 4. After conversion, it becomes 0110.

[0099] Let the value of dimension 2 (time interval ID) be... (Binary 011), after conversion is 0011.

[0100] S242. Determine the positional distribution pattern of each dimension in the target index key value according to the preset weight priority of each dimension.

[0101] Unlike traditional round-robin polling, this step allows different weights and priorities to be assigned to different dimensions based on the importance of the business rules.

[0102] Specifically, for high-weight dimensions, their binary bits should be assigned to higher (more significant) positions in the target index key value. The purpose of this is to ensure that when high-weight attributes undergo subtle changes, the resulting index key value changes more significantly, thereby forming clusters in the index space dominated by high-weight attributes.

[0103] Specifically, the system generates a length of A bit-mask map is used. This map specifies which bit in which dimension the k-th bit in the target binary sequence should originate from. For example, if the weight of dimension 1 is greater than the weight of dimension 2, the bit-mask distribution pattern might be defined as: the high-order bits of the target sequence are filled first in the high-order bits of dimension 1, and then the low-order bits are alternated.

[0104] S243. According to the bit order distribution pattern, extract the bit values ​​to be processed from each of the binary bit strings in sequence, and perform bit interleaving operation to fill the extracted bit values ​​to be processed into the corresponding positions of the target binary sequence.

[0105] The system performs bit interleaving based on the above bit order distribution pattern. For example, assuming the most basic equal-weighted alternation pattern is used, if dimension 1 (x): 0110 (bit order: ), Dimension 2 (y): 0011 (position: The interlacing rule is .

[0106] The extraction and filling process is as follows: Fill the 0th position. -> ...1; Fill in the first position -> ...01; fill in the second position -> ...101; Fill in the 3rd position -> ...1101...and so on. The final generated target binary sequence is: 00101101.

[0107] S244. Convert the filled target binary sequence into a decimal integer to obtain the index key value that maintains the multidimensional spatial proximity.

[0108] Finally, the system converts the mixed binary sequence (e.g., 00101101) generated in step S243 back into a decimal integer (i.e., 45). This integer is the final index key value used for index retrieval.

[0109] It is understandable that, through the processing described in S241-S244, it successfully transforms the Euclidean distance proximity in the multidimensional attribute space into numerical proximity in the integer space. In a physical sense, this means that two target objects with similar attribute characteristics (e.g., similar amounts and geographical locations) will also have very similar index key values ​​after mapping.

[0110] Because the index keys of similar objects are highly clustered on the integer axis, the set bits in the bitmap exhibit a clear continuity when building the subsequent regular bitmap index library. This continuity maximizes the activation of the run container mechanism in the underlying compressed bitmap (such as Roaring Bitmap), achieving extremely high storage compression ratios using run-length encoding (RLE) and significantly improving the cache hit rate of the CPU when performing bitwise logical operations.

[0111] As another implementation of step S20, this application also provides an implementation scheme based on direct feature combination. This scheme is suitable for business scenarios with fewer dimensions or lower requirements for spatial proximity, and can quickly generate index key values ​​with lower computational cost.

[0112] In this embodiment, step S20 specifically includes the following sub-steps:

[0113] S25. Obtain the attribute values ​​of each dimension in the multidimensional attribute data. For discrete attributes (such as "gender" and "city"), directly obtain their text or enumeration values; for continuous numerical attributes (such as "amount"), map them to discrete interval IDs based on a preset step size rule. For example: User attributes are {City: "Shanghai", Level: "L2", Activity Range: "A5"}.

[0114] S26. Following the preset dimensional order, concatenate the attribute values ​​or their corresponding discrete IDs of each dimension into a feature string. The system uses a predefined rule template (Schema) to concatenate the values ​​of each dimension using specific delimiters, generating a unique feature signature. For example, the concatenated feature signature is "City:Shanghai|Level:L2|Active:A5".

[0115] S27. Using a preset hash algorithm, calculate the feature identifier string and determine the calculated hash value as the index key value. To map a variable-length string to a fixed integer index space, the system uses a hash function (such as MurmurHash, CityHash, or a truncated MD5 value) to operate on the feature identifier string, generating a 32-bit or 64-bit integer. For example: Hash("City:Shanghai|Level:L2|Active:A5") → Integer index key value 892013.

[0116] Compared to the aforementioned Z-order-based implementation, this embodiment, while sacrificing some spatial proximity (hash algorithms typically scatter data distribution), boasts advantages in its simple implementation logic and extremely low computational overhead. It can also transform complex multidimensional objects into unique integer IDs, thereby supporting precise matching in the bitmap index and addressing the issue of low SQL query efficiency.

[0117] S30. Using the index key value, search in the pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules respectively.

[0118] Specifically, after generating an index key value that represents the characteristics of the target object, the system uses this index key value as a query credential to retrieve data from the pre-built rule bitmap index library.

[0119] In this embodiment, to address the read-write lock contention issue that arises when a large-scale rule engine faces frequent rule changes, the rule bitmap index library employs a dual-layer storage structure that supports read-write separation in its physical storage architecture. This dual-layer storage structure specifically consists of a base bitmap layer and an incremental bitmap layer. The base bitmap layer is primarily used to store rule matching data that has been fixed in historical timeframes and no longer changes frequently; it is typically represented as a read-only persistent file snapshot. The incremental bitmap layer, on the other hand, is specifically used to store rule change data that has occurred within the current time window; it is typically represented as a dynamic read-write container residing in memory.

[0120] Based on the aforementioned dual-layer storage architecture, the system, when performing retrieval operations, is not limited to a single storage space. Instead, it utilizes the index key value to initiate retrieval requests to both the base bitmap layer and the incremental bitmap layer to obtain multiple conditional bitmaps at different levels corresponding to the index key value. Specifically, the system employs multi-threading or asynchronous I / O technology to perform parallel retrieval in both the base bitmap layer and the incremental bitmap layer. Through this parallel mechanism, the system can obtain bitmap data at different levels corresponding to the index key value from both historical fixed data and real-time changed data dimensions. The advantage of this retrieval method is that it concurrently processes the time-consuming base data reading and the highly real-time incremental data reading, effectively reducing overall retrieval latency and providing a complete basic data source for subsequent fusion of historical data and real-time changed data. This allows for real-time awareness of rule changes without blocking read requests.

[0121] Building upon the aforementioned dual-layer storage architecture, this application further refines the data structure of the incremental bitmap layer to better manage the rule lifecycle, particularly addressing data consistency issues caused by rule decommissioning or changing rules. Specifically, the incremental bitmap layer is not a single storage container but comprises two independently maintained bitmap objects: one is an addition bitmap, specifically used to record newly added rule matching relationships within the current time window; the other is a removal bitmap, specifically used to record rule matching relationships that have been removed or expired within the current time window.

[0122] Based on this refined storage structure, when the system obtains the final condition bitmap that can be used for computation, it executes a "read-time merging" logical strategy, which specifically includes steps S31 to S33:

[0123] S31. Using the index key value, obtain the baseline state bitmap in the base bitmap layer, and obtain the newly added state bitmap and the removed state bitmap in the incremental bitmap layer respectively.

[0124] Specifically, the system uses the aforementioned generated index key value as a unified retrieval credential. During the parallel retrieval process, it reads the baseline state bitmap representing historical snapshot data from the base bitmap layer. Simultaneously, the system retrieves the newly added state bitmap and the removed state bitmap associated with the index key value from the memory container of the incremental bitmap layer. It should be noted that these three bitmaps are physically independent; they represent the rule-related states of the same attribute value at different time dimensions.

[0125] S32. Perform bitwise AND-NOT operations on the reference state bitmap and the removal state bitmap to generate an intermediate bitmap that excludes failure rules.

[0126] After acquiring the aforementioned basic data, the system first processes the "rule invalidation" logic. Specifically, the system uses the baseline state bitmap as the operand and the removal state bitmap as the mask operand, performing a bitwise AND NOT operation (usually represented as Base & ~Removed). Through this operation, the system can force the binary bits corresponding to rule IDs that exist in the baseline state bitmap but also appear in the removal state bitmap to be set to 0 (i.e., cleared). The physical meaning of this step is to "subtract" currently offline or modified invalid rules from the historical full data, thereby generating a clean intermediate bitmap that excludes invalid rules.

[0127] S33. Perform a bitwise OR operation on the intermediate bitmap and the newly added state bitmap to generate the condition bitmap that integrates real-time change data.

[0128] After cleaning up the invalid data, the system proceeds to process the "rule addition" logic. Specifically, the system performs a bitwise OR operation (usually represented as Intermediate | Added) on the intermediate bitmap generated in step S32 and the newly added status bitmap obtained in step S31. This operation merges the binary bits corresponding to the newly added rule IDs within the current time window into the bitmap. Finally, the bitmap generated by the operation is the condition bitmap that integrates historical data and real-time change data.

[0129] To illustrate the merging process more clearly, let's assume that for the index key value "Key=100" (representing "location: Wuhan"), the system retrieves the following data:

[0130] Base state bitmap: {Rule_1, Rule_2, Rule_3}, binary representation is ...0111.

[0131] The removed status bitmap (Removed): {Rule_2}, represented in binary as ...0010. This indicates that the operations team has just removed the applicable cities for Rule_2 from "Wuhan".

[0132] Added status bitmap: {Rule_5}, binary representation is ...10000. This indicates that the operations team has just launched a new rule, Rule_5, which applies to "Wuhan".

[0133] The system's calculation process is as follows:

[0134] Execute S32 (AND NOT): Calculate {Rule_1, Rule_2, Rule_3} - {Rule_2}, i.e., ...0111& (~...0010), resulting in {Rule_1, Rule_3} (intermediate bitmap). At this point, the invalid Rule_2 is successfully removed.

[0135] Execute S33 (OR): Calculate {Rule_1, Rule_3} | {Rule_5}, which is ...0101 | ...10000, resulting in {Rule_1, Rule_3, Rule_5}.

[0136] The result {Rule_1, Rule_3, Rule_5} is the final generated condition bitmap, which accurately reflects the set of real rules corresponding to "Key=100" at the current moment. In this way, this application achieves millisecond-level precise awareness of rule changes without modifying the underlying base file or requiring global locking.

[0137] In another embodiment, this application also provides an implementation scheme based on a single-layer static index. This scheme is generally suitable for business scenarios with low rule change frequency but extremely high query performance requirements (e.g., offline batch processing scenarios where rules are only fully updated once a day at midnight).

[0138] In this embodiment, the rule bitmap index library does not adopt the "base + incremental" two-layer read-write separation architecture in the previous embodiments, but is constructed as a single-layer global memory mapping structure (e.g., a BitSet based on Redis or a Map in memory).<Integer, Bitmap> (Structure). In this structure, all rule matching data (new or old) is merged and stored in the same global bitmap object.

[0139] Based on this architecture, the execution process of step S30 is a direct key-value lookup operation: the system directly uses the index key as the lookup key to perform a match in the single-layer global memory mapping structure. If the key is matched, the system directly returns the globally unique bitmap corresponding to the key as the condition bitmap, without performing the parallel retrieval or multi-layer data merging operations in the aforementioned embodiments.

[0140] It should be noted that although this single-layer retrieval mode is simpler in terms of the reading process (requiring only one memory address), it usually requires a write lock or full reload of the entire global bitmap object when facing rule changes. Therefore, its performance in "high-concurrency read / write" scenarios is weaker than the aforementioned two-layer architecture implementation. However, this implementation still fully utilizes the efficient retrieval characteristics of bitmap indexing, enabling rapid retrieval of the condition bitmap and supporting subsequent bit logic operations.

[0141] S40. Perform bit logic combination operations on the multiple condition bitmaps to generate a matching result bitmap.

[0142] After obtaining multiple condition bitmaps corresponding to different business rule dimensions through the aforementioned steps, the system needs to perform bit logic combination operations on these bitmaps according to the Boolean relationship defined by the business logic (usually a logical "AND" relationship, which requires the target object to meet all conditions at the same time).

[0143] Specifically, the system will perform bitwise AND operations in the natural order defined by the rules (e.g., condition A → condition B → condition C).

[0144] In scenarios involving massive amounts of data, the filtering rates vary significantly depending on the conditions. Processing a large, dense bitmap first generates a huge intermediate result set, leading to high CPU load and memory bandwidth consumption in subsequent operations. To address this computational waste, in some preferred embodiments, the system employs a dynamic execution plan generation mechanism based on "data sparsity." Specifically, this includes steps S41 to S43:

[0145] S41. Obtain the cardinality statistical features of each of the plurality of condition bitmaps, wherein the cardinality statistical features characterize the number of set elements contained in the corresponding condition bitmap.

[0146] Before performing specific bitwise operations, the system first quickly obtains the cardinality statistics of each conditional bitmap to be involved in the operation by accessing the metadata interface of the bitmap object (such as the getCardinality() method in Roaring Bitmap). The cardinality statistics are an integer value that precisely represents how many binary bits in the bitmap are set to 1 (i.e. how many rules contain the current attribute value).

[0147] It is worth noting that since modern compressed bitmap structures typically maintain a counter in the header, the operation of obtaining cardinality features is usually a lightweight operation with O(1) complexity, which consumes almost no computational resources.

[0148] S42. Based on the cardinality statistical characteristics, sort the operation priorities of the multiple condition bitmaps in ascending order to generate an execution plan sequence.

[0149] The system reorders the aforementioned conditional bitmaps according to the principle of "sparseness first". Specifically, the smaller the cardinality (i.e., the sparser the bitmap), the higher its operation priority and the earlier its position in the execution plan sequence; the larger the cardinality (i.e., the denser the bitmap), the later its position.

[0150] S43. Based on the execution plan sequence, perform bitwise AND operations on the plurality of condition bitmaps in sequence to generate the matching result bitmap.

[0151] The system performs bitwise AND operations sequentially according to the rearranged sequence. Specifically, the system first computes the sparsest bitmap (e.g., a bitmap containing only 5 rules), immediately limiting the cardinality of the resulting "intermediate result bitmap" to within 5. In subsequent computations, even if the subsequent bitmaps are very dense (e.g., containing 1 million rules), the CPU only needs to perform a small number of bit probes or intersection operations based on this extremely small "intermediate result bitmap," without having to traverse the dense large bitmap.

[0152] Ultimately, each bit index in the resulting matching bitmap represents the ID of a target rule that the target object has matched.

[0153] For example, suppose the target object needs to satisfy three attribute conditions simultaneously, and the corresponding bitmap and cardinality are as follows:

[0154] Bitmap A (Gender = Male): Base number 5,000,000 (extremely dense).

[0155] Bitmap B (City = Wuhan): Base number 500,000 (Medium).

[0156] Bitmap C (Membership Level = Black Diamond): Base number 100 (extremely sparse).

[0157] The operation logic in this embodiment is as follows when generating the matching result bitmap:

[0158] 1. C & B: First, process the sparsest C. Since C only has 100 points, the bitmap library (such as RoaringBitmap) will automatically use an efficient array binary search or hash search to quickly verify these 100 points from B. The generated intermediate results will have a maximum of 100.

[0159] 2. Result & A: Only the remaining <100 points need to be used to verify in A.

[0160] In this way, the intermediate result set quickly converges to a very small size in the first step, which greatly reduces the number of CPU instruction cycles and L1 / L2 cache usage in subsequent steps, thereby achieving an order-of-magnitude improvement in matching performance.

[0161] In another embodiment, this application also supports bit logic combination operations based on a fixed order. In this embodiment, the system does not perform cardinality statistics or reordering operations, but directly loads the condition bitmap and inputs it into the logic operation pipeline according to the order of expressions defined by business rules (e.g., the order of WHERE conditions in SQL statements) or the parsing order of multidimensional attribute data in the message. Although this implementation may be less computationally efficient than the aforementioned embodiments when dealing with datasets with huge cardinality differences, its advantage lies in its simple implementation logic, the absence of additional metadata query overhead, and its suitability for lightweight scenarios where the rule data is relatively evenly distributed or where latency is extremely sensitive (or even where sorting time is undesirable).

[0162] S50. Based on the matching result bitmap, determine the target rule that the target object is matched by.

[0163] Specifically, after the bit logic combination operation in step S40, the system generates a final matching result bitmap. The state of each binary bit in this bitmap clearly indicates whether the target object meets the corresponding business rules.

[0164] In this step, the system parses the matching result bitmap to output the final business result. Specifically, the system calls the efficient iteration interface of the bitmap container (such as the Iterator or nextSetBit method) to traverse all the set index positions in the matching result bitmap. Then, the system extracts the integer index of each set point, which corresponds to the unique rule identifier (Rule ID) in the rule base. The system encapsulates the extracted Rule IDs into a list or set and returns them as the response data for this matching request to the upstream business system.

[0165] Thanks to the underlying structure of compressed bitmaps (such as Roaring Bitmap), the traversal process is not a linear scan of all bits, but skips all "0" value regions and directly locates the container or position where the "1" value is located.

[0166] To further optimize the storage efficiency of massive rule indexes in memory, especially in large-scale scenarios involving hundreds of millions of rules, this application embodiment has implemented a special compression design for the underlying data structure of the rule bitmap index library.

[0167] In some embodiments, the regular bitmap index library does not use a traditional single fixed bitmap (such as JavaBitSet), but is built based on a hierarchical compressed bitmap structure, preferably using Roaring Bitmap or a variant structure that is isomorphic to it.

[0168] The core design concept of this compressed bitmap structure lies in splitting the 32-bit integer index key into two parts: high-bits and low-bits. The high-bits are used to locate specific "chunks" or "buckets," while the low-bits are stored in specific containers. To accommodate data with different distribution characteristics, this structure integrates three storage containers with different physical forms:

[0169] 1. Array Container: Used to store sparse data. When the number of bits in a block is small (e.g., less than 4096), the system directly uses an ordered short integer array (short[]) to store the specific values.

[0170] 2. Bitmap Container: Used to store dense random data. When the number of set elements in a block is large (e.g., more than 4096) and their distribution is relatively discrete, the system uses a raw bitmap of a fixed size (e.g., 8KB) to directly map the data.

[0171] 3. Run Container: Used to store continuous data. When the system detects that there are a large number of continuous integer sequences in the data (e.g., 10, 11, 12, ..., 100), it uses Run-Length Encoding (RLE) to store them, that is, only the "starting value + length" (e.g., <10, 90>) is stored.

[0172] It is particularly noteworthy that the rule-based bitmap index library described in this application possesses an adaptive container selection mechanism. Specifically, the rule-based bitmap index library is configured to: during the data writing process, monitor the distribution characteristics of index key values ​​in real time, and automatically switch the storage format to the run container in response to the numerical continuity characteristics exhibited by the index key values ​​in the integer index space.

[0173] This adaptive mechanism forms a key technical synergy with the topological dimensionality reduction mapping (such as Z-order encoding) in step S20 of this application. As mentioned earlier, through topological dimensionality reduction mapping, objects with similar attributes in multidimensional space (e.g., a series of rules with amounts in [100, 200] and times within three days) are mapped to a set of highly continuous integer index keys. When this set of continuous index keys is written to the rule bitmap index library, the index library's writing engine recognizes this continuity artificially "manufactured" by the encoding algorithm, thereby triggering internal heuristic rules to force the selection of a run-length container for storage.

[0174] By employing the combined strategy of "topology encoding + run-length container," compared to using only array containers or bitmap containers, run-length containers can further compress storage space by an order of magnitude when processing continuous data generated by topology mapping (e.g., compressing 1000 consecutive integers from 2KB to only 4 bytes). This not only significantly reduces memory footprint, but more importantly, because the data structure of run-length containers is extremely compact, it can reside in the CPU's L1 / L2 cache for a long time, thereby significantly improving memory throughput and computation speed when performing subsequent bitwise AND / OR operations.

[0175] In actual business scenarios (such as large-scale promotional events), there are often a large number of users with completely identical attributes (e.g., all are "Wuhan region + Gold Member + Spending > 1000"). For these users, the matching result bitmap is completely identical. To avoid repeatedly executing the encoding and calculation process S20-S40 for every identical request, the system executes the following "result caching and reuse" process, which includes the following steps S61-S63:

[0176] S61. Generate a hash signature for the matching result bitmap.

[0177] The system performs a hash calculation (e.g., using MD5, SHA-256, or CRC64 algorithms) on the bitmap of the matching result generated in step S40 to generate a unique hash signature. This signature serves as the digital fingerprint of the "rule combination result". Through this hash signature, the system achieves addressing of the "matching result content", rather than addressing the "user".

[0178] S62. The hash signature, the matching result bitmap, and the attribute identifier of the target object are associated and stored in the cache space, wherein the attribute identifier is parsed from the matching request.

[0179] Specifically, the system writes the relevant data to a distributed cache (such as Redis) or a local heap cache (LocalCache), establishing the following mapping relationship:

[0180] 1. Index Mapping (Signature → Result): Establishes a mapping between the hash signature and the matching result bitmap (or the parsed list of Rule IDs). If the result with the signature already exists in the cache, it does not need to be stored again, thus achieving deduplication of result data storage.

[0181] 2. Attribute association (AttributeID → Signature): The attribute identifier of the target object (e.g., RequestID or a combination key of UserID + ContextID parsed from the request) is associated and stored with the hash signature.

[0182] S63. In response to a subsequent receiving of a matching request with the same attribute identifier, the cache space is retrieved according to the attribute identifier. If a corresponding target hash signature is found, the cache matching result corresponding to the target hash signature is returned directly.

[0183] Specifically, in response to subsequent matching requests with the same attribute identifier (e.g., the same user refreshing the page within a short period of time, or different users with exactly the same attribute characteristics initiating requests), the system executes the following logic:

[0184] 1. Retrieve cache space directly based on the attribute identifier in the request.

[0185] 2. If a corresponding target hash signature is found, the corresponding cache matching result is obtained based on the hash signature.

[0186] 3. The system directly returns the cached result, thus skipping all subsequent attribute encoding, bitmap retrieval, and bit logic operation steps.

[0187] Through the aforementioned caching mechanism, this application achieves the technical application of "compute once, serve multiple times." Thus, in concurrent scenarios with a large number of homogeneous requests, this mechanism significantly reduces the CPU's computational load and further compresses system response time from milliseconds to microseconds.

[0188] As can be seen from the above embodiments, the bitmap-index-based object matching method of this application has the following beneficial effects:

[0189] 1. Ultra-fast response and linear scalability

[0190] This application abandons the traditional B+ tree query of databases or the expression parsing mode of rule engines, transforming complex multidimensional object matching into the most efficient bit-logic combination operations at the computer's underlying level. This not only significantly reduces rule matching latency but also prevents the latency from increasing exponentially with the increase in rule dimensions, effectively solving the performance bottleneck problem in large-scale business scenarios. Simultaneously, the deterministic computation based on bitmaps guarantees 100% matching accuracy, avoiding the misjudgment risk of Bloom filter schemes.

[0191] 2. Ultimate optimization of storage space and caching efficiency

[0192] This application transforms "Euclidean proximity" in a multidimensional attribute space into "numerical continuity" in a one-dimensional index space through topological mapping. This maximizes the activation of the run-length encoding (RLE) mechanism in the underlying storage structure, enabling sparse high-dimensional data to be stored with an extremely high compression ratio. This not only significantly reduces memory usage but also allows core index data to reside in the CPU's L1 / L2 cache for extended periods, significantly improving memory throughput and computation speed.

[0193] 3. Lock-free real-time updates in high-concurrency scenarios

[0194] To address the "read-write mutual exclusion" problem caused by the need for global locking during rule updates in existing technologies, this application adopts a two-tier storage architecture that separates basic and incremental memory layers. Through a read-time merging strategy, the system isolates rule change operations within a lightweight incremental memory layer. This allows the system to provide non-blocking, low-latency real-time matching and reading services while handling frequent rule updates and shutdowns, perfectly supporting dynamic operational needs such as those during major e-commerce promotions.

[0195] 4. Computational pruning based on data distribution

[0196] This application prioritizes the computation of highly sparse conditional bitmaps, leveraging the "short-circuit effect" of bitwise operations to enable the system to rapidly converge the size of the intermediate result set in the early stages of computation. This avoids invalid traversals of dense bitmaps, significantly reducing the number of CPU instruction cycles and achieving intelligent savings in computing power.

[0197] 5. Automatic deduplication of hotspot traffic

[0198] By introducing a result caching mechanism based on hash signatures, the system achieves addressing of "content" rather than "user ID". In this way, when faced with sudden surges in traffic or a large number of homogeneous requests, the system can directly reuse the calculated matching results, reducing the processing complexity of some requests to O(1) and greatly improving the overall throughput of the system.

[0199] Furthermore, embodiments of this application also provide a computer-readable storage medium (or a non-volatile computer-readable storage medium) storing a computer program (or instructions). When the computer program is executed by a processor, it implements the various steps in the above-described embodiments of the bitmap-index-based object matching method. The computer-readable storage medium may include any medium capable of storing program code, including but not limited to: read-only memory (ROM), random access memory (RAM), magnetic disk, optical disk, flash memory, hard disk (HDD), or solid-state drive (SSD). This storage medium may exist independently or be integrated into a processor or server.

[0200] The embodiments described herein may be provided as methods, systems, or computer program products. Therefore, this application may be implemented entirely in hardware, entirely in software, or a combination of hardware and software. Furthermore, this application may also be embodied as a computer program product implemented on one or more computer-readable storage media (including but not limited to disk storage, optical storage, flash memory, etc.).

[0201] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this embodiment. It should be understood that each flow, block, and combination thereof in the flowchart illustrations and / or block diagrams can be implemented by computer program instructions. These instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device for execution, thereby producing a machine for implementing a specified function. Simultaneously, these instructions can also be stored in a computer-readable storage medium or loaded onto a computer device, causing the device to perform a series of operational steps to produce a computer-implemented process.

[0202] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. If such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. An object matching method based on bitmap indexing, characterized in that, include: In response to receiving a matching request for a target object, obtain the multidimensional attribute data of the target object; Based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space; Using the index key value, a search is performed in the pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules respectively; Perform bit logic combination operations on the multiple condition bitmaps to generate a matching result bitmap; Based on the matching result bitmap, the target rule that the target object is matched with is determined.

2. The object matching method based on bitmap index as described in claim 1, characterized in that, Based on a preset encoding mapping definition, the multidimensional attribute data is converted into index key values ​​in an integer index space, including: Obtain at least one continuous numerical attribute contained in the multidimensional attribute data; Based on the preset interval discretization rules, the target numerical interval to which the continuous numerical attribute belongs is determined; Extract the interval identifier code of the target numerical interval, and use the interval identifier code as the discrete code of the continuous numerical attribute to construct a discrete feature vector; The discrete feature vectors are subjected to topological dimensionality reduction mapping to generate the index key values.

3. The object matching method based on bitmap index as described in claim 2, characterized in that, Performing topological dimensionality reduction mapping on the discrete feature vectors to generate the index key values ​​includes: Each discrete code in the discrete feature vector is converted into a fixed-length binary bit string; Based on the preset weight priority of each dimension, determine the positional distribution pattern of each dimension in the target index key value; According to the bit order distribution pattern, the bit values ​​to be processed in each of the binary bit strings are extracted sequentially, and bit interleaving operation is performed to fill the extracted bit values ​​to be processed into the corresponding positions of the target binary sequence. The filled target binary sequence is converted into a decimal integer to obtain the index key value that maintains the multidimensional spatial proximity.

4. The object matching method based on bitmap index as described in claim 1, characterized in that, The rule bitmap index library includes a base bitmap layer and an incremental bitmap layer. The base bitmap layer is used to store rule matching data that has been fixed in historical time, and the incremental bitmap layer is used to store rule change data that has occurred in the current time window. A search is performed in a pre-built rule bitmap index library to obtain multiple condition bitmaps corresponding to multiple candidate rules, including: Using the index key value, parallel searches are performed in the base bit layer and the incremental bit layer respectively to obtain multiple condition bitmaps at different levels corresponding to the index key value.

5. The object matching method based on bitmap index as described in claim 4, characterized in that, The incremental bitmap includes a new bitmap for recording newly added rule matching relationships and a removed bitmap for recording removed rule matching relationships; Using the index key value, parallel searches are performed in the base bit layer and the incremental bit layer respectively to obtain multiple condition bitmaps at different levels corresponding to the index key value, including: Using the index key value, a baseline state bitmap is obtained in the base bit layer, and a newly added state bitmap and a removed state bitmap are obtained in the incremental bit layer, respectively. Perform a bitwise AND-NOT operation on the reference state bitmap and the removal state bitmap to generate an intermediate bitmap that excludes failure rules; Perform a bitwise OR operation on the intermediate bitmap and the newly added state bitmap to generate the condition bitmap that integrates real-time change data.

6. The object matching method based on bitmap index as described in claim 1, characterized in that, Performing bitwise logic combination operations on the multiple condition bitmaps to generate a matching result bitmap includes: Obtain the cardinality statistics of each of the plurality of condition bitmaps, wherein the cardinality statistics represent the number of set elements contained in the corresponding condition bitmap; Based on the cardinality statistical characteristics, the operation priorities of the multiple condition bitmaps are sorted in ascending order to generate an execution plan sequence; Based on the execution plan sequence, bitwise AND operations are sequentially performed on the multiple condition bitmaps to generate the matching result bitmap.

7. The object matching method based on bitmap index as described in claim 4, characterized in that, The rule-based bitmap index library is built upon a compressed bitmap structure, which includes an array container for storing sparse data, a bitmap container for storing dense data, and a run-length container for storing continuous data; wherein... The rule bitmap index library is configured to: adaptively select the run container to store continuous index key values ​​in response to the numerical continuity characteristics exhibited by the index key values ​​in the integer index space, wherein the numerical continuity characteristics are obtained by transforming the multidimensional attribute data through topological dimensionality reduction mapping.

8. The object matching method based on bitmap indexing as described in any one of claims 1 to 7, characterized in that, After generating the matching result bitmap, the object matching method further includes: Generate a hash signature for the matching result bitmap; The hash signature, the matching result bitmap, and the attribute identifier of the target object are associated and stored in the cache space, wherein the attribute identifier is parsed from the matching request; In response to a subsequent matching request with the same attribute identifier, the cache space is retrieved based on the attribute identifier. If a corresponding target hash signature is found, the cache matching result corresponding to the target hash signature is returned directly.

9. An object matching device based on bitmap indexing, characterized in that, The method includes a memory, a processor, and a bitmap-indexed object matching program stored in the memory and executable on the processor. When the processor executes the bitmap-indexed object matching program, it implements the bitmap-indexed object matching method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a bitmap-indexed object matching program, which, when executed by a processor, implements the bitmap-indexed object matching method as described in any one of claims 1-8.

Images