System and method for structuring and accessing tenant data in a hierarchical multi-user environment.

Abstract

The invention relates to a multi-user hierarchical storage system for user data (100) comprising a computer-readable storage medium configurable into horizontal partitions, a plurality of user nodes stored on the storage medium, a plurality of child nodes accessible from the user nodes, and a plurality of horizontal partitions, wherein each horizontal partition contains the data of a single user, and the user nodes and child nodes are located on the horizontal partitions. The system includes at least one virtual horizontal partition for storing the child nodes. The invention also relates to a computer implementation method for handling parallel access requests to user nodes in such a system.

Description

Scope of the invention

[0001] The invention relates to the storage and access to data in computer systems involving a multi-user environment. Technical background

[0002] The increasing demand for data storage creates scalability problems. Storing huge amounts of highly consistent data in a single storage solution can pose problems in terms of performance, usability, and system security isolation.

[0003] Vertical scaling means adding central processing unit, memory, or disk capacity. This ensures linear growth in productivity, but after a while, the method stops working.

[0004] Horizontal scaling involves dividing the data into parts and decomposing them across different storage areas. Dividing the data into parts is called fragmentation. Decomposition is called partitioning. The storage areas can be decomposed across one or more disks.

[0005] Multi-user hierarchical systems present unique challenges. The distribution of data associated with different tenants across different databases in multi-user hierarchical environments creates access problems related to the location of data within the trees and subtrees constituting the system.

[0006] In the absence of subtrees, scaling is achieved by selecting a separate resource pool, rather than by overlapping resources for each tenant or group of tenants. However, in the presence of child subtrees, there is no obvious way to organize efficient access to child data.

[0007] When dealing with multi-user systems with thousands of tenants, parallel data requests must be processed quickly. User tenants manipulate their data by downloading and searching it, compiling statistics, creating reports, or submitting data requests based on complex filtering parameters. This work can create a queue with millions of parallel data requests. If the storage system processes these requests slowly, user tenants will experience service degradation. And when data from multiple tenants is stored on a common partition, one user (one tenant) can overload the system, and this will affect other tenants. Summary description

[0008] This invention solves the problem of partitioning storage data in a hierarchical, multi-user environment. In this environment, unique tenant data is stored on partitions. The tenant tree is segmented with linked components, and a database partition is further divided so that tenant data is stored on separate partitions.

[0009] Hierarchical arrays generally contain a limited degree of nesting. One object of the invention is to apply optimized partitioning techniques to hierarchical structures and to increase the performance of parallel processing requests.

[0010] The partitioning is optimized so that the access areas of the different tenants are covered by the minimum number of partitions. The segmentation algorithm imposes the restriction that only the tenants' data can reside on a single partition, connected by a hierarchical topology.

[0011] In one embodiment, the hierarchical multi-user storage system comprises: a computer-readable storage medium configurable into partitions; a plurality of tenant nodes stored on the storage medium; a plurality of child nodes accessible from the tenant nodes; a plurality of partitions on which the tenant nodes and child nodes are located; and at least one virtual partition for storing the child nodes.

[0012] In one embodiment, tenant data is distributed among trees giving access to child data and also including migrated tenant data.

[0013] In another embodiment, the hierarchical multi-user storage system includes a reconstructed tenant access tree.

[0014] In another embodiment, the data of at least one tenant is stored on a single partition.

[0015] In another embodiment, parallel access requests to tenant nodes are handled in a hierarchical multi-user distributed data storage environment by the following means: partitioning the data storage by partitions, in which each partition contains the data of a single tenant; creating a hierarchical data access structure equal to a multi-user structure of a storage service, in which each level of the hierarchical data access structure corresponds to an access level to all subsequent levels of the hierarchy; in which the lowest level of the hierarchical data access structure corresponds to an access level to a single partition;and the processing of parallel data access requests, in which each data access request is routed to a target partition according to a hierarchical structure, and in which data requests from one tenant do not load partitions from another tenant.

