Local multitenancy for database systems

Abstract

The system and method include: creating a first instance of a tenant object in a database instance; associating the first instance of the tenant object with a first plurality of database artifacts including first data associated with the first instance of the tenant object; creating a second instance of the tenant object in the database instance; associating the second instance of the tenant object with a second plurality of database artifacts including second data associated with the second instance of the tenant object; and receiving and responding to queries on the first data associated with the first instance of the tenant object and queries on the second data associated with the second instance of the tenant object.

Description

[0001] Cross-reference to related applications

[0002] This application claims priority to U.S. Provisional Patent Application Nos. 63 / 352,779 and 63 / 352,811, filed June 16, 2022, the entire contents of which are incorporated herein by reference for all purposes. Background Technology

[0003] Multitenancy is a software architecture pattern that facilitates the sharing of computing resources among different user groups. For example, a single multitenant application (e.g., a Software as a Service (SaaS) application) can serve multiple end-user groups (i.e., customers) within a single software instance. Such a software instance uses a much smaller computing resource footprint than the computing resources required to provision a software instance to each customer. Therefore, multitenancy can provide significant cost benefits.

[0004] In a multi-tenant architecture, each customer's data is typically mapped to a corresponding tenant in the underlying data layer. This mapping allows for logical separation of data within the data layer and facilitates access to it by multi-tenant applications. In some multi-tenant architectures, each tenant's data is managed by different database instances running within the same computing system (e.g., rack servers). These architectures provide excellent separation of tenant data, but in some scenarios, requiring a full database instance for each tenant can be costly and inefficient. For example, even the smallest database instance might consume 32GB of storage, which could represent significantly more computing resources than a small tenant should need.

[0005] Other multi-tenant data architectures use a single database instance to manage data for multiple tenants. Because the data in this architecture is not physically separated, multi-tenant applications are responsible for tracking and managing the data in a tenant-aware manner. For example, a database system might use a single instance for all tenants, where each tenant's data is partitioned via a distinguishing column. Multi-tenant applications use the values ​​of the distinguishing column to identify data belonging to a specific tenant. On the other hand, the database is unaware of the existence of multiple tenants and operates in the same way as if it were accessed by a single-tenant application.

[0006] Database systems offer advantageous features such as encryption, backup / recovery, cloning, and migration of the data stored within them. What is needed is a database system that provides these instance-level features at the tenant level. Attached Figure Description

[0007] Figure 1 This is a block diagram of a database system that provides native multitenancy according to some embodiments.

[0008] Figure 2This is a block diagram of a database system that provides native multitenancy according to some embodiments.

[0009] Figure 3 This is a block diagram illustrating a cloud-based database architecture that provides native multitenancy, according to some embodiments.

[0010] Figure 4 This is a block diagram of a database system that provides native multitenancy according to some embodiments.

[0011] Figure 5 This is a flowchart of the process of creating a tenant in a cloud database instance according to some embodiments.

[0012] Figure 6 This is a block diagram of a database system that provides native multi-tenancy and tenant-level encryption according to some embodiments.

[0013] Figure 7 This is a block diagram of a cloud-based system according to some embodiments. Detailed Implementation

[0014] The following description is provided to enable those skilled in the art to make and use the described embodiments. However, various modifications will be apparent to those skilled in the art.

[0015] According to some embodiments, a native multitenant database system includes database-level tenant objects (e.g., database directory objects) that facilitate the implementation of a multitenant architecture at the application layer. A tenant object is a logical collection of data and metadata artifacts that have been assigned to a tenant. A tenant can be exposed as a first-class database object (i.e., having an identity independent of any other database entity).

[0016] The specific instantiated database artifacts assigned to a tenant object (i.e., a particular tenant) may include, but are not limited to, data on one or more schemas, tables, and partitions, as well as metadata defining the tenant's tables, virtual tables, caches, remote sources, workload classes used to manage the resource usage of the tenant's database objects, and views on the database user. Advantageously, the tenant's lifecycle can be decoupled from the lifecycle of its assigned database artifacts. However, in some embodiments, discarding a tenant from the database instance results in the discarding of the artifacts assigned to it, provided that those artifacts have not been assigned to another tenant of the database instance.

