US-20260127144-A1 - HYBRID DATA STORAGE ARCHITECTURE FOR MULTI-TENANT SERVICES

US20260127144A1US 20260127144 A1US20260127144 A1US 20260127144A1US-20260127144-A1

Abstract

Systems and methods described herein relate to a hybrid data storage architecture for multi-tenant services. A first tenant selects a standalone schema and a second tenant selects a shared schema. The standalone schema is generated for the first tenant. First data of the first tenant is stored in a plurality of dedicated tables of the standalone schema. Second data of the second tenant is stored in a plurality of shared tables of the shared schema. A virtual schema comprises view definitions that correspond to the plurality of shared tables and that filter based on a tenant identifier of the second tenant. The second data is operated on via the virtual schema. One or more data operations with uniform operation patterns are applied across the standalone schema and the shared schema.

Inventors

Hui Li

Assignees

SAP SE

Dates

Publication Date: 20260507
Application Date: 20241105

Claims (20)

1 . A system comprising: at least one memory that stores instructions; and one or more processors configured by the instructions to perform operations comprising: generating a standalone schema comprising a plurality of dedicated tables for a first tenant; storing first data of the first tenant in the plurality of dedicated tables of the standalone schema; storing second data of a second tenant in a plurality of shared tables of a shared schema, the second data of the second tenant being distinguished from data of other tenants by use of a second tenant identifier of the second tenant; storing third data of a third tenant in the plurality of shared tables of the shared schema, the third data of the third tenant being distinguished from data of other tenants by use of a third tenant identifier of the third tenant; generating a virtual schema comprising view definitions that correspond to the plurality of shared tables and that filter based on the second tenant identifier; and performing data operations on the first data in the standalone schema and the second data in the shared schema, the second data in the shared schema being operated on via the virtual schema, and the data operations comprising one or more uniform operation patterns applied across the standalone schema and the shared schema.
2 . The system of claim 1 , wherein the first tenant has a first tenant identifier, the operations further comprising: receiving, from a device associated with the first tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the standalone schema to the shared schema, the schema type conversion comprising: copying the first data from the standalone schema to at least a subset of the plurality of shared tables of the shared schema; deleting the plurality of dedicated tables of the standalone schema; and generating further view definitions that correspond to at least the subset of the plurality of shared tables and that filter based on the first tenant identifier of the first tenant.
3 . The system of claim 1 , wherein the standalone schema is a first standalone schema for the first tenant, the operations further comprising: receiving, from a device associated with the second tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the shared schema to a further standalone schema, the schema type conversion comprising: removing the view definitions from the virtual schema; generating a second standalone schema for the second tenant; copying the second data from the shared schema to the second standalone schema; and deleting the second data from the shared schema.
4 . The system of claim 1 , wherein the one or more uniform operation patterns include one or more preconfigured operation patterns for at least one of querying operations, editing operations, or deleting operations.
5 . The system of claim 4 , wherein one or more operation patterns for inserting operations are nonuniform between the standalone schema and the shared schema.
6 . The system of claim 1 , wherein the one or more uniform operation patterns comprise one or more Structured Query Language (SQL) statement structures that are automatically applied to data in both the standalone schema and the shared schema.
7 . The system of claim 1 , wherein the one or more uniform operation patterns include preconfigured operation patterns for at least two of querying operations, editing operations, or deleting operations.
8 . The system of claim 1 , wherein each of the view definitions define a view with a name that matches the name of a respective one of the plurality of shared tables.
9 . The system of claim 1 , wherein the plurality of shared tables are shared among multiple tenants and distinguishes tenant data by respective tenant identifiers.
10 . The system of claim 9 , the operations further comprising: generating a respective virtual schema for each of the multiple tenants.
11 . The system of claim 1 , the operations comprising: receiving, from a first device associated with the first tenant, a first selection to use the standalone schema, wherein the generating of the standalone schema is performed in response to the receiving of the first selection; and receiving, from a second device associated with the second tenant, a second selection to use the shared schema, wherein the generating of the virtual schema is performed in response to the receiving of the second selection.
12 . The system of claim 11 , the operations comprising: causing presentation of a user interface at the first device and the second device, the user interface including a first user-selectable element to perform the first selection and a second user-selectable element to perform the second selection.
13 . The system of claim 2 , the operations comprising: causing presentation of a user interface at the device associated with the first tenant, the user interface including a user-selectable element to trigger generation of the conversion request.
14 . The system of claim 3 , the operations comprising: causing presentation of a user interface at the device associated with the second tenant, the user interface including a user-selectable element to trigger generation of the conversion request.
15 . A computer-implemented method performed by a computer system comprising a memory and at least one hardware processor, the computer-implemented method comprising: generating a standalone schema comprising a plurality of dedicated tables for a first tenant; storing first data of the first tenant in the plurality of dedicated tables of the standalone schema; storing second data of a second tenant in a plurality of shared tables of a shared schema, the second data of the second tenant being distinguished from data of other tenants by use of a second tenant identifier of the second tenant; storing third data of a third tenant in the plurality of shared tables of the shared schema, the third data of the third tenant being distinguished from data of other tenants by use of a third tenant identifier of the third tenant; generating a virtual schema comprising view definitions that correspond to the plurality of shared tables and that filter based on the second tenant identifier; and performing data operations on the first data in the standalone schema and the second data in the shared schema, the second data in the shared schema being operated on via the virtual schema, and the data operations comprising one or more uniform operation patterns applied across the standalone schema and the shared schema.
16 . The computer-implemented method of claim 15 , wherein the first tenant has a first tenant identifier, the computer-implemented method further comprising: receiving, from a device associated with the first tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the standalone schema to the shared schema, the schema type conversion comprising: copying the first data from the standalone schema to at least a subset of the plurality of shared tables of the shared schema; deleting the plurality of dedicated tables of the standalone schema; and generating further view definitions that correspond to at least the subset of the plurality of shared tables and that filter based on the first tenant identifier of the first tenant.
17 . The computer-implemented method of claim 15 , wherein the standalone schema is a first standalone schema for the first tenant, the computer-implemented method further comprising: receiving, from a device associated with the second tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the shared schema to a further standalone schema, the schema type conversion comprising: removing the view definitions from the virtual schema; generating a second standalone schema for the second tenant; copying the second data from the shared schema to the second standalone schema; and deleting the second data from the shared schema.
18 . One or more non-transitory computer-readable media storing computer-executable instructions that, when executed by a computing system, cause the computing system to perform operations comprising: generating a standalone schema comprising a plurality of dedicated tables for a first tenant; storing first data of the first tenant in the plurality of dedicated tables of the standalone schema; storing second data of a second tenant in a plurality of shared tables of a shared schema, the second data of the second tenant being distinguished from data of other tenants by use of a second tenant identifier of the second tenant; storing third data of a third tenant in the plurality of shared tables of the shared schema, the third data of the third tenant being distinguished from data of other tenants by use of a third tenant identifier of the third tenant; generating a virtual schema comprising view definitions that correspond to the plurality of shared tables and that filter based on a tenant identifier of the second tenant; and performing data operations on the first data in the standalone schema and the second data in the shared schema, the second data in the shared schema being operated on via the virtual schema, and the data operations comprising one or more uniform operation patterns applied across the standalone schema and the shared schema.
19 . The one or more non-transitory computer-readable media of claim 18 , wherein the first tenant has a first tenant identifier, the operations further comprising: receiving, from a device associated with the first tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the standalone schema to the shared schema, the schema type conversion comprising: copying the first data from the standalone schema to at least a subset of the plurality of shared tables of the shared schema; deleting the plurality of dedicated tables of the standalone schema; and generating further view definitions that correspond to at least the subset of the plurality of shared tables and that filter based on the first tenant identifier of the first tenant.
20 . The one or more non-transitory computer-readable media of claim 18 , wherein the standalone schema is a first standalone schema for the first tenant, the operations further comprising: receiving, from a device associated with the second tenant, a conversion request; and in response to receiving the conversion request, automatically performing a schema type conversion to convert from the shared schema to a further standalone schema, the schema type conversion comprising: removing the view definitions from the virtual schema; generating a second standalone schema for the second tenant; copying the second data from the shared schema to the second standalone schema; and deleting the second data from the shared schema.