[0016] In another embodiment, parallel access to tenant nodes in a hierarchical multi-user data storage environment is configured, where the tenant nodes are stored on virtual partitions, by calculating a storage allocation configuration for the tenant nodes using a packaging algorithm; by virtualizing at least one partition for the storage of a tenant node consistent with the calculated allocation configuration; and by accepting concurrent processing requests to access one or more tenant nodes on a virtual partition. Brief description of the figures

[0017] FIG. 1 shows an implementation of data partitioning in a hierarchical multi-user system

[0018] FIG. 2 shows examples of data merging and fission.

[0019] FIG. 3 shows a hierarchical tenant system with linear clustering.

[0020] FIG. 4 shows a hierarchical tenant system with linear data allocations

[0021] FIG. 5 shows a hierarchical system of tenants with a grouping of tenants

[0022] FIG. 6 shows the grouping of large nodes within the framework of a tenant tree.

[0023] FIG. 7 shows a grouping of a tenant tree into connected components.

[0024] FIG. 8 shows a reconstructed partition tree with multiple tenants.

[0025] FIG. 9 shows a reconstructed partition tree as a function of the movement of the tenants.

[0026] FIG. 10 shows an allocation of virtual partitions on a physical partition

[0027] FIG. 11 shows a distribution of the tenant data during the load tests.

[0028] FIG. 12 shows a distribution of the data according to the partitions or fragments. Detailed description

[0029] Partitioning in hierarchical multi-user systems

[0030] Multi-tenancy involves independent service clients, the tenants, sharing a single pool of resources. The hierarchy means that the system's tenants are organized according to a tree structure, where each tenant has access to its own data and that of its child subtrees.

[0031] Performance requirements are associated with processing time, response time to requests under parallel load conditions, and the number of requests the system can handle. Performance is closely related to scalability. Scalability is the ability of a system to increase its performance based on additional resources.

[0032] Vertical scaling is achieved by adding or removing computing resources from the system. Examples of such resources include processor size, memory size, and network bandwidth capacity. No changes are required in application programs, and performance can be linear with respect to the number of resources added.

[0033] Horizontal scaling is achieved by adding or removing additional copies of the application programs. Generally, resources are allocated to each new copy, but sometimes the original shared resource pool is sufficient.

[0034] The ability of a system to scale is referred to as elasticity in cloud systems. Cloud applications with high data density can be bottlenecked by data stores. The elasticity of data stores can be increased by fragmentation and partitioning.

[0035] Fragmentation and partitioning are processes that divide data into several parts. Fragmented data is located on one copy of the storage. Partitioned data is located on different copies of the storage. Data can be partitioned based on range keys in tables, key hashes, timestamps, geographic data, and columns.

[0036] FIG. 1 shows a hierarchical multi-user system 100 in a cloud-based environment. A cloud instance 102 includes databases 104A, 104Bet, and 104C and the platform core 106. The platform core 106 includes instances of the task manager 108A, 108B, 108C, and 108D and an API gateway 110. The task manager instances 108A, 108B, 108C, and 108D communicate with the databases 104A-C. The API gateway 110 communicates with the client 114 via the REST API 122 and the agent 116 on operating system 122A, the API client 118 on operating system 122Bet, and the user interface 120 on operating system 122C. The 122A-C operating systems can be operating systems from any brand.

[0037] The databases 104A, 104B and 104C are distributed among the tenants 126A-N. The tenants 126A-D correspond to the database 104A, the tenants 126EH correspond to the database 104B, and the tenants 126I-N correspond to the database 104C.

[0038] When data is partitioned in a multi-user system, the data can be distributed between the partitions either by fission or by merging.

[0039] FIG. 2 shows two possible methods of data distribution 200 for the data of tenant A202, the data of tenant B204 and the data of tenant C206. Data merging 208 appears in copies 210 and 212. Data splitting 214 appears in copies 216 and 218.

[0040] Data merging groups data into semantic groups. Each group is assigned to only one repository. This arrangement allows for high performance for group operations when necessary, due to the high consistency of the data between these groups. Data splitting separates the data from the semantic groups uniformly across different storage locations and performs group operations in parallel.

