Memory-based normalization of cache objects to reduce cache memory occupancy

Abstract

Embodiments of the invention relate to memory-based normalization of cache objects for reducing cache memory occupancy. Database objects are retrieved from a database and parsed as normalized cache data objects. Database objects are stored in normalized cached data objects in a cache repository, and tenant data requests are serviced by the normalized cached data objects. The normalized cache data objects include references to shared objects in a pool of shared objects, which may be shared across different rows of the normalized cache data objects and across different tenant cache systems.

Description

[0001] Divisional Application Instructions

[0002] This application is a divisional application of a Chinese invention patent application with an international filing date of January 29, 2020, which entered the Chinese national stage on September 10, 2021, national application number 202080020558.X, and name “Memory-based normalization of cache objects for reducing cache memory usage”. Background Art

[0003] Embodiments of the present application relate to in-memory normalization of cache objects for reducing cache memory footprint. Background Art

[0005] Computing systems are widely used today. Some computing systems are multi-tenant systems that host services for multiple different tenants or organizations.

[0006] In such computing systems, tenants often access data stored in one or more different data repositories. To improve the performance of the service, tables from the data repository or database are often cached as in-memory data structures. The data stored in the database or data repository may not be arranged according to an optimized schema. This is done to reduce the complexity of queries required to access the data and / or to improve the performance of the database or data repository.

[0007] This may mean that redundancy exists in a database or data repository with respect to database objects stored there. Summary of the invention

[0008] Database objects are retrieved from the database and parsed into normalized cache data objects. Database objects are stored in normalized cache data objects in the cache repository, and tenant data requests are serviced by normalized cache data objects. Normalized cache data objects include references to shared objects in a shared object pool, and shared objects can be shared across different rows of normalized cache data objects and across different tenant cache systems.

[0009] This Summary is provided to introduce some concepts in a simplified form that are further described in the Detailed Description below. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the Background. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 is a block diagram of an example of a computing system architecture.

[0011] Figure 2 An example of a conventional database table is shown (in simplified form).

[0012] Figure 3 is a block diagram illustrating one example of a service computing system in greater detail.

[0013] Figure 4 is a flow chart illustrating one example of the operation of the service computing system in more detail.

[0014] Figure 5 is a flow chart illustrating one example of the operation of the memory loading system.

[0015] Figure 6 is a block diagram illustrating one example of a cache repository in greater detail.

[0016] Figure 7 An example of a normalized object is shown.

[0017] Figure 8 An example of an object that can be shared between rows is shown.

[0018] Fig. 9 An example of objects that can be shared between tenants is shown.

[0019] Fig.10 is a flow diagram illustrating one example of the operation of cache sharing logic.

[0020] Fig.11 It shows the deployment in cloud computing architecture Figure 1 A block diagram of an example of the architecture is shown.

[0021] Fig.12 is a block diagram illustrating one example of a computing environment that may be deployed in the architecture shown in the previous figures. DETAILED DESCRIPTION

[0022] Figure 11 is a block diagram illustrating one example of a computing system architecture 100. The architecture 100 illustrates that a service computing system 102 can access a set of data repositories 104-106 (which can be in the service computing system 102, or located elsewhere) and illustratively hosts services that can be accessed by client (or tenant) computing systems 108-110 via a network 112. A user 114 of the client (or tenant) computing system 108 can illustratively access data on the data repositories 104-106 via the services hosted by the service computing system 102 via the network 112. Similarly, a user 116 of the client (or tenant) computing system 110 can also access data stored in the data repositories 104-106 via the network 112 using services hosted by the service computing system 102. Thus, the network 112 can be any of a variety of different types of networks. It can be any of a wide area network, a local area network, a near field communication system, a cellular communication network, or any of a variety of other networks or network combinations.

[0023] exist Figure 1 In the example shown, the service computing system 102 illustratively includes a processor or server 117, service logic 118, one or more cache repositories 120, and may include various other items 122. The service logic 118 may have a front end that receives data requests from client computing systems 108-110 requesting access to various data items in the data repositories 104-106. In servicing these requests, the service logic 118 may include back-end logic that retrieves the requested data and stores it as cache data 124 in the cache repositories 120. Doing so may improve the performance of the service in responding to subsequent data requests for the same data from various different client computing systems 108-110.

[0024] For example, cache data 124 in cache repository 120 may include database tables from data repositories 104-106 stored as in-memory data structures. In this manner, data may be accessed more quickly (from cache repository 120) in response to requests from client computing systems 108-110. Thus, it can be seen that any cache data 124 stored in cache repository 120 increases the memory footprint of a service (or process) hosted by service computing system 102 using the data.

[0025] In addition, the database schema used to store data in the data repositories 104-106 may not be normalized or optimized. Therefore, there may be redundancy between the various different data objects stored in the data repositories 104-106. This is done to reduce the query complexity of queries against the data repositories 104-106 and to improve the performance of the databases (or data repositories) 104-106 in responding to queries.

