Mechanism for predicting system resource consumption of transactions

Abstract

Techniques related to determining whether execution of a transaction exceeds a system resource threshold are disclosed. A computer system stores a pre-computed authority data structure associated with particular data stored in a database. The pre-computed data structure can be used to determine whether a user can access the particular data. The computer system can obtain metric information regarding parameters involved in various types of transactions that can be executed to recalculate the pre-computed authority data structure. Upon receiving a request to execute a transaction that involves recalculating the authority data structure, the computer system can determine whether execution of the transaction will exceed a system resource threshold based on the metric information and the particular type of transaction. If the transaction exceeds the threshold, the computer system can prevent the transaction from executing and provide a suggestion to allow the transaction to execute.

Description

[Technical Field]

[0001] The present disclosure relates generally to computer systems, and more particularly to various mechanisms for predicting system resource consumption of transactions / operations. [Background technology]

[0002] Businesses routinely implement database management systems (or simply "database systems") that allow them to store collections of information in an organized manner that allows users to efficiently access and manipulate them. Database systems may implement any of a variety of different types of databases for storing information, such as relational databases, non-relational databases, etc. In operation, a database system receives requests from users via applications or from other systems, such as another database system, to perform transactions on information stored in the database system's database store. Systems that utilize databases may rely on access rules and policies to control user access to data and to prevent unauthorized access to the database. [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a block diagram illustrating example elements of a system including an access control system for controlling user access to a data store, according to some embodiments. [Figure 2A] FIG. 2 is a block diagram illustrating an exemplary permission structure that may be used to control access to corresponding data objects, according to some embodiments. [Figure 2B] FIG. 2 is a block diagram illustrating an example transaction received by an access control system to update a permission structure, according to some embodiments. [Figure 3] FIG. 1 is a block diagram illustrating an exemplary benchmark of a sample transaction, according to some embodiments. [Figure 4] FIG. 1 is a block diagram illustrating an example process for creating metric information, according to some embodiments. [Figure 5] FIG. 1 is a block diagram illustrating an example process for predicting whether to allow a transaction to be executed, according to some embodiments. [Figure 6] FIG. 1 is a flow diagram illustrating an example method related to determining whether a transaction exceeds a system resource threshold, including recalculating a pre-calculated authority data structure, according to some embodiments. [Figure 7] FIG. 1 is a block diagram illustrating elements of a computer system for implementing various systems described in this disclosure, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0004] A system can store and utilize access rules to control user access to data in its databases. When a user attempts to access records in a table, the system often performs a set of actions, such as checking access rules and analyzing access inheritance, to determine whether the user can access those records. This process can take a significant amount of time and therefore affect the user experience. Instead of analyzing all access rules with every user query against a data table, in some embodiments, record access data is pre-calculated and stored in an associated “rules” table that holds information related to a user's set of permitted access to the data table. Thus, when a user attempts to access a record from that table, the system checks the rules table and provides the record to the user if the rules table indicates that the user has permission. For example, if a database administrator makes a change to a user's access permissions, the system can execute a change rules transaction to update all associated rule tables to reflect the change in the user's access permissions. The size of the rules table and the computational cost of the change rules transaction often depend on the size of the organization hosted by the system and how the organization administrator defines access rules and policies.

[0005] Large organizations typically have thousands of users accessing a database, which can result in very large rule tables with thousands of access rules and millions of rows. Changes to access rules in rule tables of that size can result in rule change transactions large enough to present problems for processing within the system (e.g., utilizing enough database resources to reach resource limits set in the database). In some cases, these transactions run for days before failing, thereby frustrating users of the system and consuming a significant amount of computing power for an extended period of time. Therefore, it may be desirable to detect such rule change transactions and prevent them from proceeding and wasting valuable time and resources. The present disclosure addresses, among other things, the technical problem of how to predict and mitigate rule change transactions that are too resource-expensive.

[0006] In various embodiments described below, a computer system measures metrics that account for rule change transactions, identifies whether the rule change transaction will exceed a system resource threshold when requested by a user, and takes appropriate action to prevent the transaction from proceeding if the system resource threshold is exceeded. In various embodiments, benchmark tests are first conducted to establish baseline resource consumption for various types of rule change transactions. That resource consumption can be broken down into individual components (e.g., number of roles, number of users in source roles, etc.) and used to define a formula. Next, values / metrics that map to the individual components are collected for specific tenants in the system. For example, the number of roles for a specific tenant is collected. When a rule change transaction is performed for a specific tenant, in various embodiments, the system retrieves the tenant's values / metrics and uses them as inputs to a formula (associated with the specific type of rule change operation being performed) that determines the resource consumption of that rule change transaction. If the system determines via the formula that the rule change transaction will consume more system resources than a predetermined threshold (e.g., 8 gigabytes of memory), the rule change transaction is prevented from executing. The system may notify a particular tenant that the requested rule change transaction will not proceed and may further provide the tenant with suggestions for reducing the resource cost of the transaction (e.g., reducing the number of roles).

[0007] These techniques can be advantageous over traditional approaches because they allow a system to predict and prevent computationally forbidden rule change transactions from executing, instead of waiting a significant amount of time until such transactions fail and potentially affect other resources. By informing the user about potential solutions for preventing such transactions and allowing them to execute, the user experience is improved (e.g., the user does not waste time on a rule change transaction that will fail). Also, the provider of the system may save time and computing resources that may be costly to obtain from a cloud infrastructure provider. An exemplary application of these techniques is described with reference to FIG. 1.