[0017] A local multi-tenant database system can include one or more database instances, data for all tenants, and an engine for processing that data. The single system also includes a single persistence for the data across all tenants. By allowing multiple independent tenants, or more precisely, customers, to be hosted on a single instance and share computing resources, deploying new tenants to the database instance is associated with near-zero marginal cost. The latter comes at the cost of lower isolation between different tenants. Furthermore, the embodiments implement a pay-as-you-go model with a finer granularity than is required to provision individual database instances.

[0018] In cases where tenants require stronger data isolation than the logical isolation described above, a tenant can be deployed as the sole tenant of the database instance. Because this arrangement does not fully leverage the cost-effectiveness of multi-tenancy, the price charged to a single tenant may be higher than other methods.

[0019] According to some embodiments, the database system supports requests for tenant-level database operations that would otherwise need to be implemented by the application. These operations may include tenant creation, tenant dropping, tenant migration, restoring a tenant from a backup, tenant cloning, tenant resizing, and tenant resource limits. In some embodiments, a shared service exposes an API (e.g., via REST) ​​invoked by multitenant applications to request these tenant-level operations from the database system using, for example, an associated tenant ID. Current database system DDLs can be extended to support the assignment of database artifacts to tenants.

[0020] Tenant-level cloning operations can be useful for loading new customers in order to provide template data to them. Cloning operations are a form of tenant creation.

[0021] Some implementations provide tenant-level recovery of point-in-time data. This recovery does not restore data for all customers (i.e., the entire database instance), but rather restores data for a specific tenant. For example, if one tenant's data is corrupted, only the data of the corrupted tenant needs to be recovered.

[0022] In some implementations, one user can define only the artifacts assigned to a tenant, and another user can only be allowed to perform cloning / moving operations. Otherwise, a malicious administrator could create a tenant, assign objects to it, and clone the tenant's contents to another system completely under the malicious administrator's control. Additionally, a malicious administrator could discard a tenant and delete all objects assigned to that tenant.

[0023] The implementation can provide tenant-level encryption to encrypt data in tables assigned to tenants. This functionality encrypts each tenant's persistent data (i.e., at-rest data) using a separate tenant-specific key, even though this data is not physically isolated from other tenants' data within the database instance. Therefore, the implementation can enable the database instance to access a customer-specific key repository.

[0024] Shared data and metadata (e.g., database directories, users, shared containers) can be encrypted in the persistence layer using a database instance-specific key. In contrast, existing systems provide encryption of the entire persistence layer using a single database instance-specific key.

[0025] A tenant's location, i.e., the database instance in which the tenant and its artifacts reside, is one of the tenant's attributes and is determined by multi-tenant applications. The application can also determine to move a tenant from one database instance to a different database instance as the tenant grows or shrinks in data size and resource consumption. This move provides resilience in cloud-based implementations and is preferably performed online to avoid downtime. Tenant-specific security attributes, such as encryption, should be preserved during the tenant move operation.

[0026] Database resource consumption quotas can be defined at the tenant level. These quotas can address the "noisy neighbor" problem. Depending on the technical infrastructure's ability to measure and control this usage, tenant session variables can define tenant-specific usage limits for memory, threads, network I / O, disk I / O, disk size, and more.

[0027] Figure 1 This is a block diagram of system 100 according to some embodiments. The elements shown in system 100 and all other architectures depicted herein can be implemented using any suitable combination of known or becoming known computing hardware and / or processor executable code. Such combinations may include one or more programmable processors (microprocessors, central processing units, microprocessor cores, execution threads), one or more non-transitory electronic storage media, and processor executable code. In some embodiments, two or more elements of system 100 are implemented by a single computing device, and / or two or more elements of system 100 are located in the same location. One or more elements of system 100 may be implemented as cloud services using cloud-based resources (e.g., Software as a Service, Platform as a Service), and / or other systems that flexibly allocate computing resources based on demand, need, price, and / or any other metric.

