CN111796929B - Tenant merging method in multi-tenant mode - Google Patents
Tenant merging method in multi-tenant mode Download PDFInfo
- Publication number
- CN111796929B CN111796929B CN202010425959.5A CN202010425959A CN111796929B CN 111796929 B CN111796929 B CN 111796929B CN 202010425959 A CN202010425959 A CN 202010425959A CN 111796929 B CN111796929 B CN 111796929B
- Authority
- CN
- China
- Prior art keywords
- tenant
- label
- merging
- labels
- tenants
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0645—Rental transactions; Leasing transactions
Landscapes
- Engineering & Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Theoretical Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Finance (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- Development Economics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Marketing (AREA)
- Economics (AREA)
- General Engineering & Computer Science (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
The invention discloses a tenant merging method under a multi-tenant mode, which belongs to the field of computer data information processing and comprises the following steps: creating tenant administrators and distributing different tenant labels to each tenant administrator; a tenant administrator creates user information for corresponding tenants and assigns tenant labels to each tenant; merging the tenant labels corresponding to the tenant administrators to be merged to obtain new tenant labels; and updating the tenant label of each merged tenant administrator and the corresponding tenant into a new tenant label after the merging operation. The merging process of the invention is simpler and more feasible, the problems brought by the merging of the tenants in the future can be greatly reduced, when the tenants are merged, the codes and the business table records are not required to be modified, the merging of all the tenants is supported to the maximum extent, the tenant merging operation can be operated by a super administrator, and the tenant administrator and the tenants thereof can not be aware of the operation.
Description
Technical Field
The invention belongs to the field of computer data information processing, and particularly relates to a tenant merging method in a tag-level data isolation multi-tenant mode.
Background
Multi-tenant technology (Multi-tenant technology) is a software architecture technology that shares the same system or program components in an environment where multiple users are implemented and still ensures isolation of data between users. A system supporting multi-tenant technology needs to perform virtual partitioning on its data and configuration in design, so that each tenant or organization of the system can use a separate system instance, and each tenant can perform personalized configuration on the rented system instance according to its own needs.
The multi-tenant technology has different effects due to the adoption of different isolation means, and the following isolation methods are mainly adopted in the general isolation method.
Operating system level isolation: in the mode, tenants have a complete operating system environment, different tenants can freely select different operating systems, such as Windows or Linux, and can freely install required application software, databases and the like in the installed operating systems, and the mode is common in cloud servers in public cloud environments. In this mode, due to hardware resource limitations, it is generally not preferable that each physical server exceeds 10 tenants, otherwise the performance is poor.
Database level isolation: in the mode, one tenant can share one database, the data isolation level is strongest, the data security is highest, the backup and recovery of the data are most convenient, the requirement on the data independence is high, and tenants with more requirements on the data expandability can be considered for use. The hardware cost in the mode is high, if the database adopts a commercial database, the database cost is also high, and the number of supported tenants is limited. This model is primarily faced in real-world production environments by banks, hospitals, etc. tenants that require very high levels of data isolation.
SCHEMA level isolation: in the mode, all tenants share one database, and each tenant has an independent Schema space. Schema represents a collection of database objects that contains: the table, view, storage process and index objects have high isolation level, high data security and troublesome data backup and recovery. If the database fails, data recovery is difficult, all tenants can be affected due to the fact that data of other tenants are involved in the recovery of the database, and cross-tenant data statistics is difficult to achieve.
And (3) label-level isolation: in this mode, all tenants share one database, one Schema and each data table. Each tenant is distinguished through the TennantID (each table is provided with a separate tenant label field to describe the tenant attribute of each record under a certain data table), the sharing degree is highest, the isolation level is lowest, the data security is lowest, and the backup and recovery of the data are most troublesome. If one table has a problem, all tenants can be affected. The mode has the greatest advantage that the most tenants are supported by the least servers, the advantage is favored by cost-sensitive users, and most multi-tenant schemes adopt the mode at present.
For a real scene, 50 government administration departments have respective electronic document or business electronic document filing requirements, and if each department establishes a filing management software system, the situation is really suspected of repeated construction. Thus, the government may mandate that a governing authority (e.g., an archive office) construct a multi-tenant structured archive management software system in its data center and open it for use by 50 authorities, such that 50 authorities are 50 tenants. In fact, the above 4 modes can achieve this requirement, but with a cost difference.
If the department of communication a is merged with the department of communication B (for example, the department of communication is merged with the department of railway into the department of mass communication, the department of light industry, the department of textile into the department of commerce, etc.), the person of the original department of communication a can only access the official document of the department of communication a, and the person of the department of communication B can only access the official document of the department of communication B, after merging, the person of the new department of communication (assumed as the department of communication AB) is required to access both the official document of the original department of communication a and the official document of the department of communication B. If a multi-tenant architecture constructed by the first three modes is adopted, it can be imagined that technical actions such as scheme discussion, library guidance, data relocation, user relocation, cutover switching and the like of an owner and an undertaking party are performed in one round and another round, and the process is very troublesome.
Because the first three isolation technologies are used less, the method and the device only aim at solving the problem of how to merge tenants in a multi-tenant mode of the tag-level isolation technology.
Disclosure of Invention
Aiming at the problems of complex tenant merging and high cost in the prior art, the invention provides a tenant merging method in a multi-tenant mode based on a tag level data isolation technology.
In order to achieve the technical purpose, the technical scheme adopted by the invention is as follows:
a tenant merging method in a multi-tenant mode comprises the following steps:
creating tenant administrators and distributing different tenant labels to each tenant administrator;
a tenant administrator creates user information for corresponding tenants and assigns tenant labels to each tenant;
merging the tenant labels corresponding to the tenant administrators to be merged to obtain new tenant labels;
and updating the merged tenant label of each tenant administrator and the corresponding tenant into a new tenant label after the merging operation.
Preferably, the tenant administrator is created by a super administrator.
Preferably, the number of field bits of the tenant label is the same as the number of created tenant administrators.
Preferably, the fields of the tenant labels are counted in a k-system manner, the number of the field bits is n, and the tenant labels corresponding to n tenant administrators are respectively a 0 k 0 、a 1 k 1 、a 2 k 2 ……a n-1 k n-1 K is not less than 2, n is not less than 1 and is a positive integer, a 0 、a 1 、a 2 ……a n-1 Respectively taking any positive integer not more than k.
Preferably, the field of the tenant label adopts a 2-ary count.
Preferably, the merging operation is an addition operation of the tenant label corresponding to the tenant administrator needing merging.
Compared with the prior art, the method is simpler and easier to implement, can greatly reduce the problems brought by tenant merging in the future, and does not need to modify codes and service table records completely when the tenants are merged.
The method supports the combination of any number of tenants, supports the combination of all the tenants to the maximum extent, and can be operated by a super administrator, so that the tenant administrator and the tenants thereof cannot be aware of the operation.
Drawings
Fig. 1 is a flowchart of a tenant merging method in a multi-tenant mode according to a specific embodiment of the present invention.
Detailed Description
In order to facilitate understanding of those skilled in the art, the present invention is further described below with reference to the following examples and the accompanying drawings, which are not intended to limit the present invention.
As shown in fig. 1, a tenant merging method in a multi-tenant mode includes the following steps:
s100: creating tenant administrators and assigning different tenant labels to each tenant administrator
The tenant administrator can be created by a super administrator, and can also be applied by the tenant administrator and obtained by the super administrator through auditing.
To take an example below, first the hypervisor creates A, B, C, D, etc. tenants and assigns 1, 2, 3, 4, etc. tenant labels to each tenant, and the tenant dictionary table is shown below.
ID | Tenant label | Tenant description |
1 | 1 | Staff of tenant A |
2 | 2 | Staff of tenant B |
3 | 3 | Staff of tenant C |
4 | 4 | Staff of tenant D |
… | … | … |
Tenant B creates an administrator account UserB0, and assigns a tenant label of 2 to it, and a record will be inserted into the user table, as follows:
ID | tenant label | User ID | Other user characteristics field |
1 | 2 | UserB0 | Such as name, gender, age, time of recording, etc |
S200: the tenant administrator creates user information for the corresponding tenant and assigns a tenant label to each tenant
The tenant B administrator UserB0 may create user information for all the staff of tenant B, assign its own tenant label to the created user, and after continuous operation, there are n users under tenant B, respectively UserB1, UserB2, …, and UserBn, at this time, the records of the user table are as follows
ID | Tenant label | User ID | Other user characteristics field |
1 | 2 | UserB0 | Such as name, gender, age, time of recording, rights, etc |
2 | 2 | UserB1 | … |
3 | 2 | UserB2 | … |
… | 2 | … | … |
n+1 | 2 | UserBn | … |
n+2 | 1 | UserA0 | … |
n+3 | 1 | UserA1 | … |
If UserB2 is ready to add a record to the business table, the normal operation steps are as follows:
1) querying a user table to obtain that the tenant label of UserB2 is 2;
2) and opening a service table 1, inserting a record into the service table 1, filling 2 in the tenant label field, filling other fields according to the service, wherein for convenience of comparison, the service field value is set to be 0 xBDBDBDBDB.
Service table 1
ID | Tenant label | Other service fields |
1 | 2 | 0xDBDBDBDB |
The business table may have multiple tables, which is simplified to 1 table, and the same reason is true.
If UserA1 is ready to add a record to the business table, the normal operation steps are:
1) querying a user table to obtain that the tenant label of UserA1 is 1;
2) and opening a service table 2, inserting a record into the service table 2, filling a tenant label 1 of UserA1 into a tenant label field, filling other fields according to services, wherein for convenience of comparison, a service field value is set to be 0 xFFFFCCCC.
Service table 2
If the user a1 prepares to query a record with a service field of 0xdbdbdb, it is not queried because the tenant tag of the user a1 is not equal to the tenant tag of the record of 0 xdbdbdb.
Similarly, if the user b2 is preparing to query a record with a service field of 0 xfffcccc, it is also not queried, and the same reasoning is as above.
When the demand of merging the tenant a and the tenant B occurs, the following two general implementation methods are available:
1) modifying software codes, and adding special condition treatment of combination in all CRUD operation (namely adding, deleting, modifying and checking operations), so that the method is too cumbersome, modification omission is easily caused, and software defects are formed, and the method needs to be avoided to the utmost extent;
2) modifying data, and brushing the tenant label of the tenant B user into the tenant label of the tenant A, namely the tenant label of the tenant B user is changed into 1, at the moment, the tenant B user can access the data of the tenant A, but the tenant A and the tenant B user cannot access the data of the original tenant B at present; next, all the business records with the tenant label of 2 (i.e. tenant B) in the database table are refreshed to be 1 (i.e. tenant a), and after completion, users of tenant AB can access the data. Although this approach is feasible, 2 tenants merge better, 3 tenants merge? 4, 5, … n tenant merge? It is conceivable that the merging is relatively complex.
S300: in order to solve the problem in S200, in this step, a tenant label corresponding to the tenant administrator that needs to be merged is merged to obtain a new tenant label.
S400: then, updating the tenant label of each merged tenant administrator and the corresponding tenant into a new tenant label after the merging operation
By the method, the merged tenant administrator and the tenant label of the corresponding tenant are updated in time, so that when the service field is accessed, the tenant can access the service table which belongs to different tenant labels before due to the fact that the tenant label is the same.
Specifically, some examples of processing the tenant label to implement tenant merging are provided in this embodiment.
Firstly, the field bit number of the tenant label is required to be the same as the number of created tenant administrators, and if m tenant administrators are to be created, the field bit number of the tenant label is m bit numbers.
A simpler method is that the fields of the tenant label adopt k-system counting, and then the tenant labels corresponding to m tenant administrators respectively take a 0 k 0 、a 1 k 1 、a 2 k 2 ……a m-1 k m-1 K is not less than 2, m is not less than 1 and is a positive integer, a 0 、a 1 、a 2 ……a m-1 Respectively taking any positive integer not more than k.
If decimal is used, then k equals 10, assuming a 0 、a 1 、a 2 ……a m-1 Respectively and sequentially taking 1, 2, 3, 4, 5, 6, 7, 8, 9, 1, 2, 3, 4, 5, 6, 7, 8, and 9 … …, then the tenant label corresponding to 8 tenant administrators can respectively take 00000001, 00000020, 00000300, 00004000, 00050000, 00600000, 07000000, and 80000000.
If the 1 st tenant and the 2 nd tenant need to be merged, merging the tenant labels of the 1 st tenant and the 2 nd tenant, wherein the merging operation adopts a relatively simple addition operation, so that the tenant label needing to be merged by the 1 st tenant and the 2 nd tenant is updated to 00000021, and other tenant labels are kept unchanged.
If the field of the tenant label adopts 2-system counting, the tenant merging method is more intuitive.
Such as: the tenant label corresponding to 16 tenant administrators is 16 bits, and in order to distinguish the scale adopted by the tenant label, the scale bit can be added in front of the tenant label, so that:
the tenant label of tenant 1 is 0b0000000000000001
The tenant label of tenant 2 is 0b 0000000000000010
The tenant label of tenant 3 is 0b0000000000000100
… and so on.
If the tenants 3, 6 and 9 need to be merged, the following steps are carried out:
the tenant label of tenant 3 is 0b0000000000000100
The tenant label of tenant 6 is 0b0000000000100000
The tenant label of tenant 9 is 0b0000000100000000
1) Adding the 3 tenant labels to obtain a new tenant label of 0b 0000000100100100;
2) the tenant labels recorded in all user tables under tenant 3, tenant 6, tenant 9 are replaced with new tenant label 0b 0000000100100100.
The operation does not need to make any change and modification on the record data of the business table.
Only 16-bit and maximum 16 tenants are listed above, and actually 32-bit, 64-bit, 128-bit or 256-bit can be set according to business needs to meet the requirement of the corresponding number of tenants
It should be noted that, the tenant label using binary counting also has the following characteristics: when database table record query is carried out, when the tenant label of the user and the tenant label of the business table record are filtered, the tenant label matching is represented by using (the tenant label of the user and the tenant label of the business table record) > 0. Where & denotes bitwise and operation. In this way, the tenant can merge without modifying the code and the service table record in the future.
In particular, the tenant labels of the several merged tenants before merging cannot be reassigned to new tenants, otherwise tenant drift will result.
The tenant merging method in the multi-tenant mode provided by the application is introduced in detail above. The description of the specific embodiments is only intended to facilitate an understanding of the methods of the present application and their core concepts. It should be noted that, for those skilled in the art, it is possible to make several improvements and modifications to the present application without departing from the principle of the present application, and such improvements and modifications also fall within the scope of the claims of the present application.
Claims (2)
1. A tenant merging method in a multi-tenant mode is characterized by comprising the following steps:
creating tenant administrators, and distributing different tenant labels to each tenant administrator, wherein the tenant administrators are created by a super administrator;
a tenant administrator creates user information for corresponding tenants and assigns tenant labels to each tenant;
merging the tenant labels corresponding to the tenant administrators to be merged to obtain new tenant labels, wherein the merging operation is to perform addition operation on the tenant labels corresponding to the tenant administrators to be merged;
updating the merged tenant label of each tenant administrator and the corresponding tenant into a new tenant label after merging operation;
the field digit number of the tenant label is the same as the created number of the tenant administrators, the fields of the tenant label are counted in a k-system mode, the field digit number is n, and the tenant labels corresponding to the n tenant administrators respectively take a 0 k 0 、a 1 k 1 、a 2 k 2 ……a n- 1 k n-1 K is not less than 2, n is not less than 1 and is a positive integer, a 0 、a 1 、a 2 ……a n-1 Respectively taking any positive integer not more than k.
2. The tenant merging method in the multi-tenant mode according to claim 1, characterized in that: and the field of the tenant label adopts 2-system counting.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010425959.5A CN111796929B (en) | 2020-05-19 | 2020-05-19 | Tenant merging method in multi-tenant mode |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010425959.5A CN111796929B (en) | 2020-05-19 | 2020-05-19 | Tenant merging method in multi-tenant mode |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111796929A CN111796929A (en) | 2020-10-20 |
CN111796929B true CN111796929B (en) | 2022-09-16 |
Family
ID=72806738
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010425959.5A Active CN111796929B (en) | 2020-05-19 | 2020-05-19 | Tenant merging method in multi-tenant mode |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111796929B (en) |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108306972A (en) * | 2018-02-06 | 2018-07-20 | 山东渔翁信息技术股份有限公司 | A kind of cloud cryptographic service method, platform, system and computer readable storage medium |
CN108829507A (en) * | 2018-03-30 | 2018-11-16 | 北京百度网讯科技有限公司 | The resource isolation method, apparatus and server of distributed data base system |
-
2020
- 2020-05-19 CN CN202010425959.5A patent/CN111796929B/en active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108306972A (en) * | 2018-02-06 | 2018-07-20 | 山东渔翁信息技术股份有限公司 | A kind of cloud cryptographic service method, platform, system and computer readable storage medium |
CN108829507A (en) * | 2018-03-30 | 2018-11-16 | 北京百度网讯科技有限公司 | The resource isolation method, apparatus and server of distributed data base system |
Also Published As
Publication number | Publication date |
---|---|
CN111796929A (en) | 2020-10-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9720943B2 (en) | Columnar table data protection | |
US10318551B2 (en) | Reporting and summarizing metrics in sparse relationships on an OLTP database | |
US9898549B1 (en) | Tenant-aware database for software as a service | |
CN111919216A (en) | On-demand de-identification of data in computer storage systems | |
CN103577440B (en) | A kind of data processing method and device in non-relational database | |
US20160335304A1 (en) | Data partitioning and ordering | |
US20130191523A1 (en) | Real-time analytics for large data sets | |
US20070179941A1 (en) | System and method for performing an inexact query transformation in a heterogeneous environment | |
US9129010B2 (en) | System and method of partitioned lexicographic search | |
US10289707B2 (en) | Data skipping and compression through partitioning of data | |
US10296497B2 (en) | Storing a key value to a deleted row based on key range density | |
CN108897874B (en) | Method and apparatus for processing data | |
US11868328B2 (en) | Multi-record index structure for key-value stores | |
CN112434015B (en) | Data storage method and device, electronic equipment and medium | |
CN112912870A (en) | Conversion of Tenant Identifiers | |
US20220108404A1 (en) | Systems and methods for distributed ledger-based auditing | |
US10248668B2 (en) | Mapping database structure to software | |
WO2012004880A1 (en) | Keyword conversion device, keyword conversion program, recording medium, and keyword conversion method | |
US10606829B1 (en) | Methods and systems for identifying data inconsistencies between electronic record systems using data partitioning | |
US8229946B1 (en) | Business rules application parallel processing system | |
CN111796929B (en) | Tenant merging method in multi-tenant mode | |
US8005844B2 (en) | On-line organization of data sets | |
CN111680069A (en) | Database access method and device | |
US8270612B2 (en) | Mapping compound keys | |
CN111459949A (en) | Data processing method, device and equipment for database and index updating method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20240531 Address after: Room 1408, 14th Floor, Block B, Building 8, Guanchengyuan, Haidian District, Beijing, 100080 Patentee after: BEIJING CSSCA TECHNOLOGIES CO.,LTD. Country or region after: China Address before: 210000 11 / F, block B, Chuangzhi building, 17 Xinghuo Road, Jiangbei new district, Nanjing City, Jiangsu Province Patentee before: Guanqun information technology (Nanjing) Co.,Ltd. Country or region before: China |