Key-value caching system and method

Abstract

A computer-implemented key-value caching system is provided. The system is configured to store key-value pairs and to process commands received from at least one client. The system includes a plurality of dictionaries, with each dictionary having at least a section of memory allocated in the system. Each value belongs to one of a plurality of data types, each given data type of the plurality of data types is associated with one dictionary of the plurality of dictionaries, each dictionary is configured to enforce atomicity, and the system is configured to ensure that the plurality of keys comprises only unique keys. Some dictionaries can be configured to store metadata about each key-value pair.Some dictionaries can be configured to use different memory policies.

Description

KEY-VALUE CACHING SYSTEM AND METHOD

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This is the first application related to the present disclosure.TECHNICAL FIELD

[0003] The technical field relates to key-value caches, and more specifically to key-value caching systems including a plurality of dictionaries and associated methods.BACKGROUND

[0004] In distributed key-value (KV) caching systems, where multiple processes or clients operate simultaneously, ensuring mutual exclusion becomes crucial. Mutual exclusion refers to the property that only one process can access a shared resource at any given time. Without proper coordination, concurrent access to shared resources can lead to data corruption, inconsistent states, and race conditions, making it challenging to maintain data integrity and produce predictable results.

[0005] Therefore, atomicity plays a critical role in addressing these challenges by providing a mechanism for coordinating access to shared resources. By employing atomicity, processes can signal their intention to use a particular resource exclusively, ensuring that no other process can access it until the current process is finished. This guarantees that only one process can perform critical operations on the shared resource at a time, avoiding conflicts and preserving data integrity.

[0006] Distributed KV caching system is commonly used for building high-speed, scalable, and reliable applications. These cache systems enable data to be stored in temporary memory, greatly reducing data access times. By providing a rich set of data types that go beyond simple key-value pairs and a comprehensive set of commands to interact with its data structures and perform various operations, distributed KV caching system becomes a good candidate for high-performance computing, real-time analytics, content delivery networks (CDNs) , and distributed systems.

[0007] Among the various data types, the data types that are more likely to contribute to higher latency or slower performance are the ones that involve more complex operations or require additional processing. For example, sorted sets involve additional processing due to the need to maintain the ordering of elements based on their associated scores. When performing operations like range queries or retrieving elements by rank or score, the KV caching system needs to perform sorting and ranking operations, which can take more time compared to simpler data types. Additionally, data types such as hashes or lists can also experience higher latency when dealing with large numbers of fields or elements. The time required to process and retrieve multiple fields within a hash can be slightly higher compared to simpler data types.

[0008] Therefore, due to the nature of atomicity in distributed KV caching systems, the data types that are more likely to contribute higher latency, may end up with causing performance fluctuations to an application, or even a short period of downtime.

[0009] Therefore, there is a need for a KV caching system that is capable of enforcing atomicity without the processing of complex data types creating a bottleneck that negatively affects the performance of the system.SUMMARY

[0010] The present disclosure is directed to a key-value caching system that addresses the bottleneck problem by relying on a plurality of dictionaries having at least a section of memory allocated in the system. Each data type is associated with one dictionary, such that atomic operations performed in one dictionary does not affect the performance of the other dictionaries.

[0011] In accordance with an aspect, a method for operating a computer-implemented key-value caching system is provided. The method includes receiving, by a server, a command from a client, parsing, by the server, the command into components, the components including at least a command name and a target key, based on the command name and / or the target key, determining, by the server, a data type associated with the command, determining, by the server, a dictionary data structure associated with the data type, sending the command from the server to the dictionary data structure, and processing the command by the dictionary data structure.

[0012] In accordance with another aspect, a computer-implemented key-value caching system is provided. The system is configured to store a plurality of values associated with a corresponding plurality of keys and to process commands received from at least one client. The system includes a plurality of dictionaries, each dictionary data structure having at least a section of memory allocated in the system. In the system, each value belongs to one of a plurality of data types, each given data type of the plurality of data types is associated with one dictionary data structure of the plurality of dictionary data structures, each dictionary data structure is configured to enforce atomicity, and the system is configured to ensure that the plurality of keys comprises only unique keys.