[0041] Data fusion is preferred for distributing storage because it provides better tenant isolation and reduces the performance costs of aggregated queries.

[0042] Isolating tenants from one another is an important aspect of the security and performance of multi-user systems. Storage should be organized as if it were dedicated to each tenant individually. If each tenant's data is stored on only one partition, any performance slowdown caused by unusual loads will only affect the partition's neighbors. If each tenant's data is stored on multiple partitions, unusual loads will affect the performance of the entire application. When partitions are located some distance apart, processing times can become very long for a tenant whose partitions are located further away.

[0043] In this context, a tenant or a tenant node can invoke an application, a virtual machine, a container, a virtual server, a database or other processes that can be hosted.

[0044] The useful output power of each tenant is proportional to the amount of data that tenant possesses. If the number of tenants is large, it must be assumed that the ratio between the useful output power and the amount of data will follow a normal distribution. The differences between the tenants will essentially be related to the intensity of their use of the service. If the data of all the tenants is distributed across the number of partitions such that the partitions are generally uniform, the parallel loads on these partitions will also be uniform.

[0045] The tenant data is distributed relatively uniformly across the minimum number of partitions of limited size and can be rebalanced. The system determines which data to migrate and how to implement the migration according to this distribution scheme. Packaging algorithms are the preferred tools for achieving an optimal distribution.

[0046] In this case, the focus is on applications where each client-tenant works with its own virtual application instance and has access to the application instances of its children. The tenant nodes contain data and can also be linked to other nodes.

[0047] FIG. 3 shows a hierarchical system 300 with tenant nodes 305, 306 and 307. The tenant node 305 has access to the data of its own node 305 and of the nodes in the descending direction 307, 308 and 309. The tenant node 306 has access to the nodes 306, 310, 312 and 314. The tenant 313 has access to the nodes 313, 316 and 317.

[0048] When data is stored on the same database, a column contains the identifier of each tenant. Each row explicitly indicates to whom the stored data belongs. The storage space of each tenant must be easily accessible to ensure rapid access.

[0049] FIG. 4 shows the hierarchical multi-user system 400 with tenants 401-417. In the system 400, tenant data can be divided equally among the distributed partitions and organized so that client requests are forwarded to the partitions containing the relevant tenant data and the corresponding filters are applied. Performance problems arise when high data intensity is dispersed among the partitions. Remote access areas from the originating tenant may include tenant data in a large number of partitions. And performance can decrease further as the number of partitions increases.

[0050] FIG. 5 shows the hierarchical multi-user system500where the tenants501-517 have been grouped together to avoid data dispersion.

[0051] Preferably, all nodes do not exceed the allowed container size before applying the optimization methods. When the nodes are larger than the allowed container size V, the tenant tree is preferably modified before optimization. FIG. 6 shows an example of node splitting 600 where a large node 602 with a node size > V is on a tenant tree with nodes 604, 606, and 608. A new tenant tree is preferably created by dividing the node 602 into a number of nodes 610, 612, as large as necessary, and updating the initial large node 602 so that its size is now a fraction of V.

[0052] The tenant nodes have access to partitions containing subtree nodes. FIG. 7 shows a hierarchical partition tree 700 comprising tenant nodes 701-717 divided between partitions 720, 722, 724, 726, and 728. FIG. 7 illustrates that access trees are not always subtrees of the general partition tree. For example, in FIG. 7, partition 722, which includes the origin node 702, has two children: partition 720 with the root node 703 and partition 724 with the root node 708. The access tenant tree 705 consists of only two elements: partition 722 with the root node 702 and the child partition 724 with the root node 708. As FIG. 7 shows, not all children of the root nodes of partition trees can be children of the root nodes of access trees.

[0053] Packaging algorithms, combined with two additional parameters, can be used to account for distributions. Whenever a container is reused or underutilized, a distribution algorithm can be applied to the entire tree and, based on the results, the migration can be calculated. However, the algorithms completely ignore the previous division into containers, so the migrations can be very large.