[0026] However, in many current systems, the service logic 118 copies the database table directly to the cache as cache data 124 in the cache repository 120. Therefore, in many current systems, the in-memory cached copies of the database objects (e.g., cache data 124) also include the same redundancy found in the data repositories 104-106. Depending on the level of redundancy, this can significantly increase the memory footprint of the service (or process) hosted by the service computing system 102.

[0027] Although it may not be necessary to modify the database schema used by the data repository 104-106, the service logic 118 according to one example described herein reduces the memory footprint of the service (or process) without modifying the database schema or any upstream application contracts that will be maintained with the various applications or services that access the data. Instead, the service logic 118 illustratively normalizes the in-memory data structure (cache data 124) and shares the normalized objects with different in-memory cache objects. The memory loading system (described in more detail below) parses the database structure (e.g., table) retrieved from the data repository 104-106 into a set of normalized objects. The normalized objects include objects that are shared with other objects in the cache data 124 on an inter-row basis. It also includes data shared between different tenants. In this way, when a client computing system 108-110 requests access to the cache data, the data can be quickly retrieved in a manner that is invisible to the client computing system 108-110 because it is stored in-memory as cache data 124. However, since it is stored in a normalized and shared data structure, the memory footprint corresponding to the service (or process) is greatly reduced.

[0028] To further illustrate this point, Figure 2 An example of a simplified version of a traditional database table is shown. The strongly typed class corresponding to the table (called AttributeMetadata class) is shown in Table 1 below:

[0029] Table 1

[0030]

[0031]

