Patent Application
20190294604
The present invention relates to the field of database management technologies, and in particular, to system, server and a data update notification method.
A database management system (DBMS) may include at least one server (herein also referred to as publisher) and multiple clients (herein also referred to as subscribers), and at least one database that stores collections of objects and allows read and write operations to the objects. A database schema may be used to describe one or more fields allowed for each object type. The database may associate a separate schema to each client. In other words, some clients may run with different schema versions.
Schema evolution is a functionality of databases that for a given object type allows the schema to be changed to a new version. Objects stored in the database according to a given schema version, may be read using an older or newer schema version. If the object is read with a newer schema version, we call this upgrade schema evolution. If the object is read with an older schema, we call this downgrade schema evolution.
After one or more objects of the database are changed or modified, the problem addressed is how to notify one or more clients using different schema versions of any changes in the system so that the clients and the server can keep consistent copies of the same data objects even according to different schema versions.
An attempt to address this problem is called “Upward and downward compatible schema evolution” (US2006004781A1), which is a proposal for schema evolution for both upward and downward-compatibility in object and data models. The procedure is to perform upward and downward schema evolution of the full/whole object, and to notify the whole or full data object modified for different schema versions to multiple clients in inefficiency way.
However, there is still a need for an efficient notification scheme for different schema versions when dealing with notifications of partial changes or updates.
Accordingly, embodiments of the present invention are to provide a system, a server and data update notification method, which notifies partial updates to one or more clients using different schema versions in an efficient way during on-going schema evolution.
The above-mentioned object of the present invention is achieved by the solution provided in the independent claims. Further, implementations are defined in the dependent claims.
A first aspect of the present invention provides a server for use in a database management system, including:
Therefore, the server of the first aspect is efficient in terms of the performance and network usage consumption. This is achieved because when dealing with notifications of partial updates, only a set of partial update operations modified for different schema versions is notified by the server, instead of notifying the whole/full data object modified for different schema versions. In addition, this is also achieved because schema evolution or transformation is performed on the set of partial update operations, instead of the whole/full data object, by the server.
In one embodiment, the first update instruction comprises:
The second update instruction comprises:
Thus, the server provides a flexible way of carrying information that indicates the schema used by the first (source or sending) or second (target or receiving) client directly or indirectly.
In one embodiment, the catalog information comprises a plurality of schemas of one or more clients, and wherein the transformation module is configured to:
Thus, the server provides a particularly efficient way of on-going schema evolution (i.e. transformation) from the first update instruction expressed in the first schema into the second update instruction expressed in the second schema. In particular, an efficient way of on-going schema evolution (i.e. transformation) from a set of partial update operations, which are associated to data using the first schema in the first client into a set of partial update operations, which are associated to data using the second schema in the second client.
In one embodiment, the transformation module is further configured to:
Thus, the server provides a flexible way of identifying the schema used by the first (sending) client directly or indirectly.
According to a second aspect the invention relates to a data update notification method for notifying updates in a database management system, the method performed by a server. The method comprises the operations of:
Thus, the method of the second aspect is efficient in terms of the performance and network usage consumption. This is achieved because when dealing with notifications of partial updates, only a set of partial update operations modified for different schema versions is notified, instead of notifying the whole/full data object modified for different schema versions. In addition, this is also achieved because schema evolution is performed on the set of partial update operations, instead of the whole/full data object.
In one embodiment, the first update instruction includes:
Thus, the method provides a flexible way of carrying information indicates the schema used by the first (sending) or second (receiving) client directly or indirectly.
In one embodiment, the operation of transforming the first update instruction defined in the first schema into a second update instruction defined in a second schema on the basis of catalog information comprises:
Thus, the method provides a particularly efficient way of on-going schema evolution (i.e. transformation) from the first update instruction expressed in the first schema into the second update instruction expressed in the second schema. In particular, a particularly efficient way of on-going schema evolution (i.e. transformation) from a set of partial update operations, which are associated to data using the first schema in the first client into a set of partial update operations, which are associated to data using the second schema in the second client.
In one embodiment, the method further comprises:
Thus, the method provides a flexible way of identifying the schema used by the first (sending) client directly or indirectly.
The method of embodiments of the present invention achieves the same advantages as described above for the device. The method may be carried out with additional method operations, which correspond to the functions carried out by the various implementation forms described above for the device.
According to a third aspect the invention relates to a database management system. The system comprises: a first client, a second client and a server, wherein:
Therefore, the system is efficient in terms of the performance and network usage consumption. This is achieved because when dealing with notifications of partial updates, a second update instruction corresponding to a second schema different from the first schema used by the first client is sent to the second client in the system during on-going schema evolution, thus only a set of partial update operations modified for different schema versions is notified in the system, instead of notifying the whole/full data object modified for different schema versions. In addition, this is also achieved because schema evolution is performed on the update instruction, instead of the whole/full data object in the system.
In one embodiment, the system further comprises a third client,
Thus, the system allows for more efficiency in terms of the performance and network usage consumption. In particular, in a real subscribe & notify scenario, thousands of clients subscribe to the same data object and the server has to notify the same change to all of them. The gain in network usage and bandwidth is directly proportional to the number of notifications.
In one embodiment, the first update instruction includes:
Thus, the system provides a flexible way of carrying information that indicates the schema used by the first (sending) or second or third (receiving) client directly or indirectly.
In one embodiment, the catalog information comprises a plurality of schemas of one or more clients, and wherein the server is configured to:
Thus, the system provides a particularly efficient way of on-going schema evolution (i.e. transformation) from the first update instruction expressed in the first schema into the second update instruction expressed in the second schema, in particular, a particularly efficient way of on-going schema evolution (i.e. transformation) from a set of partial update operations, which are associated to data using the first schema in the first client into a set of partial update operations, which are associated to data using the second schema in the second client.
In one embodiment, the server is further configured to:
Thus, the system provides a flexible way of identifying the schema used by the first (sending) client directly or indirectly.
A fourth aspect of the present invention provides a computer-readable storage medium storing program code, the program code comprising instructions for carrying out the method of the second aspect or one of the implementations of the second aspect.
The above aspects and implementation forms of the present invention will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:
In the various figures, identical reference signs will be used for identical or at least functionally equivalent features.
A clear and full description is given below to the solutions according to embodiments of the present disclosure, with reference to the accompanying drawings.
In order to conveniently understand embodiments of the present invention, several terms that will be introduced in the description of the embodiments of the present invention are illustrated herein first.
As used herein, a database is an organized collection of data. In other words, the database stores collections of objects and allows read and write operations to the objects. In the database, objects can be of different object types.
As used herein, an object of a database (also referred to as a database object or data object, in short object) may be any defined object in a database that is used to store or reference data. It may be understood as a data item that is uniquely identified by a primary key. For example, a database object may be a table, a view, a sequence, an index, one or more fields of a record, one or more records, or one or more tables.
As used herein, a database schema (in short schema) may be used to describe one or more fields allowed for each object type. In other words, the schema is the structure of the database that defines the objects in the database. There may be a plurality of schema versions involved in a single database, or involved among a plurality of databases. The schema versions of the database(s) may include an initial schema version and subsequent schema versions, for example, S1, S2 (a newer schema based on S1), and S0 (an older schema based on S1). It is noted that schema version information may be information for differentiating between different schemas, while the schema itself may be information for describing one or more fields of a database object, for example, {‘name’:string, ‘age’:number, . . . }.
As used herein, a catalog of a database may include metadata in which definitions of database objects are stored.
As used herein, a server (also referred to as a database server or publisher) is a computing device that provides database services to other computing devices (also referred to as clients, database clients or subscribers), as defined by the client-server model. Database management systems (DBMSs) provide database server functionality, and some DBMSs rely on the client-server model for database access. In an exemplary embodiment, the clients may comprise a plurality of standalone workstations, terminals, mobile devices or the like, or may comprise personal computers (PCs).
The following description will present examples in which it will be assumed that there exist one or more server instances (e.g., database servers) in a cluster that communicate with one or more “clients” (e.g., personal computers or mobile devices). The embodiments of the present invention, however, are not limited to any particular environment or device configuration. Instead, embodiments may be implemented in any type of system architecture or processing environment capable of supporting the methodologies presented herein.
There are one or more schemas existing in the system 100, at any time. In particular, each client may run with (using) a different schema, for example, the first client 203 runs with a first schema S1, the second client 205 runs with a second schema S2, the third client 207 runs with a third schema S3, . . . and the Nth client runs with a Nth schema Sn. At least some of the schemas S1 to Sn may be different from each other. In one example and as shown in
The first client 203 is configured to send a first update instruction to the server 201, wherein the first update instruction indicates a set of partial update operations. The partial update operations are associated to first data stored by the first client 203 using the first schema. Such first update instruction may be understood to be a program or a set of partial update operations and not the object or data within the object itself. Accordingly, the object or the (partial) data within the object, which have to be updated, are not exchanged between client and server.
The server 201 is configured to transform the received first update instruction defined in the first schema into a second update instruction defined in a second schema, in particular, on the basis of catalog information, and notify the second update instruction to the second client 205 which uses the second schema. The second update instruction indicates a set of partial update operations, the partial update operations are associated to second data stored by the second client 205 using the second schema. Such second update instruction may be understood to be a program or a set of partial update operations and not the object or data with the object itself. Accordingly, the object or the data within the object, which have to be updated, are not exchanged between client and server. The catalog information will be described in more detail further below.
The second client 205 is configured to apply the received second update instruction to the second data to be updated stored by the second client 205 using the second schema. In this manner the second client 205 and the first client 203 can keep consistent data in the second schema and the first schema respectively.
As an example, the second data to be updated may be a database object stored by the second client 205 using the second schema. The second client is configured update the database object by applying the received second update instruction to the stored database object to obtain an updated database object using the second schema.
The database object is associated to an object identifier, which may be a fixed value or sequence of values that identify uniquely one object with respect to the others.
The same procedure done for the second client 205 is also applied to the other clients, such as the third client 207, where the server 201 transforms the source update instruction (for example first update instruction) defined in the source schema (for example first schema) into a target update instruction (for example third update instruction) defined in a target schema (for example third schema) used by the target client (for example third client).
In any of the embodiments described above and in the following, the update instruction may include:
In such embodiments, the set of partial update operations may include any one or combination of the following: adding/removing/modifying the value of a field, adding/removing/renaming a field, changing a field type, changes on an attribute configuration, adding default values or any other update operation that modifies the data object.
In one example, the catalog information may include a plurality of schemas of one or more entities (i.e. clients and servers) of the system 100.
Alternatively, in another example, the catalog information may include a plurality of schemas and a list of clients with the respective schema versions they use. In other words, the catalog information may include a mapping between a plurality of client information (such as client IDs) and a plurality of schema versions.
It can be understood that information required by the database server may include at least one of the following:
In any of the embodiments described above and in the following, the server 201 is configured to generate a transformation rule from the first schema to the second schema on the basis of the first schema and the second schema included in the catalog information, and to obtain the second update instruction (defined in the second schema) by applying the generated transformation rule to the set of partial update operations indicated by the first update instruction (defined in the first schema). In an example, the server 201 may generate the transformation rule from the first schema to the second schema, then apply the transformation rule to modify the dependencies from the first schema to the second schema, and extract partial update operations for the second schema.
Generation of the transformation rule may be performed by using a rule based algorithm that creates a graph of dependencies between the partial update operations and the first schema.
In some embodiments, the server 201 is further configured to:
In order to keep consistent copies of the same data objects, in one example, as shown in
Alternatively, in another example, if the current schema of a stored object of the server 201 is the first schema, the server 201 is further configured to:
Alternatively, in another example, if the current schema of a stored object of the server is the third schema, the server 201 is further configured to:
Correspondingly, in such example, the server 201 is further configured to transform the first update instruction (defined in the first schema) into the third update instruction (defined in the third schema). The third update instruction indicates a set of partial update operations, the partial update operations being associated to third data stored by the third client 207 using the third schema.
It can be understood that in such embodiments, if the first schema is newer than the second schema, on-going downgrade schema evolution/transformation is performed in the system 100; if the first schema is older than the second schema, on-going upgrade schema evolution/transformation is performed in the system 100. It may show the on-going schema evolution mechanism according to the present invention where multiple clients or servers have copies of the same data with different schemas.
As can be seen from above, the system of the present invention is efficient in terms of the performance and network usage consumption. This is achieved because when dealing with notifications of partial updates, a target (second) update instruction corresponding to a target (second) schema different from the source (first) schema used by the source (first or sending) client is sent to the target (second or receiving) client in the system during on-going schema evolution, thus only a set of partial update operations modified for different schema versions is notified in the system, instead of notifying the whole/full data object modified for different schema versions. In addition, this is also achieved because schema evolution is performed on the update instruction, instead of the whole/full data object, by the server. Regarding with additional advantages, reference may be made to the aforementioned description in the summary part, which is not repeated herein.
There are one or more schema versions for each table existing in the database 209, at any time. Each object in the database 209 is associated to a given schema version. The clients 203, 205 have copies of the same data with different schemas. For example, the first client 203 with the same object in a first schema, and the second client 205 with the same object in a second schema. Each of the first and second clients 203, 205 has in its main memory a local cache that contains a copy of its most frequent accessed objects. Each object is updated in the cache after each read or write operation.
The first update instruction (also referred to as source update instruction) can be represented as a set of partial update operations or actions expressed in any schema version supported by a sending or source client 203 or 205, and sent to the server 201 as database operations by the sending or source client.
After performing schema evolution (i.e. transformation) on the first (source) update instruction, the second update instruction (also referred to as target update instruction) can be represented as a set of partial update operations or actions expressed in any schema version supported by a receiving or target client, and sent from the server 201 to the receiving or target client as notifications. In other words, notifications may be update instructions expressed in the schema version of the receiving or target client.
In one example, the above update instruction contains information for updating (or deleting) one or more fields (or sub-fields) of a data object. Further implementation of the above update instruction will be described in more detail below.
For other implementation details of the system 200, reference may be made to the above embodiments, which are not repeated herein.
As can be seen from above, the system 200 of the present invention has the following advantages:
For other detailed implementation details of the system 200, reference may be made to the above embodiments, which are not repeated herein.
As shown in
As shown in
As shown in
In any of the embodiments described above and in the following, the update instruction includes:
In some embodiments of the present invention, as shown in
It is noted that the transformation rule can be computed using a rule based algorithm that considers predicates such as adding a field, removing a field, changing a field type, changes on the configuration of a file, adding default values and so on;
In some embodiments, the method may further includes:
As one example, the method may further includes:
Thus, the method of the embodiment provides a particularly efficient way of keeping consistent copies of the same data objects when the server uses the first schema.
Alternatively, as another example, the method may further includes:
Thus, the method of the embodiment provides a particularly efficient way of keeping consistent copies of the same data objects when the server uses the second schema.
Alternatively, as another example, the method may further includes:
Correspondingly, the method further comprises: transforming the first update instruction (defined in the first schema) into the third update instruction (defined in the third schema). The third update instruction indicates a set of partial update operations, the partial update operations being associated to third data stored by a third client using the third schema.
Thus, the method of the embodiment provides a particularly efficient way of keeping consistent copies of the same data objects when the server uses the third schema.
The operations of the method of flowchart 500 are not limited to the order described below, and the various steps may be performed in a different order. Further, two or more operations of the method of flowchart 500 may be performed simultaneously with each other.
The method of
After operation 502, the flowchart 500 transitions to operation 503, where it is determined whether a field F exists in the schema S′. The catalog may comprise a plurality of schemas, where the schema describes the fields allowed for each object type of each schema version. If the field F does not exist in the schema S′ (NO at operation 503), the flowchart 500 transitions to operation 508, where it is further determined whether more actions is waiting for proceed.
If the field F exists in the schema S′ (YES at operation 503), the flowchart 500 transitions to operation 504, where it is further determined whether the field F has been renamed to a field F′ in the schema S′. In this example, the server determines whether the field F has been renamed to a field F′ in the schema S′ on the basis of the schema S and schema S′ obtained from the catalog.
If the field F has been renamed to a field F′ in the schema S′ (YES at operation 504), the flowchart 500 transitions to operation 505, where a part of a transformation rule, i.e. “rename the field F to F′” is obtained. If the field F has not been renamed to a field F′ in the schema S′ (NO at operation 504), the flowchart 500 transitions to operation 506, where it is further determined whether the data type of V has changed in the schema S′ or not. In one example, the server determines whether the data type of V has changed in the schema S′ by comparing the data type of the field between the two schemas S and S′ while taking the position of the field into consideration.
If the data type of V has changed in the schema S′ (YES at operation 506), the flowchart 500 transitions to operation 507, where another part of the transformation rule, i.e. “transform V to V′ with the new data type” is obtained. If the data type of V has not changed in the schema S′ (NO at operation 506), the flowchart 500 transitions to operation 508, where it is further determined whether more actions are waiting.
If more actions are waiting (YES at operation 508), the flowchart 500 transitions to operation 509, where among a set of operations or actions of partial update expressed in the schema S, the next action F=V is read. If no more action is waiting for proceed (NO at operation 508), the flowchart 500 transitions to operation 510, where the flowchart 500 ends.
After operation 509, the flowchart 500 may return to operation 503 to perform another sub process.
As can be seen from above, the transformation rule from schema S to S′ including “renaming the field F to F′” and “transforming the value V to V′ with the new data type” can be generated, thus a target update instruction defined in the schema S′, i.e. modifying the value of the field F′ to be V′ can be obtained by applying said transformation rule to the source update instruction defined in the schema S, i.e. modifying the value of the field F to be V.
It is noted that U may indicate directly or indirectly a set of partial update operations (a program, a set of instructions) that can be understood in the schema S but does not include the data object. For example, “U′(D, S):={id=‘Mary’}” may be a program that tells to the database server to search for object D with schema S and to modify the value of the ‘id’ field to ‘Mary’.
At block S603, the server M transforms U(D,S) to U′(D,S′). In particular, the server M generates upgrade transformation rules from S to S′: T(S->S′). The upgrade transformation rules may include renaming ‘id’ to ‘name’. Further the server M applies T(S->S′) to U(D,S) to obtain a second update instruction U′(D,S′):={name=‘Mary’}.
It is noted that U′ may indicate directly or indirectly a set of partial update operations (a program, a set of instructions) that can be understood in the schema S′ but does not include the data object. For example, “U′(D, S′):={name=‘Mary’}” may be a new program that tells to the database server or a receiving client (subscriber) to search for object D with schema S′ and to modify the value of the ‘name’ field to ‘Mary’.
Thus the server M allows for transforming a program (i.e. first update instruction) into a new program (i.e. second update instruction) that can be understood in the new schema in an efficient way, i.e. without reading the data object.
At block S605, the server M applies the second (target) update instruction U′ to D(S′) and stores the result. The current schema version in the server M is S′.
At block S607, the server M notifies the second (target) update instruction U′ to the client Y which uses the schema S′, so that the client Y applies U′ (D, S′) into its cached version of D(S′) and stores the result.
At block S701, the client Y, which has objects in a newer schema version S′, modifies D(S′) and sends the third update instruction U (D, S′) to the server M;
It is noted that U may indicate directly or indirectly a set of partial update operations (a program, a set of instructions) that can be understood in the schema S′ but does not include the data object. For example, “U (D, S′):={name=‘Sue’, age=38}” may be a program that tells to the database server to search for object D with schema S′, and to modify the value of the ‘name’ field to ‘Sue’ and to modify the value of the ‘age’ field to ‘38’”.
At block S703, considering the object is already stored with schema S′ in the server M, the server M applies the third update instruction directly to the object and stores it. The current schema version in the server M is S′.
At blocks S705 and S707, the server M transforms U (D,S′) to U′(D,S). In particular, the server M generates downgrade transformation rules from S′ to S: T(S′->S). The downgrade transformation rules may include renaming ‘name’ to ‘id’ and skipping ‘age’ (in S705). Further the server M applies T(S′->S) to U (D, S′) to obtain a fourth update instruction U′ (D, S):={id=‘Sue’} (in block S707).
It is noted that U′ may indicate directly or indirectly a set of partial update operations (a program, a set of instructions) that can be understood in the schema S but does not include the data object. For example, “U′(D, S):={id=‘Sue’}” may be a new program that tells to the database server or a receiving client (subscriber) to search for object D with schema S and to modify the value of the ‘id’ field to ‘Sue’”.
At block S709, the server M notifies the fourth (target) update instruction U′(D,S) to the client X, so that the client X applies it to its local copy and caches the result.
As can be seen from
As can be seen from
As shown in
In any of the embodiments described above and in the following, the update instruction may comprise:
In some embodiments of the present invention, the catalog information comprises a plurality of schemas of one or more clients, and the transformation module 2011 is configured to:
In some embodiments of the present invention, the transformation module 2012 is further configured to:
Furthermore, as one example, the server 201 may include a local management module (not illustrated in
Alternatively, as another example, the server 201 may include a local management module, configured to:
Alternatively, as another example, the server 201 may include a local management module, configured to:
Correspondingly, in one example, the transformation module 2012 is further configured to transform the first update instruction (defined in the first schema) into the third update instruction (defined in the third schema).The third update instruction indicates a set of partial update operations, the partial update operations being associated to third data stored by a third client using the third schema.
For other detailed implementation details and advantages, reference may be made to the above embodiments.
As can be seen from above, the server of embodiments of the present invention is efficient in terms of the performance and network usage consumption. This is achieved because when dealing with notifications of partial updates, a second update instruction corresponding to a second schema different from the first schema used by the first client is sent to the second client during on-going schema evolution, thus only a set of partial update operations modified for different schema versions is notified by the server, instead of notifying the whole/full data object modified for different schema versions. In addition, this is also achieved because schema evolution is performed on the update instruction, instead of the whole/full updated data object, by the server. Regarding with additional advantages, reference may be made to the aforementioned description in the summary part, which is not repeated herein.
The processor 2001 may be a central processing unit (CPU), a graphics processing unit (GPU) or an application-specific integrated circuit (ASIC), or be configured as one or more integrated circuits implementing this embodiment of the present invention.
The memory 2003 may include one or more levels of cache. The memory 2003 has stored therein control logic (i.e., computer software) and/or data.
The processor 2001 is configured to, by reading instructions stored by the memory 2003:
For other detailed implementation details and advantages, reference may be made to the above embodiments. In an implementation, the communication module 2011 and the transformation module 2012 illustrated in
The present invention has been described in conjunction with various embodiments herein. However, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed present invention, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.
| Number | Date | Country | Kind |
|---|---|---|---|
| 16203937.4 | Dec 2016 | EP | regional |
This application is a continuation of International Application No. PCT/CN2017/114826, filed on Dec. 6, 2017, which claims priority to EP Patent Application No. EP16203937.4, filed on Dec. 14, 2016. The disclosures of the aforementioned applications are hereby incorporated by reference in their entireties.
| Number | Date | Country | |
|---|---|---|---|
| Parent | PCT/CN2017/114826 | Dec 2017 | US |
| Child | 16440522 | US |
