Storing and retrieving data within a data store.

Abstract

The data item is searched for in the first and / or second datasets of the data store. If the data item is found in the first dataset, and if the data item was updated in the first dataset after the second dataset became an overlay of the first dataset, first data stored in association with the data item in the first dataset is returned. If the data item is found in the first and second datasets, and if the data item was updated in the first dataset after the second dataset became an overlay of the first dataset, second data stored in association with the data item in the second dataset is returned. The second dataset is identified based on overlay metadata indicating that the second dataset is an overlay of the first dataset.

Description

[Technical Field]

[0001] The present invention relates to a method for storing and retrieving data in a data store. Such data may be machine learning system model data, i.e., data for machine learning models used by a machine learning system. Examples of such data, but not limited to, include parameter data and / or state data for machine learning models. The machine learning system may be a real-time transaction processing system. [Background technology]

[0002] Over the past two decades, digital payments have exploded, with more than three-quarters of all payments worldwide now using some form of payment card or e-wallet. Point-of-sale systems are increasingly shifting from cash-based to digital. In short, commercial systems worldwide now rely heavily on electronic data processing platforms. This presents numerous engineering challenges largely hidden from non-expert users. For example, digital transactions must be completed in real time, i.e., with the minimum level of latency that computer devices encounter at the point of purchase. Digital transactions also need to be secure and resistant to attacks and plunder. The processing of digital transactions is also constrained by the historical development of global electronic systems for payments. For example, most infrastructure is still built around models designed for mainframe architectures that are in use more than 50 years ago.

[0003] As digital transactions increase, new security risks are also becoming apparent. Digital transactions present new opportunities for fraud and malicious activity. In 2015, it was estimated that 7% of digital transactions were fraudulent, and that this number is only increasing due to the shift of more economic activity online. Fraud losses are on the rise.

[0004] For businesses involved in commercial transactions, risks such as fraud are economic issues, but implementing technical systems to process transactions is an engineering challenge. Traditionally, banks, retailers, and card issuers have developed "written-on-paper" rules or procedures that were manually performed by staff to mark or block certain transactions. As transactions have become digital, one approach to building technical systems to process them has been to supply these sets of developed standards to computer engineers and ask them to implement them using a digital representation of the transactions; that is, to translate handwritten rules into coded logical statements that can be applied to electronic transaction data. This traditional approach is running into several problems as the volume of digital transactions increases. Firstly, any processing applied needs to be done "in real time," for example, with a latency of milliseconds. Secondly, thousands of transactions need to be processed per second (for example, a typical "load" can be 1,000 to 2,000 per second), and the load changes unexpectedly over time (for example, the launch of a new product or a set of tickets can easily increase the average load level several times over). Thirdly, transaction processors and banks' digital storage systems are often siloed or partitioned for security reasons, and digital transactions often involve an interconnected web of retail systems. Fourthly, large-scale analysis of actual reported and predicted fraud is now possible. This indicates that traditional methods of fraud detection are inadequate, namely, they have low accuracy and a high rate of false positives. This, in turn, has a physical impact on digital transaction processing, leading to the rejection of more genuine point-of-sale and online purchases, and often causing those seeking to utilize new digital systems to abandon them.

[0005] In recent years, more machine learning techniques have been adopted for processing transactional data. As machine learning models mature in the academic community, engineers are beginning to try applying them to the processing of transactional data. However, this again pits them against problems. Even when academic or theoretical machine learning models are provided to engineers and they are asked to implement them, this is not easy. For example, the problems of large-scale transactional processing systems come into play. Machine learning models do not have the luxury of unlimited inference time as they do in the laboratory. This means that it is simply not practical to implement some models in real-time settings, or that they require significant adaptation to enable real-time processing at the volume levels encountered by real-world servers. Moreover, engineers must contend with the problem of implementing machine learning models on data that is siloed or segregated based on access security, and in situations where the rate of data updates is extreme. The problems faced by engineers building transactional processing systems can be seen as being of the same kind as those faced by network engineers or database engineers: machine learning models need to be applicable, but they must satisfy the system throughput and query response time constraints set by the processing infrastructure. There are no easy solutions to these problems. In fact, the fact that many transaction processing systems are confidential, proprietary, and based on older technologies means that engineers often lack the body of knowledge developed in these adjacent fields and frequently face challenges specific to the field of transaction processing. Moreover, the field of large-scale, practical machine learning is still relatively young, with only a few established design patterns or textbooks for engineers to rely on.

[0006] As described above, engineers who build transaction processing systems may face the same kinds of problems as database engineers. Examples of such database-related problems include, but are not limited to, creation, configuration, management, maintenance, use, structuring, optimization, security, and organization. However, the requirements for databases used in transaction processing systems, in particular, the requirement to implement machine learning systems and provide real-time processing, can differ significantly from database requirements in other technical fields. For example, such transaction processing systems may need to provide one or more of the following: (i) real-time database read capability, (ii) high availability for “online” transaction processing capability with limited or no downtime for database administration, (iii) the ability to handle significant amounts of state data that can accumulate rapidly, (iv) high stability and reliability, (v) data security, and (vi) the ability to handle access from multiple different clients.

[0007] Copy-on-write snapshots are a standard feature in most existing database systems. Additionally, existing database systems allow new sets of data to be copied on top of existing sets of data. However, the latter scales linearly with the size of the new set of data. Furthermore, existing database systems cannot make large modifications atomically or in parallel with other clients accessing the same set of data. [Overview of the project] [Means for solving the problem]

[0008] Aspects of the present invention are presented in the appended independent claims. Several variations of the present invention are then presented in the appended dependent claims. Further aspects, variations, and examples are presented in the following embodiments for carrying out the invention.

[0009] Examples of the present invention are described below simply as examples, with reference to the accompanying drawings. [Brief explanation of the drawing]

[0010] [Figure 1A] This is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 1B] This is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 1C] This is a schematic diagram illustrating various exemplary electronic infrastructures for transaction processing. [Figure 2A] This is a schematic diagram illustrating various examples of data storage systems for use by machine learning transaction processing systems. [Figure 2B] This is a schematic diagram illustrating various examples of data storage systems for use by machine learning transaction processing systems. [Figure 3A] This is a schematic diagram illustrating various examples of transaction data. [Figure 3B] This is a schematic diagram illustrating various examples of transaction data. [Figure 4] This is a schematic diagram illustrating exemplary components of a machine learning transaction processing system. [Figure 5A] This sequence diagram illustrates an exemplary set of processes performed by various computing entities on transactional data. [Figure 5B] This sequence diagram illustrates an exemplary set of processes performed by various computing entities on transactional data. [Figure 6A] This is a state graph representing an exemplary data store. [Figure 6B] This is a state graph representing an exemplary data store. [Figure 6C] This is a state graph representing an exemplary data store. [Figure 6D] This is a state graph representing an exemplary data store. [Figure 6E] It is a state graph representing an exemplary data store. [Figure 7] It is a state graph representing another exemplary data store. [Figure 8A] It is a schematic diagram showing various examples of data and information stored in the data store. [Figure 8B] It is a schematic diagram showing various examples of data and information stored in the data store. [Figure 9] It is a state graph representing another exemplary data store. [Figure 10] It is a state graph representing another exemplary data store. [Figure 11] It is a state graph representing another exemplary data store. [Figure 12A] It is a state graph representing other exemplary data stores. [Figure 12B] It is a state graph representing other exemplary data stores. [Figure 13A] It is a state graph representing other exemplary data stores. [Figure 13B] It is a state graph representing other exemplary data stores. [Figure 14] It is a state graph representing another exemplary data store. [Figure 15] It is a state graph representing another exemplary data store. [Figure 16A] It is a graph representing an exemplary data queue. [Figure 16B] It is a graph representing an exemplary data queue. [Figure 16C] It is a graph representing an exemplary data queue. [Figure 16D] It is a graph representing an exemplary data queue. [Figure 16E] It is a graph representing an exemplary data queue. [Figure 17A] It is a graph representing other exemplary data queues. [Figure 17B] It is a graph representing other exemplary data queues. [Figure 18] This is a state graph representing another exemplary data store. [Modes for carrying out the invention]

[0011] introduction Several examples described herein relate to strategies for use in machine learning systems for transaction processing. In some examples, a machine learning system is applied in real time to a high-volume transaction processing pipeline to provide an indication of whether a transaction or entity conforms to a previously observed and / or predicted pattern of activity or action, for example, whether the transaction or entity is “normal” or “abnormal.” The term “behavioral” is used herein to refer to this pattern of activity or action. The indication may consist of a scalar value normalized within a predetermined range (e.g., 0 to 1) which can then be used to prevent fraud and other misuse of the payment system. The machine learning system may apply a machine learning model that is updated as more transaction data is acquired, for example, constantly trained on new data, to reduce false positives and maintain the accuracy of the output metric. Examples described herein relate to improved handling of such data, for example, in terms of exploring and storing such data in one or more data stores. This example may be particularly useful in preventing fraudulent activity when the physical presence of a payment card cannot be verified (for example, in online transactions known as "card-not-present"), or in commercial transactions where high-value transactions are commonplace and it is often difficult to classify the patterns of behavior as "unexpected." Therefore, this example facilitates transaction processing when these transactions are primarily "online," that is, transmitted digitally via one or more public communication networks.

[0012] Several examples described herein allow machine learning models to be tailored to be specific to certain entities, such as account holders and retailers. For example, a machine learning model may model entity-specific patterns of behavior rather than general group or aggregated behavior that would result in poor accuracy. The policies and machine learning systems described herein can dynamically update machine learning models despite large transaction flows and / or the need for isolation of different data sources. Again, the examples described herein provide improved policies for reading and storing machine learning model data to be used within such machine learning models.

[0013] This example may apply to a wide variety of digital transactions, including, but is not limited to, card payments, so-called "wire" transfers, peer-to-peer payments, Bankers' Automated Clearing System (BACS) payments, and Automated Clearing House (ACH) payments. The output of the machine learning system may be used to prevent a wide variety of fraudulent criminal behaviors, such as card fraud, application fraud, payment fraud, retail fraud, gambling fraud, and money laundering.

[0014] For example, this exemplary machine learning system, configured and / or trained according to Figures 1A to 18 below, enables fast inference that can be easily parallelized to provide processing latency of one second or less and to manage large volumes of processing (e.g., billions of transactions per year).

[0015] More specifically, the examples described herein allow multiple divergent sets of data to be stored in a data store (such as a database) based on a common historical set of data without the historical data being duplicated. The examples allow one set of data to be logically replaced by another set of data without all the data from one set being copied on top of the data in another set. The examples allow for the creation of a new set of data accessible to the client as a single atomic operation without requiring the data to be copied within the data store. If such data comprises machine learning model data, machine learning system processing latency can be reduced and throughput can be increased. Various measures are provided to make most data changes recognizable as part of a single atomic change to “state ID” metadata, as will be described in more detail below. For example, a large set of data may be copied into a separate dataset from the live dataset used by the running process, rather than being copied into the “live” dataset. The separate dataset may have state IDs independent of the live state IDs used by the live dataset. The new state ID of the new dataset can be made atomically recognizable to existing processes by setting the new dataset as an overlay on the live dataset and notifying clients of the state metadata changes. Clients can then read data from a mixture of the live dataset and the new dataset, rather than requiring a manual copy operation to be performed before data can be read from the combined single dataset. Maintaining separate datasets in this way also reduces the risk of unintentional and unwanted changes to the live dataset, which could negatively impact transaction processing, for example.

[0016] Several definitions of terms The term “data” is used herein in various contexts to refer to digital information, such as that represented by a known bit structure in one or more programming languages, though not limited to any specific form. In use, data may refer to digital information stored as a bit sequence in computer memory. Some machine learning models may operate on structured arrays of data in a predefined bit format. In the terminology of the art, these may be called multidimensional arrays or “tensors.” It should be noted that for machine learning methods, for example, a multidimensional array having a defined range in multiple dimensions may be “flattened” so that it is represented (for example, in memory) as an array or vector of values ​​stored according to a predefined format (e.g., n-bit integers or floating-point numbers, signed or unsigned). Therefore, as used herein, the term “tensor” covers multidimensional arrays having one or more dimensions (e.g., vectors, matrices, volumetric arrays, etc.). However, data may take other forms.

[0017] The term "structured numerical representation" is used to refer to numerical data in a structured form, such as a one-dimensional or multi-dimensional array that stores numerical values ​​having common data types, such as integer or floating-point values. A structured numerical representation may include tensors (as used in machine learning terminology). A structured numerical representation is typically stored as a set of indexed and / or contiguous memory locations; for example, a one-dimensional array of 64-bit floating-point numbers may be represented in computer memory as a contiguous array of 64-bit memory locations in a 64-bit computing system.

[0018] The term "transaction data" is used herein to refer to electronic data associated with a transaction. A transaction comprises a series of communications between different electronic systems for carrying out a payment or exchange. Generally, transaction data may include data that relates to and may indicate events (e.g., actions to be taken in a timely manner) that are relevant to the transaction processing and may provide information for the transaction processing. Transaction data may include structured data, unstructured data, and semi-structured data. In some cases, transaction data may be used more broadly to refer to actions taken with respect to one or more electronic devices. Transaction data may take various forms depending on the exact implementation. However, different data types and formats may be converted by pre-processing or post-processing as appropriate.

[0019] The term “interface” is used herein to refer to any physical and / or logical interface that enables one or more of data inputs and / or data outputs. An interface may be implemented by a network interface adapted to send and / or receive data, or by retrieving data from one or more memory locations, such as by a processor executing a set of instructions. An interface may also include physical (network) connections through which data is received, such as hardware for enabling wired or wireless communication over a particular medium. An interface may include an application programming interface, as well as / or method calls or returns. For example, in a software implementation, an interface may include passing data to a function initiated via a method call, and / or a memory reference to such a function, where the function comprises computer program code executed by one or more processors; in a hardware implementation, an interface may include wired interconnects between different chips, chipsets, or parts of a chip. In drawings, an interface may be indicated by the boundary of a processing block having inward and / or outward arrows representing data transfers.