[0013] In accordance with a further aspect, a server for operating a computer-implemented key-value caching system is provided. The server includes a memory for storing instructions and a processor configured to execute the instructions. Executing the instructions configures the processor to receive a command from a client, parse the command into components, the components including at least a command name and a target key, based on the command name and / or the target key, determine a first data type from a plurality of data types associated with the command, determine a first dictionary data structure associated with the first data type from a plurality of dictionary data structures, and forward the command to the first dictionary data structure.BRIEF DESCRIPTION OF THE DRAWINGS

[0014] For a better understanding of the embodiments described herein and to show more clearly how they may be carried into effect, reference will now be made, by way of example only, to the accompanying drawings which show at least one exemplary embodiment.

[0015] Figures 1 and 2 are schematics of a key-value caching system, in accordance with an embodiment.

[0016] Figure 3 is a flowchart of a method implemented in a key-value caching system, in accordance with an embodiment.DETAILED DESCRIPTION

[0017] It will be appreciated that, for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements or steps. In addition, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practised without these specific details. In other instances, well-known methods, procedures and components have not been described in detail so as not to obscure the embodiments described herein. Furthermore, this description is not to be considered as limiting the scope of the embodiments described herein in any way but rather as merely describing the implementation of the various embodiments described herein.

[0018] In the present disclosure, the terms “a” or “an” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0019] In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an example embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of the example embodiment for its intended application.

[0020] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0021] In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching the two elements but also “substantially” , “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

[0022] In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the  expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

[0023] In the present disclosure, the terms “system” and “network” may be used interchangeably in different embodiments of this application. “At least one” means one or more, and “a plurality of” means two or more. The term “and / or” describes an association relationship of associated objects, and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character “ / ” indicates an “or” relationship between associated objects. “At least one of the following items (pieces) ” or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, “at least one of A, B, or C” includes: only A; only B; only C; A and B; A and C; B and C; or A, B, and C, and “at least one of A, B, and C” may also be understood as including: only A; only B; only C; A and B; A and C; B and C; or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as “first” and “second” in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0024] With reference to figure 1, an exemplary environment for a computer-implemented key-value (KV) caching system is depicted, including caching system device 100, which implements the KV caching system. The device 100 may be in communication with a client computing device 50 via one or more communication links 51, 101, including wired and / or wireless communication links, combinations thereof, links which traverse one or more networks, including local area networks, wide-area networks, the internet, and the like.

[0025] The devices 50 and 100 may be any suitable computing devices, such as, but not limited to, mobile computing devices such as phones, smart phones, tablets, laptop computers, handheld and / or wearable devices, and the like, or fixed computing devices, such as desktop computers, servers, kiosks, and the like.

[0026] The devices 50 and 100 each includes at least one processor 52, 102, memory 53, 103 and a communications interface 51, 101.

[0027] The processors 52 and 102 may include a central processing unit (CPU) , a microcontroller, a microprocessor, a processing core, a field-programmable gate array (FPGA) , a graphics processing unit (GPU) , or similar. The processors 52 and 102 may include multiple cooperating processors. The processors 52 and 102 may cooperate with the memories 53 and 103 to realize the functionality described herein.

[0028] The memories 53 and 103 may include a combination of volatile (e.g., Random Access Memory or RAM) and non-volatile memory (e.g., read-only memory or ROM, Electrically Erasable Programmable Read Only Memory or EEPROM, flash memory) . All or some of the memories 53 and 103 may be integrated with the processors 52 and 102. The memory can store data 54 and 104 as well as applications 55 and 105, each including a plurality of computer-readable instructions executable by the processors 52 and 102. The execution of the instructions by the processors 52 and 102 configures the devices 50 and 100 to perform the actions discussed herein. In particular, the applications 55 and 105 stored in the memory 105 can include applications to perform command parsing and processing. When executed by the processors 52 and 102, the applications 55 and 105 configure the processors 52 and 102 and / or the devices 50 and 100 to perform various functions discussed in greater detail below.

[0029] With reference to figure 2, an exemplary computer-implemented KV caching system 100 is depicted. Broadly described, the system 100 is configured to receive commands from clients 50a-b, to parse and pre-process the commands, and to dispatch each command to an appropriate dictionary 130a-c based on data type. In some embodiments, every data type, such as string, hash and list, has and manages its own unified cache dictionary for processing its own keys. In some embodiments, each one of these cache dictionary has a unified lock to process its own type keys one at a time, enforcing uniqueness to maintain data consistency for its own data type.