[0008] Referring now to FIG. 1 , a block diagram of system 100 is shown. System 100 includes a set of components that may be implemented via hardware or a combination of hardware and software. In the illustrated embodiment, system 100 includes a data store 110, an access control system 120, and a user system 130. As further shown, data store 110 includes data objects 111, an authorization structure 112, and metrics information 113. Also shown, access control system 120 includes a benchmark module 121, a metrics information module 122, a prediction module 123, an execution module 124, and a blocking module 125. In some embodiments, system 100 is implemented differently than illustrated. As one example, access control system 120 may interact with (e.g., receive requests from) other systems (e.g., application servers) other than user system 130.

[0009] In various embodiments, system 100 implements a platform service (e.g., a customer relationship management (CRM) platform service) that enables users of that service to develop, run, and manage applications. System 100 may be a multi-tenant system that provides various functions to tenants (e.g., individual users, businesses, government agencies, etc.) hosted by the multi-tenant system. Thus, system 100 may execute software routines from various different entities (e.g., the provider and tenants of system 100) and provide code, web pages, and other data to users, databases, and entities (e.g., third-party systems) associated with system 100. In various embodiments, system 100 is implemented using a cloud infrastructure provided by a cloud provider. Thus, data store 110 and access control system 120 may run on and utilize available cloud resources (e.g., computing resources, storage resources, etc.) of the cloud infrastructure to facilitate their operation. For example, access control system 120 may run in one or more virtual environments hosted on server-based hardware contained within a data center. However, in some embodiments, system 100 is implemented utilizing local or private infrastructure, as opposed to a public cloud. Other embodiments of system 100 may include more or fewer components or modules than are shown. For example, system 100 may include only data store 110 and access control system 120, while user system 130 operates as part of a different system.

[0010] Data store 110, in various embodiments, is a data repository that stores a collection of information organized to allow access and manipulation of that information. Data store 110 may be embodied in one or more physical or virtualized computer systems and may include support software (e.g., storage servers) that enable access control system 120 to perform operations (e.g., access, store, etc.) on the information stored in data store 110. For example, data store 110 may be implemented using Apache HBase™. In various embodiments, data store 110 utilizes single or multiple storage devices connected to each other over a network (e.g., a storage-attached network (SAN)) and configured to store information redundantly to prevent data loss. The storage devices may persistently store data, and thus data store 110 can serve as persistent storage for system 100. Also, in various embodiments, data written to data store 110 by one system (e.g., access control system 120) is accessible to other systems (e.g., another access control system 120).

[0011] In various embodiments, various types of data are stored in data store 110 using various data structures, including data objects 111. Data object 111 may be a database table, an index, or another type of data structure (e.g., a document object for a non-relational database). If data object 111 is a database table, a row of that data object 111 may correspond to a record containing one or more values. A record, in various embodiments, is a key-value pair containing data and a key that can be used to look up the record, where the key may be a primary key composed of values ​​of one or more fields of the associated data object 111. In various embodiments, data object 111 may store data for multiple tenants, and thus each record may include a field defining the tenant as a subset of data identifying the tenant.

[0012] As shown, data store 110 further stores, among other things, permission structure 112 and metric information 113. Permission structure 112 is a data structure that stores record access data that, in various embodiments, can be used to control user access to records of associated data objects 111. Examples of data objects 111 and permission structures 112 are described in more detail with respect to FIGS. 2A-2B . Metric information 113, in various embodiments, describes metrics associated with tenants (e.g., organizations), data objects 111, and / or permission structures 112. Metric information 113 may be used by access control system 120 to determine whether a particular rule change transaction exceeds system resource thresholds and, therefore, should be blocked from execution. Metric information 113 is described in more detail with respect to FIG. 4 .

[0013] In various embodiments, access control system 120 manages access to data in data store 110. In some embodiments, access control system 120 is a database server that provides database services such as data storage, data retrieval, and data manipulation. Access control system 120 may thus receive database requests to perform database transactions, which may be received from user system 130 via an application server using an established database connection. A database transaction, in various embodiments, is a logical unit of work (e.g., a set of database statements) to be performed in connection with data store 110. For example, processing a database transaction may include executing a SELECT statement to select and return one or more records from one or more data objects 111 in response to the issuer of the database request. To determine whether those records can be returned, in various embodiments, access control system 120 accesses one or more authority structures 112 corresponding to one or more data objects 111 and evaluates their record access data. In some embodiments, access control system 120 is an application server that interacts with a database server on behalf of a user of user system 130. Thus, access control system 120 may receive communications from user systems 130 and provide requests (e.g., rule change requests, data update requests, etc.) to database servers related to data in data store 110 and to perform operations on behalf of users of user systems 130. Access control system 120 may also, in various cases, implement both an application server and a database server.

[0014] Access control system 120 may receive a request from user system 130 or another entity to insert, update, or delete one or more access rules that affect a user's access to data store 110. In various embodiments, processing the request includes recalculating record access data stored in one or more authority structures 112. Accordingly, access control system 120 may execute or cause to be executed a rule change transaction to recalculate the record access data. Before executing or causing to be executed a rule change transaction, in various embodiments, access control system 120 predicts whether the transaction will exceed a set of system resource thresholds (e.g., utilize more than 8 gigabytes of system memory). To facilitate that prediction, access control system 120 includes various executable software modules. Benchmark module 121, in various embodiments, generates benchmarks that enable benchmark testing for various rule change transactions to determine baseline resource consumption for those rule change transactions. Benchmark module 121 is described in more detail with respect to FIG. 3. Metric information module 122, in various embodiments, collects metrics for different tenants of system 100 associated with individual components that affect the resource consumption of various rule change transactions. Metric information module 122 is described in more detail with respect to FIG. 3. Prediction module 123, in various embodiments, predicts whether a rule change transaction will exceed a system resource threshold based on the metrics collected by metric information module 122 and one or more equations. Prediction module 123 may then interact with either enforcement module 124 or prevention module 125 based on its prediction.If the rule change transaction is allowed to proceed, the execution module 124 executes or causes the transaction to execute and recalculate one or more authority structures 112; otherwise, the prevention module 125 prevents the transaction from being executed.