[0054] FIG. 8 shows a partition tree800 reconstructed with tenant nodes801-817 and showing four possible scenarios for the movement of tenants by hierarchy. In FIG. 8, the nodes801'-817' represent the post-migration positions of the nodes801-817 on the partitions820,822,824 and826.

[0055] According to the first scenario, the non-root holder 817 moves in the original segment up to 817'. This move can be performed with known partitioning methods without clients noticing any substitution

[0056] According to the second scenario, the root tenant 811 becomes 811'. In this case, the partition tree must be rebuilt for the system to function correctly.

[0057] According to the third scenario, a non-root tenant becomes and moves to another segment, in which the access tree of that tenant contains an element. In this case, you have three possibilities. The data can be migrated to a new storage partition with a new segment. Another solution is to allocate a new storage partition and migrate the data to it. Or the data can remain in use on the old partition.

[0058] For the first two options, algorithms are used to determine whether it is worthwhile to move the data from this tenant to a separate partition. If the data is moved to a separate partition, the partition tree must be updated.

[0059] The third option involves the implementation of virtual partitions. Virtual partitions also define tree partitions. A virtual partition is simply the individual virtual partition and a few other virtual partitions that can reside on the same physical partition. Virtual partitions are obtained by dividing the segments that form the physical partitions. In FIG. 8, there will be two virtual partitions with roots 808' and 809', located on the same partition with root 808. These can also be considered as partitions located on a single physical storage device.

[0060] Even though the third migration scenario is more difficult to implement, it makes it possible to ensure a continuous movement of the tenants.

[0061] According to the fourth scenario, a non-root tenant moves to another segment, where the access tree of that tenant consists of more than one element. This scenario is a more general case of the third scenario. The partition tree must be rebuilt because the data of the original partition must be accessible as well as the data of the child partitions.

[0062] Algorithms are chosen that allow the arrangement of tenants on a tree to be modified and give clients access to their data.

[0063] One approach is to construct a tenant tree a posteriori by performing a data migration between physical storages.

[0064] Another approach would be to integrate tree reconstitution into the process and to carry out the migration at the same time as tree reconstitution.

[0065] Yet another approach would be to introduce a virtual partition tree with a correspondence between them and the physical partitions and to perform real migrations independently of the reconstruction of the tenant tree.

[0066] The first approach can be used if the transfer needs to be as fast as possible. Hot data can be migrated first and then cold data. However, this approach has the disadvantage that the customer will not see their data for a certain period of time.

[0067] If the migration does not need to be instantaneous but total data consistency after the transfer is important, then the second approach can be used. First, separate storage is distributed if necessary. This is followed by a live migration of all data owned by the tenant from their current partition to the target datastore. During the migration, the partition tree is rebuilt following the addition of a new partition, which logically terminates the transfer. At this point, the data on the old storage can be deleted. The data on the old storage can be deleted because it cannot be viewed by the tenant at this stage anyway due to access restrictions. Users will not experience any side effects related to data consistency loss, but they will have to wait for the operation to complete.

[0068] FIG. 9 shows a migration with a partition tree reconstructed with newly added partitions. In FIG. 9, nodes 901'-917' represent the post-migration positions of nodes 901-917. The tree comprising partitions 920, 922, 924, and 926 is reconstructed as new partitions 928, 930, 932, 934, and the original partition 924.

[0069] The third approach with virtual partitions is illustrated in FIG. 10. In FIG. 10, nodes 1001'-1017' represent the post-migration positions of nodes 1001-1017 on partitions 1020, 1022, 1024, and 1026. This approach is based on a separate physical partition tree and a separate virtual partition tree. First, a virtual partition is allocated for the original tenant data. At the same time, the virtual partition tree is reconstructed, and the tenant transfer operation is logically completed. The necessary migrations are performed asynchronously to re-establish a bijective correspondence between the virtual and physical partitions.

[0070] This process will go unnoticed by the user. The tenant transfer is instantaneous and without loss of data consistency.

