Maintaining temporal associations for event data in an event database

A method includes detecting a plurality of events associated assets of an enterprise system and generating database record structures based on the detected events, each database record structure comprising a first field storing an association key identifying one of the assets, a second field storing a first timestamp associated with a first detected event stored in that database record structure for its identified asset, and at least a third field storing a value associated with a second detected event stored in that database record structure for its identified asset. The method also includes maintaining indexing structures for the first, second and third fields, receiving a query to resolve a temporal association for a queried assets at a specified time, and utilizing the indexing structures to locate a particular one of the database record structures storing the temporal association for the queried asset at the specified time.

FIELD

The field relates generally to information processing, and more particularly to managing data in information processing systems.

BACKGROUND

Various information processing systems provide capabilities for searching and retrieving stored data. In an event database, for example, assets may be associated with different events or other characteristics over time. In such cases, it may be desired to provide query functionality to resolve the temporal association of a particular asset with a particular event or other characteristic. As the amount of data being stored increases, so does the amount of storage and other computing resources required for resolving or otherwise executing such queries of stored data.

SUMMARY

Illustrative embodiments of the present disclosure provide techniques for maintaining temporal associations for event data in data record structures. Advantageously, the temporal associations in the data record structures enable efficient query processing.

In one embodiment, a method comprises detecting a plurality of events, each of the events being associated with one of a plurality of assets of an enterprise system. The method also comprises generating a plurality of database record structures based at least in part on the detected events, each of the database record structures comprising a first field storing an association key identifying one of the plurality of assets, a second field storing a first timestamp associated with a first detected event stored in that database record structure for its identified asset, and at least a third field storing a value associated with a second detected event stored in that database record structure for its identified asset. The method further comprises maintaining indexing structures for at least the first field, the second field and the third field of the plurality of database record structures, receiving a query to resolve a temporal association for a queried one of the plurality of assets at a specified time, and utilizing the indexing structures to locate a particular one of the plurality of database record structures storing the temporal association for the queried asset at the specified time. The method is performed by at least one processing device comprising a processor coupled to a memory.

DETAILED DESCRIPTION

FIG. 1shows an information processing system100configured in accordance with an illustrative embodiment. The information processing system100is assumed to be built on at least one processing platform and provides functionality for maintaining temporal associations for event data. The system100includes an enterprise security operations center (SOC)102, which is assumed to monitor an enterprise system110accessed by a plurality of client devices104-1,104-2, . . .104-M (collectively, client devices104). The enterprise SOC102, client devices104and enterprise system110are coupled to a network106. Also coupled to the network106is an event database108, which may store various information relating to events associated with assets in the enterprise system110. The assets in the enterprise system110may include physical computing resources, virtual computing resources, or combinations thereof. The virtual computing resources may include virtual machines (VMs), software containers, etc.

The client devices104may comprise, for example, physical computing devices such as IoT devices, mobile telephones, laptop computers, tablet computers, desktop computers or other types of devices utilized by members of an enterprise, in any combination. Such devices are examples of what are more generally referred to herein as “processing devices.” Some of these processing devices are also generally referred to herein as “computers.” The client devices104may also or alternatively comprise virtualized computing resources, such as VMs, software containers, etc.

The client devices104in some embodiments comprise respective computers associated with a particular company, organization or other enterprise. At least portions of the system100may thus be referred to herein as collectively comprising an “enterprise.” Numerous other operating scenarios involving a wide variety of different types and arrangements of processing nodes are possible, as will be appreciated by those skilled in the art.

The event database108, as discussed above, is configured to store and record information relating to events associated with assets in the enterprise system110. Such information may include, but is not limited to, temporal associations stored efficiently in data record structures as described in further detail below.

The event database108in some embodiments is implemented using one or more storage systems or devices associated with the enterprise SOC102. In some embodiments, one or more of the storage systems utilized to implement the event database108comprises a scale-out all-flash content addressable storage array or other type of storage array.

Other particular types of storage products that can be used in implementing storage systems in illustrative embodiments include all-flash and hybrid flash storage arrays, software-defined storage products, cloud storage products, object-based storage products, and scale-out NAS clusters. Combinations of multiple ones of these and other storage products can also be used in implementing a given storage system in an illustrative embodiment.