Description

TECHNICAL FIELD The subject matter disclosed herein generally relates to cloud computing technologies. More specifically, but not exclusively, the subject matter relates to a hybrid data storage architecture for multi-tenant services or platforms, such as software as a service (SaaS) platforms. BACKGROUND In a multi-tenant system (e.g., a SaaS platform), a single database or database system serves multiple tenants. To manage database storage, the multi-tenant system typically utilizes either a standalone schema data storage model or a shared schema data storage model. In the standalone schema model, each tenant owns a respective standalone schema with dedicated tables, and the standalone schemas typically utilize the same database table structure. In the shared schema model, tenants share a common database schema, with data coexisting in common tables and different tenants being distinguished by way of tenant identifiers. A standalone schema model can provide technical benefits such as stricter segregation of data, better data security, and easier data migration or recovery. However, as the number of tenants grows, the database has to maintain an increasing number of tables, consuming significant hardware and software resources and potentially degrading system performance. A shared schema model consumes comparatively less resources per tenant, often making the shared schema model a less costly option. However, the shared schema model can introduce technical complexities in ensuring proper data segregation, maintaining data security, or facilitating data migration or recovery. BRIEF DESCRIPTION OF THE DRAWINGS Some examples are shown for purposes of illustration and not limitation in the figures of the accompanying drawings. In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views or examples. To identify the discussion of any particular element or act more easily, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced. FIG. 1 is a diagrammatic representation of a network environment that includes a database schema management system to implement a hybrid data storage architecture, according to some examples. FIG. 2 is a block diagram of components of a database schema management system, according to some examples. FIG. 3 is a diagrammatic representation of a hybrid data storage architecture, according to some examples. FIG. 4 is a flowchart illustrating operations of a method for providing hybrid data storage in a multi-tenant environment, according to some examples. FIG. 5 is a flowchart illustrating operations of a method for automatically converting a schema type from a standalone schema to a shared schema, according to some examples. FIG. 6 is a flowchart illustrating operations of a method for automatically converting a schema type from a shared schema to a standalone schema, according to some examples. FIG. 7 is a user interface diagram illustrating a user interface that enables the selection of a standalone schema or a shared schema, according to some examples. FIG. 8 is a user interface diagram illustrating a user interface that enables the triggering of a conversion request for changing a schema type, according to some examples. FIG. 9 is a block diagram showing a software architecture for a computing device, according to some examples. FIG. 10 is a block diagram of a machine in the form of a computer system, according to some examples, within which instructions may be executed for causing the machine to perform any one or more of the methodologies discussed herein. DETAILED DESCRIPTION Systems and methods described herein relate to a hybrid data storage architecture. Examples in the present disclosure provide a flexible, adaptable system that incorporates multiple storage models to cater to diverse tenant requirements. For example, tenants are provided with different storage model options within the context of a single SaaS platform. While existing multi-tenant systems require tenants to adhere to a single storage model (e.g., the model chosen by the SaaS provider), the present disclosure provides a technical solution that enables tenants to choose between a standalone schema and a shared schema based on their specific requirements or preferences. This approach provides flexibility by offering technical benefits of both storage models. Examples in the present disclosure provide a consistent interface for at least some data operations across both standalone and shared schemas, enabling the system to maintain uniform operation patterns for operations such as querying, editing, and deleting data, regardless of the underlying schema type chosen by each tenant. Additionally, the system may provide a mechanism for automatically converting between schema types. A “standalone schema,” as used herein, refers to a dedicated schema for an individual entity, such as a tena