[0028] According to some embodiments, database instance 110 provides native multitenancy. Database instance 110 can be provided on any suitable combination of hardware and software, including one or more computer servers or virtual machines. In some embodiments, database instance 110 includes a containerized application executing within a software container. As is known in the art, such a container can be implemented by one or more nodes of a cluster (e.g., a Kubernetes cluster).

[0029] Database instance 110 includes a data engine 111 for processing data and metadata stored in volatile (e.g., random access) memory 112. Memory 112 includes data 118 and metadata 119 allocated to all tenants of database instance 110. Each tenant of system 100 will be described as corresponding to a customer, where a customer can be a company, department, workgroup, or any other user group. A tenant can correspond to a specific cloud resource / service subscription for a given customer. In this respect, a customer can be associated with more than one subscription, and therefore can be associated with more than one tenant.

[0030] Specifically, storage 112 includes tenant instance 114 of tenant "A" and tenant instance 116 of tenant "B". Each tenant instance 114 and 116 is an instance of a tenant object defined in metadata 119. Tenant instances 114 and 116 may be stored within data 118, but are depicted separately for ease of understanding.

[0031] As described above, each tenant instance 114 and 116 is a collection of database artifacts. Artifacts assigned to each tenant instance 114 and 116 are stored between data 118 and metadata 119. Therefore, dashed lines are used to depict artifact A 115 assigned to tenant instance 114 and artifact B 117 assigned to tenant instance 116 to represent references to the database artifacts in data 118 and metadata 119. Database artifacts assigned to tenant instances may include, for example, one or more schemas, tables, and partitions. Database artifacts may also include metadata defining tables, virtual tables, caches, remote sources, workload classes for managing resource usage of database objects for tenants, and views for database users.

[0032] Database instance 110 also includes persistence 113 for persisting data 118 and metadata 119 for all allocated tenants (as well as separately depicted instances 114 and 116). Persistence 113 can be implemented using any persistent data storage system known or becoming known, including but not limited to distributed data storage systems. Persistence 113 can persist transaction logs and other database artifacts known in the art.

[0033] Database instance 110 thus provides a single data server for all tenants' data and metadata, an engine for processing the data, and a single persistence mechanism for the data and metadata. Hosting multiple independent tenants on such a single database instance facilitates the sharing of computing resources at near-zero marginal cost.

[0034] Multitenant application 120 may include SaaS applications, but embodiments are not limited thereto. Multitenant application 120 may be provided on one or more computer servers or virtual machines and may include containerized applications that execute within software containers. Multitenant application 120 issues queries (e.g., SQL, MDX) to database instance 110 based on input received from users 135 and 145 of clients 130 and 140, respectively.

[0035] Assume that customer A 130 corresponds to tenant A 114 of database instance 110, and customer B 140 corresponds to tenant B 116 of database instance 110. Upon receiving input from user 135 of customer A 130, multi-tenant application 120 can send a query to database instance 110 indicating the association with tenant A 114. Similarly, upon receiving input from user 145 of customer B 140, multi-tenant application 120 can send a query to database instance 110 along with an indication of the association of that query with tenant B 116. Upon receiving a query from multi-tenant application 120, database instance 110 processes the query using data engine 111 and artifacts assigned to the tenant associated with the query.

[0036] Therefore, multi-tenant application 120 is able to identify the tenant corresponding to the user from whom it receives input. For example, each user can log in to multi-tenant application 120 using a tenant-specific subscription. Thus, multi-tenant application 120 associates a user with the tenant of the subscription the user has already logged into. In another example, communication between the user and multi-tenant application 120 may include a tenant identification token.