Although not explicitly shown inFIG. 1, one or more input-output devices such as keyboards, displays or other types of input-output devices may be used to support one or more user interfaces to the enterprise SOC102or components thereof such as threat detection and remediation system112, as well as to support communication between the enterprise SOC102, the threat detection and remediation system112and other related systems and devices not explicitly shown.

In some embodiments, the client devices104may implement host agents that are configured for communication with the threat detection and remediation system112. Alerts or notifications generated by the threat detection and remediation system112of the enterprise SOC102are provided over network106to the client devices104via the host agents. The host agents are assumed to be implemented via the client devices104, which may comprise computing or processing devices associated with or operated by a system administrator, IT manager or other authorized personnel of the enterprise system110. For example, a given host agent may comprise a mobile telephone equipped with a mobile application configured to receive alerts from the enterprise SOC102or the threat detection and remediation system112and to provide an interface for the host agent to select particular remedial measures for responding to the alert or notification. Examples of such remedial measures may include blocking access by one or more of the client devices104to the enterprise system110or assets thereof, requiring user input or authentication by the client devices104to obtain information from or otherwise utilize one or more assets of the enterprise system110, triggering further review of the enterprise system110or assets thereof, etc. Remedial measures may also include detecting and correcting (e.g., by modifying a configuration thereof) one or more malfunctioning assets (e.g., due to security threats affecting such assets, misconfiguration of such assets, etc.). The remedial measures may further include identifying other assets in the enterprise system110that may be subject to similar malfunctioning (e.g., due to the same security threat or misconfiguration, due to dependencies between assets, etc.) and appropriately altering configurations thereof.

It should be noted that a “host agent” as this term is generally used herein may comprise an automated entity, such as a software entity running on a processing device. Accordingly, a security agent or host agent need not be a human entity.

Although shown as an element of the enterprise SOC102in this embodiment, the threat detection and remediation system112in other embodiments can be implemented at least in part externally to the enterprise SOC102, for example, as a stand-alone server, set of servers or other type of system coupled to the network106. In some embodiments, the threat detection and remediation system112may be implemented at least in part within one or more of the client devices104.

The threat detection and remediation system112in theFIG. 1embodiment is assumed to be implemented using at least one processing device. Each such processing device generally comprises at least one processor and an associated memory, and implements one or more functional modules for controlling certain features of the threat detection and remediation system112. In theFIG. 1embodiment, the threat detection and remediation system112comprises an event detection module114, a temporal association recording module116and an event query module118.

The event module114is configured to detect events associated with the assets of the enterprise system110. The events may associate or disassociate assets of the enterprise system110with values. For example, an asset may be a computing device of the enterprise system110, and the detected events may include login and logout events for the computing device. The login events associate users with the computing device, and the logout events disassociate users with the computing device. As another example, an asset may be an Internet Protocol (IP) address allocated for use by the enterprise system110, and the detected events may include Dynamic Host Configuration Protocol (DHCP) lease assignments. The DHCP lease assignments may associate or disassociate the IP address with a computing device of the enterprise system.

The temporal association recording module116is configured to generate a plurality of database record structures based at least in part on the detected events. Each of the database record structures may comprise: a first field storing an association key identifying one of the plurality of assets; a second field storing a first timestamp associated with an earliest detected event stored in that database record structure for its identified asset; and a third field storing a value associated with a second detected event stored in that database record structure for its identified asset. The value stored in the third field may comprise a predetermined value indicating an open database record structure, or a timestamp associated with a most recent event stored in that database record structure for its identified asset to indicate a closed database record structure. In some embodiments, each of the database record structures further comprises: a fourth field storing a set of resolved values for its identified asset from a closed database record structure for its identified asset; a fifth field storing modifications to temporal associations of its identified asset; and a sixth field storing a modification count specifying a number of modifications to the temporal association of its identified asset stored in that database record structure. Each of the detected events associates or disassociates one of the plurality of assets with one or more values, and the fifth field of each of the plurality of database record structures stores modifications to the temporal associations of its identified asset by recording association and disassociation of its identified asset with the one or more values.