[0032] Can be Figure 2 As can be seen from the figure, the redundancy of the database table is relatively high. In the current system, in the database schema used to generate the database table (for example, Figure 2 There is a one-to-one mapping between the in-memory objects stored as cache data 124, so using the current system, the same amount of redundancy is found in cache data 124.

[0033] Figure 3 is a block diagram showing some portions of the service computing system 102 and data repositories 104-106 in more detail. Some items are similar to Figure 1 The items shown are similarly numbered. Figure 3 In the example shown, data repository 104 illustratively includes a set of tables 126, and it may include various other data 128. Similarly, data repository 106 illustratively includes a set of tables 130, and it may include various other items 132. Figure 3 Also shown, in one example, service logic 118 may include a memory loading system 134 and various other service logic 136. The memory loading system 134 itself illustratively includes data store access logic 138, normalized object identification logic 140, resolution logic 142, cache loading logic 144, cache sharing logic 146, and it may include various other items 148.

[0034] Parsing logic 142 itself illustratively includes data item identifier logic 150, canonical object construction logic 152, reference generator logic 154, and it may include other items 156. Before describing the overall operation of memory loading system 134 in more detail, a brief description of some of the items in system 134 and their operation will first be provided.

[0035] The request processing logic 137 may receive a data access request from one of the client (or tenant) computing systems 108-110. It processes the request to identify the data requested for access. Assuming that the data has not yet been loaded into the cache 120, it identifies the specific data to be accessed and provides the indication to the data repository access logic 138. The data repository access logic 138 then interacts with the specific data repository 104-106 to access the requested data. For example, the data access request may access data in one or more different tables 126-130. Therefore, the data repository access logic 138 obtains access to these requested tables.

[0036] The normalized object identification logic 140 uses a normalization strategy to identify any specific normalized object, in the cache repository 120, the specific normalized object will be created and the table will be stored in the specific normalized object. The specific normalized object identified by the normalized object identification logic 140 can be any of a variety of different types of normalized objects, and they can vary from case to case. In addition, each group of normalized objects can be predefined, or they can be identified on the fly when a data request is received. In addition, the groups of normalized objects created for any given table or group of tables (or other data structures) retrieved from the databases 104-106 can be dynamic because they change over time based on machine learning techniques or based on other criteria. Therefore, the logic 140 can be logic that uses a lookup table or otherwise accesses a predefined set of objects. It can be a predefined algorithm that identifies the group of normalized objects based on the requested data or other criteria, or it can be a machine learning dynamic model that dynamically identifies the group of normalized objects using a neural network or otherwise.

[0037] Once the set of normalized objects is identified, parsing logic 142 parses the retrieved table into these normalized objects. Data item identifier logic 150 identifies the different data items in the retrieved table. Normalized object construction logic 152 identifies whether a normalized object has already been constructed for the data item. If so, reference generator logic 154 generates a reference to the normalized object that has already been constructed. If not, normalized object construction logic 152 constructs a normalized object for the data item.

[0038] The cache loading logic 144 loads the normalized objects (and / or references) into the cache repository 120 as cache data 124. The cache sharing logic 146 then shares the cache data 124 (the sharable data stored in the normalized objects) between different normalized objects that reference the sharable data objects. In this way, the cache data 124 can be used to respond to data access requests from the tenant computing systems 108-110 using the shared data without the client computing systems 108-110 even knowing that the data is shared between different normalized objects in the cache.

[0039] Figure 4 1 is a flow chart illustrating one example of the operation of the memory loading system 134 in more detail. First, the memory loading system 134 determines that an item from at least one of the data repositories 104-106 is to be loaded into the cache storage 120 for use by the service computing system 102. This is done by Figure 4In one example, one or more data items (such as tables) may be loaded into the cache store 120 when a service or a process in a service is started. This is indicated by box 162. In another example, an item (e.g., a table) may be loaded into the cache store 120 in response to a data access request from a client computing system 108-110. This is indicated by box 164.

[0040] It is assumed that at block 160 the data is not already represented in the cache repository 120. This is indicated by block 166. For the purposes of the present discussion, it is also assumed that the data to be loaded from the data repositories 104-106 into the cache repository 120 is represented as tables 126-130 in the data repository. This is indicated by block 168. However, it should be understood that it may also be represented by other data structures. It may also be possible to identify in other ways that an item from one of the data repositories is to be loaded into the cache 120. This is indicated by block 170.

[0041] The request processing logic 137 identifies one or more specific tables to be loaded and indicates this to the data store access logic 138. The logic 138 interacts with the appropriate data stores 104-106 to access the tables to be loaded into the cache 120. Accessing the tables is done by Figure 4 172 in the flowchart of FIG.

[0042] The normalized object identification logic 140 then identifies a set of normalized objects to be loaded into the cache 120 as the cache data 124 to represent the table being accessed. This is indicated by box 174. As described above, a particular set of normalized objects can be dynamically identified based on the content or structure of the table or other data item being accessed. This is indicated by box 176 and can be done using machine learning techniques, using a dynamic object identification model, or in other ways. In another example, the set of normalized objects to be generated in the cache repository 120 to represent the table being accessed can be a predefined set of objects. This is indicated by box 178. The set of objects can also be identified in other ways, and this is indicated by box 180.

[0043] For the purposes of this description, it will be assumed that the set of normalized objects includes objects with non-shareable attributes or data and sharable objects with sharable attributes or data. It will also be assumed that the sharable objects can be decomposed into a set of objects including inter-row sharable objects 182 and inter-tenant sharable objects 184. Non-sharable objects are indicated by 186. Inter-row sharable objects 182 include data that is sharable across rows of a data table. Inter-tenant sharable objects 184 include data that is sharable across tenants for a specific table, and non-sharable objects 186 include data that is not sharable across rows or tenants.

[0044] The parsing logic 142 then parses the table being accessed into the set of normalized objects. Figure 4 , as indicated by block 188 in the flowchart of . For example, the data item identifier logic 150 identifies the data item to be parsed, such as a row or a combination of rows and columns. The normalized object construction logic 152 determines whether there is already a normalized object that has been constructed for the data item and can be referenced (e.g., contains shared data for the data item). If so, the reference generator logic 154 generates a reference to the shared object. However, if not, the normalized object construction logic 152 constructs a normalized object that will contain the data for the data item.

[0045] The cache loading logic 144 then loads the normalized objects (newly constructed objects and references to existing objects) into the cache repository 120 as cache data 124. This is indicated by box 190. The cache data 124 can then be used by the service. In the event that shared data (or shareable objects) have been generated and stored in the cache data 124, the cache sharing logic 146 manages the sharing of any shareable objects in response to subsequent data access requests. This is indicated by box 192. Again, the sharing can be inter-row sharing as indicated by box 194. It can be inter-tenant sharing as indicated by box 196, or it can be sharing in other ways, as indicated by box 198.

[0046] Before describing the sharing process in more detail, a more detailed description of how a data item (such as a table) is parsed into the set of normalized objects will first be provided. Figure 5 is a flowchart showing an example thereof. Figure 6 is a block diagram showing one example of the cache storage 120 in more detail. Figure 5 and 6 .

[0047] exist Figure 6In the example shown, cache data 124 includes a cache for each tenant in a plurality of different tenants. These include Tenant 1 cache 200 to Tenant N cache 202. Each tenant cache 200-202 includes a set of normalized cache data objects. Cache 200 includes normalized cache data objects 204-206, while Tenant N cache 202 includes normalized cache data objects 208-210. Each set of normalized objects includes a set of non-shared attributes 212, 214, 216, and 218, respectively. It also illustratively includes a set of references 220, 222, 224, and 226 to inter-row sharable objects stored in a shared object pool 228, respectively. References 220-226 point to shared objects in the shared object pool 228, which, for example, contain data that can be shared across rows of a table. Each of the normalized cache data objects 204 - 210 also illustratively includes references 230 , 232 , 234 , and 236 , respectively, to shared objects in a shared object pool 228 that includes data that may be shared across tenants.

[0048] Thus, the shared object pool 228 illustratively includes a set of shared objects 238-240. It may also include other items 242. The shared objects 238-240 include data that can be shared across rows and across different tenants. Thus, the normalized cache data objects 204-210 include non-shared attributes within themselves that cannot be identified by referencing the shared objects 238-240. Each of the normalized cache data objects 204-210 also includes a reference to a shared object, where the data can be obtained from the shared objects 238-240 in the shared object pool 228. As described above, Figure 6 The references shown are specifically references 220 - 226 to inter-row sharable objects containing data shared across rows and references 230 - 236 to inter-tenant sharable objects containing data shared across tenants.

[0049] Figure 5 is a diagram showing how parsing logic 142 illustratively generates Figure 6 The data item identifier logic 150 first identifies the data item in the table. This is done by Figure 5 The block 250 in the flowchart of is indicated. For example, a data item may be a row or a column in a table. It may be a group of rows or columns, or another data item.

[0050] The normalized object construction logic 152 then determines whether the normalized object 204-210 already exists in the cache repository 120 for the item being analyzed. This is indicated by box 252. For example, the data item may have been retrieved or accessed and parsed so that a normalized object for it already exists. Alternatively, it may not have been accessed recently, so a normalized object for the data item does not yet exist in the cache repository 120. If a normalized object (or shareable object) for the data item already exists, the reference generator logic 154 adds a reference to the already constructed shareable object in the cache 120. This is indicated by box 254. However, if a normalized object for the data item has not yet been created in the cache 120, the normalized object construction logic 152 constructs a normalized object (and, if possible, a shareable object) in the cache 120. This is indicated by box 256. Processing continues until there are no more data items to be parsed. This is indicated by box 258.

[0051] Constructing the normalized object in cache 120 may include identifying non-shareable attributes, as indicated by block 260, and constructing the shareable object in shared object pool 228, as indicated by block 262. It also illustratively includes generating a reference to the shareable object in shared object pool 228, which may be indicated by block 264. The normalized object may also be constructed in other ways, as indicated by block 266.

[0052] At this point, a more concrete example may be helpful. For the sake of example, assume that Figure 2 The data table shown and described is the data table being parsed.

[0053] Figure 7 It shows that it can be targeted Figure 2 An example of a normalized object 270 generated by the table shown. It can be seen that the normalized object 270 includes a list of non-shareable attributes 272, a list of references to objects that can be shared between tenants 274, and a list of references to objects that can be shared between rows 276. Non-shareable attributes 272 may include unique identifiers such as those that are not shared across rows or tenants. References 274 to objects that can be shared between tenants may include references to sharable objects in a shared object pool 228, wherein the referenced objects share attributes that can be shared across tenants. This may include a variety of different contents, such as attribute names, or any other information that can be shared by different tenants. References 276 to objects that can be shared between rows also illustratively include references to sharable objects in a shared object pool 228. Illustratively, these shared objects will share data that can be shared across multiple different rows in a table. This may also include a variety of different types of information. For example, it may include other common metadata such as data types (e.g., multiple tables have the same data type) or common across multiple rows.

[0054] Figure 8 An example of a set of inter-row sharable objects 278 is shown. As can be seen, the inter-row sharable objects have Figure 7 The shared attributes include name 282, physical name 284, and Boolean attributes 286 and 288. Thus, instead of Figure 7 The objects shown repeat all information, and the interline references 276 simply reference the shared properties in the object 278. This greatly reduces redundancy.

[0055] Fig. 9 Similar to Figure 8 , except that it includes a set of sharable objects 290 that share properties between tenants. Object 290 includes pointer 292, which is connected to Figure 7 The same reference to the object 274 found in . The shared attributes include the entity ID 294 and the column identifier 296. Likewise, not in Figure 7 Copy this information into the object shown in Fig. 9 Insert a simple reference identifying the sharable object into the cache memory, which contains this information. Again, this greatly reduces redundancy in the cache memory 120.

[0056] Table 2 shows the above Figure 7-9 An example of how the class of the object shown looks like:

[0057] Table 2

[0058]

[0059]

[0060] Fig.10 1 is a flow chart illustrating one example of the operation of the cache sharing logic 146 in a multi-tenant scenario when sharing a shareable object in the shared object pool 228 with the caches of various tenants. The service logic 118 and the specific request processing logic 137 first receive a data access request from a client computing system 108-110. This is done by Fig.10 The data repository access logic 138 then determines whether the data has been loaded into the cache repository 120 for the tenant. For example, it may be determined whether a normalized cache data object (e.g., Figure 6 204 in the object). This is done by Fig.10If not, the memory loading system 134 parses the data and loads it into the cache repository 120, as described above. In doing so, it may generate a reference to a shareable object in the shared object pool 228. Loading data into the cache in this manner is performed by Fig.10 , as indicated by block 314 in the flowchart of FIG.

[0061] Once a set of normalized objects representing the requested data have been loaded into the cache repository 120, the cache sharing logic 146 retrieves any non-shareable data from the corresponding tenant cache. This is indicated by box 316. It then retrieves any inter-tenant shareable data from the shared object pool 228. This is indicated by box 318. In one example, it does this by accessing the normalized data object (e.g., object 204) and following the inter-tenant references / pointers in the normalized object 204 to obtain data from the identified shareable object. This is indicated by box 320. It can also retrieve shared data from any inter-tenant shareable data object in the shared object pool 228 in other ways. This is indicated by box 322.

[0062] The cache sharing logic 146 then retrieves any inter-row shareable data from the shared objects in the shared object pool 228. Fig.10 This may also be done by following inter-row references / pointers in the normalized objects in the tenant cache. This is indicated by box 326. It may also be done in other ways, as shown in box 328.

[0063] The other service logic 136 then generates an output based on the retrieved data and returns the retrieved data to the requesting tenant computing system via the output. Fig.10 denoted by block 330 in the flowchart of FIG.

[0064] Thus, it can be seen that the present specification provides a memory loading system that processes data from data stores without changing the mode in which the data is stored in these data stores and stores it as normalized objects in the tenant's cache store. Since normalized objects reduce redundancy, the memory footprint of the service (or process) providing access to the data is greatly reduced. This is also done in a way that is invisible to the tenant computing system requesting access to the data.

[0065] Fig.11 yes Figure 1The block diagram of the architecture 100 shown in FIG. 5 is different in that its elements are arranged in a cloud computing architecture 500. Cloud computing provides computing, software, data access and storage services that do not require end users to understand the physical location or configuration of the system providing the service. In various embodiments, cloud computing uses appropriate protocols to provide services over a wide area network such as the Internet. For example, a cloud computing provider provides applications over a wide area network and can access them through a web browser or any other computing component. The software or components of the architecture 100 and the corresponding data can be stored on a server at a remote location. The computing resources in a cloud computing environment can be integrated at a remote data center location or can be dispersed. Cloud computing infrastructure can provide services through a shared data center, even if they are only an access point for users. Therefore, the components and functions described herein can be provided from a service provider at a remote location using a cloud computing architecture. Alternatively, they can be provided from a conventional server or installed directly or otherwise on a client device.

[0066] This description is intended to include both public and private cloud computing.Cloud computing (public and private) provides a substantially seamless pool of resources and reduces the need to manage and configure the underlying hardware infrastructure.

[0067] Public clouds are managed by the vendor and typically use the same infrastructure to support multiple consumers. Also, in contrast to private clouds, public clouds free the end user from the burden of managing hardware. Private clouds can be managed by the organization itself, and the infrastructure is typically not shared with other organizations. The organization still maintains the hardware to some extent, such as installation and repairs.

[0068] exist Fig.11 In the example shown, some items are like Figure 1 those shown and are similarly numbered. Fig.11 Specifically illustrated is that the service computing system 102 may be located in a cloud 502 (which may be public, private, or a combination of some public and other private). Thus, users 114 and 116 use systems 108 and 110 to access these systems through the cloud 502.

[0069] Fig.11 Another example of a cloud architecture is also depicted. Fig.11It is also contemplated that some elements of the architecture 100 may be located in the cloud 502, while others are not. For example, the data repositories 104 and 106 may be located inside or outside the cloud 502 and accessed through the cloud 502. Regardless of where they are located, they may be directly accessed by the systems 108-110 over a network (wide area network or local area network), may be hosted by a service at a remote site, or may be provided as a service through the cloud, or may be accessed through a connection service residing in the cloud. All of these architectures are contemplated herein.

[0070] It should also be noted that the architecture 100 or a portion thereof can be disposed on a variety of different devices. Some of these devices include servers, desktop computers, laptop computers, tablet computers or other mobile devices, such as palmtop computers, mobile phones, smart phones, multimedia players, personal digital assistants, etc.

[0071] Fig.12 is an example of a computing environment in which the architecture 100 or a portion thereof, for example, may be deployed. Fig.12 , an example system for implementing some embodiments includes a general purpose computing device in the form of a computer 810. Components of the computer 810 may include, but are not limited to, a processing unit 820 (which may include a processor or server from the previous figures), a system memory 830, and a system bus 821 that couples various system components including the system memory to the processing unit 820. The system bus 821 may be any of several types of bus structures using any of a variety of bus architectures, including a memory bus or memory controller, a peripheral bus, and a local bus. By way of example and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus (also known as a mezzanine bus). Reference Figure 1 The memory and programs described can be deployed in Fig.12 in the corresponding part of .

[0072] Computer 810 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by computer 810, and includes volatile and non-volatile media, removable and non-removable media. As an example and not limitation, computer-readable media may include computer storage media and communication media. Computer storage media is different from (but not including) modulated data signals or carrier waves. It includes hardware storage media, including volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic tape, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by computer 810. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a transmission mechanism, and includes any information delivery medium. The term "modulated data signal" refers to a signal whose one or more characteristics are set or changed in a manner that can encode information into a signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0073] The system memory 830 includes computer storage media in the form of volatile and / or nonvolatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. A basic input / output system 833 (BIOS), containing the basic routines that help transfer information between elements within the computer 810, such as during startup, is typically stored in ROM 831. RAM 832 typically contains data and / or program modules that are immediately accessible and / or currently being operated on by the processing unit 820. By way of example and not limitation, Fig.12 Operating system 834 , application programs 835 , other program modules 836 , and program data 837 are shown.