[0071] Hierarchical packing into containers poses a nondeterministic polynomial-hard problem. The goal is to fit objects of a predefined shape into a finite number of containers in such a way as to use the fewest possible containers. The use of exact algorithms is only possible for small dimensions. Polynomial-time algorithms are used as heuristic approximations. These algorithms can be online or offline and depend on knowledge of the object sizes. Online methods allow us to obtain information about the objects and pack them at runtime. Offline methods allow us to solve the packing problem provided that the object sizes are perfectly known. Offline methods are preferably used because the object sizes are known.

[0072] The simple offline polynomial packing algorithms are Best Fit Decreasing (BFD) and First Fit Decreasing (FFD).

[0073] In real systems, the distribution of weights and nodes in the tenant tree can change over time, and the first partition may become inefficient. To maintain a uniform distribution across the partitions, the repositories may need to be rebalanced.

[0074] If the entire subtree can be placed in a single container, the HFFD (Hierarchical First Fit Decreasing) algorithm gives the same results as a classic FFD. If the subtree cannot be contained within the entire container, all child subtrees are sorted in descending order according to the size of their tree, as well as the root note according to the size of its node.

[0075] The Hierarchical Greedy Decreasing (HGD) algorithm places subtrees into containers differently. The subtree is placed in a new container, which is then added to the list of containers. The HGD algorithm divides the tree into more containers than HFFD and thus minimizes the number and size of migrations.

[0076] The algorithms discussed work well with nodes of size V, but there may be trees with nodes larger than the allowed container size. In this case, the tree must be modified before applying the algorithms. An example is the node splitting method illustrated in FIG. 6 and described above.

[0077] Hierarchical container packing algorithms are optimized for a dynamic environment by running the algorithm only on tree segments of overloaded or underloaded containers. A list of nodes contained in the overloaded or underloaded containers is preferably generated. The list is filtered by removing all overloaded or underloaded containers. Algorithms can then be applied. This dynamic extension can be applied to all container packing algorithms, and we will call the dHFFD (dynamic Hierarchical First Fist Decreasing) and dHGD (dynamic Hierarchical Greedy Decreasing) algorithms dynamic variants.

[0078] For most real-world applications, dHFFD is the most appropriate algorithm because it reduces operating costs by minimizing the number of containers. If performance requirements outweigh operating costs, then dHGD is preferable because it reduces the number of migrations by increasing the number of allocated storage spaces.

[0079] This system and method can be applied to other storage systems, such as databases, file stores where similar scaling problems are presented.

Claims

1. A multi-user hierarchical storage system comprising: a partitionable, computer-readable storage medium; a plurality of tenant nodes stored on the storage medium; a plurality of child nodes accessible from the tenant nodes; a plurality of partitions on which tenant nodes and child nodes are located; and at least one virtual partition for storing the child nodes.

2. The system of claim 1 wherein the tenant data is distributed in trees giving access to child data and further comprising migrated tenant data.

3. The system of claim 1, wherein the data of at least one tenant are allocated to a single partition.

4. The system of claim 2 further comprising a reconstructed tenant access tree.

5. A computer-implemented method for handling parallel access requests to tenant nodes in a hierarchical multi-user distributed data storage environment, the method comprising: partitioning the data storage by partitions, in which each partition contains the data of a single tenant; creating a hierarchical data access structure equal to a multi-tenant structure of a storage service, in which each level of the hierarchical data access structure corresponds to an access level to all subsequent levels of the hierarchy; in which the lowest level of the hierarchical data access structure corresponds to an access level to a single partition;and parallel data access request processing, in which each data access request is routed to a target partition according to a hierarchical structure, and in which data requests from one tenant do not load partitions from another tenant.

6. A method for configuring parallel access to tenant nodes in a hierarchical multi-user data storage environment in which the tenant nodes are stored on virtual partitions, the method comprising: calculating a storage distribution configuration for the tenant nodes using a packaging algorithm; virtualizing at least one partition for the storage of a tenant node compatible with the calculated distribution configuration; and accepting concurrent processing requests to access one or more tenant nodes on a virtual partition.