[0030] It can be appreciated that either the system 100 can be implemented on a single computing device or it can be implemented across a plurality of devices that share the processing among them.

[0031] In some embodiments, the client devices 50a, 50b interface with key-value databases through robust APIs, which provide a wide range of functionalities for data manipulation and retrieval. As an example, the system 100 can offer APIs available in one or more programming languages, enabling seamless integration with different application environments. These APIs can allow developers to perform operations such as setting and getting values, managing data structures, executing transactions, and  performing pub / sub messaging. For instance, a client application can interact with the system 100 through a RESTful API or a direct client library, sending commands such as “SET” to store data and “GET” to retrieve data. The APIs can support asynchronous operations, which can be leveraged to build high-performance applications that handle multiple requests concurrently. Additionally, the system 100 can support scripting, using a purpose-built scripting language or an existing language such as Lua, allowing complex operations to be executed atomically within the system 100.

[0032] In some embodiment, system 100 is implemented a cache server 110 that is configured to accept connections from clients 50a-b and to read commands from the connections. As an example, system 100 can operate as an in-memory server that clients can connect to over a network. Clients send commands to the server 110, which can process the commands and returns the results. This architecture can support high concurrency and low latency, allowing for real-time applications.

[0033] In some embodiments, the cache server 110 operates as a gateway and passes commands received to a cache core 120, which can for instance include a distinct server and / or process configured for processing the commands. Each command can be inserted in a suitable data structure upon being received for individual processing by the cache core 120. Cache core can be responsible for analyzing each command. For instance, a command can correspond to a string indicating a command name and, as appropriate, a target key associated with the value of interest, one or more values to assiciate with the key and / or one or more arguments, and the cache core 120 can be configured to parse the command string to extract the command name, the key, the values and / or the arguments.

[0034] Each value stored in system 100 is associated with a data type. Data types refer to a classification related on the nature of data stored in memory, including possible values, operations, and storage format. In some embodiments, data types include primitive data types, including for instance strings, numbers, integers, real numbers and / or booleans. In some embodiments, data types also include complex, composite data types, e.g., associative and / or unordered containers, including for instance lists, arrays, vectors, ordered or unordered sets, multisets, hashes and / or maps. In some embodiments, data types can also include special data types such as streams, documents, geospatial data, binary blobs and / or bitmaps.

[0035] Each data type is further associated with a dictionary 130a-c. Therefore, processing a command associated with a KV pair, e.g., by the cache core 120, can include determining a type associated with the KV pair. In some embodiments, each command name can be associated with a data type, such that the command name can directly be mapped to the corresponding data type. As an example, command names “SET” and “GET” can be reserved for operations on strings, whereas command names “LPUSH” and “LPOP” can be used for operations on lists, and “HSET” and “HGET” for operations on hashes. In some embodiments, a data type can be provided as one of the parameters of a command. In some embodiments, the data type can be implicitly deduced based on the value. In some embodiments, the cache core can store a mapping from keys to data types, such that when a new KV pair is created by a command, the mapping can be updated to reflect the type of the new value associated with the new key.

[0036] In some embodiments, when processing a command such as “SET” that is directed to creating a new KV pair, the cache core 120 is configured to check whether the key already exists in one of the dictionaries 130a-c. If the key already exists, the cache core 120 can abort processing the command and signal to the cache server 110 to send an error message to the client that issued the command. In some embodiments, either the cache core 120 or each dictionary 130a-c is configured to maintain a data structure such as a set or a hashing comprising all the existing keys, respectively in the system or in each dictionary. In some embodiments, the data structure is a probabilistic data structure, for instance configured to ensure that no false negatives occur when verifying whether a key exists. In some embodiments, a Bloom filter is used, advantageously reducing the required memory resources. In some embodiments, the Bloom filter can be configured with configurable parameters to allow for the desired tradeoff between memory usage reduction and error rate.