[0015] User system 130, in various embodiments, is a computer system operated by a user and used to interact with other components of system 100, such as access control system 120. User system 130 may issue requests to access control system 120 for information stored in data store 110. In some examples, access control system 120 provides user system 130 with a user interface that allows the user to submit requests to access control system 120. In other examples, the user may submit those requests using a command line tool or another mechanism. In some embodiments, an application server or another system (not shown) may also be configured to issue requests to access control system 120 for information stored in data store 110.

[0016] 2A , a block diagram of an exemplary permission structure 112 that may be used to control access to a corresponding data object 111 is shown. The diagram shown in FIG. 2A illustrates example record access data stored in the permission structure 112 and how permission to access data in the data object 111 is determined based on the record access data and a match between the account ID of the data object 111 and the account ID of the permission structure 112. In some embodiments, there may be additional data structures that assist in controlling access to data in the data object 111. For example, there may be an object record table that has additional metadata related to each row / record in the data object 111, such as the date the record in the data object 111 was created or the date it was last accessed. In some embodiments, the permission structure 112 may map to multiple data objects 111 and / or the data object 111 may map to multiple permission structures 112.

[0017] As shown, data object 111 is a database table that includes data associated with an account ID field, an owner field, and an account name field. Data object 111 may include other fields that can store text-based data (e.g., lists, URLs, records, reports), audio files, video files, etc. In some embodiments, the data in the fields may point to items hosted on other computer systems (e.g., using a URL). In the illustrated embodiment, data object 111 includes an account record for a company called “Acme” (identified under the account name field), associated with an account ID of “A1” and an owner, Maria, who may be the administrator for the tenant with that account ID. Data in data object 111 may be manually uploaded by an administrator, for example, using an online portal, although in other embodiments, data is added automatically after a service-related function is performed. As an example, if Maria requests a report on Acme, the report may be automatically created and stored in the record of illustrated data object 111 (or another data object) as associated with account ID “A1” and owned by Maria.

[0018] As described above, when a user requests access to one or more records in a particular data object 111, in various embodiments, the access control system 120 looks up the relevant access rules in the permission structure 112 instead of analyzing all access rules and record access inheritance in real time. In the illustrated embodiment, the permission structure 112 is a database table. As shown, each row in the permission structure 112 describes a user associated with an account ID, their access level, and a row reason. The user field describes the entity that can request access to data in the data store 110; an entity can be an individual (e.g., Maria) or a group of users under a tenant (e.g., the Strategy department). The "access level" describes what a particular user is allowed to do (e.g., read, write, delete, create) when attempting to modify or add to the data object 111. The "row reason" indicates the process that led to the creation of the row in the permission structure 112; "manual" indicates that the row was manually added by an administrator, and "rule" indicates that the row was automatically added as a result of a rule change transaction. For example, more columns may be added to the authorization structure 112 that provide additional information related to the user (eg, last logged in time, etc.).

[0019] The permission structure 112 is used to control user access to the data object 111 using various operations. In particular, a user of the user system 130 may send a data request (e.g., open a record, run a report, access a list view, search a record, etc.) to the access control system 120. The data request may identify the type of request (e.g., read, write, or delete), the user's name / group, and an account ID. When determining whether a record of the data object 111 can be accessed by the user, in various embodiments, the access control system 120 attempts to match the value stored in the record of the account ID field with a record stored in the permission structure 112. (In some embodiments, the matching is performed through a bind operation between the data object 111 and the permission structure 112 using the "account ID" as a key.) The access control system 120 may search for a record in the permission structure 112 that matches the account ID to find the user's record in the permission structure 112. Access control system 120 may then compare the access level of the record against the type of data request submitted by the user and determine whether to proceed with the request (e.g., update the requested record). As an example, if a user in the strategy group attempts to update a record of data object 111 shown in Figure 2A, access control system 120 accesses the strategy group's record in permission structure 112 and denies the request because the strategy group does not have permission to write.

[0020] 2B, a block diagram of an exemplary transaction 210 involving an authority update request 217 to update authority structure 112 is shown. In the illustrated embodiment, there is a data store 110, an access control system 120, and a transaction 210. As further shown, data store 110 includes data object 111 and authority structure 112, and transaction 210 having a transaction type 215. The illustrated embodiment may be implemented differently than shown; for example, transaction 210 may include additional information describing a user associated with transaction 210.

[0021] Often, it may be desirable to change a user's or group's access to particular data in data store 110. For example, Maria leaves the company, and Frank subsequently assumes responsibility. Therefore, a user (e.g., an administrator at the company) may update the access rules for those data to remove privileges from Maria and grant them to Frank, which entails recalculating permission structure 112 to reflect the change. In various embodiments, permission structure 112 is updated using a rule change transaction 210 having a transaction type 215 corresponding to the specific change made to the access granted to the user or group. In various embodiments, the transaction type 215 may be one of the following types: access rule recalculation / child implicit sharing operations, group membership changes and scrutinies, role reparenting operations, account merge operations, organization-wide default changes, portal implicit sharing changes, and user visibility statistics collection. Some of these types 215 are described below, and other transaction types 215 may exist.