[0037] The multi-tenant application 120 also knows which tenants are placed on which database instances. In this regard, the multi-tenant application 120 can request and provision database instances and create tenants on the provisioned database instances. When receiving input from a user associated with a given tenant, the multi-tenant application 120 is able to determine the database instance that includes the given tenant and therefore should direct the corresponding query to that database instance.

[0038] Multitenant application 120 can request a provisioned database instance and create tenants on the provisioned database instance based on input received by a key customer user. According to some embodiments, multitenant application 120 invokes a provisioning service (…). Figure 1(Not shown in the image) to provision new database instances. Multitenant applications 120 can also invoke the tenant lifecycle management service (…). Figure 1 The REST API (not shown in the image) allows you to create tenants on a database instance, delete tenants from a database instance, move tenants to a database instance, restore tenants from a database backup, clone tenants to a database instance (i.e., create them as templates), resize tenants on a database instance, define tenant resource limits on a database instance, and more.

[0039] Figure 2 The system 200 is shown, in which, in addition to database instance 110, multi-tenant application 120 also requests to provision database instance 210. Database instance 210 includes its own data engine 211, storage 212, and persistence 213.

[0040] Multitenant application 120 also requests the creation of tenant C on database instance 210. Tenant C corresponds to client C 230. Therefore, storage 212 includes a tenant object instance 214 of tenant C assigned to artifact C 215. Artifact C 215 includes data and metadata stored in data 216 and metadata 217 in storage 212. Therefore, when input is received from user 235 of client C 230, multitenant application 120 directs any resulting queries to database instance 210 because multitenant application 120 knows that database instance 210 includes tenant C 214 corresponding to client C 230.

[0041] In some embodiments, each tenant is identified by a unique name within its own database instance. Therefore, tenant C 214 can be named tenant A because database instances 110 and 210 operate independently. Multi-tenant applications can provide multiple database instances and offer resilience to their tenants through tenant movement operations. In this case, the application should ensure that tenant movement to a target database instance does not introduce tenant name conflicts on the target database instance.

[0042] Figure 3 The diagram illustrates a system 300 in which a multi-tenant application 310 is associated with an instance farm 320. Farm 320 includes several database instances, including instances 321 and 325. Farm 320 may include on which the multi-tenant application 310 can provision the database instances and create tenant execution environments on the database instances.

[0043] Multitenant application 310 knows the database instances provisioned within farm 320 and the tenants on each database instance. Each database instance in farm 320 knows its tenants and the users, schemas, and other metadata it stores. However, a given database instance in farm 320 does not know the tenants, schemas, etc., of the other database instances in farm 320.

[0044] Multitenant application 310 can specify storage and persistence sizes for each database instance of farm 320, and increase or decrease these sizes as needed. Multitenant application 310 can also create tenants on the database instances of farm 320, specify their initial sizes, and increase or decrease the tenant sizes as needed. As mentioned above, multitenant application 310 can also remove tenants from or move tenants to database instances.

[0045] Each database instance of system 300 can be executed by a cluster (e.g., a Kubernetes cluster). Each cluster can allow multi-tenant application 310 to provision extended nodes to provide additional computing resources to its database instance. Furthermore, multi-tenant application 310 can be node-aware, allowing tenants to move between nodes of the same database instance or nodes of different database instances.

[0046] Figure 4 This is a block diagram of a system 400 providing native multitenancy according to some embodiments. Database instance 450 includes tenant object instances 452 and 454 associated with artifacts 453 and 455 as described above. For clarity, Figure 4 The data engine and persistence of database instance 450 are omitted.

[0047] Each tenant instance of database instance 450 corresponds to a corresponding one in customer 410. Customer A 411 includes key user 412 and business user 413, and customer N 417 includes key user 418 and business user 419. Figure 5 Including, for example Figure 4 The flowchart shown is a process 500 for supplying database instances and creating tenant instances therein, according to some embodiments.