It should be appreciated that the term “field” is intended to be construed broadly. Each database record may correspond to a row with each of the above-described first through sixth fields being its own column in that row. In some embodiments, one or more of the first through sixth fields may itself be part of a larger field (e.g., one or more of the first through sixth fields may be combined with other information as part of a larger field, or two or more of the first through sixth fields may be merged or combined as a single field, possible with other information). Each of the first through sixth fields may correspond to a set of designated bit positions or other designated locations within a larger field or other data structure.

The event query module118is configured to maintain indexing structures for at least the first field, the second field and the third field of the plurality of database record structures. The event query module118is also configured to receive queries to resolve temporal associations. For example, the event query module118may receive a query to resolve a temporal association for a queried one of the plurality of assets at a specified time and utilize the indexing structures to locate a particular one (e.g., a single one) of the plurality of database record structures storing the temporal association for the queried asset at the specified time.

It is to be appreciated that the particular arrangement of the enterprise SOC102, the threat detection and remediation system112, the event detection module114, the temporal association recording module116and the event query module118illustrated in theFIG. 1embodiment is presented by way of example only, and alternative arrangements can be used in other embodiments. As discussed above, for example, one or more of the enterprise SOC102, the threat detection and remediation system112, the event detection module114, the temporal association recording module116and the event query module118may in some embodiments be implemented internal to one or more of the client devices104. As another example, the functionality associated with the event detection module114, the temporal association recording module116and the event query module118may be combined into one module, or separated across more than three modules with the multiple modules possibly being implemented with multiple distinct processors or processing devices.

At least portions of the event detection module114, the temporal association recording module116and the event query module118may be implemented at least in part in the form of software that is stored in memory and executed by a processor.

It is to be understood that the particular set of elements shown inFIG. 1for maintaining temporal associations for event data is presented by way of illustrative example only, and in other embodiments additional or alternative elements may be used. Thus, another embodiment may include additional or alternative systems, devices and other network entities, as well as different arrangements of modules and other components.

By way of example, in other embodiments, the threat detection and remediation system112may be implemented external to the enterprise SOC102, such that the enterprise SOC102can be eliminated.

The enterprise SOC102, including the threat detection and remediation system112, and other portions of the system100may be part of cloud infrastructure as will be described in further detail below.

The threat detection and remediation system112and other components of the enterprise SOC102and information processing system100in theFIG. 1embodiment are assumed to be implemented using at least one processing platform comprising one or more processing devices each having a processor coupled to a memory. Such processing devices can illustratively include particular arrangements of compute, memory, storage and network resources.

The client devices104and the enterprise SOC102or components thereof (e.g., the threat detection and remediation system112, the event detection module114, the temporal association recording module116and the event query module118) may be implemented on respective distinct processing platforms, although numerous other arrangements are possible. For example, in some embodiments at least portions of the threat detection and remediation system112and one or more of the client devices104are implemented on the same processing platform. A given client device (e.g.,104-1) can therefore be implemented at least in part within at least one processing platform that implements at least a portion of the threat detection and remediation system112.

Additional examples of processing platforms utilized to implement the threat detection and remediation system112and other portions of the system100in illustrative embodiments will be described in more detail below in conjunction withFIGS. 8 and 9.

An exemplary process for maintaining temporal associations for event data will now be described in more detail with reference to the flow diagram ofFIG. 2. It is to be understood that this particular process is only an example, and that additional or alternative processes for maintaining temporal associations for event data may be performed.

In this embodiment, the process includes steps200through208. These steps are assumed to be performed by the threat detection and remediation system112utilizing the event detection module114, the temporal association recording module116and the event query module118. The process begins with step200, detecting a plurality of events, each of the events being associated with one of a plurality of assets of an enterprise system.