[0022] Regarding access rule recalculation, in some embodiments, an administrator of data store 110 or a tenant of system 100 may want to recalculate some or all of the existing record access data already precalculated in the authorization structure 112. This transaction type 215 may be executed in response to a user being granted access to a particular set of records. Access rule recalculation may become too limitless for various reasons. For example, if a tenant has a small number of users but millions of records, record access rule recalculation may be resource intensive due to the large number of records. Regarding child implicit share processing, in various embodiments, child implicit share is the ability of a parent account to access all records that its child accounts have access to. Precalculating record access data may include granting all of the child account's permissions to the parent account, resulting in more record access data being stored in the authorization structure 112. Such processing may become limitless if a parent account is associated with a large number of child accounts.

[0023] With regard to group membership changes, in various embodiments, a set of users may form a group that can itself have subgroups. Groups and subgroups may have their own rules, and all users in a given group or subgroup receive the group's rules. Thus, a group membership change transaction 210 may occur in response to any change to groups or their configuration (e.g., moving a subgroup from one group to another, removing a user from a group, or moving a user from one group to another). Such transactions 210 may be infinite in the case where multiple large groups are merged into a single group.

[0024] With regard to role reparenting, in various embodiments, a role is a set of access levels (e.g., read, create, edit, delete) to record data objects 111 that can be granted to a user or group of users. As an example, a “viewer” role may be created to give read access to all records and then granted to users (e.g., Maria, Frank, etc.). Like groups, roles may have a hierarchy associated with them. In some embodiments, roles map to an organization's formal hierarchy (e.g., a CEO may have a role at level 1, a middle manager may have a role at level 5, etc.). When a role in a hierarchy needs to be moved from one hierarchical position to another, all roles below the given role in the hierarchy must also be moved. Thus, if a given hierarchy has 10 levels, moving a role at level 8 to level 3 requires moving roles at levels 9 and 10 as well. Roles may be assigned to multiple users, and role reparenting for a given role involves recalculating the role and all users in its connected subordinate roles.

[0025] Regarding account merging, in various embodiments, it may be desirable to merge a set of accounts. For example, Maria leaves a company and it is desirable to merge her account with that of another user at the company. Those accounts may have millions of child records, and therefore the account merge transaction 210 may become open-ended when recalculating the record access data in the permission structure 112 to allow other users to access those records.

[0026] As part of conducting transaction 210, in various embodiments, access control system 120 issues an authorization update request 217 to update authorization structure 112. For example, access control system 120 may recalculate a new portion of record access data and then issue an authorization update request 217 to store the new portion in authorization structure 112. By pre-calculating and storing record access data in authorization structure 112 when rule change transaction 210 occurs, access control system 120 can more quickly determine whether a user is authorized to access a particular record, instead of calculating record access data in real time upon receiving a data request.

[0027] 3, a block diagram of an exemplary architecture for benchmarking rule change transactions is shown. In the illustrated embodiment, there is a benchmark module 121, a sample transaction 310, a sample authority structure 320, a sample metric 325, and a benchmark 330. As shown, the sample transaction 310 includes a type 215, and the benchmark 330 has a transaction type field, a memory usage field, and a time field. The illustrated embodiment may be implemented differently than shown; for example, the benchmark 330 may include additional fields describing the computing domain in which the transaction took place.

[0028] As described above, in various embodiments, metrics are collected for tenants (e.g., organizations) of the system 100 that map to individual components of a defined formula to predict whether a transaction 210 will exceed a system resource threshold. To determine which metrics affect a particular type 215 of transaction 215 and how, benchmarking can be performed to identify cases in which transactions 210 of that particular type 215 exceed a system resource threshold. These cases can then be analyzed to determine the value of the metric associated with the particular type 215 that is likely to cause the transaction 210 of that type 215 to exceed a system resource threshold. A formula can be further derived from the cases into which metrics can be input to predict whether a rule change transaction 210 of the particular type 215 will exceed a system resource threshold.

[0029] To benchmark a particular type 215, in various embodiments, the benchmark module 121 runs a set of sample transactions 310 of that particular type 215. For example, the benchmark module 121 may run a sample role reparenting transaction 210 to benchmark the resource consumption of the role reparenting transaction 310. To facilitate that benchmarking, in various embodiments, the benchmark module 121 utilizes a sample authority structure 320 and sample metrics 325. The sample authority structure 320 is the authority structure 112 used for the benchmark, and the sample metrics 325 include sample numbers of users, roles, etc., that may help derive individual components of a formula that may be used to predict the resource consumption of future transactions (e.g., transactions 210) on the authority structure 112. In various embodiments, the metrics 325 include the number of roles, the depth of the role hierarchy, the number of all tenant records, the number of groups, the number of tenant records under an account, etc.

[0030] As a sample transaction 310 completes, performance results (e.g., time and memory usage) are stored in the benchmark 330 in association with the particular type 215 of that sample transaction 310. After enough performance results have been stored for a given type 215, it may be possible to establish a formula for that type 215. Formulas for transaction types 215 as described above with respect to Figure 2B can be created. For example, the formula for a role reparenting transaction 210 may be as follows:

[0031]

number

[0032] where n is the number of roles to be reparented, d is the depth of the role hierarchy of the new parent, u is the number of users in the source role, E is the count of all entity records owned by the source role, and M is the system memory threshold or the maximum amount of memory that can be provided for execution of the transaction. As another example, the formula for group membership change transaction 210 may be:

[0033]

number

[0034] where d is the depth of the role hierarchy of the parent of the group being changed, d is the depth of the role hierarchy, and M is the system memory threshold.