[0037] The system 100 includes a plurality of dictionaries 130a-c. In some embodiments, a dictionary corresponds to or includes a data structure, for instance any data structure suitable for storing a number of values as well as a mapping between a corresponding number of keys and the values. Accordingly, a dictionary can be referred to as a dictionary data structure. In some embodiments, the dictionary data structure is an in-memory data structure, i.e., it is stored in volatile memory such as RAM to provide faster data access. It can be appreciated that the dictionary data structure can also store metadata, such as metadata related to the values stored in the dictionary. Values stored in the dictionary can correspond to any type that can be handled by the cache system 100. Keys associated with the dictionary can also correspond to one or more suitable data types. In some embodiments, some or all keys belong to a string datatype. In some embodiments, keys themselves are stored in the dictionary data structure. In some other  embodiments, the mapping from the keys to the values is stored in the dictionary data structure without actually storing the keys. Although each data type is associated with one dictionary, in some embodiments, it is possible for one, some or all the dictionaries to be associated with more than one data type. As an example, some or all primitive data types could be associated with one dictionary that is not further associated with any complex or composite data type. Because processing complex or compositve data type can be associated with bottlenecks, a dictionary handling only primitive data types will be able to operate at optimal speed. Figure 2 depicts an example with three dictionaries, but it is appreciated that system 100 can be provided with any suitable number of dictionaries greater than or equal to two and less than or equal to the number of implemented data type. Each dictionary 130a-c can run as a process on the computing device or one of the devices implementing the system 100, or can be distributed among more than one devices of the system 100. Each dictionary 130a-c is allocated at least a section of memory in the system to store values 134a-c associated with keys 132a-c in such a way that, given a key 132a1-132c3, the dictionary is capable of retrieving the corresponding value 134a1-134c3. It can be appreciated that this can be achieved in different ways, for instance by storing the keys 132a-c in a suitable data structure such as an index, or not storing the keys 132a-c and using a different suitable data structure such as a hash table. In some embodiments, different dictionaries can implement different storage and retrieval means.

[0038] In some embodiments, one, some or all the dictionaries can also store metadata 136a-c related to each KV pair to speed up the execution of certain commands. As an example, a dictionary storing composite values such as hashes, lists or sets can store the length of each value as part of metadata 136a-c, such that when a command requesting the length of a value is issued, e.g., “HLEN” , the value does not need to be retrieved. As another example, a dictionary storing lists can store the first and / or last index, and / or head and tail values of the list as part of metadata 136a-c, such that when a command requesting a specific item in the list is issued, e.g., “LPOP” , the specific desires value can be retrieved without list traversal. In some embodiments, metadata 136a-c can include metadata adapted to enforcing eviction policies, such as a creation timestamp, an access timestamp, a modification timestamp and / or an expiration timestamp, and / or an access counter associated with each KV pair.

[0039] In some embodiments, each dictionary 130a-c can have its own memory management policies 138a-c, providing end users with a finer grained control to cache behaviour. As an example, individual policies 138a-c make it possible for end users to independently assign memory space to each data type and set up field eviction policy, for instance only keeping a certain of hot fields according to business use case. Memory policies 138a-c can for instance be stored in files in the system 100, and either be accessed by each individual dictionary 130a-c upon initialization, or be accessed by the cache core 120 to parametrize the dictionaries upon initialization. In some embodiments, the policies 138a-c are stored in text files. A text file can include any number of parameter-value pairs. As an example, parameters can include “string-maxmemory” , “list-maxmemory” and “hash-maxmemory” , allowing to set distinct maximum memory usages for specific data types, “string-max-policy” , “list-max-policy” and “hash-max-policy” , allowing to define a strategy to obey the maximum memories, also named eviction rules, such as the “least recently used” , “first in, first out” , “least frequently used” , “random replacement” and / or “time-to-live” rules, enforcing the eviction of least recently used KV pairs to free space. As another example, parameters can include parameters relevant only to one or some data types, such as “hash-max-fields-per-key” to set a maximum number of fields cached for each stored hash or “list-max-elements-per-key” to set a maximum number of elements cached, i.e., a maximum length, for each stored list.