In step202, a plurality of database record structures are generated based at least in part on the detected events. Each of the database record structures may comprise: a first field storing an association key identifying one of the plurality of assets; a second field storing a first timestamp associated with an earliest detected event stored in that database record structure for its identified asset; and a third field storing a value associated with a second detected event stored in that database record structure for its identified asset. The value stored in the third field may comprise a predetermined value indicating an open database record structure, or a timestamp associated with a most recent event stored in that database record structure for its identified asset to indicate a closed database record structure. In some embodiments, each of the database record structures further comprises: a fourth field storing a set of resolved values for its identified asset from a closed database record structure for its identified asset; a fifth field storing modifications to temporal associations of its identified asset; and a sixth field storing a modification count specifying a number of modifications to the temporal association of its identified asset stored in that database record structure. Each of the detected events associates or disassociates one of the plurality of assets with one or more values, and the fifth field of each of the plurality of database record structures stores modifications to the temporal associations of its identified asset by recording association and disassociation of its identified asset with the one or more values.

Step202may include detecting a given event associated with a given asset and determining whether an open database record structure exists for the given asset. Responsive to determining that the open database record structure exists, step202may include modifying the open database record structure. Responsive to determining that no open database record structure exists for the given asset, step202may include creating a new database record structure for the given asset. An open database record structure for the given asset comprises a given database record structure having: a value in its first field matching a given association key identifying the given asset; and a value in at least one additional field comprising a modification count indicating that a number of association modifications stored in the given database record structure is below a designated threshold number of modifications. Modifying the open database record structure comprises appending the given event in the at least one additional field of the open database record structure, and incrementing the modification count in the at least one additional field of the open database record structure. Modifying the open database record structure may further comprise determining whether the incremented modification count in the at least one additional field of the open database record structure is equal to a designated threshold number of modifications and, responsive to determining that the incremented modification count in the at least one additional field of the open database record structure is equal to the designated threshold number of modifications, closing the open database record structure by updating the third field of the open database record structure from the predetermined value indicating an open database record structure to a given timestamp associated with the given event and creating a new open database record structure.

Creating the new database record structure comprises populating the first field of the new database record structure with the given association key, populating the second field of the new database record structure with a timestamp of the given event, populating the third field of the new database record structure with the predetermined value indicating an open database record structure, populating at least one additional field of the new database record structure with an association or disassociation corresponding to the given event, and incrementing a modification count of the new database record structure, the modification count indicating a number of association modifications stored in the at least one additional field in the given database record structure. Creating the new database record structure may further comprise, responsive to determining that a closed database record structure exists for the given asset, populating the at least one additional field of the new database record structure with at least one previously resolved association for the given asset from the closed database record structure for the given asset.

TheFIG. 2process continues with maintaining indexing structures for at least the first field, the second field and the third field of the plurality of database record structures in step204. In step206, a query to resolve a temporal association for a queried one of the plurality of assets at a specified time is received. In some embodiments, the queried asset comprises a computing device, the events comprise one or more login and logout events for the computing device, and the query may comprise determining a user logged in to the computing device at the specified time. In other embodiments, the queried asset comprises an IP address, the events comprise DHCP lease assignments, and wherein the query comprises determining a computing device assigned the IP address at the specified time.

In step208, the indexing structures are utilized to locate a particular one of the plurality of database record structures storing the temporal association for the queried asset at the specified time. Step208may include utilizing the indexing structure maintained for the first field to identify a set of database record structures having a value in the first field identifying the queried asset, the identified set of database record structures comprising an open database record structure and one or more closed database record structures, and utilizing the indexing structures maintained for the second field and the third field to identify a given database record structure storing the temporal association for the queried asset at the specified time from the identified set of database record structures.

As described above, illustrative embodiments provide techniques for generating and maintaining temporal associations for event data. Consider the problem of building associations from events collected over a period of time. For example, the enterprise SOC102and/or threat detection and remediation system112ofFIG. 1may be configured to monitor user login and logout events (e.g., users of client devices104logging into and out of assets of the enterprise system110). Such login and logout events may associate host names of the assets in the enterprise system110with IP addresses of the client devices104. The utility of such associations for security analysis is evident, such as in determining which user was logged onto a system when a security event occurs (e.g., infection by malware or adware, etc.). There is a need for techniques for efficient storage of temporal associations in database structures (e.g., event database108ofFIG. 1). Of course, it should be appreciated that temporal associations are not limited to use with tracking login and logout events for assets of enterprise system110. In other embodiments, for example, temporal associations may be utilized to track DHCP lease assignments or other types of events associated with the assets of the enterprise system110.