[0035] In some embodiments, this benchmarking is performed by the execution module 124 executing sample transactions 310 on the sample authority structure 320 and then storing the performance results in the benchmark module 121. However, in other embodiments, a separate benchmarking system is used to ensure that there are no external factors (e.g., user systems 130 accessing other elements of the access control system 120) during performance measurements.

[0036] 4, a block diagram of an exemplary collection of metric information 113 is shown. In the illustrated embodiment, there is an access control system 120 and a data store 110. As further shown, data store 110 includes data objects 111, permission structure 112, and metric information 113, and access control system 120 includes a metric information module 122. The illustrated embodiment may be implemented differently than shown. For example, metric information 113 may be stored separately from data store 110.

[0037] Metric information 113, in various embodiments, includes values ​​of sets of parameters (e.g., parameters of the aforementioned formulas) involved in various types of transactions 210 (e.g., role reparenting) that may be performed to recalculate authority structure 112. Metric information 113 may store, for a tenant, the number of users of the tenant, the number of roles of the tenant, the number of records of the tenant, the role hierarchy of the tenant, etc. In particular, each tenant may have its own users and user hierarchy; as a result, the transaction 210 that recalculates authority structure 112 may depend on specific tenant information. Thus, metric information module 122, in various embodiments, implements a metrics collection process for collecting values ​​of sets of parameters for different tenants of system 100. That information may be stored in data store 110; thus, metric information module 122 may access it from data store 110 (denoted as tenant information) and then rearrange the information into a format that allows values ​​of individual components of the formula to be extracted from the information and used in the formula to predict whether the corresponding rule change transaction 210 will exceed a system resource threshold.

[0038] 5, a block diagram of an exemplary process for predicting whether to allow a transaction 210 to be performed is shown. In the illustrated embodiment, there is a data store 110, an access control system 120, and a user system 130. As further shown, the data store 110 includes an authorization structure 112, and the access control system 120 has a prediction module 123, an execution module 124, and a prevention module 125. The illustrated embodiment may be implemented differently than shown; for example, the access control system 120 may receive a request to perform the transaction 210 from a non-user system and therefore provide a notification 510 to that system instead of the user system 130.

[0039] As described above, access control system 120 may receive a request to perform transaction 210 to recalculate record access data for authorization structure 112. In response to receiving the request, in various embodiments, prediction module 123 makes a decision as to whether to allow or block transaction 210 from executing. To make that decision, prediction module 123 uses relevant metrics from metric information module 122 (not shown) as inputs in an equation corresponding to transaction type 215. In particular, prediction module 123 may access metrics for the tenant associated with transaction 210 and check whether the metrics exceed a certain limit (e.g., the number of roles is greater than a role threshold, such as 100 roles) or whether the output value of an equation exceeds a certain system resource threshold (e.g., the role reparenting transaction is predicted to consume more than 8 GB of memory). For example, the prediction module 123 may use relevant metrics from the metric information module 122 and corresponding role reparenting formulas to predict the outcome of the role reparenting transaction 210 on the authority structure 112 to predict the resource consumption of the role reparenting transaction 210. In some embodiments, no formulas are used, and instead the metrics stored in the metric information module 122 are compared directly to metric limits to make the same decision (i.e., whether to proceed with the transaction 210).

[0040] If the predicted performance of transaction 210 does not exceed a system resource threshold (e.g., a role reparenting operation predicted to consume less than 8 GB of memory), prediction module 123 determines that transaction 210 will consume an appropriate number of resources and instructs execution module 124 to execute transaction 210 to update authority structure 112 via one or more authority update requests 217. Conversely, if the predicted resource consumption indicates that transaction 210 will exceed a threshold, prediction module 123 instructs prevention module 125 to block transaction 210 and also provides notification 510 to user system 130 that the attempted transaction 210 will exceed available computing resources.

[0041] In various embodiments, notification 510 includes suggestions for allowing transaction 210 to be executed without exceeding a system resource threshold. For example, notification 510 may indicate that a tenant has too many roles and should reduce the number of roles and then retry transaction 210. As another example, notification 510 may indicate that there are too many child records associated with a particular account. As yet another example, notification 510 may include a message informing a user of user system 130 that the user's membership tier is too low. That is, a tenant at a particular membership tier may have a lower transaction threshold (e.g., 4 GB) than a system resource threshold (e.g., 8 GB). Thus, the lower threshold may be used to determine whether execution of rule change transaction 210 should proceed, and the tenant may therefore be instructed to select a higher membership tier.

[0042] 6, a flow diagram of method 600 is shown. Method 600 is one embodiment of a method performed by a computer system (e.g., access control system 120) to determine whether to proceed with a transaction (e.g., transaction 210). Method 600 may be performed by executing a set of program instructions stored on a non-transitory computer-readable medium. In some embodiments, method 600 includes more or fewer steps than shown. For example, method 600 may include an additional step in which the system notifies the issuer of the transaction request that execution of the transaction will exceed a system resource threshold.

[0043] Method 600 begins at step 610, where a computer system stores a pre-computed authority data structure (e.g., authority structure 112) in association with particular data (e.g., data object 111) stored in a database (e.g., data store 110). The pre-computed authority data structure may be usable to determine whether a user can access particular data when processing a data request directed to the particular data. In some embodiments, the database stores data in the form of tables. For example, the pre-computed authority data structure may be a table containing access rules for a set of users and linked to a separate table with particular data.

[0044] In step 620, the computer system obtains metric information (e.g., metric information 113) regarding sets of parameters involved in various types of transactions that may be performed to recalculate the pre-computed authority data structure. The metric information may also relate to a particular tenant of the computer system. In some cases, a database stores data for multiple tenants of the computer system, and the metric information identifies, for a given one of the multiple tenants, tenant-specific values ​​of the set of parameters.