[0040] Advantageously, system 100 can implement atomicity at the dictionary level, thereby actually allowing the concurrent execution of commands so far as they are applied to different data types. Atomicity ensures that each individual operation is executed completely and indivisibly, ensuring that updates are fully applied or not applied at all, thereby maintaining data consistency without partial changes. In some embodiments, atomicity is enforced by each dictionary by processing strictly one command at a time, such that the n+1’th does not start executing before the n’th command is done executing. In some embodiments, an event loop for instance implemented in the cache core 120 can operate such that a state, e.g., “busy” or “not busy” is kept for each dictionary 130a-c, and such that a command directed to a “busy” dictionary at any one tick of the loop is passed over, nonetheless allowing commands directed to other dictionaries to be executed.

[0041] The system described above, allowing each data type to be independently managed as an unified cache dictionary where atomicity independently is enforced at the data type rather than at a whole key-level like existing solutions solves the problem of all key commands having to be processed serially caused by keys associated with larger objects such as large hashes, lists or sorted sets blocking all other operations, potentially contributing to service downtime for clients, which are major concerns in real-world, in-memory KV cache products. Furthermore, in some embodiments, system 100 allows keys for different data type to be migrated  in parallel from a source shard to a target shard, thereby reducing performance impact during cluster scaling, especially for larger objects such as large hashes, lists or sorted sets.

[0042] With reference to figure 3, an exemplary method 200 implemented in a key-value caching system is depicted. Broadly described, commands are received and first pre-processed at the server level so as to be dispatched to the appropriate dictionary data structure for processing. Key uniqueness can be enforced at server level, while atomicity can be enforced at dictionary level.

[0043] In an initial step 210, it can be necessary to initialize the caching system. The caching system can for instance be implemented as a daemon, a server, or another suitable type of software process. The main function of the software can include a function call, e.g., “loadServerConfigRule () ” , implemented to load a configuration parameters, for instance from a file, and a function call, e.g., “initServer () ” , implemented to initialize a plurality of dictionaries. As an example, the function “loadServerConfigRule () ” can open and parse a text file including memory space management rules and generate global parameters. As another example, the function “initServer () ” can instantiate a “Server” class including a “db” attribute that defines a mapping from a set of data types to a set of dictionaries. As an example, an enumeration type can associate each data type to an integer used to index the “db” attribute, such that each dictionary data structure can be initialized, e.g., with a method call like “server->db [i] ->initialize (i) ” , for each value “i” of the enumeration type, e.g., “STRING_TYPE” , “HASH_TYPE” , “LIST_TYPE” , etc. Dictionary initialization can also include parameterization based on the configuration loaded by the server, for instance by setting class attributes such as for example “server->db [i] ->maxmemory” and “server->db [i] ->eviction_policy” . Following this, the event loop 230 can be started to enable the server to accept client connections, for instance with a function call, e.g., “processClients () ” .

[0044] Once a connection to at least one client is established, in step 220, the server can listen to the connection in order to receive commands from the client. Every time a command is received, it is processed by the event loop 230.

[0045] The command is first pre-processed at the server level in step 240. Pre-processing includes parsing the command to extract information required to dispatch it to the proper dictionary data structure and to enforce key uniqueness. As an example, pre-processing the command can include calling a “processCommand () ” function. In particular, information extracted in step 240 can include the command name, the key, and the value. From the key and / or from the value, a data type is obtained, and the appropriate dictionary data structure, also called the target cache, is identified based on the data type. As an example, if the Redis protocol is used and the string “SET mykey "Hello" ” is received, the pre-processing step 240 can include extracting command name “SET” , key “mykey” and value “Hello” , and further inferring that the data type is the string type, and therefore that the appropriate dictionary data structure is, e.g., “server->db [STRING_TYPE] ” .

[0046] The server can be configured to enforce global key uniqueness is a subsequent step 250. Key uniqueness ensures that each entry in the cache system can be accurately identified and retrieved, preventing conflicts and data corruption, and enabling accurate storage, retrieval, and management of records. In some embodiments, the server can be configured to maintain a data structure comprising all the keys that have been set-or an indication thereof, for instance via a hash table or via a Bloom filter. As an example, a “checkKeyBloomFilter () ” function can be called. If the command “SET mykey "Hello" ” is received and the key “mykey” has already been set, an error message can be sent to the client and processing can be aborted, bypassing steps 260-290. In some embodiments, the data structure used to retain the known keys can be used to indicate the associated data type, or one data structure for each type can be maintained either by the server or by the dictionary, such that if “SET mykey "Hello" ” is received, a function such as “doesKeyExistsInOtherType () ” can be called as an example, ensuring that an error will be raised only if the key “mykey” has already been set in a data type other than the string type, thereby allowing for overwriting the value while still enforcing global key uniqueness.