Without loss of generality, the problem of creating and maintaining temporal associations for event data may be considered with respect to the problem of linking U.S. presidents with places they were associated with during their lifetimes. This reduction gives a concrete dataset for reasoning and prototyping temporal associations.FIG. 3shows a table300, illustrating a portion of a database storing such events associated with U.S. presidents. Each row in table300records a significant event in the life of a U.S. president. Each row includes a timestamp (in theFIG. 3example, at year precision) and event code (e.g., born, died, start-term, end-term) that updates that president's association with a place (e.g., two-letter state codes for the birth and death states, and WH representing White House). For example, the first row in table300records the birth of George Washington, where George Washington is associated with Virginia (VA) in 1732. This association remains until there is a died event for George Washington in 1799.

With the trail of events shown in table300, two associations can be built: President→Place, and Place→President. Given this, various queries may be answered. For example, the query may be to identify the places that George Washington was associated with at various times, such as: in 1750—{VA}; in 1790—{VA, WH}; in 1798—{VA}; and in 2019—{ }. The query may alternatively be to determine who was associated with a particular place, such as VA, at a particular time, such as 1790—{George Washington, Thomas Jefferson, . . . } (e.g., where “ . . . ” represents all other U.S. presidents born in VA and alive in 1790 not shown in table300). The query may also be to determine who was associated with the White House at a particular time, such as in 1800—{John Adams}. Various other types of queries are possible. A system that can answer these queries efficiently should also be able to build temporal associations (e.g., user login/logout, DHCP lease assignments, etc.) useful for analyzing and remediating security events for enterprise system110. In some embodiments, it is desired that answering or resolving a query requires only a single look-up read.

To start, the problem of generating temporal associations is modeled by generalizing actions (e.g., login, logout, born, died, start-term, end-term, etc.) to events of the following type:

enum Type {ASSOCIATE,DISASSOCIATE}
That is, for the purpose of association building, an “interesting” event (e.g., one which is to be tracked via temporal associations) either makes an association or breaks an association. With the event type generalized, the event itself may be generalized as:

Given the above, events in table300can be modeled as follows:

Similarly, login and logout events can be modeled as follows:

With the events modeled, an efficient interface may be modeled as:

public interface AssociationService<V> {/* Record an observed association event */void record(Event(V) event);/* Get the values associated with a given key for a given time */Set(V) getAssociations(String key, Instant time);}

These interfaces enable a Test-Driven Development (TDD) specification that can be iterated over to evaluate prototypes as follows:

Given the above, some embodiments build a partially-persistent structure. An ordinary data structure is ephemeral, in that making changes to the data structure overwrites any previous versions. In some cases, however, it is desired to maintain multiple versions of the data structure. As used herein, a data structure is considered partially persistent if multiple versions of the data structure may be accessed (e.g., a current version and one or more previous versions), though it is assumed that only the current or newest version of the data structure may be modified. A data structure is considered fully persistent if multiple versions (e.g., a current version and one or more previous versions) may be both accessed and modified.

Various techniques may be used to implement both partially and fully persistent data structures. A need exists, however, for techniques that translate such methods for linked data structures to commodity databases that may be required for a particular implementation. Illustrative embodiments utilize the data record structure400shown inFIG. 4. The data record structure400includes an association key, a first time stamp (e.g., min(t)) a last time stamp (e.g., max(t1) or ∞), one or more previous or resolved values from previous records for the association key (e.g., V−1, V0), a modifications box of a fixed size that stores association modification events (e.g., t1-V1, t2-V2, t3-V3), and a current count of modification events stored in the data record structure. Each data record structure retains associations in the time range [first, last) for a given key value. The count, in some embodiments, is a bounded number of modification events. The count field may have an associated maximum value (e.g., countmax) that determines when a data record structure is split as described in further detail below. The countmaxvalue is a tuning parameter, which can be used to prevent the modifications field of the data record structure400from growing unbounded. The countmaxvalue may also be used in facilitating automated cleanup of records, use the last timestamp to automatically delete records. In some embodiments, the database storing the data record structures (e.g., event database108inFIG. 1) indexes on the “last” value to make cleanup easier.