[0045] In step 630, the computer system receives an update request that includes performing a transaction. The transaction is a particular one of various types of transactions (e.g., role reparenting) that may be performed to recalculate a pre-computed authorization data structure. In some embodiments, the transaction includes a group membership change operation that includes modifying the number of users included in a particular group that are authorized to access at least a portion of the particular data. Furthermore, in some cases, the metric information for the group membership change operation identifies the number of records managed by users in the particular group.

[0046] Determining the parameters involved in a transaction type may be accomplished prior to the update request. For example, the system may execute one or more test transactions of a particular type of transaction and, during execution of the test transactions, obtain benchmark metric information regarding resource consumption of the particular type of transaction. A set of specific parameters involved in a particular type of transaction may be derivable from the benchmark metric information.

[0047] At step 640, the computer system determines, based on the metric information and the particular type of transaction, whether execution of the transaction will exceed a system resource threshold, which in some embodiments corresponds to the amount of memory allowed by the computer system to be used when executing a given transaction.

[0048] This determination may be made by the computer system based on stored metadata. In some embodiments, the computer system stores restriction metadata describing value limits for some parameters of the set of parameters and prevents execution of the transaction in response to determining that the value of a parameter associated with the transaction exceeds the value limit specified by the restriction metadata for that parameter. In further embodiments, the system may further store membership metadata describing account information for one or more of the set of tenants. The restriction metadata may be determined based on the membership data.

[0049] The computer system may perform additional steps after making the determination. For example, in response to determining that execution of the transaction would exceed a system resource threshold, the computer system may block execution of the transaction and provide a notification (e.g., notification 510) to the issuer of the update request that execution of the transaction has been blocked. The notification may identify one or more solutions for allowing the transaction to subsequently execute.

[0050] Exemplary Computer System 7, a block diagram of an exemplary computer system 700 is depicted that may implement system 100, data store 110, access control system 120, and / or user system 130. Computer system 700 includes a processor subsystem 780 coupled to system memory 720 and an I / O interface 740 via an interconnect 760 (e.g., a system bus). I / O interface 740 is coupled to one or more I / O devices 750. While a single computer system 700 is shown in FIG. 7 for convenience, system 700 may be implemented as two or more computer systems operating together.

[0051] Processor subsystem 780 may include one or more processors or processing units. In various embodiments of computer system 700, multiple instances of processor subsystem 780 may be coupled to interconnect 760. In various embodiments, processor subsystem 780 (or each processor unit within 780) may include a cache or other form of on-board memory.

[0052] System memory 720 can be used to store program instructions executable by processor subsystem 780 to cause system 700 to perform the various operations described herein. System memory 720 can be implemented using different physical memory media, such as hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RAMBUS RAM, etc.), read-only memory (PROM, EEPROM, etc.), etc. Memory in computer system 700 is not limited to primary storage devices such as memory 720. Rather, computer system 700 can also include other forms of storage, such as cache memory in processor subsystem 780 and secondary storage devices (e.g., hard drives, storage arrays, etc.) on I / O devices 750. In some embodiments, these other forms of storage can also store program instructions executable by processor subsystem 780. In some embodiments, program instructions that, when executed, implement the benchmark module 121, the metric information module 122, the prediction module 123, the execution module 124, and / or the prevention module 125 may be included / stored within the system memory 720.

[0053] I / O interface 740 may be any of a variety of types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I / O interface 740 is a bridge chip (e.g., a southbridge) from a frontside to one or more backside buses. I / O interface 740 may be coupled to one or more I / O devices 750 via one or more corresponding buses or other interfaces. Examples of I / O devices 750 include storage devices (hard drives, optical drives, removable flash drives, storage arrays, SANs, or their associated controllers), network interface devices (e.g., to a local or wide area network), or other devices (e.g., graphics, user interface devices, etc.). In one embodiment, computer system 700 is coupled to a network via network interface device 750 (e.g., configured to communicate via WiFi, Bluetooth, Ethernet, etc.).

[0054] The present disclosure includes references to "embodiments" that are non-limiting implementations of the disclosed concepts. References to "an embodiment," "one embodiment," "particular embodiment," "some embodiments," "various embodiments," etc. do not necessarily refer to the same embodiment. Numerous possible embodiments are contemplated, including the specific embodiment described in detail, as well as modifications or alternatives that fall within the spirit or scope of the present disclosure. Not all embodiments necessarily exhibit any or all of the potential advantages described herein.

[0055] This disclosure may describe potential advantages that may result from the disclosed embodiments. Not all implementations of these embodiments necessarily manifest any or all of the potential advantages. Whether advantages are realized for a particular implementation depends on many factors, some of which are outside the scope of this disclosure. Indeed, there are several reasons why an implementation within the scope of the claims may not exhibit some or all of the disclosed advantages. For example, a particular implementation may include, along with one of the disclosed embodiments, other circuitry outside the scope of this disclosure that negates or reduces one or more of the disclosed advantages. Furthermore, suboptimal design practices of a particular implementation (e.g., implementation techniques or tools) may also negate or reduce the disclosed advantages. Even assuming a skilled implementation, realization of advantages may still depend on other factors, such as the environmental conditions in which the implementation is deployed. For example, inputs provided to a particular implementation may prevent one or more problems addressed in this disclosure from occurring on a particular occasion, resulting in the benefits of that solution not being realized. Given the existence of possible factors external to this disclosure, it is expressly intended that any potential advantages described herein should not be construed as claim limitations that must be met in order to demonstrate infringement. Rather, the identification of such potential advantages is intended to illustrate the types of improvements available to a designer having the benefit of this disclosure. The permissive description of such advantages (e.g., stating that a particular advantage "may result") is not intended to convey doubt as to whether such advantages can actually be realized, but rather to recognize the technological reality that realization of such advantages often depends on additional factors.