[0074] The computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. For example only, Fig.12A hard disk drive 841 that reads or writes to non-removable non-volatile magnetic media, and an optical disk drive 855 that reads or writes to a removable non-volatile optical disk 856 (such as a CD ROM or other optical media) are shown. Other removable / non-removable volatile / non-volatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.

[0075] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, and not limitation, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), program-specific integrated circuits (ASICs), program-specific standard products (ASSPs), system-on-chip systems (SOCs), complex programmable logic devices (CPLDs), and the like.

[0076] The above discussion and Fig.12 The drives and their associated computer storage media shown in FIG. 8 provide storage of computer readable instructions, data structures, program modules and other data for the computer 810. Fig.12 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to illustrate that they are at least different copies.

[0077] A user can enter commands and information into the computer 810 through input devices such as a keyboard 862, a microphone 863, and a pointing device 861 (such as a mouse, trackball, or touch pad). Other input devices (not shown) may include a joystick, a game controller, a satellite dish, a scanner, or the like. These and other input devices are typically connected to the processing unit 820 through a user input interface 860 that is coupled to the system bus, but may be connected through other interfaces and bus structures such as a parallel port, a game port, or a universal serial bus (USB). A visual display 891 or other type of display device is also connected to the system bus 821 via an interface such as a video interface 890. In addition to the display, the computer may also include other peripheral output devices such as speakers 897 and a printer 896 that may be connected through an output peripheral interface 895.