[0048] Process 500 and all other processes mentioned herein may be embodied in program code that can be executed by one or more processing units (e.g., processors, processor cores, processor threads) and read from one or more non-transitory computer-readable media (such as hard disk drives, volatile or non-volatile random access memory, DVD-ROMs, flash drives, and magnetic tapes), and then stored in a compressed, uncompiled, and / or encrypted format. In some embodiments, hardwired circuitry may be used in place of, or in combination with, the program code used to implement the processes according to some embodiments. Therefore, the embodiments are not limited to any particular combination of hardware and software.

[0049] At S510, the database instance where the tenant resides is initially provisioned. (Reference) Figure 4For example, a key user 412 can access a multi-tenant application 420 to request the provisioning of a database instance. This request is forwarded to the service manager 430 and the cloud service agent 440. Then, at S520, the cloud service agent 440 provides the database instance 450 as a cloud-based resource.

[0050] At S520, a tenant object instance is created in the database instance. Continuing the example above, key user 412 can access multitenant application 420 to request the creation of a tenant on database instance 450. This request is forwarded to service manager 430, service broker 460, and tenant management service 470. Tenant management service 470 then instructs database instance 450 to create tenant A instance 452 based on the tenant object defined in metadata 457. Tenant A instance 452 can be identified by the tenant ID known to database instance 450 and multitenant application 420.

[0051] Next, at S530, database artifacts are assigned to the tenant instance created at S520. For example, multi-tenant application 420 requests tenant management service 470 to instruct database instance 450 to associate tenant A instance 452 with artifact A 453. Key user 412 may have previously operated multi-tenant application 420 and service broker 460 to define artifact A 453 within data 456 and metadata 457 of database instance 450. Although created by service broker 460, all database artifacts are managed by multi-tenant application 420.

[0052] Some implementations may use deployment infrastructure to define database artifacts to be assigned to tenant instances. Deployment infrastructure can provide a declarative approach for defining database objects (e.g., as design-time artifacts) using containers. For example, service broker 460 may create containers corresponding to database schemas and additional metadata (e.g., users, roles, and privileges that can then be assigned to tenant instances). Such containers can be isolated from each other by schema-level access privileges. Application 420 can access any database object in the container's database schema using the assigned per-schema technical database user.

[0053] The process loops at S540 until a command to create another tenant in the database instance is received. For example, key user 418 of customer N 417 can access multitenant application 420 to request the creation of a tenant on database instance 450. This request is forwarded to service manager 430, service broker 460, and tenant management service 470, which instructs database instance 450 at S520 to create tenant N instance 454. At S530, multitenant application 420 also instructs tenant management service 470 to assign the previously defined artifact N 455 to tenant N instance 454.

[0054] After provisioning database instance 450 and creating tenants 452 and 454, multitenant application 420 may receive input, for example, from business user 413 of customer A 411. In response, application 420 directs any resulting queries to database instance 450 via tenant management service 470 and identifies tenant A 452. Database instance 450 responds to the query based on artifact A453 of tenant instance A 452. In the case where multitenant application 420 receives input from business user 419 of customer N 417, any resulting queries are directed to database instance 450 and responded to based on artifact N 455 of tenant instance N 454.

[0055] Figure 6 This is a block diagram of a system 600 that provides native multitenancy and tenant-level encryption according to some embodiments. The elements of system 600, which are numbered similarly to those of system 400 (i.e., 6xx to 4xx), can be implemented and operated similarly.

[0056] System 600 shows from Figure 4 The persistence 660 of database instance 650 is omitted. Persistence 660 can be implemented using any suitable storage system or one or more. Persistence 660 stores data 662, 664 for each tenant of instance 650, data 666 of instance 650 not assigned to a specific tenant, and metadata 668 of instance 650. Advantageously, and compared to existing systems, persistent data 662 and 664 are encrypted using encryption keys specific to their corresponding tenants (i.e., clients) (i.e., data encryption keys (DEK)A and DEKN). Furthermore, persistent unassigned data 666 and metadata 668 are encrypted using a database instance-specific encryption key (i.e., DEKDB).