[0056] Unless otherwise specified, the embodiments are non-limiting. That is, the disclosed embodiments, even if only a single example of a particular feature is described, are not intended to limit the scope of claims drafted based on this disclosure. The disclosed embodiments are intended to be illustrative rather than restrictive, unless otherwise stated in the disclosure. Accordingly, the application is intended to allow claims that encompass the disclosed embodiments and such alternatives, modifications, and equivalents as would be apparent to those skilled in the art having the benefit of this disclosure.

[0057] For example, features in the present application may be combined in any suitable manner. Accordingly, during prosecution of this application (or an application claiming priority to this application), new claims may be formulated to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined where appropriate with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from each independent claim may be combined where appropriate.

[0058] Thus, the accompanying dependent claims may each be drafted as dependent on a single other claim, and additional dependencies are also contemplated. Any combination of features in the dependent claims consistent with this disclosure is contemplated and may be claimed in this or another application. In short, combinations are not limited to those specifically recited in the accompanying claims.

[0059] It is also contemplated that, where appropriate, a claim drafted in one form or statutory type (e.g., apparatus) is intended to support a corresponding claim in another form or statutory type (e.g., method).

[0060] Because this disclosure is a legal document, various terms and phrases may be subject to administrative and judicial interpretation. The definitions provided in the following paragraphs, as well as throughout this publication, are hereby provided to be used in determining how to interpret the claims drafted based on this disclosure.

[0061] A reference to a singular item (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more" unless the context clearly indicates otherwise. A "plurality" of items refers to a set of two or more items.

[0062] The word "may" is used herein in a permissive sense (i.e., having the possibility, being able to), and not in a mandatory sense (i.e., must).

[0063] The terms "comprising" and "including" and their forms are open-ended and mean "including, but not limited to."

[0064] When the term "or" is used in this disclosure in reference to a list of alternatives, it is generally understood to be used in an inclusive sense unless the context dictates otherwise. Thus, a statement of "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either x or y, but not both" make clear that "or" is used in an exclusive sense.

[0065] References to "w, x, y, or z, or any combination thereof" or "at least one of w, x, y, and z" are intended to encompass all possibilities, from a single element to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element of the set (e.g., w but not x, y, or z), any two elements (e.g., w and x but not y or z), any three elements (e.g., w, x, and y but not z), and all four elements. Thus, the phrase "at least one of w, x, y, and z" refers to at least one element of the set [w, x, y, z], thereby covering all possible combinations of this list of elements. This phrase should not be interpreted as requiring that there be at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0066] In this disclosure, various "labels" may precede nouns or noun phrases. Unless the context dictates otherwise, different labels used for a feature (e.g., "first circuit," "second circuit," "particular circuit," "given circuit," etc.) refer to different instances of the feature. Furthermore, the labels "first," "second," and "third," when applied to features, do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) unless otherwise stated.

[0067] The phrase "based on" is used to describe one or more factors that influence a decision. This term does not exclude the possibility that additional factors may influence the decision. That is, the decision may be based only on the identified factors, or may be based on the identified factors as well as other unidentified factors. This phrase identifies B as a factor used to determine A or that influences the decision of A. This phrase does not exclude that the decision of A may also be based on some other factor, such as C. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0068] "in response to" The phrases "response to" and "responsive to" describe one or more factors that cause an effect. The phrases do not exclude the possibility that additional factors may influence or otherwise cause the effect, either together with the identified factors or independently of the identified factors. That is, the effect may be responsive to those factors alone, or to the identified factors as well as other unspecified factors. Consider the phrase "doing A in response to B." This phrase does not exclude that doing A may also be jointly responsive to some other factor, such as C. This phrase is also intended to encompass embodiments in which A is done alone in response to B. Here, "in response to" The phrase "responsive to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "responsive to" is synonymous with the phrase "at least partially in response to."

[0069] Within this disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured" to perform one or more tasks or operations. This formulation—[entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., something physical). More specifically, this formulation is used to indicate that this structure is configured to perform one or more tasks during operation. A structure can be said to be "configured" to perform some task even if the structure is not currently operating. Thus, an entity described or listed as being "configured to" perform a task refers to a physical thing, such as a device, a circuit, or a system having a processor unit and a memory that stores executable program instructions to perform the task.

[0070] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations, and it will be understood that these entities are "configured to" perform these tasks / operations unless otherwise noted.

[0071] The term "configured" does not mean "configurable." For example, an unprogrammed FPGA is not considered to be "configured" to perform a particular function. However, this unprogrammed FPGA may be "configurable" to perform that function. After appropriate programming, the FPGA may be said to be "configured" to perform a particular function.

[0072] For purposes of U.S. patent applications based on this disclosure, a statement in a claim that a structure is "configured to" perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) for that claim element. If an applicant wishes to invoke section 112(f) during prosecution of a U.S. patent application based on this disclosure, the phrase "performing a function" should be used. Recite claim elements using the construction "means for" (a function).

Claims