[0078] The computer 810 operates in a networked environment using logical connections to one or more remote computers, such as a remote computer 880. The remote computer 880 may be a personal computer, a handheld device, a server, a router, a network computer, a peer device, or other public network node, and typically includes many or all of the elements described above with respect to the computer 810. Fig.10 The logical connections shown include a local area network (LAN) 871 and a wide area network (WAN) 873, but other networks may also be included. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

[0079] When used in a LAN networking environment, the computer 810 is connected to the LAN 871 through a network interface or adapter 870. When used in a WAN networking environment, the computer 810 typically includes a modem 872 or other means for establishing communications over the WAN 873, such as the Internet. The modem 872, which may be internal or external, may be connected to the system bus 821 via the user input interface 860 or other appropriate mechanism. In a network environment, program modules depicted with respect to the computer 810 or portions thereof may be stored in the remote memory storage device. By way of example and not limitation, Fig.12 Remote application programs 885 are shown residing on remote computer 880. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0080] It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of these are considered herein.

[0081] Example 1 is a computing system comprising:

[0082] request processing logic that receives a data access request from a requesting computing system and identifies a data table in a database to be accessed;

[0083] Data access logic, obtaining the identified data table from the database;

[0084] parsing logic to parse the data table into a normalized cache data object, the normalized cache data object including non-shareable data attributes and a reference to an inter-row shareable data object, the inter-row shareable data object including cross-table row shareable data attributes; and