[0047] Once the correct dictionary data structure has been selected and it has been determined that the command does not breach key uniqueness, in step 260, it can be sent to the selected dictionary for actual processing, e.g., to set, modify or delete a KV pair. As an example, a “Command () ” function or a more specialized function such as “hsetCommand () ” can be called to process the function, this command further calling an appropriate specialized processing function such as “dictSetVal () ” .

[0048] Contemporarily with step 260, step 270 can be performed by the selected dictionary to enforce its memory based on the command being processed in step 260. In some embodiments, the dictionary checks if necessary to take any action to optimize the memory space according to the config rules. As an example, if a dictionary responsible for handling hashes receive a command such as “HSET myhash field1 "Hello" ” . In some embodiments, the dictionary can use the memory space management rules to  control its cache behaviour as part of the eviction before further processing key command logic. With the help of rule parameters for each KV cache, an eviction check can be performed, as an example using a “isMaxMemoryOver () ” function call, to determine whether the cache dictionary is over its maximum memory allowed and / or would be if the command was executed without eviction. If this is the case, as an example, implementing an LRU eviction policy, five sampling keys can be randomly selected in the dictionary, the last accessed timestamp can be compared for these five samples, and the best key can be selected from among the five samples to be removed, e.g., by a “dictFreeKey () ” function call. Additionally, a check can be performed, as an example using a “isMaxFieldOver () ” , to determine whether the object, e.g., the hash, is above it maximum size allowed and / or would be if the command was executed without eviction. If this is the case, as an example, again implementing an LRU eviction policy, five sampling fields can be randomly selected in the hash, the last accessed timestamp can be compared for these five samples, and the best field can be selected from among the five samples to be removed, e.g., by a “removeField () ” function call.

[0049] In some embodiments, key metadata is maintained at runtime for one, some or all data type. This can require a further step 280 including updating the metadata. In some embodiments, the metadata maintenance logic is embedded within any key commands that need to keep tracking of the metadata by either updating or retrieving. As an example, in a dictionary storing hashes, both functions “hsetCommand () ” and “hdelCommand () ” can include a function call to a further function such as “updateMetadata () ” , configured to respectively increment and decrement a length metadata attribute associated with the key. As another example, any function call associated with a key can include a call to a further function “updateMetadata () ” , configured to update an expiration metadata attribute associated with the key. This makes it possible, when a command such as “HLEN” or “LLEN” is processed, to retrieve easily the stored length of the hash or list, without having to count the number of fields or elements at runtime as is implemented in currently existing KV cache systems.

[0050] Once the dictionary has processed the command, a reply can be generated and sent to the server in step 290, for forwarding to the client. Step 290 can also include sending an indication to the event loop 230 that the dictionary is ready to process a new command. In some embodiment, sending the reply to the server provides an indication of the dictionary being ready for a new command. As an example, a “Reply () ” command can be called to generate a reply to send to the server.

[0051] Certain currently existing KV cache systems are designed to have a single KV cache dictionary for managing all native data types, which helps customers solve a wide variety of problems, from caching, to queuing, to event processing. These systems guarantee cache data safety by mutual exclusion: at any given moment, only one client can process one command inside the single cache dictionary. In all these existing systems, though, if certain key commands contribute a very noticeable latency, other key commands will have no choice but waiting for them to complete, which will eventually cause serious performance fluctuations. For example, very large hash or list keys, e.g., with thousands of fields, contribute to a noticeable amount of latency.

[0052] In some currently existing KV cache systems, data is automatically sharded across multiple nodes. This means that each node only needs to store a subset of the total data, reducing the memory requirements per node and improving overall performance. With data sharding, these systems enable parallel processing and improved throughput. Multiple client queries can be handled in parallel by different nodes, increasing the overall throughput of the system. However, command operating on keys associated with large objects as mentioned above may be evenly distributed across the whole cluster which still makes every shard perform slow when working with those keys.