[0057] According to some embodiments, the DEK DB is a public-private key pair generated as part of the creation of database instance 650. Database instance 650 uses the DEK DB's public key to encrypt data 665 and data 668 before storing them in persistence 660. Database instance 650 uses the DEK DB's private key to decrypt data 665 and data 668 as needed. In some embodiments, the DEK DB's private key is stored in encrypted form in secure storage persistence 675.

[0058] For example, a key user 695 of the database instance provider 690 provides a Key Encryption Key (KEK) DB to the key management system 680 for storage in the key vault 685. The KEK DB is used to encrypt the private key of the DEK DB before storing it in the secure persistent storage 675. The KEK DB may also include a private-public key pair, where the key vault 685 stores the private key of the KEK DB, and the corresponding public key is used to encrypt the private key of the DEK DB before storing it in the secure persistent storage 675.

[0059] Therefore, when database instance 650 wants to decrypt data 665 or data 668, database instance 650 requests the private key of the DEK DB from secure storage 670. In response, secure storage 670 requests key management system 680 to use the private key of the DEK DB to decrypt the stored encryption private key of the DEK DB. Then, database system 650 uses the private key to decrypt the DEK DB to decrypt the desired data 665 or data 668.

[0060] Similarly, DEK A may include a public-private key pair generated during the creation of tenant A 652. Database instance 650 uses the public key of DEK A to encrypt data 662 before storing it in persistence 660. Database instance 650 uses the private key of DEK A to decrypt data 662 as needed. In some embodiments, the private key of DEK A is stored in encrypted form in secure storage persistence 675.

[0061] Customer A 611's key user 612 provides KEK A to the key management system 680 for storage in the key vault 685. KEK A is used to encrypt the private key of DEK A before storing the private key of DEK A in the secure persistent storage 675. KEK A may include a private-public key pair, where the key vault 685 stores the private key of KEK A, and the corresponding public key is used to encrypt the private key of DEK A before storing the private key of DEK A in the secure persistent storage 675.

[0062] When database instance 650 wishes to decrypt data 662, it requests the private key of DEK A from secure storage 670. In response, secure storage 670 requests key management system 680 to use the private key of DEK A to decrypt the stored encryption private key of DEK A. This request can be issued to a client-specific account 611 of key management system 680. Database instance 650 then uses the decryption private key of DEK A to decrypt the desired data 662. Therefore, if client A revokes DEK A from key vault 685, database provider 690 cannot decrypt the stored private key DEK A, and thus cannot decrypt data 662. The aforementioned process can occur for each newly created tenant N.

[0063] Architecture 600 can provide other encryption not described herein. For example, TLS / SSL can be used to encrypt data transmitted from the client to and from database instance 650 during transport. Furthermore, known techniques (e.g., using client-controlled keys) can be used to encrypt individual table columns in non-persistent storage 651.

[0064] Figure 7 A cloud-based database deployment 700 according to some embodiments is illustrated. User equipment 710 may include any suitable computing system operable by key or business users to access a cloud-based multitenant application. User equipment 710 may store and execute web browser program code to access a Uniform Resource Locator (URL) associated with the login page of such multitenant application. As is known in the art, a web browser can download and execute program code of client-side components of a multitenant application.

[0065] According to some embodiments, application server nodes 720, 722, and 724 can host multitenant applications. Database nodes 730, 732, and 734 can host one or more database instances that are natively multitenant as described herein, accessible to multitenant applications. Each node deployed on 700 can include a separate physical machine or virtual machine. Such virtual machines can be allocated by a cloud provider offering self-service and on-demand provisioning, auto-scaling, security, compliance, and identity management features.

[0066] The foregoing figures illustrate a logical architecture for describing processes according to some embodiments, and actual implementations may include more or different components arranged in other ways. Other topologies may be used in conjunction with other embodiments. Furthermore, each component or device described herein may be implemented by any number of devices communicating via any number of other public and / or private networks. Two or more such computing devices may be located remotely to each other and may communicate with each other via any known network(s) and / or private connection(s). Each component or device may include any number of hardware and / or software elements suitable for providing the functionality described herein as well as any other functionality. For example, any computing device may include a programmable processor to execute program code causing the computing device to operate as described herein.