[0085] The cache loading logic loads the normalized cache data object into a cache storage repository corresponding to the requesting computing system.

[0086] Example 2 is a computing system of any or all of the previous examples, wherein the parsing logic is configured to parse the data table into the normalized cache data object by including a reference to an inter-tenant sharable data object, wherein the inter-tenant sharable data object includes inter-tenant sharable data that is sharable between multiple different tenant cache systems.

[0087] Example 3 is the computing system of any or all of the previous examples, wherein the parsing logic comprises:

[0088] data identifier logic configured to identify data items in the data table; and

[0089] Normalized object construction logic is configured to determine whether a normalized cache data object already exists in the cache and can be referenced for data in the identified data item.

[0090] Example 4 is a computing system of any or all of the previous examples, wherein if the normalized object construction logic determines that a normalized cache data object does not exist in the cache repository and can be referenced for data in the identified data item, then the normalized object construction logic is configured to construct the normalized cache data object corresponding to the identified data item.

[0091] Example 5 is the computing system of any or all of the previous examples, wherein the parsing logic further comprises:

[0092] A reference generator logic is configured to generate the reference to the inter-row shareable data object.

[0093] Example 6 is the computing system of any or all of the previous examples, wherein the reference generator logic is further configured to generate the reference to the inter-tenant shareable data object.

[0094] Example 7 is the computing system of any or all of the previous examples, wherein the normalized object construction logic is configured to identify inter-row sharable data in the identified data items and construct a first sharable object including the inter-row sharable data.

[0095] Example 8 is the computing system of any or all of the previous examples, wherein the cache loading logic is configured to load the first sharable object into a shared object pool in the cache repository.

[0096] Example 9 is the computing system of any or all of the previous examples, wherein the normalized object construction logic is configured to identify inter-tenant sharable data in the identified data item and construct a second sharable object including the inter-tenant sharable data.