[0020] The terms “component” and “module” are used interchangeably to refer to either a hardware structure having a specific function (for example, in the form of mapping input data to output data) or a combination of general-purpose hardware and specific software (for example, specific computer program code executed on one or more general-purpose processors). A component or module may be implemented as a specific packaged chipset, such as an application-specific integrated circuit (ASIC) or a programmed field-programmable gate array (FPGA), and / or as a software object, class, class instance, script, code, etc., which is executed when used by a processor.

[0021] The term “machine learning model” is used herein to refer to at least a hardware-executable implementation of a machine learning model or function. Known models within the field of machine learning include logistic regression models, naive Bayes models, random forests, support vector machines, and artificial neural networks. Classifier implementations may be made within one or more machine learning programming libraries, including, but not limited to, scikit-learn, TensorFlow, and PyTorch.

[0022] The term "map" is used herein to refer to the transformation or conversion of a first set of data values ​​to a second set of data values. The two sets of data values ​​may be arrays of different sizes, with the output array having fewer dimensions than the input array. The input and output arrays may have common or different data types. In some examples, the mapping is a one-way mapping to scalar values.

[0023] The term "datastore" is used herein to refer to a repository for storing data. An example of a datastore is a database. However, a datastore may take different forms, for example, depending on the implementation details. Another exemplary type of datastore is a file storage system.

[0024] The term "dataset" is used herein to refer to a collection of data. A dataset may, for example, be empty when it is created.

[0025] The term “data item” is used herein to refer to information being searched for within a data store. A data item may uniquely identify a record within the data store. The terms “key” and “search key” may be used herein interchangeably with the term “data item.” Data may be stored in relation to data items within the data store.

[0026] The term “data element” is used herein to refer to all or part of a given data stored in a data store. The data may comprise one or more data elements in this respect.

[0027] The term "metadata" is used herein to refer to information that provides information about other data. Metadata may be stored in the same data store as the state data, or it may be stored in a different data store.

[0028] Exemplary Transaction Processing System Figures 1A–1C show a set of exemplary transaction processing systems 100, 102, and 104. These exemplary transaction processing systems are described to provide context for the invention described herein, but should not be seen as limiting, as the configuration of any one implementation may differ based on the specific requirements of that implementation. However, the exemplary transaction processing systems described enable those skilled in the art to identify several high-level technical features that are important to the following description. The three exemplary transaction processing systems 100, 102, and 104 illustrate various areas where modifications may occur.

[0029] Figures 1A–1C show a set of client devices 110 configured to initiate a transaction. In this example, the set of client devices 110 includes a smartphone 110-A, a computer 110-B, a point-of-sale (POS) system 110-C, and a portable retail device 110-D. These client devices 110 provide a set of non-exclusive examples. In general, any electronic device or set of devices may be used to initiate a transaction. In some cases, the transaction involves a purchase or payment. For example, the purchase or payment may be an online or mobile purchase or payment made via smartphone 110-A or computer 110-B, or a purchase or payment made on a retail premises, such as via POS system 110-C or portable retail device 110-D. The purchase or payment may be for goods and / or services.

[0030] In Figures 1A to 1C, the client device 110 is communicatively coupled to one or more computer networks 120. The client device 110 may be communicatively coupled in various ways, including by one or more wired networks and / or wireless networks, including a telecommunications network. In a preferred example, all communications across one or more computer networks are secured, for example, using the Transport Layer Security (TLS) protocol. In Figure 1A, two computer networks are shown as 120-A and 120-B. These may be separate networks or different parts of a common network. The first computer network 120-A communicatively couples the client device 110 to a retailer server 130. The retailer server 130 may run computer processes that implement a process flow for transactions. For example, the retailer server 130 may be a backend server that processes transaction requests received from a POS system 110-C or a portable retailer device 110-D, or that can be used by an online retailer to run a website where purchases may be made. It will be understood that the examples in Figures 1A to 1C represent necessary simplifications of actual architectures, and that there may be several interacting server devices that run an online retail business, including, for example, a separate server device for providing hypertext markup language (HTML) pages detailing products and / or services, and for handling the payment process.

[0031] In Figure 1A, the retailer server 130 is communicatively coupled to a further set of backend server devices for processing transactions. In Figure 1A, the retailer server 130 is communicatively coupled to the payment processor server 140 via a second network 120-B. The payment processor server 140 is communicatively coupled to a first data storage device 142 that stores transaction data 146 and a second data storage device 144 that stores auxiliary data 148. The transaction data 146 may consist of batches of transaction data relating to different transactions initiated over a period of time. The auxiliary data 148 may consist of transaction-associated data, such as records that store retailer data and / or end-user data. In Figure 1A, the payment processor server 140 is communicatively coupled to the machine learning server 150 via a second network 120-B. The machine learning server 150 implements a machine learning system 160 for processing transaction data. The machine learning system 160 is configured to receive input data 162 and map it to output data 164 used by the payment processor server 140 to process specific transactions, such as transactions originating from the client device 110. In some cases, the machine learning system 160 receives at least transaction data associated with a specific transaction and provides an alert or numerical output used by the payment processor server 140 to determine whether the transaction will be authorized (i.e., approved) or rejected. Thus, the output of the machine learning system 160 may include labels, alerts, or other indications of fraudulent activity or general malicious or unusual activity. The output may include a probability representation such as a score or probability. In some cases, the output data 164 may include scalar numbers. The input data 162 may further include data derived from one or more of the transaction data 146 and auxiliary data 148.In some cases, output data 164 indicates the level of deviation from a particular expected pattern of behavior based on past observations or measurements. For example, this may indicate fraudulent or criminal behavior when it differs significantly from the observed pattern of behavior, often, especially on a large scale. Output data 164 may form a measure of behavior. The expected pattern of behavior may be defined either explicitly or implicitly based on observed interactions between different entities in the transaction process flow, such as end users or customers, retailers (including point-of-sale and back-end locations or entities, where these may differ), and banks.

[0032] The machine learning system 160 may be implemented as part of a transaction processing pipeline. An exemplary transaction processing pipeline will be described later with respect to Figures 5A and 5B. The transaction processing pipeline may include electronic communication between the client device 110, the retail server 130, the payment processor server 140, and the machine learning server 150. Other server devices, such as a banking server that grants authorization from the issuing bank, may also be involved. In some cases, the client device 110 may communicate directly with the payment processor server 140. When in use, the transaction processing pipeline typically needs to be completed within 100 or 200 milliseconds. Generally, processing times of less than one second may be considered real time (for example, humans generally perceive events over a time span of 400 ms). Furthermore, the desired maximum latency for the complete round-trip time for transaction processing may be 100-200 ms, and within this time span, the time allocated to the machine learning system 160 may be a small portion of this total, such as 10 ms (i.e., less than 5-10% of the target processing time), as the majority of that time may be reserved for other operations in the transaction processing flow. This presents a technical constraint on the implementation of the machine learning system 160. Moreover, in real-world implementations, the average processing volume may be around 1000-2000 per second. This means that most "off-the-shelf" machine learning systems are not suitable for implementing the machine learning system 160. This further means that most machine learning techniques described in academic papers cannot be implemented within the aforementioned transaction processing pipeline without non-trivial adaptations. There is also the problem that anomalies are rare events by their very nature, and therefore accurate machine learning systems are difficult to train.

[0033] Figure 1B shows a variant 102 of the exemplary transaction processing system 100 in Figure 1A. In this variant 102, the machine learning system 160 is implemented within a payment processor computer infrastructure, running, for example, on a payment processor server 140 and / or on locally coupled servers within the same local network as the payment processor server 140. The variant 102 in Figure 1B may be preferred for larger payment processors because it enables faster response times, greater control, and improved security. However, functionally, the transaction processing pipeline may be similar to that of Figure 1A. For example, in the example of Figure 1A, the machine learning system 160 may be initiated by a secure external application programming interface (API) call, such as a Representation State Transfer (REST) ​​API call using Hypertext Transfer Protocol Secure (HTTPS), while in Figure 1B, the machine learning system 160 may be initiated by an internal API call, provided that a common-end API can handle both requests (e.g., the REST HTTPS API may provide an external wrapper for the internal API).

[0034] Figure 1C shows another variant 104 of the exemplary transaction processing system 100 of Figure 1A. In this variant 104, the machine learning system 160 is communicatively coupled to a local data storage device 170. For example, the data storage device 170 may be on the same local network as the machine learning server 150, or it may be on a local storage network accessible to the machine learning server 150. In this case, there are multiple local data storage devices 170-A to 170-N, where each data storage device stores partitioned auxiliary data 172. The partitioned auxiliary data 172 may contain parameters for one or more machine learning models. In some cases, the auxiliary data 172 may contain states for the machine learning models, where the states may relate to one or more specific entities such as users or retailers. The partitioning of the auxiliary data 172 may need to be applied to meet security requirements set by third parties such as payment processors, one or more banks, and / or one or more retailers. During use, the machine learning system 160 accesses auxiliary data 172-A to 172-N via multiple local data storage devices 170-A to 170-N based on input data 162. For example, input data 162 may be received via API requests from a specific source and / or may include data identifying that a specific partition should be used to process the API requests. More details of different storage systems that may be applied to meet security requirements are presented in Figures 2A and 2B.

[0035] Exemplary data storage configuration Figures 2A and 2B show two exemplary data storage configurations 200 and 202 that may be used by an exemplary machine learning system 210 for processing transactional data. The examples in Figures 2A and 2B are two non-limiting examples illustrating different options available for implementation, and specific configurations may be selected according to individual circumstances. The machine learning system 210 may have an implementation form of the machine learning system 160 described in the earlier examples in Figures 1A-1C. The examples in Figures 2A and 2B enable the machine learning system 210 to process transactional data that is secured using heterogeneous cryptographic parameters in order to securely process transactional data for heterogeneous entities. It will be understood that the configurations in Figures 2A and 2B may not be used if the machine learning system 160 is implemented for a single set of secure transactions and auxiliary data, for example, within an internal transaction processing system or as a hosted system for use by a single payment processor.

[0036] Figure 2A shows a machine learning system 210 communicatively coupled to a data bus 220. The data bus 220 may comprise the internal data bus of a machine learning server 150, or it may form part of a storage area network. The data bus 220 communicatively couples the machine learning system 210 to a plurality of data storage devices 230, 232. The data storage devices 230, 232 may comprise any known data storage devices, such as magnetic hard disks and solid-state devices. Although the data storage devices 230, 232 are shown as different devices in Figure 2A, they may alternatively form different physical areas or storage portions within a common data storage device. In Figure 2A, the plurality of data storage devices 230, 232 store historical transaction data 240 and auxiliary data 242. In Figure 2A, a first set of data storage devices 230 stores the historical transaction data 240, and a second set of data storage devices 232 stores the auxiliary data 242. The auxiliary data 242 may comprise one or more of the following: model parameters for a set of machine learning models (such as trained parameters for a neural network architecture and / or configuration parameters for a random forest model), and state data for those models. In some cases, various sets of historical transaction data 240-A~N and auxiliary data 242-A~N may be associated with various entities that securely and collectively use the services provided by the machine learning system 210, for example, these may represent data for various banks that need to be kept separate as part of the conditions for providing machine learning services to those entities.

[0037] Figure 2B illustrates another method in which different sets of historical transaction data 240-A~N and auxiliary data 242-A~N may be stored. In Figure 2B, the machine learning system 210 is communicably coupled to at least one data storage device 260 via a data transfer channel 250. The data transfer channel 250 may comprise a local storage bus, a local storage area network, and / or a remote secure storage coupling (such as one that sits over an insecure network, like the Internet). In Figure 2B, a secure logical storage layer 270 is provided using the physical data storage device 260. The secure logical storage layer 270 may be a virtualized system that appears to the machine learning system 210 as a separate physical storage device, but is actually implemented independently on at least one data storage device 260. The logical storage layer 270 may provide separate encrypted partitions 280 for data relating to a group of entities (for example, relating to different issuing banks), and different sets of historical transaction data 240-A to N and auxiliary data 242-A to N may be stored in the corresponding partitions 280-A to N. In some cases, entities may be dynamically created when a transaction is received for processing based on data stored by one or more of the server systems shown in Figures 1A to 1C.

[0038] Exemplary transaction data Figures 3A and 3B show examples of transaction data that may be processed by machine learning systems such as 160 or 210. Figure 3A shows how transaction data may consist of a set of records 300, each having a timestamp and multiple transaction fields. The records 300 may be time-ordered or strictly ordered in another manner. In some examples, the transaction data may be optionally grouped and / or filtered based on timestamps. For example, Figure 3A shows a division of transaction data into current transaction data 310 associated with the current transaction and “older” i.e., historical transaction data 320 within a predetermined time range of the current transaction. The time range may be set as a hyperparameter of any machine learning system. Alternatively, the “older” i.e., historical transaction data 320 may be set as a number of transactions. A combination of the two methods is also possible.

[0039] Figure 3B illustrates how transaction data 330 for a particular transaction may be stored in numerical format for processing by one or more machine learning models. For example, in Figure 3B, the transaction data has at least fields, namely, the transaction amount, a timestamp (e.g., as a Unix epoch), the transaction type (e.g., card payment or direct debit), a product description or identifier (e.g., relating to the item being purchased), a retailer identifier, an issuing bank identifier, a set of characters (e.g., Unicode characters in a field of a predetermined character length), a country identifier, and so on. Note that a wide variety of data types and formats may be received and preprocessed into appropriate numerical representations. In some cases, outgoing transaction data, such as that generated by a client device and sent to the retailer server 130, may be preprocessed to convert alphanumeric data types into numerical data types for application by one or more machine learning models. Other fields present in the transaction data may include, but are not limited to, account numbers (e.g., credit card numbers), the location where the transaction is taking place, and the method by which the transaction is performed (e.g., by phone, via telephone, or on a website).