[0053] Certain currently existing KV cache systems rely on partitioning the keyspace of a local cache between threads so that each thread atomically processes command against its own slice. This relaxes the scope of lock, but is bound to the number of processors and / or threads available, because the number of slices depends on the number of threads. Therefore, small instance with less processing resources may not benefit from this solution.

[0054] The currently existing systems do not provide an effective way of solving slow key commands, such as commands associated with particular data types, e.g., working with large hash or list keys which block and slow down other fast processed keys such as small string key commands. This is because any key command has to be serially process, and therefore keys such as large hash, list or sorted set keys block the execution of all other commands, potentially contributing to service downtime to clients, which are major concerns in real-world In-memory KV cache products, and all popular communities along with recognizable cloud providers are facing. As an example, during cluster scaling, the cluster reshuffling implementation of existing systems forces keys to be migrated one by one to new shard, in a process known as “slot migration” . During this migration process, each key needs to block both source and target shard, write the key to the cache dictionary in the target shard, delete the key in the source shard, then  unblock the source and target to ensure atomicity and consistency. Therefore, a key such as large hash, list or sorted set key, e.g., with thousands of fields, which takes a noticeable amount of time to migrate, will introduce latency and / or downtime to clients.

[0055] Furthermore, existing “cache on flash” solutions, which refers to in-memory KV cache data tiering solutions which maintains application performance while moving less-frequently accessed data to less expensive solid-state storage, have to read key out of disk and promote back to a cache dictionary, which means keys such as large hash, list or sorted ste keys, e.g., with thousands of fields, take longer to work with, in particular blocking both source and target longer during migration.

[0056] To address the performance fluctuation problem in prior arts occur to different in-memory KV cache data types, the present disclosure introduced a sophisticated data type driven KV cache, which avoids excessively long atomicity enforcement against all key-level. The systems and methods described herein introduce an idea of data type-driven KV cache which allows each data type to be independently managed as a separate cache dictionary so atomicity is finer grained towards each data type instead of all key-level. Some noticeable latency contributors mentioned in existing systems will never enforce atomicity against any other data type keys hence will never impact the performance to other types such as small string keys which are most popular, frequently used, ultra-fast to process in production environment.

[0057] Since each data type is independently managed as a separate cache dictionary, the systems and methods described herein additionally allows for memory space management rules along with metadata for each data type, allowing the KV cache to answer key commands such as “HLEN” , “LLEN” and “LPOP” using existing KV metadata without having to look for the key, find its value object, and / or traverse the object to find the answer.

[0058] Managing each data type in a specific cache for the purpose of serving finer grained atomicity solves the pain point of keys associated with certain data types contributing huge latency in existing systems, while maintaining atomicity. The performance gain can especially be appreciated during slot migration where both the source and the target are blocked for every migrating key, causing performance fluctuations or even downtime. Furthermore, this solution makes it possible to allow end users to tune data type memory cache rules for each cache dictionary. It provides the end goals of fine-grained cache tuning for every data type to keep desirable number of keys and fields in cache over only one cache dictionary for all data types.

[0059] A person skilled in the art should understand that embodiments of this application may be provided as a method, an apparatus (or system) , computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0060] This application is described with reference to the flowcharts and / or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device and enable a machine to execute the instructions. When executed by any computer or the processor of a programmable data processing device, the instructions cause the apparatus to implement specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams. The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0061] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or on another programmable device provide steps for implementing specific functions as described in one or more procedures in the flowcharts and / or one or more blocks in the block diagrams.

[0062] It is clear that a person skilled in the art can make various modifications and variations to this application without departing from the scope of this disclosure. This disclosure is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

Claims