[0097] Example 10 is the computing system of any or all of the previous examples, wherein the cache loading logic is configured to load the second sharable object into the shared object pool in the cache repository.

[0098] Example 11 is the computing system of any or all of the preceding examples, further comprising:

[0099] A cache sharing logic is configured to identify a normalized cache data object corresponding to a data access request, and obtain non-shareable data attributes from the normalized cache data object corresponding to the data access request, and obtain the inter-row sharable data from the inter-row sharable data object based on the reference to the inter-tenant sharable data object in the normalized cache data object, and obtain inter-tenant sharable data from the inter-tenant sharable data object based on the reference to the inter-tenant sharable data object in the normalized cache data object.

[0100] Example 12 is a computer-implemented method comprising:

[0101] Based on the data access request from the requesting computing system, identifying a data table in the database to be accessed;

[0102] Retrieve the identified data table from the database;

[0103] parsing the data table into a normalized cache data object, the normalized cache data object comprising non-shareable data attributes and a reference to an inter-row shareable data object, the inter-row shareable data object comprising cross-table row shareable data attributes; and

[0104] The normalized cache data object is loaded into a cache repository corresponding to the requesting computing system.

[0105] Example 13 is a computer-implemented method of any or all of the previous examples, wherein parsing comprises:

[0106] The data table is resolved into the normalized cache data object by including a reference to an inter-tenant sharable data object including inter-tenant sharable data sharable between a plurality of different tenant cache systems.

[0107] Example 14 is a computer-implemented method of any or all of the previous examples, wherein parsing comprises:

[0108] identifying a data item in the data table; and

[0109] A determination is made as to whether a normalized cache data object already exists in the cache and can be referenced for data in the identified data item.

[0110] Example 15 is a computer-implemented method of any or all of the previous examples, wherein if it is determined that a normalized cache data object does not exist in the cache repository and can be referenced for data in the identified data item, then the normalized cache data object corresponding to the identified data item is constructed in the cache repository.

[0111] Example 16 is a computer-implemented method of any or all of the previous examples, wherein parsing further comprises:

[0112] generating said reference to said inter-row sharable data object; and

[0113] The reference to the inter-tenant shareable data object is generated.

[0114] Example 17 is a computer-implemented method of any or all of the previous examples, wherein constructing comprises:

[0115] Identifying inter-row sharable data in the identified data items;

[0116] constructing a first sharable object including the inter-row sharable data; and

[0117] The first sharable object is loaded into a shared object pool in the cache repository.

[0118] Example 18 is a computer-implemented method of any or all of the previous examples, wherein constructing comprises:

[0119] Identifying data that can be shared between tenants in the identified data items;

[0120] constructing a second sharable object including the inter-tenant sharable data; and

[0121] The second sharable object is loaded into the shared object pool in the cache repository.

[0122] Example 19 is the computer-implemented method of any or all of the previous examples, further comprising:

[0123] identifying a normalized cache data object corresponding to a data access request;

[0124] obtaining a non-shareable data attribute from the normalized cache data object corresponding to the data access request;

[0125] obtaining the inter-row sharable data from the inter-row sharable data object based on the reference to the inter-row sharable data object in the normalized cache data object; and

[0126] Inter-tenant sharable data is obtained from the inter-tenant sharable data object based on the reference to the inter-tenant sharable data object in the normalized cache data object.

[0127] Example 20 is a computing system comprising:

[0128] request processing logic that receives a data access request from a requesting computing system and identifies a data table in a database to be accessed;

[0129] Data access logic, obtaining the identified data table from the database;

[0130] parsing logic to parse the data table into normalized cache data objects, the normalized cache data objects including non-shareable data attributes, references to inter-row sharable data objects, and references to inter-tenant sharable data objects, the inter-row sharable data objects including cross-table row sharable data attributes, the inter-tenant sharable data objects including inter-tenant sharable data sharable between a plurality of different tenant cache systems; and

[0131] The cache loading logic loads the normalized cache data object into a cache storage repository corresponding to the requesting computing system.

[0132] Although the present invention has been described with reference to preferred embodiments, workers skilled in the art will recognize that changes may be made in form and detail without departing from the spirit and scope of the invention.

Claims

1. A computing system comprising: at least one processor; as well as a memory storing instructions executable by the at least one processor, wherein the instructions, when executed, cause the computing system to: receiving a data access request associated with a requesting tenant computing system; identifying a requested data table based on the data access request; parsing the requested data table into a normalized cache data object, the normalized cache data object comprising a reference to an inter-tenant sharable data object, the inter-tenant sharable data object comprising inter-tenant sharable data, the computing system being configured to share the inter-tenant sharable data between a plurality of different tenant cache systems; as well as The normalized cache data object is stored in a cache repository corresponding to the requesting tenant computing system. 2 . The computing system of claim 1 , wherein the plurality of different tenant cache systems correspond to a plurality of different tenants.