[0067] All systems and processes discussed herein can be embodied in program code stored on one or more non-transitory computer-readable media. Such media may include, for example, DVD-ROM, flash memory drives, magnetic tape, and solid-state random access memory (RAM) or read-only memory (ROM) storage units. Therefore, embodiments are not limited to any particular combination of hardware and software.

[0068] This document describes components that can communicate with each other, directly or indirectly, through any number of different systems used for transmitting data, including but not limited to shared memory communication, local area networks, wide area networks, telephone networks, cellular networks, fiber optic networks, satellite networks, infrared networks, radio frequency networks, and any other type of network that can be used to transmit information between devices. Furthermore, communication between systems can be carried out through any one or more known or becoming known transport protocols, such as Asynchronous Transfer Mode (ATM), Internet Protocol (IP), Hypertext Transfer Protocol (HTTP), and Wireless Application Protocol (WAP).

[0069] The embodiments described herein are for illustrative purposes only. Those skilled in the art will recognize that other embodiments can be practiced through modifications and changes to the above embodiments.

Claims

1. A database system, comprising: Memory, storage: Metadata defines tenant objects and multiple database artifacts; A first instance of a tenant object, the first instance being associated with a first plurality of database artifacts, the first plurality of database artifacts including first data associated with the first instance of the tenant object; and A second instance of the tenant object, the second instance being associated with a second plurality of database artifacts, the second plurality of database artifacts including second data associated with the second instance of the tenant object; as well as A processing unit is used to execute program code for a database instance, the program code being executable to enable the system to: Receive and respond to queries for first data associated with a first instance of the tenant object and queries for second data associated with a second instance of the tenant object; and Receive and respond to a request to move a first instance of a tenant object and a first plurality of database artifacts from the database instance to a second database instance when data size and resource consumption increase or decrease, wherein the move is performed online, and wherein a second instance of the tenant object and the second plurality of database artifacts are not moved to the second database instance.

2. The system of claim 1, wherein the system includes a persistent storage system for storing first persistent data associated with a first instance of a tenant object and second persistent data associated with a second instance of a tenant object.

3. The system according to claim 2, wherein, The first persistent data is encrypted using a first encryption key associated with a first instance of the tenant object, and the second persistent data is encrypted using a second encryption key associated with a second instance of the tenant object.

4. The system of claim 3, wherein the persistent storage system stores third persistent data not associated with a first instance or a second instance of a tenant object, the third persistent data being encrypted using a third encryption key, and the metadata being encrypted using the third encryption key.

5. The system of claim 1, wherein the program code is executable to cause the system to receive and respond to a request to restore a first instance of a tenant object and a first plurality of database artifacts from a backup, wherein, The second instance of the tenant object and the second and a second database artifacts are not restored from the backup.

6. The system of claim 1, wherein the program code is executable to cause the system to receive and respond to a request to associate a first resource consumption limit with a first instance of a tenant object and a second resource consumption limit with a second instance of a tenant object, wherein, The first resource consumption limit is different from the second resource consumption limit.

7. A computer-implemented method, comprising: Create the first instance of the tenant object in the database instance; Associate a first instance of a tenant object with a first plurality of database artifacts, the first plurality of database artifacts including first data associated with the first instance of the tenant object; Create a second instance of the tenant object in the database instance; Associate a second instance of the tenant object with a second plurality of database artifacts, the second plurality of database artifacts including second data associated with the second instance of the tenant object; Receive and respond to queries for first data associated with a first instance of a tenant object and queries for second data associated with a second instance of a tenant object; as well as Receive and respond to a request to move a first instance of a tenant object and a first plurality of database artifacts from the database instance to a second database instance when data size and resource consumption increase or decrease, wherein the move is performed online, and wherein a second instance of the tenant object and the second plurality of database artifacts are not moved to the second database instance.