Given a data record structure such as the structure400shown inFIG. 4, the associations that apply at a given time can be resolved using the algorithm500shown inFIG. 5. The filter {r: rkey=key)∧(r.first≤time<r.last)} returns the record needed to resolve a getAssociations(key, time) response. With indices on key, first and last fields, a database can furnish matching records efficiently.

In some embodiments, a node copying scheme for linked data structures is extended to documents in commodity databases. The algorithm600shown inFIG. 6provides pseudocode for recording temporal association events. The algorithm600makes use of a “new” command described below, as well as the “resolve” command described above. As noted above, the algorithm600supports the use of a configurable limit countmaxfor the maximum modifications allowed in a single data record structure. When an event is received, it is added to its applicable open record (e.g., key≡event.key ∧count<countmax). If this update brings the count up to the limit, the record is closed and a fresh one is started with its previous value set to the resolved value of the association as per the current record.

For a carefully chosen value of countmax, most updates should take a single read and write. Most commodity databases support “upserts” which can reduce the number of network exchanges to one. For example, a single findOneAndUpdate call may be used to record the majority of events as follows:

//Encode the event as a modificationDocument mod = new Document(TIME, event.time) .append(VALUE,event.value);mod.append(TYPE, event.type == ASSOCIATE(;//Update (or insert) the record to register this modificationcollection.findOneAndUpdate(and(eq(KEY, event.key),lt(MOD_COUNT, maxModifications)),combine(inc(MOD_COUNT, 1), min(FIRST_TIME, event.time),addToSet(MODIFICATIONS, mod)), upsert);
When a record splits, an extra save is used to ensure future events do not go to the now closed record.

Once the modification count reaches the configured maximum, the record is closed (e.g., it will not be returned on line 2 in the RECORD routine described above). This closure is aligned with setting the last field in the record to the time of the last of its recorded modifications. Next, a new record is created for future events for the same key.

The new record sets its first field to the last field of the current record, and its previous field to the resolved association at that time. Eventually, when a new event arrives line 2 in the RECORD routine described above returns the new record and the event is recorded as a modification in it.

Concretely, with countmax=3, consider the process of recording the following events:

The first event creates a new record for the key gwashington. The second is registered as a modification in that record. The third event is recorded as a modification as well, but it triggers a split. This is illustrated inFIGS. 7A and 7B.FIG. 7Ashows the data record structure710after the first two events are entered into the record.FIG. 7Billustrates splitting the data record structure710into data record structures720and730. More particularly, data record structure710shows the record for key gwashington after storing the first two events, data record structure720shows the third event for key gwashington closing the current record by setting the last time stamp to 1796 and opening a new data record structure730for future events, where the data record structure730has its previous field set to the resolved associations.FIG. 7Cshows a subsequent update to the data record structure730for the fourth event. The closed record (e.g., data record structure720) and the updated open record (e.g., data record structure730′) record associations for distinct time frames (e.g., [1732, 1796) and [1796, ∞), respectively). The value “∞” in the last field of a data record structure indicates an open database record structure.

In some embodiments, temporal associations are implemented by sharing a database instance that is used by a set of applications in a security information and event management (SIEM) system. In this context, the following runtime constraints apply: (i) disk usage should be minimized, (ii) automated record expiry should be supported, (iii) efficient write throughput and association lookups should be supported. A prototype implementation for this use case by a PartialPersistenceAssociation-Service. The implementation meets the functional requirements and is reasonably efficient. For example, with the following indexes:

The techniques described herein for generating and maintaining temporal associations for events are completely agnostic of the implementation choices (e.g., the particular type of database used) and can be easily ported to other environments (e.g., for a Software-as-a-Service (SaaS) implementation). For example, the record and query algorithms can be implemented as a completely server-less solution using cloud computing platforms.