3. The computing system of claim 1 , wherein the instructions, when executed, cause the computing system to: identifying a data item in the requested data table; and The inter-tenant sharable data in the data item is identified, and a second sharable object including the inter-tenant sharable data is constructed.

4. The computing system of claim 3, wherein the instructions, when executed, cause the computing system to: The second sharable object is loaded into a shared object pool in the cache repository.

5. The computing system of claim 1 , wherein the normalized cache data object comprises a first normalized cache data object, and the instructions, when executed, cause the computing system to: identifying a second normalized cache data object corresponding to a second data access request; obtaining a non-shareable data attribute from the second normalized cache data object corresponding to the second data access request; as well as The inter-tenant sharable data is obtained from the inter-tenant sharable data object based on the reference to the inter-tenant sharable data object in the normalized cache data object.

6. The computing system of claim 5, wherein the requesting tenant computing system comprises a first requesting tenant computing system, and the instructions, when executed, cause the computing system to: receiving the second data access request from a second tenant computing system; and The data requested in the second data access request is determined to be loaded into a cache repository for the second tenant computing system based on the reference to the inter-tenant sharable data object.

7. The computing system of claim 1 , wherein the instructions, when executed, cause the computing system to: identifying a data item in the requested data table; and A determination is made as to whether a normalized cache data object already exists in the cache store and can be referenced for data in the data item.

8. The computing system of claim 7, wherein the instructions, when executed, cause the computing system to: Based on determining that a normalized cache data object does not already exist in the cache repository, constructing the normalized cache data object corresponding to the data item.

9. A computer-implemented method comprising: receiving a data access request associated with a requesting tenant computing system; identifying a requested data table based on the data access request; parsing the requested data table into a normalized cache data object, the normalized cache data object comprising a reference to an inter-tenant sharable data object, the inter-tenant sharable data object comprising inter-tenant sharable data, wherein the computing system is configured to share the inter-tenant sharable data among a plurality of different tenant cache systems; as well as The normalized cache data object is stored in a cache repository corresponding to the requesting tenant computing system.

10. The computer-implemented method of claim 9, wherein the plurality of different tenant cache systems correspond to a plurality of different tenants.

11. The computer-implemented method of claim 9, further comprising: Identify a data item in the requested data table; as well as The inter-tenant sharable data in the data item is identified, and a second sharable object including the inter-tenant sharable data is constructed.

12. The computer-implemented method of claim 11 , further comprising: The second sharable object is loaded into a shared object pool in the cache repository.

13. The computer-implemented method of claim 9, wherein the normalized cache data object comprises a first normalized cache data object, and the method further comprises: identifying a second normalized cache data object corresponding to a second data access request; obtaining a non-shareable data attribute from the second normalized cache data object corresponding to the second data access request; as well as The inter-tenant sharable data is obtained from the inter-tenant sharable data object based on the reference to the inter-tenant sharable data object in the normalized cache data object.

14. The computer-implemented method of claim 13, wherein the requesting-tenant computing system comprises a first requesting-tenant computing system, and the method further comprises: receiving the second data access request from a second tenant computing system; as well as The data requested in the second data access request is determined to be loaded into a cache repository for the second tenant computing system based on the reference to the inter-tenant sharable data object.

15. The computer-implemented method of claim 9, further comprising: Identify a data item in the requested data table; as well as A determination is made as to whether a normalized cache data object already exists in the cache store and can be referenced for data in the data item.

16. The computer-implemented method of claim 15, further comprising: Based on determining that a normalized cache data object does not already exist in the cache repository, constructing the normalized cache data object corresponding to the data item.

17. A computing system comprising: at least one processor; as well as a memory storing instructions executable by the at least one processor, wherein the instructions, when executed, provide: request processing logic configured to receive a data access request from a requesting computing system and identify a data table based on the data access request; Data access logic is configured to obtain the data table; parsing logic configured to parse the data table into a normalized cache data object, the normalized cache data object comprising a non-shareable data attribute and a reference to an inter-tenant sharable data object, the inter-tenant sharable data object comprising inter-tenant sharable data, the computing system being configured to share the inter-tenant sharable data between a plurality of different tenant cache systems; as well as The cache loading logic is configured to load the normalized cache data object into a cache storage repository corresponding to the requesting computing system.

18. The computing system of claim 17, wherein the plurality of different tenant cache systems correspond to a plurality of different tenants.

19. The computing system of claim 17, wherein the parsing logic comprises: data identifier logic configured to identify data items in the data table; as well as Normalized object construction logic is configured to determine that a normalized cache data object does not already exist in the cache repository, can be referenced for data in the data item, and based on the determination, construct the normalized cache data object corresponding to the data item.

20. The computing system of claim 17, wherein the parsing logic is configured to: identifying a data item in the data table; and identifying the inter-tenant sharable data in the data item, and constructing a second sharable object including the inter-tenant sharable data; and The second sharable object is loaded into a shared object pool in the cache repository.

Images