8. The computer-implemented method according to claim 7, further comprising: The first persistent data associated with the first instance of the tenant object and the second persistent data associated with the second instance of the tenant object are stored in the persistent storage system.

9. The computer-implemented method according to claim 8, wherein, The first persistent data is encrypted using a first encryption key associated with a first instance of the tenant object, and the second persistent data is encrypted using a second encryption key associated with a second instance of the tenant object.

10. The computer-implemented method according to claim 9, further comprising: A third encryption key is used to encrypt third persistent data that is not associated with a first instance or a second instance of a tenant object, as well as metadata defining a first plurality of database artifacts and a second plurality of database artifacts; and the encrypted third persistent data and metadata are stored in a persistent storage system.

11. The computer-implemented method according to claim 7, further comprising: Receives a request to restore the first instance of a tenant object and the first plurality of database artifacts from a backup; as well as In response to the request, a first instance of the tenant object and a first plurality of database artifacts are restored from the backup, wherein a second instance of the tenant object and a second plurality of database artifacts are not restored from the backup.

12. The computer-implemented method according to claim 7, further comprising: Receive a request to associate a first resource consumption limit with a first instance of a tenant object and a second resource consumption limit with a second instance of a tenant object; as well as In response to the request, a first resource consumption limit is associated with a first instance of the tenant object and a second resource consumption limit is associated with a second instance of the tenant, wherein the first resource consumption limit is different from the second resource consumption limit.

13. A non-transitory computer-readable medium storing program code, said program code being executable by one or more processing units to enable a computing system to: Create the first instance of the tenant object in the database instance; Associate a first instance of a tenant object with a first plurality of database artifacts, the first plurality of database artifacts including first data associated with the first instance of the tenant object; Create a second instance of the tenant object in the database instance; Associate a second instance of the tenant object with a second plurality of database artifacts, the second plurality of database artifacts including second data associated with the second instance of the tenant object; Receive and respond to queries for first data associated with a first instance of a tenant object and queries for second data associated with a second instance of a tenant object; as well as Receive and respond to a request to move a first instance of a tenant object and a first plurality of database artifacts from the database instance to a second database instance when data size and resource consumption increase or decrease, wherein the move is performed online, and wherein a second instance of the tenant object and the second plurality of database artifacts are not moved to the second database instance.

14. The medium of claim 13, wherein the program code may also be executed by one or more processing units to enable the computing system to: The first persistent data associated with the first instance of the tenant object and the second persistent data associated with the second instance of the tenant object are stored in the persistent storage system. in, The first persistent data is encrypted using a first encryption key associated with a first instance of the tenant object, and The second persistent data is encrypted using a second encryption key associated with a second instance of the tenant object.

15. The medium of claim 14, wherein the program code may also be executed by one or more processing units to enable the computing system to: A third encryption key is used to encrypt third persistent data not associated with a first instance or a second instance of a tenant object, as well as metadata defining a first plurality of database artifacts and a second plurality of database artifacts; and Storing encrypted third-party persistent data and metadata in a persistent storage system.

16. The medium of claim 13, wherein the program code may also be executed by one or more processing units to enable the computing system to: Receives a request to restore the first instance of a tenant object and the first plurality of database artifacts from a backup; and In response to the request, a first instance of the tenant object and a first plurality of database artifacts are restored from the backup. in, The second instance of the tenant object and the second and a second database artifacts are not restored from the backup.

17. The medium of claim 13, wherein the program code may also be executed by one or more processing units to enable the computing system to: Receive a request to associate a first resource consumption limit with a first instance of a tenant object and a second resource consumption limit with a second instance of a tenant object; and In response to the request, a first resource consumption limit is associated with a first instance of the tenant object and a second resource consumption limit is associated with a second instance of the tenant. in, The first resource consumption limit is different from the second resource consumption limit.

Images