1. 1. A method for determining whether a transaction exceeds a system resource threshold, comprising: recalculating a pre-computed authority data structure; storing, by a computer system, the pre-computed authority data structure in association with particular data stored in a database, the pre-computed authority data structure usable to determine whether a user can access the particular data when processing a data request directed to the particular data; obtaining, by the computer system, metric information regarding sets of parameters involved in various types of transactions that may be performed to recalculate the pre-computed authority data structure; receiving an update request at the computer system, the processing of the update request involving performing the transaction, the transaction being a particular one of the various types of transactions that may be performed to recalculate the pre-computed authority data structure; determining, by the computer system, whether execution of the transaction will exceed the system resource threshold based on the metric information and the particular type of the transaction.

2. The method of claim 1 , wherein the pre-computed authorization data structure is a table containing access rules for a set of users and is linked to a separate table having the specific data.

3. In response to determining that the execution of the transaction exceeds the system resource threshold, the computer system: preventing execution of said transaction; 10. The method of claim 1, further comprising: providing a notification to an issuer of the update request that the transaction has been prevented from executing, the notification identifying one or more solutions for allowing the transaction to execute.

4. 2. The method of claim 1, wherein the database stores data for multiple tenants of the computer system, and the metric information identifies, for a given one of the multiple tenants, tenant-specific values ​​of the set of parameters.

5. executing, by said computer system, one or more test transactions of said particular type of transaction; 2. The method of claim 1, further comprising: as part of executing the one or more test transactions, the computer system obtaining benchmark metric information related to resource consumption of the particular type of transaction, wherein a particular set of parameters involved in the particular type of transaction is derivable from the benchmark metric information.

6. 2. The method of claim 1, wherein the transaction comprises a group membership change operation comprising changing the number of users included in a particular group that are permitted to access at least a portion of the particular data.

7. The method of claim 6 , wherein the metric information identifies a number of records managed by users in the particular group.

8. The method of claim 1 , wherein the system resource threshold corresponds to an amount of memory that the computer system is permitted to use when executing a given transaction.

9. storing, by the computer system, constraint metadata describing constraints on values ​​of some of the set of parameters; preventing the execution of the transaction in response to determining, by the computer system, that a value of a parameter associated with the transaction exceeds a value limit specified by the limit metadata for that parameter; The method of claim 1 further comprising:

10. A computer-readable medium having stored thereon program instructions executable by a computer system to cause the computer system to perform operations, the operations comprising: storing a pre-computed authority data structure associated with particular data stored in a database, the pre-computed authority data structure usable to determine whether a user can access the particular data when processing a data request directed to the particular data; obtaining metric information regarding sets of parameters involved in various types of transactions that may be performed to recalculate the pre-computed authority data structure; receiving an update request, the processing of the update request involving performing a transaction, the transaction being a particular one of the various types of transactions that may be performed to recalculate the pre-computed authority data structure; and determining whether execution of the transaction will exceed a system resource threshold based on the metric information and the particular type of the transaction.

11. The operation, in response to determining that the execution of the transaction exceeds the system resource threshold, comprises: preventing execution of said transaction; providing a notification to the issuer of the update request that execution of the transaction has been blocked, the notification identifying one or more solutions for allowing the transaction to be executed; The computer-readable medium of claim 10 further comprising:

12. The operations include: executing one or more test transactions of the particular type of transaction; obtaining, as part of executing the one or more test transactions, benchmark metric information related to resource consumption of the particular type of transaction, wherein a particular set of parameters involved in the particular type of transaction is derivable from the benchmark metric information; The computer-readable medium of claim 10 further comprising:

13. The operations include storing constraint metadata describing constraints on values ​​of some of the set of parameters; preventing the execution of the transaction in response to determining that a value of a parameter associated with the transaction exceeds a value limit specified by the limit metadata for that parameter; The computer-readable medium of claim 10 further comprising:

14. The computer-readable medium of claim 10 , wherein the metric information identifies, for a given one of a plurality of tenants hosted by the computer system, values ​​of a set of the parameters specific to the given tenant.

15. 11. The computer-readable medium of claim 10, wherein the system resource threshold corresponds to an amount of processing power that is permitted by the computer system to be used when performing a given transaction.

16. 1. A system comprising: at least one processor; and a memory storing program instructions executable by the at least one processor to cause the system to perform operations, the operations comprising: storing a pre-computed authority data structure associated with particular data stored in a database, the pre-computed authority data structure usable to determine whether a user can access the particular data when processing a data request directed to the particular data; obtaining metric information regarding sets of parameters involved in various types of transactions that may be performed to recalculate the pre-computed authority data structure; receiving an update request, the processing of the update request involving executing the transaction, the transaction being a particular one of the various types of transactions that may be performed to recalculate the pre-computed authority data structure; and determining whether execution of the transaction will exceed a system resource threshold based on the metric information and the particular type of the transaction.

17. The operation is responsive to determining that the execution of the transaction exceeds the system resource threshold: preventing execution of said transaction; 17. The system of claim 16, further comprising: providing a notification to the issuer of the update request that the transaction has been prevented from executing, the notification identifying one or more solutions for allowing the transaction to execute.

18. The operations include: executing one or more test transactions of the particular type of transaction; 17. The system of claim 16, further comprising, as part of executing the one or more test transactions, obtaining benchmark metric information related to resource consumption of the particular type of transaction, wherein a particular set of parameters involved in the particular type of transaction is derivable from the benchmark metric information.

19. The operations include storing constraint metadata describing constraints on values ​​of some of the set of parameters; 20. The system of claim 16, further comprising: preventing the execution of the transaction in response to determining that a value of a parameter associated with the transaction exceeds a value limit specified by the limit metadata for that parameter.

20. The system of claim 16 , wherein the metric information identifies, for a given one of a plurality of tenants hosted by the system, values ​​of a set of the parameters specific to the given one of the tenants.

Images