[0040] Exemplary machine learning system Figure 4 shows an example 400 of a machine learning system 402 that may be used to process transaction data. The machine learning system 402 may implement one or more of the machine learning systems 160 and 210. The machine learning system 402 receives input data 410. The format of the input data 410 may depend on which machine learning model is being applied by the machine learning system 402. If the machine learning system 402 is configured to perform fraud detection or anomaly detection with respect to a transaction, for example, an ongoing transaction as described above, the input data 410 may include transaction data such as 330 (i.e., data that forms part of a data package for the transaction), as well as data derived from historical transaction data (such as 300 in Figure 3A) and / or data derived from auxiliary data (such as 148 in Figures 1A-1C or 242 in Figures 2A and 2B). The auxiliary data may include secondary data linked to one or more entities identified in the primary data associated with the transaction. For example, if transaction data for an ongoing transaction identifies the user, the retailer, and one or more banks associated with that transaction (such as the issuing bank and the retailer's bank for the user) through unique identifiers present in the transaction data, the auxiliary data may include data relating to these transaction entities. The auxiliary data may also include data derived from activity records, such as interaction logs and / or authentication records. In some cases, the auxiliary data is stored in one or more static data records and retrieved from these records based on the received transaction data. Additionally or alternatively, the auxiliary data may include machine learning model parameters retrieved based on the content of the transaction data. For example, the machine learning model may have parameters specific to one or more of the user, retailer, and issuing bank, and these parameters may be retrieved based on which of these are identified in the transaction data.For example, one or more of users, retailers, and issuing banks may have corresponding embeddings, which may comprise retrieveable or mappable tensor representations of the entities. For example, each user or retailer may have a tensor representation (e.g., a floating-point vector of size 128 to 1024) that can be retrieved from a database or other data storage, or generated by the embedding layer based on, for example, a user or retailer index.

[0041] Input data 410 is received at the input data interface 412. The input data interface 412 may have an API interface, such as an internal or external API interface, as described above. In some cases, a payment processor server 140, as shown in Figures 1A to 1C, makes a request to this interface, where the request payload includes transaction data. The API interface may be defined to be agnostic with respect to the format or source of the transaction data. The input data interface 412 is communicatively coupled to the machine learning model platform 414. In some cases, a request made to the input data interface 412 triggers the execution of the machine learning model platform 414 using the transaction data supplied to the interface. The machine learning model platform 414 is configured as an execution environment for applying one or more machine learning models to the input data 410. In some cases, the machine learning model platform 414 is configured as an execution wrapper for multiple different selectable machine learning models. For example, the machine learning models may be defined using a model definition language (e.g., an extended markup language - similar to or using an extended markup language such as XML). The model definition language may include (in particular, independently or in combination) SQL, TensorFlow, Caffe, Thinc, and PyTorch. In some cases, the model definition language comprises executable computer program code to perform one or more of the training and inference of the machine learning model being defined. The machine learning model may include, for example, artificial neural network architectures, ensemble models, regression models, decision trees such as random forests, graph models, and Bayesian networks. The machine learning model platform 414 may define common (i.e., shared) input and output definitions such that different machine learning models are applied in a common (i.e., shared) manner.

[0042] In this example, the machine learning model platform 414 is configured to provide at least one scalar output 416, which may be normalized within a default range such as 0 to 1. Once normalized, the scalar output 416 may be seen as the probability that a transaction associated with the input data 410 is fraudulent or anomalous. In this case, a value of "0" may represent a transaction that aligns with a normal pattern of activity for one or more of the users, retailers, and issuing banks, while a value of "1" may indicate that the transaction is fraudulent or anomalous, i.e., does not align with an expected pattern of activity (although those skilled in the art will know that the normalized range may differ, such as being inverted or within different boundaries, and may have the same functional effect). While the range of values ​​may be defined as 0 to 1, it should be noted that the output values ​​may not be uniformly distributed within this range, for example, a value of "0.2" may be a common output for a "normal" event, and a value of "0.8" may be seen as exceeding a threshold for a typical "anomalous" or fraudulent event. The machine learning models implemented by the machine learning platform 414 may perform a certain form of mapping between high-dimensional input data (e.g., transactional data and optional retrieval aid data) and a single-value output. In some cases, for example, the machine learning platform 414 may be configured to receive input data for machine learning models in numerical format, and each defined machine learning model may be configured to map similarly defined input data. The exact machine learning models applied by the machine learning model platform 414, and the parameters for those models, may be determined based on configuration data. The configuration data may be contained within the input data 410 and / or identified using the input data 410 and / or set based on one or more configuration files parsed by the machine learning platform 414.

[0043] In some cases, the machine learning model platform 414 may provide additional outputs depending on the context. In some implementations, the machine learning model platform 414 may be configured to return “reason codes” that capture a human-friendly explanation of the machine learning model’s output with respect to questionable input attributes. For example, the machine learning model platform 414 may indicate which of one or more input elements or input units in the input representation influenced the model output, for example, a combination of the “amount” channel exceeding a learned threshold and the “merchant” element or set of units (such as embedded or indexed) being outside a given cluster. If the machine learning model platform 414 implements a decision tree, these additional outputs may include paths through the decision tree or aggregated feature importance, based on an ensemble of trees. In the case of a neural network architecture, this may include layer output activations and / or layer filters with positive activations.

[0044] In Figure 4, some implementations may include an optional alarm system 418 that receives the scalar output 416. In other implementations, the scalar output 416 may be passed directly to the output data interface 420 without post-processing. In this latter case, the scalar output 416 may be packaged in the response to the original request to the input data interface 412. In both cases, the output data 422 derived from the scalar output 416 is provided as the output of the machine learning system 402. The output data 422 is returned to enable final processing of the transaction data. For example, the output data 422 may be returned to the payment processor server 140 and used as the basis for a decision to approve or reject the transaction. Depending on the implementation requirements, in some cases the alarm system 418 may process the scalar output 416 to return a binary value (e.g., "1" is equivalent to rejection) indicating whether the transaction should be approved or rejected. In some cases, the decision may be made by applying a threshold to the scalar output 416. This threshold may be context-dependent. In some cases, the alarm system 418 and / or the output data interface 420 may also receive additional inputs, such as explanatory data (e.g., the “reason code” described above) and / or original input data. The output data interface 420 may generate an output data package for output data 422, which combines these inputs with the scalar output 416 (e.g., for logging and / or further consideration). Similarly, alarms generated by the alarm system 418 may include, for example, the scalar output 416, the additional inputs described above, and / or be based on the additional inputs described above.

[0045] In a preferred implementation, the machine learning system 402 is used in “online” mode to process a large volume of transactions within a narrowly defined time range. For example, under normal processing conditions, the machine learning system 402 may process requests within 7–12 ms and may be able to manage 1000–2000 requests per second (these are median constraints from real-world operating conditions). However, the machine learning system 402 may also be used in “offline” mode, for example, by providing selected historical transactions to the input data interface 412. In offline mode, input data may be passed to the input data interface in batches (i.e., groups). The machine learning system 402 may also implement machine learning models that provide scalar outputs for entities, as well as or instead of transactions. For example, the machine learning system 402 may receive requests associated with an identified user (e.g., a cardholder or payment account holder) or an identified retailer and may be configured to provide a scalar output 416 indicating the possibility that the user or retailer is fraudulent, malicious, or anomalous (i.e., a general threat or risk). For example, this may form part of a continuous or periodic monitoring process, or a one-time request (for example, as part of an application for a service). The supply of scalar output to a particular entity may be based on a set of transactional data, including it, up to the last authorized transaction, within a sequence of transactional data (for example, transactional data for entities similar to the entity that should be in Figure 3A).

[0046] Exemplary Transaction Process Flow Figures 5A and 5B show two possible exemplary transaction process flows 500 and 550. These process flows may occur in the context of exemplary transaction process systems 100, 102, and 104 shown in Figures 1A and 1C, as well as other systems. Process flows 500 and 550 are provided as examples of contexts to which a machine learning transaction processing system may be applied, but not all transaction process flows necessarily follow the processes shown in Figures 5A and 5B, and process flows may change between implementations, between systems, and over time. The exemplary transaction process flows 500 and 550 reflect two possible cases: a first case represented by transaction process flow 500 in which the transaction is approved, and a second case represented by transaction process flow 550 in which the transaction is rejected. Each transaction process flow 500, 550 involves the same set of five interacting systems and devices, namely, a POS or user device 502, a retail system 504, a payment processor (PP) system 506, a machine learning (ML) system 508, and an issuing bank system 510. The POS or user device 502 may comprise one of the client devices 110, the retail system 504 may comprise a retail server 130, the payment processor system 506 may comprise a payment processor server 140, and the machine learning system 508 may comprise an implementation of machine learning systems 160, 210, and / or 402. The issuing bank system 510 may comprise one or more server devices that perform transaction functions on behalf of the issuing bank. The five interacting systems and devices 502-510 may be communicably connected by one or more internal or external communication channels, such as a network 120.In some cases, several of these systems may be combined; for example, the issuing bank may also function as a payment processor, and thus systems 506 and 510 may be implemented using a common system. In other cases, a similar process flow may be performed, particularly for retailers (e.g., without involving a payment processor or issuing bank). In this case, the machine learning system 508 may communicate directly with the retailer system 504. In these variations, the general functional transaction process flow may remain similar to that described below.

[0047] The transaction process flows in both Figure 5A and Figure 5B include several common (i.e., shared) processes 512-528. In block 512, a POS or user device 502 initiates a transaction. In the case of a POS device, this may involve a cashier attempting to receive an electronic payment using a front-end device, and in the case of a user device 502, this may involve a user making an online purchase using a credit or debit card or an online payment account (e.g., clicking "Complete" in an online basket). In block 514, the payment details are received as electronic data by the retail system 504. In block 516, the retail system 504 processes the transaction and makes a request to the payment processor system 506 to authorize the payment. In block 518, the payment processor system 506 receives a request from the retail system 504. The request may be made over a proprietary communication channel or as a secure request over a public network (e.g., an HTTPS request over the Internet). The payment processor system 506 then requests the machine learning system 508 to obtain a score or probability for use when processing the transaction. Block 518 may additionally include retrieving auxiliary data for combining with the transaction data sent to the machine learning system 508 as part of the request. In other cases, the machine learning system 508 may have access to a data storage device that stores the auxiliary data (for example, similar to the configurations in Figures 2A and 2B), and thus may retrieve this data as part of its internal operations (for example, based on identifiers provided in the transaction data and / or defined as part of a machine learning model being implemented).

[0048] Block 520 shows a model initialization operation performed before any request from the payment processor system 506. For example, the model initialization operation may comprise loading a defined machine learning model and parameters that instantiate the defined machine learning model. In block 522, the machine learning system 508 receives a request from the payment processor system 506 (for example, via a data input interface such as 412 in Figure 4). In block 522, the machine learning system 508 may perform any defined preprocessing before applying the machine learning model initialized in block 520. For example, if the transaction data still holds character data such as a retailer identified by a string or character transaction description, this may be converted to suitable structured numerical data (for example, by converting string categorical data to identifiers via a lookup operation or other mapping, and / or by mapping characters or groups of characters to vector embeddings). Then, in block 524, the machine learning system 506 applies the instantiated machine learning model by supplying the input data derived from the received request to the model. This may comprise applying the machine learning model platform 414 as described with reference to Figure 4. In block 526, the instantiated machine learning model generates a scalar output, which may be processed by the machine learning system 508 to determine a binary decision of "approve" or "reject," or, if preferred, returned to the payment processor system 506 as a response to the request made in block 518.

[0049] In block 528, the output of the machine learning system 508 is received by the payment processor system 506 and used to approve or reject the transaction. Figure 5A shows the process in which a transaction is approved based on the output of the machine learning system 508, and Figure 5B shows the process in which a transaction is rejected based on the output of the machine learning system 508. In Figure 5A, the transaction is approved in block 528. Then, in block 530, the request is made to the issuing bank system 510. In block 534, the issuing bank system 510 approves or rejects the request. For example, if the end user or cardholder has sufficient funds and authorization to cover the transaction costs, the issuing bank system 510 may approve the request. In some cases, the issuing bank system 510 may apply a second level of security, but this is not necessary if the issuing bank relies on anomaly detection performed by the payment processor using the machine learning system 508. In block 536, authorization from the issuing bank system 510 is returned to the payment processor system 506, which in block 538 sends a response to the retailer system 504, which in block 540 responds to the POS or user device 502. If the issuing bank system 510 approves the transaction in block 534, the transaction may be completed and a positive response may be returned to the POS or user device 502 via the retailer system 504. The end user may encounter this as an "authorized" message on the screen of the POS or user device 502. The retailer system 504 may then complete the purchase (for example, by initiating internal processing to complete the purchase).

[0050] At a later point in time, one or more of the retail system 504 and the machine learning system 508 may save data related to the transaction, for example, as part of the transaction data 146, 240, or 300 in the previous example. This is shown in the dashed blocks 542 and 544. The transaction data may be saved along with one or more of the output of the machine learning system 508 (e.g., scalar fraud or anomaly probabilities) and the final outcome of the transaction (e.g., whether it was approved or rejected). The saved data may be stored for use as training data for a machine learning model performed by the machine learning system 508. The saved data may also be accessed as part of a future iteration of block 524, for example, to form part of future auxiliary data. In some cases, the final outcome or result of a transaction may not be known at the time of the transaction. For example, a transaction may only be labeled as anomaly through later review by analysts and / or automated systems, or based on feedback from a user (e.g., when a user reports fraud or indicates that a payment card or account has been threatened for some date). In these cases, ground truth labels may be collected over time following the transaction itself for the purpose of training the machine learning system 508.

[0051] Next, referring to the alternative process flow in Figure 5B, in this case, one or more of the machine learning system 508 and the payment processor system 506 reject the transaction based on the output of the machine learning system 508. For example, if the scalar output of the machine learning system 508 exceeds a retrieved threshold, the transaction may be rejected. In block 552, the payment processor system 506 issues a response to the retail system 504, which is received in block 554. In block 554, the retail system 504 takes steps to prevent the transaction from completing and returns an appropriate response to the POS or user device 502. This response is received in block 556, and the end user or customer may be informed that their payment has been rejected, for example, via a "rejected" message on the screen. The end user or customer may be prompted to use a different payment method. Although not shown in Figure 5B, in some cases, the issuing bank system 510 may be informed that a transaction relating to a particular account holder has been rejected. The issuing bank system 510 may be informed as part of the process shown in Figure 5B, or as part of a periodic (e.g., daily) update. However, the transaction does not have to be part of the transaction data 146, 240, or 300 (because it was not approved) and may still be logged by at least the machine learning system 508, as shown by block 544. For example, as in Figure 5A, the transaction data may be saved together with the output of the machine learning system 508 (e.g., the scalar probability of fraud or anomaly) and the final result of the transaction (e.g., that it was rejected).

[0052] Exemplary data store structure As described above, the exemplary machine learning system described herein stores and retrieves data in one or more data stores within one or more data storage devices. The following example relates to how such data stores are created, maintained, and used, as well as to the structure and contents of such data stores. Such example addresses, or at least improves, certain database-related problems in the context of machine learning systems, and in particular machine learning systems that facilitate real-time transaction processing. More specifically, the following example relates to a “hierarchical state” data store configuration in which multiple different “layers” of state data (also referred herein as “data”) are stored in a data store. Each layer comprises one or more state datasets (also referred herein as “datasets” or “state”) that store state data. Such a hierarchical state configuration may be used in various different types of state implementations, i.e., implementations in which states are stored and retrieved for use by the exemplary machine learning system described herein. In the example, the data stored in the data store includes historical transaction data and / or auxiliary data as described above. However, the techniques described herein may be applied to other types of data.

[0053] Hierarchical states allow for the dynamic construction of "effective states" using state data from several different state data sources, such as different state datasets, without the need to modify each individual state data one by one. In effect, hierarchical states merge state data from multiple different state datasets rather than requiring the state data to reside within a single state dataset. This can be particularly useful, though not limited to, when large amounts of state data reside in different datasets, and when combining separate datasets into a single dataset in a single step would involve significant resources, such as time. Such datasets may be separate for various reasons, such as providing a data maturation environment to allow different machine learning models to be tested. However, the state data in those separate datasets may still be relevant, and the exemplary machine learning systems described herein may benefit from using state data from separate datasets rather than being constrained to using a single dataset, for example, in terms of yielding more accurate results. Some of the exemplary implementations described herein may be used for database-based state types. Other exemplary implementations are described for data queues where stored data is temporally ordered rather than randomly accessed, as in a database. One exemplary implementation of this type is found on Apache Kafka (sometimes simply referred to as "Kafka" in this specification). However, such exemplary implementations may take other forms.

[0054] The hierarchical state, as described herein, uses various concepts including parent and overlay, which are described below. Roughly speaking, the parent dataset of a child dataset is the dataset to which the child dataset is linked through parent metadata, which is created before the child dataset is created. Roughly speaking, the overlay dataset of a given dataset is the dataset to which the given dataset is linked through overlay metadata, which is applied to the given dataset after the overlay dataset and the given dataset are created.

[0055] Figure 6A shows a state graph (sometimes simply referred to as the “graph” herein) 600 representing an exemplary datastore. The exemplary datastore comprises a first dataset 611 that stores state data. The first dataset 611 is identified using identification data in the form of a state ID “state1”. Although the exemplary datastore represented in graph 600 contains only one dataset, as will become apparent below, state IDs are used in exemplary state implementations to extract different sets of states within the same set, i.e., different datasets within the same datastore. In this example, “state1” is the “current” state ID, sometimes referred to as the “root” or “live” state ID. When writing to the datastore, all data is written to the specified live dataset. In this example, the first dataset 611 is the root dataset of the datastore, as indicated by item 620. In this example, since the first dataset 611 is the only dataset in the exemplary datastore, all data is read from the first dataset 611.

[0056] Figure 6B shows another state graph 602 representing another exemplary datastore. The datastore represented by graph 602 may correspond to the datastore represented by graph 600 at a later point in time. Exemplary graph 602 demonstrates a parent state. In this example, the datastore comprises a first dataset 611 and a second dataset 612, where the first dataset 611 is the parent dataset (or simply "parent") of the second dataset 612, and the second dataset 612 is the child dataset (or simply "child") of the first dataset 611. Thus, the parent dataset 611 and the child dataset 612 have a hierarchical relationship in state graph 602, as shown in 630. In this example, the parent dataset 611 and the child dataset 612 are identified using identification data in the form of state IDs "state1" and "state2," respectively. As previously mentioned, new data is written to the root (child) dataset 612 which has state ID "state2." New data is not written to the parent dataset 611 with state ID "state1", but (historical) data may be read from the parent dataset 611. In the example, the new dataset with the new state ID starts as an empty dataset. In this specific example, the child dataset 612 is assigned a new state ID ("state2") and was initially empty when it was created. Therefore, the new dataset with the new state ID is filled with (modified) data as new data is written to the new dataset. The parent link indicated by item 630 begins to operate when data is read from the datastore. When performing a read operation, if the data item being searched for (sometimes called a "key") is not found in the current dataset, the data item is searched for in the parent dataset. In the example, the parent link is via parent metadata stored in the datastore. However, in this example, metadata is stored in the datastore, and metadata is not necessarily stored in the same datastore as the state data.Metadata may be stored in a different type of datastore than the state data it stores. For example, state data may be stored in a database, while metadata may be stored in a file, such as an Apache Kafka queue. Alternatively, metadata and state data may be stored in the same type of datastore as each other.

[0057] Figure 6C shows another state graph 604 representing another exemplary datastore. The datastore represented by graph 604 may correspond to the datastore represented by graph 602 at a later point in time. Exemplary graph 604 demonstrates multiple parent states. In this example, the datastore comprises a first dataset 611, a second dataset 612 which is a child of the first dataset 611, and a third dataset 613 which is a child of the second dataset 612 (and therefore a grandchild of the first dataset 611). Thus, the first dataset 611, the second dataset 612, and the third dataset 613 are called the grandparent dataset 611, the parent dataset 612, and the child dataset 613, respectively. In this example, the grandparent dataset 611, the parent dataset 612, and the child dataset 613 are identified using identification data in the form of state IDs "state1", "state2", and "state3", respectively. In this example, as indicated by item 620, the child dataset 613 is the root of the datastore. Parent links 630 and 631 exist between the grandparent dataset 611 and the parent dataset 612, and between the parent dataset 612 and the child dataset 613, respectively. The first parent metadata may define the link between the grandparent dataset 611 and the parent dataset 612, and the second parent metadata may define the link between the parent dataset 612 and the child dataset 613. This is in contrast to metadata that only defines the link between the grandparent dataset 611 and the child dataset 613, and does not perform a comprehensive search of the dataset, as will be explained below. When a read operation is performed, if the data item being searched for is not found in the current dataset (child dataset 613 in this example), the parent dataset 612 is searched up the state graph to the grandparent dataset 611 for the data item, etc. Effectively, this means that each dataset is a copy-on-write state snapshot at the point where a new dataset branches off away from the root.When a child dataset is created from it, the parent dataset is no longer modified; in other words, when a child dataset is created from it, the parent dataset becomes immutable.

[0058] Figure 6D shows another state graph 606 representing another exemplary datastore. Exemplary graph 606 demonstrates multiple root states. In this example, the datastore comprises a first dataset 611, a second dataset 612 which is a child of the first dataset 611, a third dataset 613 which is a child of the second dataset 612 (and therefore a grandchild of the first dataset 611), and a fourth dataset 614 which is also a child of the second dataset 612 (and therefore a grandchild of the first dataset 611). Thus, the first dataset 611, the second dataset 612, the third dataset 613, and the fourth dataset 614 are referred to as the grandparent dataset 611, the parent dataset 612, the first child dataset 613, and the second child dataset 614, respectively. In this example, the grandparent dataset 611, the parent dataset 612, the first child dataset 613, and the second child dataset 614 are identified using identification data in the form of state IDs "state1", "state2", "state3", and "state4", respectively. In this example, as indicated by items 620 and 621, both child datasets 613 and 614 are root datasets of the datastore. Therefore, new data can be written to one or both of the child datasets 613 and 614. Specifically, state ID "state3" may be used to write data to the first child dataset 613, and state ID "state4" may be used to write data to the second child dataset 614. Similarly, a read access to the datastore using state ID "state3" will start first in the first child dataset 613, while a read access to the datastore using state ID "state4" will start first in the second child dataset 614. Different clients may have different status IDs and may use different status IDs, for example, for data security purposes.Parent links 630, 631, and 632 exist between the grandparent dataset 611 and the parent dataset 612, between the parent dataset 612 and the first child dataset 613, and between the parent dataset 612 and the second child dataset 614, respectively. As can be seen in this example of multiple routes, multiple child state IDs, namely "state3" and "state4", can point to a single parent state ID, namely "state2".

[0059] Figure 6E shows another state graph 608 representing another exemplary data store. Exemplary graph 608 corresponds to exemplary graph 606 shown in Figure 6D, but exemplary state data values ​​are shown to demonstrate state divergence. In this example, the parent dataset 612 stores data 640, which has a single data element with an exemplary value of "10" stored for a given data item (not shown in Figure 6E); the first child dataset 613 stores data 641, which has a single data element with an exemplary value of "15" stored for the same given data item; and the second child dataset 614 stores data 642, which has a single data element with an exemplary value of "13" again stored for the same given data item. The two child datasets 613 and 614 both start as equivalent, since they are both empty when created and both share the same parent dataset 612. However, they then slowly diverge over time as different data 641, 642 are written into each root 620, 621, and thus into each child dataset 613, 614.

[0060] When a data store is explored according to the example, the explorer is looking for a data item, and the data associated with the data item is returned. For example, depending on the implementation details, a data item can take various forms. However, in one possible form, a data item is a tuple based on bankID (identifying a particular bank), entityType (indicating a particular type of entity), and entityId (identifying a particular entity).

[0061] Figure 7 shows another state graph 700 representing a different exemplary data store. The exemplary graph 700 demonstrates overlays and overlay states.

[0062] In this example, the state graph 700 includes a grandparent state 711 and a parent dataset 712, which was created at timestamp "50" (as indicated by timestamp data 740) and whose data was stored in relation to data item "E1" at timestamp "100" (as indicated by item 750). The state graph 700 also includes a first child dataset 713 and a second child dataset 714, created at timestamp "150" as indicated by timestamp data 741 and 742, respectively. As indicated by items 751 and 752, data is stored in the first child dataset 713 and the second child dataset 714 in relation to data item "E2" at timestamp "160", and data is stored in the first child dataset 713 in relation to data item "E3" at timestamp "210". Unlike in Figure 6E, the values ​​of the stored data are not shown in Figure 7. The values ​​of the data stored in the first child dataset 713 and the second child dataset 714, respectively, in relation to the data item "E2" at timestamp "160", may be different from each other. In this example, the second child dataset 714 became an overlay of the first child dataset 713 at timestamp "180", as indicated by item 760. As described above, a data element represents all or part of a given data stored in the data store, and in this respect, data may consist of one or more data elements. In this example, the overlay data element selection metadata indicates that the overlay data elements "m1" and "m2" from the second child dataset 714 should be applied to the first child dataset 713, as indicated by item 760. The overlay data elements "m1" and "m2" may relate to different machine learning models and may consist of different machine learning model data. The overlay data element selection metadata indicates the specific data elements from the second child dataset 714 that will be used as the overlay dataset. The second child dataset, 714, may contain data elements that are not applied via the overlay.For example, the second child dataset 714 may contain an additional data element "m3" that is not overlaid. This can be true even if the first child dataset 713 also contains the corresponding "m3" data element. In the example, certain data elements from the overlay dataset that improve the machine learning system's behavior may be selected for application, while other data elements that do not improve the machine learning system's behavior may be suppressed from being applied.

[0063] Therefore, as the example shows, an overlay dataset is used to update data in one dataset with data in another dataset without actually copying any data from one dataset to the other. This is achieved in the example by modifying metadata for the overlay target dataset (the dataset to which the overlay dataset is applied) to indicate that the data will potentially be read from the overlay dataset, rather than from the dataset to which the overlay dataset is applied. The data may thus be read between two given timestamps associated with the overlay dataset. The timestamps may include a lower timestamp corresponding to when the overlay dataset was created (before it was overlaid). The timestamps may include a higher timestamp corresponding to when the overlay dataset was overlaid.

[0064] In this example, every piece of data forming a hierarchical state type stores a timestamp. In this example, the timestamp is a strictly increasing integer indicating when the data was updated. However, timestamps can take various different forms, while still indicating the order in which updates occurred. A timestamp may be a last modified timestamp, indicating when the data was last updated, but a timestamp does not necessarily indicate the most recent update in all examples.

[0065] When reading state data items from a given dataset to which an overlay dataset has been applied, if the data read from the given dataset has been modified (for the last time) between the time the overlay dataset was created and the time the overlay dataset was applied to the given dataset (also known as "facilitated"), the overlaid data will be read from the overlay dataset and applied on top of the data read from the given dataset. As described above, the overlaid data may be limited to specific overlay data elements, for example, depending on the state type.

[0066] An exemplary sequence of operations for generating an exemplary state graph 700 is described below. First, a first dataset 711 with state ID "state1" is created empty and without a parent. At timestamp "50", a second dataset 712 with state ID "state2" is created as a child of the first dataset 711. The second dataset 712 is empty when it is created, and the first dataset 711 becomes immutable when the second dataset 712 is created. At timestamp "100", the second dataset 712 is in the root state, and at timestamp "100", the data item "E1" is written into the second dataset 712. At timestamp "150", a third dataset 713 and a fourth dataset 714, with state IDs "state3" and "state4", respectively, are created as children of the second dataset 712. The third dataset 713 and the fourth dataset 714 are empty when they are created, and the second dataset 712 becomes immutable when the third dataset 713 and the fourth dataset 714 are created. At timestamp "160", both the third dataset 713 and the fourth dataset 714 are roots, and at timestamp "160", the data item "E2" is written into the third dataset 713 and the fourth dataset 714. At timestamp "180", the overlay data elements "m1" and "m2" are selected for overlay application on the third dataset 713, and the fourth dataset 714 is overlaid on the third dataset 713. The fourth dataset 714 becomes immutable when it becomes an overlay on the third dataset 713. At timestamp "210", the third dataset 713 is the only root dataset (and therefore not immutable), and at timestamp "210", the data item "E3" is written to the third dataset 713.

[0067] The exemplary data store represented by state graph 700 may store the following data: { stateId: state2, key: E1, data: {[m1(E1)2, m2(E1)2, m3(E1)2]}, timestamp: 100}, { stateId: state3, key: E2, data: {[m1(E2)3, m2(E2)3, m3(E2)3]}, timestamp: 160}, { stateId: state4, key: E2, data: {[m1(E2)4, m2(E2)4, m3(E2)4]}, timestamp: 160}, and { stateId: state3, key: E3, data: {[m1(E3)3, m2(E3)3, m3(E3)3]}, timestamp: 210}.

[0068] In such example data, "mi(Ej)" k This indicates a data element in the k-th dataset that has another value related to the i-th machine learning model, which is stored in relation to the key Ej.

[0069] The exemplary datastore represented by state graph 700 may store the following metadata: { stateId: state1, startTime: 0, endTime: 50}, { stateId: state2, startTime: 50, endTime: 150, parent: state1}, { stateId: state3, startTime: 150, parent: state2, overlay: { state4, [m1, m2], (150, 180)}}, and { stateId: state4, startTime: 150, endTime: 180, parent: state2}.

[0070] In this example, the third dataset 713 is a child of the second dataset 712, but it does not itself contain the data item "E1" from the second dataset 712. Also, even though the fourth dataset 714 is an overlay of the third dataset 713, the data in the fourth dataset 714 associated with the data item "E2" is not actually copied into the third dataset 713. Instead, metadata links the second dataset 712, the third dataset 713, and the fourth dataset 714, and as a result, as will be explained below, data can be read from a mixture of these datasets without any data being copied from one dataset to another.

[0071] Therefore, metadata is separate from the data stored in the datastore and provides information about that data. In the example, metadata provides information at the dataset level, not at the data level or data element level. In the example, metadata can be modified independently of other data. Minor changes to metadata, which may be quick to make, can result in significant changes to valid data that can be read from the datastore without requiring a significant amount of data to be copied.

[0072] In this example, the first dataset 711 is the root between timestamps "0" and "50", the second dataset 712 is the root between timestamps "50" and "150", and the fourth dataset 714 is the root between timestamps "150" and "180". The third dataset 713 is the root at timestamp "150" and is the current root.

[0073] An exemplary (simplified) read logic for reading from the state graph 700 is described below. An exemplary write logic is also described below. Read and write operations may be described together in this specification, but a read does not necessarily imply that a write will occur immediately. The same data item may be read multiple times before a write is performed into the root dataset.

[0074] To read the data item "E1", the current dataset, i.e., the third dataset 713, is searched (also called "queried"). "E1" is not found in the third dataset 713. The second dataset 712 is identified via parent metadata and queried as the parent dataset of the third dataset 713, and "E1" is found with a modified timestamp of "100". In this respect, the overlay is not applicable, and therefore the data associated with "E1" is returned. Referring to the example above, the returned data would be [m1(E1)2, m2(E1)2, m3(E1)2]. The returned data may be written directly to the root dataset, i.e., the third dataset 713, in relation to the data item "E1". When written back into the third dataset 713, the data item "E1" will have a timestamp greater than "180". Subsequent read requests for "E1" will retrieve the returned data from the third dataset 713, rather than retrieving the data again from the second dataset 712.

[0075] To read the "E2" data item, the current dataset, i.e., the third dataset 713, is searched and "E2" is found with a modified timestamp of "160". The modified timestamp of "160" read from the third dataset 713 is within the active overlay period for the fourth dataset 714, i.e., from "150" to "180". Thus, the fourth dataset 714 is identified via the overlay metadata, and the data elements "m1(E2)4" and "m2(E2)4" are read from the fourth dataset 714. In this example, the data element "m3(E2)4" is not read from the fourth dataset 714 in light of the overlay data element selection metadata. In this example, "m1(E2)4" and "m2(E2)4" as read from the fourth dataset 714 replace the data elements "m1(E2)3" and "m2(E2)3" read from the third dataset 713, but the data element "m3(E2)3" as read from the third dataset 713 is not replaced by the data from the fourth dataset 714. The data associated with "E2" that is being modified, namely [m1(E2)4, m2(E2)4, m3(E2)3], is returned. The "E2" data read from the fourth dataset 714, namely "m1(E2)4" and "m2(E2)4", or the modified data of that name, namely "m1(E2) 4_mod " and "m2(E2) 4_modThe data is then written directly back to the root dataset, i.e., the third dataset 713, along with "m3(E2)3" and a modification timestamp greater than the overlay application timestamp of "180". Data read from the third dataset 713 and / or the fourth dataset 714 may be modified by the machine learning system before being written back to the root dataset. In general, writes are performed after the data read from the datastore has been modified by the machine learning system. Therefore, the data written to the root dataset may be the data that is read, or a modified version of the data that is read. When an overlay dataset is applied to another dataset, no new state ID is created, whether it is applied for the overlaid dataset or to the dataset to which the overlay dataset is applied. If applicable, only the metadata of the existing root dataset is modified in order to redirect reads to the overlay dataset. In this sense, the overlay dataset effectively becomes the immutable part of the contents of the root dataset.

[0076] To read the "E3" data item, the current dataset, i.e., the third dataset 713, is searched, and "E3" is found with a modification timestamp of "210". The overlay is not applicable in this respect because the fourth dataset 714 was overlaid on the third dataset 713 (at timestamp "180"), and "E3" was written into the third dataset 713 (at timestamp "210"). Therefore, "E3" in the third dataset 713 should already contain any changes made to "E3" in the fourth dataset 714, if they exist. The data associated with "E3", i.e., [m1(E3)3, m2(E3)3, m3(E3)3], is returned from the third dataset 713 without modification.

[0077] Overlays can also be applied across changes to child states. State reads take all applicable overlays into account and reconstruct the active state accordingly.

[0078] When exploring (also called "reading") a data item, overlays added after the data item was last processed may still be checked against the data item. This is the case when the overlay end time is greater than the timestamp of the data item's (last) modification, even if the overlay start time is after the timestamp of the data item's (last) modification. This is because, for example, if the overlay changes how the data item was resolved, the data item may be in the overlay but not in any of its primary parent datasets. As a result, even if the timestamp of the data item's (last) modification is outside the time range of the overlay, that information can still be included when retrieving the data item.

[0079] More specifically, consider a state store comprising a first dataset, a second dataset which is the root dataset created as a child of the first dataset at timestamp "150", and a third dataset which is also created as a child of the first dataset at timestamp "150", but becomes an overlay of the second dataset at timestamp "180". Also consider that the first dataset contains a data item "E1" with data element "m1" having the value "15", the third dataset contains a data item "E1" with data element "m1" having the value "20", and that the overlay data element selection metadata indicates that data elements "m1" and "m2" should be applied to the second dataset. In this example, "E1" was written to the first dataset several times before timestamp "150", and then "E1" was written only to the third dataset between timestamps "150" and "180", i.e., "E1" was not written to the second dataset either. The read logic, for example, if it finds "E1" with timestamp "75" in the first dataset, also searches the third dataset (which was added as an overlay at timestamp "180") and applies its overlay to the data read from the first dataset. This also applies when the data item exists only in the overlay, for example, if "E1" was never written to the first dataset at all. If such a data item is not found in any parent dataset of the root dataset, the data item will have a valid read timestamp of "0" (or the smallest possible different timestamp value) when checking the overlay.

[0080] Figures 8A and 8B illustrate how data and metadata can be stored in a data store, following an example.

[0081] In this example, entity 800, sometimes called a “record,” represents exemplary information stored in the data store. In this example, entity 800 includes a stateId field 801 with the value “state1,” indicating that the information shown within entity 800 is associated with a dataset to which the state ID “state1” has been assigned. In this example, entity 800 also includes a data item field 802 with the value “E1,” indicating that entity 800 stores data relating to data item “E1.” In this example, entity 800 also includes a data field 803 containing data elements [m1, m2, m3]. In this example, “m1,” “m2,” and “m3” each have one or more respective values ​​associated with their respective machine learning models. In this example, entity 800 also includes a timestamp field 804 with the value “100,” indicating that “E1” was updated at timestamp “100.”

[0082] In this example, entity 810 represents exemplary metadata. In this example, entity 810 includes a stateId field 811 with the value "state3", indicating that the metadata shown within entity 810 is associated with a dataset to which the state ID "state3" is assigned. In this example, entity 810 also includes a startTime field 812 with the value "150", indicating that the dataset with state ID "state3" was created at timestamp "150". In this example, entity 810 also includes a parent field 813 with the value "state2", indicating that the dataset with state ID "state2" is the parent of the dataset with state ID "state3". In this example, entity 810 also includes an overlay field 814 with the value "state4, [m1, m2], (150, 180)" which indicates (i) that the dataset with state ID "state4" is an overlay of the dataset with state ID "state3", (ii) that only data elements "m1" and "m2" should be applied from the overlay dataset (with state ID "state4"), and (iii) that the upper timestamp "180" indicates when the overlay dataset (with state ID "state4") became an overlay of the dataset with state ID "state3", and that the overlay dataset (with state ID "state4") has upper and lower timestamps "150" and "180", respectively. Although not shown in Figure 8B, entity 810 may also include, for example, an endTime field indicating when a given dataset became immutable, and / or one or more additional overlay fields associated with one or more additional overlays of a given dataset.

[0083] Figure 9 shows another state graph 900 representing a different exemplary dataset. Exemplary graph 900 demonstrates unrelated states. In this example, the datastore comprises a great-grandparent dataset 911, a grandparent dataset 912, a parent dataset 913, a parent overlay dataset 914, a child dataset 915, and a child overlay dataset 916. In this example, datasets 911-916 are identified using identification data in the form of state IDs "state1"-"state6," respectively. In this example, the parent overlay dataset 914 is a child of the grandparent dataset 912 and is also an overlay of the parent dataset 913. In this example, the child overlay dataset 916 is an overlay of the child dataset 915 but is not a child of the parent dataset 913. In detail, in this example, the parent dataset 913 itself has an overlay dataset in the form of the parent overlay dataset 914. In the configuration shown in Figure 9, both the parent dataset 913 and the parent overlay dataset 914 are still immutable.

[0084] Overlays often share a parent dataset with the overlay target dataset (the dataset to which the overlay is applied), but this is not always the case. Irrelevant datasets can be overlaid. In such cases, the overlay may use an overlay start time of "0". This feature can be used, for example, to insert mature new model data into an existing system without having to copy all the data from the mature new model into the existing system. In the illustrative graph 900, the child overlay dataset 916 corresponds to an (initially) irrelevant state.

[0085] Therefore, a relevance of parent state relationships to the definition of a state can be observed. The state relationship metadata for a state ID cannot be altered without significantly changing the data accessible within that state, since the valid data associated with that state is the result of a mixture of states from the parent dataset and the overlay.

[0086] Figure 10 shows another state graph 1000 representing another exemplary dataset. The exemplary dataset represented by state graph 1000 is similar to the exemplary dataset represented by state graph 900, except that the fourth dataset 1014 is an overlay of the fifth dataset 1015 instead of the third dataset 1013. Thus, in this example, the fifth dataset 1015 has two overlays, namely the fourth dataset 1014 and the sixth dataset 1016. Additionally, in this example, the sixth dataset 1016 is a child of the third dataset 1013. As specific examples, consider (i) the fourth dataset 1014 comprises a data item "E1" having data elements "m14" and "m24", and the fourth dataset 1014 becomes an overlay of the fifth dataset 1015 at a timestamp of "50", (ii) the sixth dataset 1016 also comprises a data item "E1" having data elements "m16" and "m26", and the sixth dataset 1016 becomes an overlay of the fifth dataset 1015 at a later timestamp of "100", and (iii) the fifth dataset 1015 also comprises a data item "E1" having data elements "m15" and "m25" with a modified timestamp of "75".Assuming that all overlay data elements are read from the fourth dataset 1014 and the sixth dataset 1016, the read logic would (i) first find the data item "E1" in the fifth dataset 1015 with a modified timestamp of "75", and (ii) identify the fourth dataset 1014 as an overlay for the fifth dataset 1015 based on the overlay metadata, but since the overlay timestamp of "50" for the fourth dataset 1014 is earlier than the modified timestamp of "75", the data in the fourth dataset 1014 This does not involve searching for the data item "E1", (iii) based on the overlay metadata, the sixth dataset 1016 is identified as an overlay of the fifth dataset 1015, and since the overlay timestamp "100" for the sixth dataset 1016 is later than the modified timestamp "75", the data item "E1" is searched for in the sixth dataset 1016, and (iv) for the data item "E1", instead of returning data elements "m15" and "m25" from the fifth dataset 1015, data elements "m16" and "m26" are returned from the sixth dataset 1016. Data element "m1." 6_mod " and "m2 6_mod That is, the modified "m16" and "m26" will be written into the fifth dataset 1015 in relation to the data item "E1". As explained above, such writes do not have to be performed immediately after such reads.

[0087] In terms of execution, each read into a separate dataset and overlay is a separate read operation into the datastore. Parent and overlay logic can be relatively complex and may be difficult to execute as a single query on the datastore. Therefore, depending on how many datasets are involved, some read operations may be performed before the given data is returned. However, all writes are made into the root dataset. Therefore, the next time the data is read, it is read directly from the root dataset as a single read. However, when a new dataset is created (as an empty dataset), all reads are from the parent, involving at least two read operations. In some implementations, new datasets may be populated relatively quickly with the data that is most frequently modified. Additionally, the number of read operations may decrease over time and tend to be skewed towards previous operation rates. Nevertheless, determining that a particular data item does not exist in the valid datasets (a mixture of applicable datasets in the graph) involves reading from all relevant datasets until the earliest dataset has been read. This increases read operations whenever a new dataset is created from the current root. To mitigate this, a cleanup operation may be configured to consolidate older datasets together to reduce the number of datasets in the hierarchy. This can limit the number of read operations required. The cleanup operation may be performed periodically or in other ways.

[0088] Figure 11 shows another state graph 1100 representing an exemplary data store. The exemplary graph 1100 demonstrates the eligible state.

[0089] The hierarchical state cleanup operation addresses both the potential performance degradation and datastore size caused by the ever-increasing number of hierarchical states. As shown, performance potentially degrades as more state layers are created and linked to each other. Discovering data items can take an increasing amount of time because an increasing number of parent datasets may need to be explored. This is especially true if the data item does not exist in any of the dataset layers, as this forces the lookup to go through the entire dataset history. The number of queries increases linearly with the number of datasets. This problem grows as datasets are facilitated, creating more overlays. Data items may still be found in overlays when they are not found in the main branches of the state tree, and therefore overlays are also checked.

[0090] To manage such potential performance degradation, older datasets may be cleaned up as part of a hierarchical state cleanup operation to reduce the number of queries that need to be performed when looking for a particular data item. This operation also saves space in the datastore. In the example, non-hierarchical datasets are not cleaned up. This does not significantly affect performance when non-hierarchical datasets are small. With respect to the hierarchical state cleanup operation procedure, dataset layers eligible for cleanup are folded into a single dataset layer, which we refer to herein as the “target state,” thus preventing extra reads. The target state is the lowest common ancestor of dataset layers pointed to by a root with a parent that is locked (in other words, immutable) before a configurable cutoff. Datasets eligible for cleanup are (i) the strict ancestors of the target dataset, (ii) the overlays of the strict ancestors of the target dataset, and (iii) the overlays of the target dataset.

[0091] In the example graph 1100, the second dataset 1112 is the lowest common ancestor of the datasets pointed to by the root dataset (the fourth dataset 1114 and the fifth dataset 1115), with a parent (dataset 1111) locked before the cutoff 1170. Therefore, dataset 1112 is in the target state. It is not necessarily eligible for cleanup itself. Datasets 1113, 1114, and 1115 are descendants of the target dataset, i.e., dataset 1112. Therefore, they are also not eligible for cleanup. Dataset 1111 is the exact ancestor of the target dataset, i.e., dataset 1112. Therefore, dataset 1111 is eligible for cleanup.

[0092] In this example, the cleanup procedure begins with identifying the target dataset. Datasets eligible for cleanup are identified. All relevant data from the eligible datasets is merged into the target dataset. Overlays are applied where relevant, resulting in no data loss. The target dataset's parent references are removed, making the target dataset the new, most distant ancestor of the dataset pointed to by the root. Any overlays applied to the target dataset are also removed. The eligible datasets for cleanup are completely removed.

[0093] Figure 12A shows another state graph 1200 representing a different exemplary datastore. Exemplary graph 1200 demonstrates hierarchical state cleanup. Exemplary graph 1200 represents the datastore before cleanup is performed.

[0094] In this example, the datastore consists of a great-grandparent dataset 1211, a grandparent dataset 1212, a parent dataset 1213, and a child dataset 1214. With four consecutive state layers, datasets 1211 and 1212 are eligible datasets for cleanup. Dataset 1213 is the target dataset. The data from datasets 1211, 1212, and 1213 are merged and written to dataset 1213. The order in which the various steps are performed ensures data consistency throughout the cleanup procedure. The valid data in the target dataset is determined by reading data from the target dataset as a "virtual root" in order to merge the data into the target dataset. For each data item present in the eligible datasets and the target dataset, the data item is read from the virtual root using the hierarchical state read logic described above. The obtained data is then written to the target dataset. The target dataset is not necessarily locked; in such cases, the target dataset is also the live root dataset. In this special case, the data contained in the target dataset is still subject to modification. In such cases, the cleanup operation is replaced by a parallel write. The parallel write ensures that the most recent data is written to the target live root dataset. In such cases, the merge step for that particular data item is rendered obsolete and aborted. Because the write is atomic, there is no risk of obtaining corrupted data resulting from the mixing of data written by cleanup and external sources. Generally, if a data item to be moved already exists in the target dataset with a modified timestamp greater than the timestamp of the data item to be moved, the data item in the target dataset will not be overwritten. This would still happen if the target dataset were locked.More specifically, writes are performed atomically, provided that the data item does not already exist in the target dataset, or that the modified timestamp of a data item already in the target is less than or equal to the modified timestamp of the data being written to the target dataset. The cutoff line is indicated by the dashed line 1270.

[0095] In the example, the timestamp written back to the merged data item is the latest timestamp among all the timestamps of the data items merged into the merged data item. This is true even if the latest data item in the example is from an overlay dataset that contains only a subset of the final data in the merged data item.

[0096] Figure 12B shows another state graph 1202 representing a different exemplary datastore. The exemplary graph 1202 shown in Figure 12B corresponds to the exemplary graph 1200 shown in Figure 12A after a cleanup operation has been performed.

[0097] Figure 13A shows another state graph 1300 representing a different exemplary data store. Exemplary graph 1300 demonstrates hierarchical state cleanup using a concrete example.

[0098] The following is an example sequence of actions to generate state graph 1300 before cleanup: Dataset 1311 is created empty and without a parent state. At timestamp "30", data item "E1" is written into dataset 1311. At timestamp "40", data item "E2" is written into dataset 1311. At timestamp "50", datasets 1312 and 1313 are created as children of dataset 1311 (empty), and dataset 1311 becomes immutable at timestamp "50". At timestamp "60", data item "E3" is written into datasets 1312 and 1313. At timestamp "65", data item "E4" is written into dataset 1312. Overlay data elements "m1" and "m2" are selected, and at timestamp "70", dataset 1312 is overlaid on dataset 1313. The overlaid dataset 1312 then becomes immutable at timestamp "70". At timestamp "80", data item "E2" is written to dataset 1313. At timestamp "100", dataset 1314 is created as a child of dataset 1313 (empty). At timestamp "100", dataset 1313 becomes immutable.

[0099] In this example, the target dataset is dataset 1313, and the datasets eligible for cleanup are datasets 1311 and 1312. For each data item present in datasets 1311, 1312, and 1313, valid data is read from a virtual root pointing to dataset 1313 and then written to dataset 1313. Overlay dataset 1312 is valid for data saved up to timestamp "70".

[0100] The simplified cleanup logic is as follows: For merging "E1", "E1" is not found in dataset 1313. No data is found in the applicable overlay dataset 1312, but "E1" is found in dataset 1311. The "E1" found in dataset 1311 is copied into dataset 1313. For merging "E2", "E2" is found in dataset 1313. The "E2" found in dataset 1313 is not modified because it already exists in dataset 1313 without an applicable overlay. For merging "E3", "E3" is found in dataset 1313. However, the data found in dataset 1313 is updated with data related to the overlay data elements "m1" and "m2" found in the applicable overlay dataset 1312. Valid data is written to dataset 1313. When merging "E4", "E4" is not found in dataset 1313. "E4" is not found in dataset 1311 either. "E4" is found in dataset 1312. Valid data only includes data related to "m1" and "m2". Valid data is written to dataset 1313. Once the data items are merged into dataset 1313, datasets 1311 and 1312 are deleted.

[0101] Figure 13B shows another state graph 1302 representing a different exemplary datastore. The exemplary graph 1302 shown in Figure 13B corresponds to the exemplary graph 1300 shown in Figure 13A after a cleanup operation has been performed. In effect, the “E1” data in dataset 1311 has been moved entirely to dataset 1313. The “E2” data in dataset 1313 remains unchanged. The “E3” data in dataset 1313 has been updated using data found in dataset 1312 related to “m1” and “m2”. The “E4” data in dataset 1312 related to “m1” and “m2” has been moved to dataset 1313.

[0102] The frequency at which hierarchical state cleanup operations are performed may be set, for example, by the operator. The length of the state snapshot history to be retained before cleaning them up may also be set, for example, by the operator.

[0103] During the merging process, which can take a relatively long time (e.g., several hours), additional changes may still be made to the datastore, provided that any modifications are made to the active cleanup operation after the cutoff. In the example, since concurrent writes inevitably provide the most recent data, the hierarchical state cleanup operation is always superseded by concurrent writes.

[0104] In some examples, the source of the timestamp described herein may be reset. The examples provide a timestamp era technique for this point, where the timestamp has multiple parts. One of the parts may be incremented while the other parts remain constant. In response to a trigger, for example, a reset of the timestamp source, the constant part may be incremented, and the part that was being incremented may be reset. For example, a multi-part timestamp may initially be incremented as (0,0), (0,1), (0,2), and (0,3), and in response to a trigger, it may be incremented as (1,0), (1,1), (1,2), etc. In response to further triggers, the timestamp may be incremented as (2,0), (2,1), (2,2), etc.

[0105] As described above, data storage and / or data stores may be divided into multiple different partitions, for example, for security reasons. Different partitions may be identified based on different partitionIds. Timestamps may be partition-based in that they are incremented at the partition level rather than at the overall system level. In the example, an entity or data item is deterministically hashed to a specific partition such that the timestamp for that entity or data item is strictly incrementing.

[0106] Regarding data deletion, data may be removed from the hierarchical state. If data exists only within the current root, it can simply be removed from the datastore. However, if data exists within the parent state and / or overlay state, it cannot be directly removed because all states other than the root are immutable. Instead, a marker is inserted into the current root state indicating the data to be considered deleted and when such deletion occurred. Subsequent reads, upon encountering the deletion marker, stop reading at that point and do not return the data. However, the old data that should be considered deleted still exists within the parent state and / or overlay state. Therefore, if a new root is created from a snapshot state, data that should be considered deleted still exists within the snapshot state. Additionally, the deletion marker, provided it is up-to-date, acts as an indicator to prevent the insertion of another marker into future roots if the data item in question is deleted again. In the example, the deletion marker is not inserted only if the data item in question exists only within an unfavored data element, such as an overlay on a model. Overlays effectively allow you to reverse deletions made in one dataset by overlaying data (from the overlay) onto data where the deletion marker was previously located in another dataset.

[0107] When a data item is cleaned up using a delete marker, the delete marker effectively causes the cleanup operation to ignore all state of that data item prior to that point. In the first example, consider a datastore that includes a target dataset, a parent dataset of the target dataset, and a grandparent dataset of the target dataset for the cleanup operation. Also consider that the parent dataset has a data item "E1" with a delete marker, and the grandparent dataset also has a data item "E1" but with a data element "m1" that has the value "30" (which may be shown as "E1: {m1: 30}"). After the cleanup, the target dataset will have no data at all for "E1" in light of the delete marker, and the parent dataset and grandparent dataset will be removed from the datastore that contains any delete markers within them. In the second example, consider that the datastore in the first example included an additional dataset between the parent dataset and the target dataset, and that the additional dataset also had a data item "E1" but with a data element "m1" that had the value "10" (which can be shown as "E1: {m1: 10}"). In the second example, the cleanup operation would place "E1: {m1: 10}" copied from the additional dataset into the target dataset, and then the additional dataset, parent dataset, and grandparent dataset would be removed from the datastore.

[0108] The overlay can also undo the delete marker. For example, consider a data store with a parent dataset having a data item "E1" with data element "m1" with the value "15" and data element "m2" with the value "20", and an updated timestamp of "75" (this may be shown as "E1: {m1: 15, m2: 20}, timestamp 75"). Also consider the first child dataset of the parent dataset, which was created at timestamp "150", is the root of the data store, and has a data item "E1" with a delete marker and an updated timestamp of "160" (this may be shown as "E1: delete, timestamp 160"). Consider further that the parent dataset's second child dataset was created at timestamp "150" and contains data element "m1" with value "20", data element "m2" with value "25", and data item "E1" with an updated timestamp of "170" (which may be represented as "E1: {m1: 20, m2: 25}, timestamp 170"). Additionally, consider that the second child dataset became an overlay of the first child dataset at timestamp "180", with overlay data element selection metadata indicating that only data element "m1" should apply to the first child dataset. In such an example, the read logic would find a delete marker for "E1" in the first child dataset and, in response, stop searching for the ancestors of the first child dataset. The read logic then checks the overlay, identifies the overlay from the second child dataset covering "150" to "180", and reads "m1" from the second child dataset. Thus, the returned data is "E1: {m1: 20}". The same logic may be used in cleanup operations such as those described herein. Such logic would also be applied if the deletion markers are in the second child dataset rather than the first child dataset, and the overlaid data elements are removed from the data item before returning them.If a deletion marker exists in the first dataset along with "E1", and the second child set is applied as a data-free overlay for "E1" over an applicable time period, then the read logic can read anything (if any) in "E1" in any ancestor of the first child dataset, and the deletion of "E1" can effectively be reversed. However, in other examples, the deletion marker will continue to be used.

[0109] Figure 14 shows another example of a state graph 1400 representing a datastore. The illustrative graph 1400 demonstrates recursive overlays. In this example, the first dataset 1411 is the grandparent dataset. The second dataset 1412 and the third dataset 1413 are both child datasets of the grandparent dataset. The fourth dataset 1414 is a child of the second dataset 1412, and therefore the second dataset is the parent of the fourth dataset 1413. The third dataset 1413 has two child datasets, namely the fifth dataset 1415 and the sixth dataset 1416. The fifth dataset 1415 is an overlay of the fourth dataset 1414. The sixth dataset 1416 is an overlay of the fifth dataset 1415. In this example, the fifth dataset 1415 (i) is an overlay of the fourth dataset 1414, (ii) has the third dataset 1413 as its parent dataset, (iii) has the first dataset 1411 as its grandparent dataset, and (iv) has the sixth dataset 1416 as an overlay, even if the fifth dataset 1415 itself is an overlay. When the fifth dataset 1415 is searched for data items, the third dataset 1413, the first dataset 1411, and / or the sixth dataset 1416 may be searched in a similar manner to how the search is performed with respect to the fourth dataset 1413.

[0110] Figure 15 shows another example of a state graph 1500 representing a data store. The exemplary data store represented by state graph 1500 corresponds to the exemplary data store represented by state graph 1400, except that the sixth dataset 1516 is an overlay of the fourth dataset 1514 and not an overlay of the fifth dataset 1515. Thus, the fourth dataset 1514 has two overlays, namely the fifth dataset 1515 and the sixth dataset 1516.

[0111] The example described above concerns a data store in the form of a database. An example concerning a data queue is described next. In this example, such a data queue stores feature vectors from a machine learning model. However, such a data queue may also store other data that should be output by the machine learning model.

[0112] As part of event processing, a model can output data onto one or more model-specific data queues that may be read next. As part of defining the queues, a model also defines the minimum duration for which data should remain in the queue. In a live system, data queues may be stored in persistent message queues. In this specific example, data queues are stored in Apache Kafka. However, in other examples, data may be stored in a different way. More specifically, there are other ways to implement the state layer using message queues, for example. For Apache Kafka topics that store data, the data retention period maps to the queue retention period. Topics are created by the controller as needed when a model is uploaded into the engine. However, topics are not deleted when a model is deleted, because the model may be regenerated immediately afterward, and the data is expected to still be there. If a model is permanently deleted, all data in the topic times out over time, leaving an empty topic in Apache Kafka that occupies minimal disk space. From the perspective of hierarchical queue states, data queues follow the state hierarchical principle described above. This is achieved on Apache Kafka by maintaining a separate topic for each active queue in each state and by stitching the queues together into a single logical queue for reading the complete content. Referring to Apache Kafka in detail, data cannot be removed from Apache Kafka queues, and therefore there is no data cleanup operation to be performed as such. Instead, queues are removed when they time out. Separate operations may be performed to remove any unused empty queues, and in general, to remove any unused and unlinked states from the datastore or metadata.

[0113] Figure 16A shows an exemplary queue 1600 in a single state, represented as a single Apache Kafka topic, i.e., "queue1-state1: [ topic1: 0 ]".

[0114] Figure 16B shows an exemplary queue 1602, where when a child state is created, a new topic is created for that state, and the metadata for the queue as a whole is updated to link the queues together. New messages are placed at the end of the most recent topic, i.e., "queue1-state2: [ topic1: 0, topic2: 23 ]". As part of the queue metadata, each topic has an "offset offset" that specifies the offset of the topic content within the entire queue. This offset is added to the message offset within each topic to obtain the message offset within the queue as a whole.

[0115] Figure 16C shows another exemplary queue 1604. Similar to hierarchical states, there can be multiple child topics based on the same parent topic, namely, "queue1-state2: [ topic1: 0, topic2: 23 ]" and "queue1-state3: [ topic1: 0, topic3: 23 ]".

[0116] Figure 16D shows another exemplary queue 1606. When states are overlaid, the root pointer changes to point directly to the overlaid topic, and the topic that is now outdated is removed, i.e., "queue1-state2: [ topic1: 0, topic3: 23 ]".

[0117] Figure 16E shows another exemplary queue 1608. There is a special case in all of these state behaviors, such that when the current topic is empty, the “parent” link of a new topic bypasses the empty topic entirely and points directly to the parent of the current topic. For example, “queue1-state3: [ topic1: 0, topic3: 23]”. This ensures that there is no topic in the middle of a queue that does not have data in it.

[0118] Data in data queues has a different state implementation than other state types. Therefore, cleanup operations behave differently for this state type. Due to the guarantee of data retention, the engine provides model queues and a way for data to be stored (Apache Kafka, not a database), and the state is only cleaned up when a model queue is found to be empty. When this is the case, the metadata corresponding to the model queue that has been made obsolete, as well as the corresponding topic itself, may be deleted. Message queues become empty when all the messages they contain eventually time out. In specific examples, a model data queue is eligible for cleanup if it satisfies the following conditions: (i) all of its ancestors, including itself, are empty, (ii) it is an ancestor of a queue pointed to by a root, and (ii) it is not directly pointed to by a root. However, other states may be used in other examples.

[0119] Figure 17A shows an exemplary model queue 1700 that is eligible for cleanup. "topic1" is empty, and all items it contained have timed out. "topic1" has no ancestors, and therefore all of its ancestors can be considered empty. "topic1" is the exact ancestor of "topic8" pointed to by the root. Therefore, "topic1" is eligible for cleanup. "topic2" is also empty. All of "topic2"'s ancestors (i.e., "topic1") are also empty. "topic2" is the exact ancestor of "topic8". Therefore, "topic2" is eligible for cleanup. "topic3" is also empty. All of "topic3"'s ancestors (i.e., "topic1") are also empty. "topic3" is also an ancestor of the topic pointed to by the root (i.e., "topic5"). Therefore, "topic3" is eligible for cleanup. "topic4" is empty. However, "topic4" is not an ancestor of any topic pointed to by the root. Therefore, "topic4" is not eligible for cleanup. "topic5" is not empty. Moreover, "topic5" is pointed to by the root. Therefore, "topic5" is not eligible for cleanup. "topic6" is empty, and all of its ancestors (i.e., "topic1" and "topic2") are also empty, and "topic6" is a strict ancestor of "topic8" which is pointed to by the root. Therefore, "topic6" is eligible for cleanup. "topic7" is not empty. Therefore, "topic7" is not eligible for cleanup. "topic8" is empty. However, one of "topic8's" ancestors (i.e., "topic7") is not empty, and "topic8" is directly pointed to by the root. Therefore, "topic8" is not eligible for cleanup. "topic9" is empty. "topic9" has no ancestors, and therefore its ancestors are considered empty. However, "topic9" is directly pointed to by the root.Therefore, "topic9" is not suitable for cleanup.

[0120] Figure 17B shows an exemplary model queue graph 1702 after the cleanup procedure is complete. When a topic is completely blank (in other words, contains no messages at all), such as "topic4" from the example above, its children bypass it to directly reference its parent (if any). In this specific example, and according to the exemplary conditions presented above, such blank topics are not cleaned up. However, such topics should remain relatively rare. More generally, in this specific example, topics that are not reachable from the root are not cleaned up. However, in other examples, empty topics such as "topic4" may be cleaned up.

[0121] Therefore, the examples described herein provide the ability to store multiple independent sets of data in a data store (such as a database) using hierarchical relationships.

[0122] A specific set of data is accessed using a state ID. In some examples, metadata is stored in the datastore along with information about the relationships between different state IDs. However, as mentioned above, metadata is not necessarily stored in the same datastore as the state data. Relationships can be parent relationships or overlay relationships. A single state ID can have 0 or 1 parent and 0 to "N" overlays. External clients accessing the datastore do so using a specific root state ID.

[0123] When saving data for a data item "E" with data elements "m1", "m2", "m3", the data is simply written into the root state and, if it exists, potentially overwrites anything else stored in the root state for "E". A timestamp or other strictly incrementing number indicating when the data was modified relative to other changes in the data store is also stored.

[0124] When reading, the client is looking for a specific data item, namely "E". If "E" exists in the root state, the data stored in the root state associated with "E" is returned to the client. Otherwise, the parent state is searched upwards in the parent hierarchy until "E" is found, or the state at the end (i.e., the top) of the tree is searched and "E" is determined not to exist.

[0125] Additionally, during the search, applicable overlays may be searched. When a state is applied as an overlay to another state, it is applied with at least one timestamp. In some examples, the overlay is applied with a first ("upper") timestamp "u" indicating when the overlay was applied to another state and optionally with a second ("lower") timestamp "t" indicating when the overlay was created. Data indicating the set of data elements to be applied from the overlay is also stored.

[0126] Once "E" is found, its timestamp "t" is examined to determine which overlay should be applied. For all overlays where t < t ≤ u in chronological order based on the upper timestamp, the data element "m" from each overlay is applied. Such data elements may be copied over data read from somewhere in the parent state hierarchy. The resulting data is then returned to the application making the query. "t" E Once "E" is found, its timestamp "t" is examined to determine which overlay should be applied. For all overlays where t < t ≤ u in chronological order based on the upper timestamp, the data element "m" from each overlay is applied. Such data elements may be copied over data read from somewhere in the parent state hierarchy. The resulting data is then returned to the application making the query. "t" E ≦ u, for all overlays, the data element "m" from each overlay is applied. Such data elements may be copied over data read from somewhere in the parent state hierarchy. The resulting data is then returned to the application making the query. n 」 from each overlay is applied. Such data elements may be copied over data read from somewhere in the parent state hierarchy. The resulting data is then returned to the application making the query. "t" EIf "E" is greater than the earlier timestamp of all existing overlays, then "E" is already saved along with the applied overlay and can therefore be returned as is. However, in the example, if such an overlay has changed how the data item was resolved, then later overlays will still be checked.

[0127] Cleanup operations can be performed in parallel with client reads and writes. This involves copying any data that does not exist in the target state, such as the root state, forward and collapsing the old state together. This uses atomic insertion operations so as not to overwrite any data that has been saved in parallel in the root state by the operating clients.

[0128] The techniques described herein may be implemented on top of Mongo, SQL, and Apache Kafka. Different implementation details may be involved.

[0129] The entire contents of a dataset may be identified by enumerating all data items present in all datasets within the data store, or at least all data items in the hierarchy from a particular root, and then querying each data item through the root dataset to see its valid data from that root.

[0130] Figure 18 shows another state graph 1800 representing a different exemplary data store. The exemplary state graph 1800 is referenced to summarize the various functions and effects of the features described herein.

[0131] Various measures (e.g., methods, devices, systems, computer programs, and computer-readable media) are provided for retrieving data in a data store. The data store comprises a first dataset 1811 and a second dataset 1812. A data item is searched for in the first dataset 1811 and / or the second dataset 1812. In response to the search finding a data item, the data stored in relation to the data item is returned. If the data item is found in the first dataset 1811, and the data item has been updated in the first dataset 1811 after the second dataset 1812 has become an overlay of the first dataset 1811, the return comprises returning the first data stored in relation to the data item in the first dataset 1811. If a data item is found in both the first dataset 1811 and the second dataset 1812, and the second dataset 1812 becomes an overlay of the first dataset 1811 after the data item has been updated in the first dataset 1811, the return includes returning the second data stored in relation to the data item in the second dataset 1812. The second dataset 1812 is identified based on the overlay metadata, which indicates that the second dataset 1812 is an overlay of the first dataset 1811.

[0132] Various measures (e.g., methods, devices, systems, computer programs, and computer-readable media) are also provided for storing data in a data store. The data store comprises a first dataset 1811 and a second dataset 1812. Data is stored in relation to data items in the first dataset 1811 and / or the second dataset 1812. The second dataset 1812 is applied as an overlay of the first dataset 1811. Overlay metadata is stored. The overlay metadata indicates that the second dataset 1812 is an overlay of the first dataset 1811.

[0133] Such a strategy uses overlays and overlay metadata to facilitate searching for or retrieving data items in a data store, where data items may reside in one or both of a first dataset 1811 and a second dataset 1812. The first dataset 1811 and the second dataset 1812 are separate datasets in that their data is not merged into a single dataset, but they are related via overlay metadata. A mixture of the first dataset 1811 and the second dataset 1812 thus allows valid data to be identified and retrieved from one or both of the first dataset 1811 and the second dataset 1812 without the two datasets being merged. Thus, overlay metadata is a data structure that controls how search operations are performed within the data store.

[0134] Such strategies can improve query response times by allowing responses to be constructed using data from different (potentially very large) datasets, compared to query responses that need to be delayed while different (potentially very large) datasets are merged.

[0135] Such a strategy executes a structured query based on the data item to be searched. Such a query may or may not have the data item to be searched, or it may identify it. The data item may uniquely identify the data to be retrieved from the data store.

[0136] Such measures, in particular, but in combination with other features described herein, may result in improved computational efficiency with respect to reduced memory read operations, improved security, improved scalability, improved throughput, and / or improved data retention.

[0137] The first dataset 1811 and the second dataset 1812 may have different technical characteristics. For example, the first dataset 1811 may be the root dataset, and the second dataset 1812 may be a non-root dataset. In such an example, data may be written to and read from the first dataset 1811, but data may only be read from the second dataset 1812.

[0138] For example, live data may be stored separately from other data, such as test data. Test data may be applied to live data as an overlay, without the need for test data to be copied over live data in a single copy operation. In the case of real-time transaction processing, transaction processing may continue based on live data while test data can be created and applied in parallel where appropriate, without the pause associated with copying. Live data and test data can be created and written independently, for example, until test data is applied as an overlay.

[0139] For example, a copy-on-write historical snapshot may be provided. Child states may be created from the old state. Assuming they are available, the event may be repeated using a different machine learning configuration. The impact that the changes would have had, compared to what happened, may then be seen. Those changes may be merged into the current live system without having to mature all the data again.

[0140] In some examples, the data item being explored is associated with an entity for which real-time anomaly detection is being performed. As described above, the strategies provided herein can reduce query response times, which can be particularly effective in the context of real-time anomaly detection.

[0141] In some examples, the data in the data store contains parameter data and / or state data for a machine learning model.

[0142] In some examples, if a second data is returned, the second data is stored in relation to a data item in the first dataset 1811. The search for the data may begin in the first dataset 1811. In such a case, the second data may be retrieved from the first dataset 1811 in a future search for the data item. This can reduce search and response times compared to searching both the first dataset 1811 and the second dataset 1812 for the data item, as it eliminates the need for additional read operations to read data from the second dataset 1812.

[0143] In some examples, in addition to the first data being stored in relation to data items in the first dataset 1811, the second data is stored in relation to data items in the first dataset 1811. Such examples allow for the selective retention of the first data, as opposed to the first data being overwritten by the second data. This may be particularly useful in examples where the data includes machine learning model data, since machine learning model data may be used in a live dataset (e.g., the first dataset 1811) and machine learning model data may be tested in a test dataset (e.g., the second dataset 1812). In such cases, valid machine learning model data in the live dataset may be selectively retained, but machine learning model data in the test dataset that is found to be valid in the test setting may be applied in combination with the machine learning model data in the live setting.

[0144] In some examples, timestamp data is stored in the data store. The timestamp data may indicate when the second data was stored in relation to a data item in the first dataset 1811. The timestamp data may also indicate whether future retrieval of the data item should include other datasets in addition to the first dataset 1811. For example, if the timestamp data indicates that the second data was stored in relation to a data item in the first dataset 1811 after an arbitrary overlay dataset was applied to the first dataset 1811, then future retrieval of the data item does not need to include any other such overlay datasets. This, in turn, can reduce query response time and the number of read operations involved in returning valid data associated with the data item can be reduced.

[0145] In some examples, the second dataset 1812 contains additional data. This additional data may not be stored in the first dataset 1811 in parallel with the storage of the second data items in relation to the data items in the first dataset 1811. In contrast to techniques where all data in the second dataset 1812 is copied into the first dataset 1811 in parallel, such examples allow data to be stored in dataset 1811 as needed.

[0146] In some such examples, additional data is stored in relation to data items in the second set 1812. The overlay data element selection metadata may indicate that the second data should be stored in relation to data items in the first dataset 1811, and that additional data should not be stored in relation to data items in the first dataset 1811. Based on the overlay data element selection data, additional data may be prevented from being stored in relation to data items in the first dataset 1811. Such examples provide a strictly defined and reliable representation of the valid data that will be constructed in the first dataset 1811 at the data element level.

[0147] In other such examples, additional data is stored in relation to additional data items in the second dataset 1812. Again, in contrast to the technique in which all data in the second dataset 1812 is copied into the first dataset 1811 in parallel, such examples allow data to be stored in dataset 1811 as needed at the data item level.

[0148] In some examples, the first dataset 1811 is a child dataset. The datastore may further include a third dataset 1813, which may be the parent of the first dataset 1811. Such examples allow for temporal data separation. For example, the third (parent) dataset 1813 may contain historical data, while the first (child) dataset 1811 may contain more recent data, such as current data.

[0149] In some examples, the first dataset 1811 potentially contains data that is not present in the third dataset 1813. Therefore, the third (parent) dataset 1813 may contain historical data, while the first (child) dataset 1811 may contain newer data, such as current data, that is not present in the historical data. This differs from other data store configurations in which a child dataset contains a subset of the data in the parent dataset.

[0150] In some examples, if the search does not find the data item in the first dataset 1811, the data item is searched for in the third dataset 1813. The third dataset 1813 may be identified using parent metadata, which may indicate that the third dataset 1813 is the parent of the first dataset 1811. The parent metadata allows the third dataset 1813 to be searched without potentially large amounts of data in the third dataset 1813 being copied into the first dataset 1811.

[0151] In some examples, the data store further comprises a dataset 1814, which is an overlay of a third dataset 1813. Data items may be explored within dataset 1814, which is an overlay of the third dataset 1813. This can improve accuracy in the system, for example, by selectively applying particularly useful data from different test datasets, so that multiple different test datasets can be applied as overlays to the first dataset 1811.

[0152] In some examples, as shown in Figure 18, the third dataset 1813 is also the parent of the second dataset 1812. Thus, multiple potentially divergent but distinct datasets can be derived from a common parent dataset and share each other.

[0153] In other examples not shown in Figure 18, the third dataset 1813 is not a parent of the second dataset 1812. Therefore, independent datasets may be used, for example, for data maturation. The fifth dataset 1815 shown in Figure 18 is an example of an overlay of the first dataset 1811 that does not share a common parent with the first dataset 1811.

[0154] In some examples, the third dataset 1813 became immutable when the first dataset 1811 and / or the second dataset 1812 were created. Thus, historical records of the data can be preserved.

[0155] In some examples, the second dataset 1812 became immutable when it was overlaid on the first dataset 1811. Additionally, new data writes may be limited to the live dataset.

[0156] In some examples, a cleanup operation is performed on a given dataset in a datastore. The cleanup operation may involve writing data from another dataset into the given dataset. The cleanup operation may involve removing metadata indicating a link between that other dataset and the given dataset. The cleanup operation may involve removing other datasets from the datastore. Such examples can reduce the search query time by reducing the number of read operations required to return positive or negative search results.

[0157] In some examples, the first dataset 1811 was empty when it was created. In some examples, the second dataset 1812 was empty when it was created. In examples where the first dataset 1811 and / or the second dataset 1812 are children of another dataset, the first dataset 1811 and / or the second dataset 1812 can be quickly created as empty sets, while the mixture of the first dataset 1811 and / or the second dataset 1812 and its parent dataset still effectively provides access to the (potentially historical) data of the parent dataset.

[0158] In some examples, the datastore further includes dataset 1815, which became an overlay of the first dataset 1811 before the second dataset 1812 became an overlay of the first dataset 1811. The second data may be returned in preference to returning the data stored in relation to data items in dataset 1815, which became an overlay of the first dataset 1811 before the second dataset 1812 became an overlay of the first dataset 1811. Therefore, the most recently updated data may be used.

[0159] In some examples, the datastore further comprises a dataset 1816, which is an overlay of a second dataset 1812. Data items may be explored within dataset 1816, which is an overlay of the second dataset 1812. Thus, a recursive overlay may be explored.

[0160] In some examples, if a data item is not found in the first dataset 1811, and the data item is found in the second dataset 1812, the return action includes returning the second data stored in relation to the data item in the second dataset 1812. Therefore, if the overlay adds a data item that was not present in the live dataset, for example, if the data item exists only in the overlay and not in the first dataset 1811, the action may be performed.

[0161] In some cases, a deletion marker associated with a given data stored in a data store is identified. The return of the given data may be deterred based on the deletion marker. Thus, an effective technique may be provided for data to be considered deleted, but such data may still be retained with the data store for other purposes.

[0162] Various methods (e.g., methods, apparatus, systems, computer programs, and computer-readable media) are also provided for searching for machine learning model data within the database. The database comprises live state 1811 and overlay state 1812. Keys are searched within live state 1811 and / or overlay state 1812. Keys are associated with one or more entities with which real-time anomaly detection is being performed. In response to the search finding a key, machine learning model data stored in relation to the key is returned. The machine learning model data comprises parameter data and / or state data for a machine learning model to be used to perform the real-time anomaly detection. If a key is found within live state 1811, and the key has been updated within live state 1811 after overlay state 1812 has become an overlay of live state 1811, the return comprises returning first machine learning model data stored in relation to the key within live state 1811. If the key is found in live state 1811 and overlay state 1812, and the overlay state 1812 becomes an overlay of live state 1811 after the key has been updated in live state 1811, the return comprises returning the second machine learning model data stored in relation to the key in overlay state 1812. Overlay state 1812 is identified based on overlay metadata, which indicates that overlay state 1812 is an overlay of live state 1811.

[0163] In the example described above, the root dataset is searched for the data item, and only if the data item is not found in the root dataset, another dataset is then identified using metadata and searched for the data item. In such an example, the other dataset is only read if it should be searched. In other examples, the root dataset and the other dataset are read before it is determined whether the other dataset needs to be searched for the data item.

[0164] Some of the examples described herein may be implemented via instructions stored in a computer-readable storage medium, such as a non-temporary computer-readable medium. The computer-readable medium may comprise one or more of the following: a rotating magnetic disk, a rotating optical disk, a flash random access memory (RAM) chip, and other mechanically moving storage media or solid-state storage media. When in use, the instructions are executed by one or more of the processors to cause the processors to perform the operations described above. The embodiments, variations, and examples described above should be understood as illustrative. Further embodiments, variations, and examples are conceivable. While some components of each example are described separately, it should be understood that functionality described with reference to one example may be suitably implemented in another example, and that some components may be omitted depending on the implementation. It should be understood that any feature described with respect to any example may be used alone or in combination with other features described, likewise in combination with one or more features of any other example, or in any combination of any other example. For example, features described with respect to system components may also be adapted to be performed as part of the described method. Furthermore, equivalents and modifications not described above may also be adopted without departing from the scope of the present invention as defined in the appended claims. [Explanation of Symbols]

[0165] 100, 102, 104 Transaction Processing System 110 Client Devices 120 Computer Networks 130 Retail Server 140 Payment Processor Servers 142 First data storage device 144 Second data storage device 146 Transaction Data 148 Supplementary data 150 Machine Learning Servers 160 Machine Learning Systems 162 Input Data 164 Output data 170 Local data storage devices 172 Supplementary data 200, 202 Data Storage Configuration 210 Machine Learning Systems 220 data bus 230, 232 Data storage devices 240 Historical Transaction Data 242 Supplementary data 250 data transfer channels 260 Data Storage Devices 270 logical memory layers 280 encrypted partitions 300 records 310 Current Transaction Data 320 Historical Transaction Data 330 Transaction Data 402 Machine Learning Systems 410 Input data 412 Input Data Interface 414 Machine Learning Model Platforms 416 scalar output 418 Alarm System 420 Output Data Interface 422 Output data 502 POS or user device 504 Retail System 506 Payment Processor System 508 Machine Learning Systems 510 Issuing Bank System 600, 602, 604, 606, 608 status graph 611 First dataset 612 Second dataset 613 Third dataset 614 The fourth dataset Data 640, 641, 642 700 Status Graph 711 Grandparents 712 Parent datasets 713 First child dataset 714 Second child dataset 740, 741, 742 Timestamp data 800 entities 801 stateId field 802 Data Item Fields 803 data fields 804 timestamp field 810 Entities 811 stateId field 812 startTime field 813 parent field 814 overlay fields 900 Status Graph 911 Great-grandparents dataset 912 Grandparents dataset 913 Parent dataset 914 Parent Overlay Dataset 915 child datasets 916 child overlay datasets 1000 status graph 1013 Third dataset 1014 The fourth dataset 1015 Fifth dataset 1016 The 6th dataset 1100 Status Graph 1111 dataset 1112 Second dataset 1113 datasets 1114 The fourth dataset 1115 The fifth dataset 1170 Cutoff 1200, 1202 State Graph 1211 Great-grandparents dataset 1212 Grandparents Dataset 1213 Parent dataset 1214 child datasets 1300, 1302 Status Graph Datasets 1311, 1312, 1313, 1314 1400 Status Graph 1411 First dataset 1412 Second dataset 1413 Third dataset 1414 The fourth dataset 1415 The fifth dataset 1416 The 6th dataset 1500 Status Graph 1514 The fourth dataset 1515 Fifth dataset 1516 The 6th dataset 1600, 1602, 1604, 1606, 1608 Queue 1700 Model Queue 1702 Model Queueing Graph 1800 Status Graph 1811 First dataset 1811 Live status 1812 Second dataset 1812 Overlay state 1813 Third dataset 1814 datasets 1815 Fifth dataset 1816 datasets

Claims

1. A computer method for searching for data in a data store, wherein the data store is The first dataset, and Second dataset Equipped with, The method described above is A step of searching for data items in the first dataset and / or the second dataset, In response to the search step finding the data item, the step of returning the data stored in relation to the data item: Equipped with, If the data item is found in the first dataset, and the data item is updated in the first dataset after the second dataset has become an overlay of the first dataset, the return step comprises the step of returning the first data stored in relation to the data item in the first dataset. If the data item is found in the first dataset and the second dataset, and the second dataset becomes an overlay of the first dataset after the data item has been updated in the first dataset, the return step comprises the step of returning the second data stored in relation to the data item in the second dataset. The method comprises the step of identifying the second dataset based on overlay metadata, wherein the overlay metadata indicates that the second dataset is an overlay of the first dataset. Computerized implementation method.

2. The computer implementation method according to claim 1, wherein the data item is associated with an entity for which real-time anomaly detection is being performed.

3. The computer implementation method according to claim 1 or 2, wherein the data comprises parameter data and / or state data for a machine learning model.

4. A computer implementation according to any one of claims 1 to 3, comprising the step of storing the second data in relation to the data item in the first dataset when the second data is returned.

5. The computer implementation method according to claim 4, wherein the storage step includes, in addition to storing the first data in relation to the data item in the first dataset, a step of storing the second data in relation to the data item in the first dataset.

6. The computer implementation method according to claim 4 or 5, further comprising the step of storing timestamp data in the data store, wherein the timestamp data indicates when the second data was stored in relation to the data item in the first dataset.

7. The computer implementation according to any one of claims 1 to 6, wherein the second dataset comprises further data, the further data is not stored in the first dataset at the same time that the second data item is stored in relation to the data item in the first dataset.

8. The computer implementation of claim 7, wherein the further data is stored in relation to the data item in the second dataset, and the overlay data element selection metadata indicates that the second data should be stored in relation to the data item in the first dataset and that the further data should not be stored in relation to the data item in the first dataset, and the method comprises the step of suppressing the storage of the further data in relation to the data item in the first dataset based on the overlay data element selection metadata.

9. The computer implementation method according to claim 7, wherein the further data is stored in relation to further data items in the second dataset.

10. The computer implementation method according to any one of claims 1 to 9, wherein the first dataset is a child dataset, the data store further comprises a third dataset, and the third dataset is the parent of the first dataset.

11. The computer implementation method according to claim 10, wherein the first dataset includes data that is not included in the third dataset.

12. In response to the search step failing to find the data item in the first dataset, the method comprises a step of searching for the data item in the third dataset. The aforementioned third dataset is an identified set that uses parent metadata, The parent metadata indicates that the third dataset is the parent of the first dataset. The computer implementation method according to claim 10 or 11.

13. The computer implementation method according to claim 12, wherein the data store further comprises a dataset which is an overlay of the third dataset, and the method comprises the step of searching for the data items in the dataset which is an overlay of the third dataset.

14. The computer implementation method according to any one of claims 10 to 13, wherein the third dataset is also the parent of the second dataset.

15. The computer implementation method according to any one of claims 10 to 13, wherein the third dataset is not the parent of the second dataset.

16. The computer implementation method according to any one of claims 10 to 15, wherein the third dataset is immutable when the first dataset and / or the second dataset are created.

17. The computer implementation method according to any one of claims 1 to 16, wherein the second dataset becomes invariant when it becomes an overlay of the first dataset.

18. The process includes the step of performing a cleanup operation on a given dataset in the data store, wherein the cleanup operation is performed The steps include writing data from another dataset into the given dataset, The steps include causing the metadata to indicate a link between the other dataset and the given dataset to be removed, The step of removing the aforementioned other dataset from the data store. Equipped with, A computer implementation method according to any one of claims 1 to 17.

19. A computer implementation according to any one of claims 1 to 18, wherein the first dataset was empty when the first dataset was created and / or the second dataset was empty when the second dataset was created.

20. The aforementioned data store, A dataset which became an overlay of the first dataset before the second dataset became an overlay of the first dataset, wherein the method includes a step of returning the second data in preference to returning data stored in relation to the data items in the dataset which became an overlay of the first dataset before the second dataset became an overlay of the first dataset, and / or A dataset which is an overlay of the second dataset, wherein the method comprises the step of searching for the data items in the dataset which is an overlay of the second dataset. Furthermore, The computer implementation method according to any one of claims 1 to 19.

21. If the data item is not found in the first dataset, and the data item is found in the second dataset, the return step comprises the step of returning the second data stored in relation to the data item in the second dataset, according to any one of claims 1 to 20.

22. The steps include identifying a deletion marker associated with a given data stored in the data store, A step of preventing the restoration of the given data based on the deletion marker, A computer implementation method according to any one of claims 1 to 21, comprising:

23. A system configured to perform the computer implementation method described in any one of claims 1 to 22.

Images