The prototype includes a benchmark that records over a million randomly generated events and measures the throughput and disk footprint for the indices. Running the prototype on a consumer laptop with 1 thread synchronizing iterations, for 16,384 distinct keys, 8,192 distinct values and maximum modifications (e.g., countmax) set to 13, the benchmark achieves 3679.609±677.967 operations per second (ops/s) average, with minimum, average and maximum ops/s of U.S. Pat. Nos. 3,524,116, 3,679,609 and 3954.690 with a standard deviation of 176.066. The confidence interval (99.99%) is [3001.642, 4357.576], assuming a normal distribution.

Usable association events, in some embodiments, are assumed to be a very small subset of the overall stream of events so the rate achieved using the prototype implementation should be sufficient. Also, these numbers are for the simple implementation described above and do not account for optimizations such as multi-threaded implementations, asynchronous of buffered writes to the database, etc. The database footprint after recording more than a million events is as follows. There are 93,600 records with a total size of 65.9 megabytes (MB) and an average size of 738 bytes (B). Note that the number of records is less than one million as the countmaxis set to 13. There are four indexes (key, first and last values as described above, along with a database-specific record identifier index), with the total size of the indexes being 3.4 MB with an average size of 878 kilobytes (KB).

Illustrative embodiments provide techniques for maintaining temporal associations for event data. Advantageously, temporal associations are recorded in database records in a manner that permits efficient query, reducing the number of lookups required thus improving database performance. Further, by indexing key, first and last (or other user-defined fields) of the temporal associations maintained in the database records, query efficiency is further improved (e.g., in requiring that only a single database record be looked up for any particular query to a temporal association).

Illustrative embodiments of processing platforms utilized to implement functionality for maintaining temporal associations for event data will now be described in greater detail with reference toFIGS. 8 and 9. Although described in the context of system100, these platforms may also be used to implement at least portions of other information processing systems in other embodiments.

FIG. 8shows an example processing platform comprising cloud infrastructure800. The cloud infrastructure800comprises a combination of physical and virtual processing resources that may be utilized to implement at least a portion of the information processing system100inFIG. 1. The cloud infrastructure800comprises multiple virtual machines (VMs) and/or container sets802-1,802-2, . . .802-L implemented using virtualization infrastructure804. The virtualization infrastructure804runs on physical infrastructure805, and illustratively comprises one or more hypervisors and/or operating system level virtualization infrastructure. The operating system level virtualization infrastructure illustratively comprises kernel control groups of a Linux operating system or other type of operating system.

The cloud infrastructure800further comprises sets of applications810-1,810-2, . . .810-L running on respective ones of the VMs/container sets802-1,802-2, . . .802-L under the control of the virtualization infrastructure804. The VMs/container sets802may comprise respective VMs, respective sets of one or more containers, or respective sets of one or more containers running in VMs.

In some implementations of theFIG. 8embodiment, the VMs/container sets802comprise respective VMs implemented using virtualization infrastructure804that comprises at least one hypervisor. A hypervisor platform may be used to implement a hypervisor within the virtualization infrastructure804, where the hypervisor platform has an associated virtual infrastructure management system. The underlying physical machines may comprise one or more distributed processing platforms that include one or more storage systems.

In other implementations of theFIG. 8embodiment, the VMs/container sets802comprise respective containers implemented using virtualization infrastructure804that provides operating system level virtualization functionality, such as support for Docker containers running on bare metal hosts, or Docker containers running on VMs. The containers are illustratively implemented using respective kernel control groups of the operating system.

The processing platform900in this embodiment comprises a portion of system100and includes a plurality of processing devices, denoted902-1,902-2,902-3, . . .902-K, which communicate with one another over a network904.

The processing device902-1in the processing platform900comprises a processor910coupled to a memory912.

The memory912may comprise random access memory (RAM), read-only memory (ROM), flash memory or other types of memory, in any combination. The memory912and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs.

Also included in the processing device902-1is network interface circuitry914, which is used to interface the processing device with the network904and other system components, and may comprise conventional transceivers.

The other processing devices902of the processing platform900are assumed to be configured in a manner similar to that shown for processing device902-1in the figure.