1.A method for operating a computer-implemented key-value caching system, the method comprising:receiving, by a server, a command from a client;parsing, by the server, the command into components, the components including at least a command name and a target key;based on the command name and / or the target key, determining, by the server, a data type associated with the command;determining, by the server, a dictionary data structure associated with the data type;sending the command from the server to the dictionary data structure; andprocessing the command by the dictionary data structure.2.The method of claim 1, further comprising:determining, by the server, whether the target key is part of a set of existing keys; andin response to the target key being part of the set of existing keys, aborting processing the command and sending an error message to the client by the server.3.The method of claim 2, wherein the set of existing keys corresponds to a Bloom filter, and wherein determining whether the target key is part of a set of existing keys comprises receiving a prediction from the Bloom filter.4.The method of any one of claims 1 to 3, further comprising:obtaining, by the server, a memory policy associated with the data type; andconfiguring, by the server, the dictionary data structure with the memory policy.5.The method of any one of claims 4, wherein processing the command by the dictionary data structure comprises enforcing the memory policy.6.The method of claim 5, wherein the memory policy sets a maximum memory, wherein enforcing the memory policy comprises:determining whether the command is directed to creating a new value;in response to the command being directed to creating the new value, determining whether creating the new value will cause the dictionary data structure to use more than the maximum memory; andin response to creating the new value causing the dictionary data structure to use more than the maximum memory, selecting and deleting an existing value from the dictionary data structure.7.The method of claim 6, wherein the memory policy sets a maximum length, wherein enforcing the memory policy comprises:determining whether the command is directed to creating a new element or field;in response to the command being directed to creating the new element or field, determining whether creating the new element or field will cause the target key to have a length greater than the maximum length; andin response to creating the new element or field causing the target key to have a length greater than the maximum length, selecting and deleting an existing element or field from the target key.8.The method of any one of claims 1 to 7, wherein processing the command by the dictionary data structure comprises updating metadata associated with the target key.9.A computer-implemented key-value caching system configured to store a plurality of values associated with a corresponding plurality of keys and to process commands received from at least one client, the system comprising a plurality of dictionaries, each dictionary data structure having at least a section of memory allocated in the system, wherein:each value belongs to one of a plurality of data types;each given data type of the plurality of data types is associated with one dictionary data structure of the plurality of dictionary data structures;each dictionary data structure is configured to enforce atomicity; andthe system is configured to ensure that the plurality of keys comprises only unique keys.10.The system of claim 9, wherein each dictionary data structure of the plurality of dictionary data structures is associated with exactly one data type of the plurality of data types.11.The system of claim 9 or 10, wherein each dictionary data structure is configured to execute no more than one of the commands at any given time.12.The system of any one of claims 9 to 11, further comprising a Bloom filter configured to verify whether a given key exists in the plurality of keys.13.The system of any one of claims 9 to 12, wherein at least one dictionary data structure of the plurality of dictionary data structures is configured to store metadata related to the values stored in the dictionary data structure, the metadata comprising a length, a head value, a tail value and / or an expiration timestamp.14.The system of any one of claims 9 to 13, wherein at least a first and a second dictionaries of the plurality of dictionaries respectively comprise a first and a second memory policies, and wherein the first memory policy is distinct from the second memory policy.15.The system of any one of claims 9 to 14, further comprising a server configured to receive the commands from the at least one client, each command comprising at least a target key, and to dispatch each command to one of the plurality of dictionaries based on a data type associated with the target key.16.The system of claim 15, wherein the server is configured to:determine whether a command is directed to creating a new value; andin response to the command being directed to creating the new value:determine whether the target key is part of the plurality of keys, andin response to the target key being part of the plurality of keys, abort processing the command and send an error message to the client.17.A server for operating a computer-implemented key-value caching system, comprising a memory for storing instructions and a processor configured to execute the instructions, wherein executing the instructions configures the processor to:receive a command from a client;parse the command into components, the components including at least a command name and a target key;based on the command name and / or the target key, determine a first data type from a plurality of data types associated with the command;determine a first dictionary data structure associated with the first data type from a plurality of dictionary data structures; andforward the command to the first dictionary data structure.18.The server of claim 17, the memory further comprising a data structure for storing existing keys, wherein executing the instructions further configures the processor to:determine whether the target key is part of the existing keys; andin response to the target key being part of the existing keys, abort processing the command and send an error message to the client.19.The server of claim 18, wherein the data structure is a Bloom filter.20.The server of any one of claims 17 to 19, wherein executing the instructions further configures the processor to:obtain a memory policy associated with a second data type;determine a second dictionary data structure associated with the second data type from the plurality of dictionary data structures; andconfigure the second dictionary data structure with the memory policy.

Images