Patent Publication Number: US-11663200-B2

Title: Content agnostic memory pageable storage model

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is a continuation of U.S. patent application Ser. No. 16/858,344, filed Apr. 24, 2020, now allowed, which claims priority to U.S. Provisional Patent Application No. 62/858,963, titled “Native Store Extension for Combined Workload Databases” to Sherkat et al, filed Jun. 7, 2019, all of which are herein incorporated by reference in their entirety. 
    
    
     BACKGROUND 
     Systems typically store particular data objects in in-memory storage. However, in doing so, systems require a full memory footprint of the data objects. Since some data objects can be very large, their corresponding memory footprint can also be large. Along these lines, in many systems, the in-memory database typically has a limited capacity. Thus, systems can have limited capacity in the amount of data objects that can be stored. Accordingly, the total cost of ownership for storing data objects is high. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The accompanying drawings are incorporated herein and form a part of the specification. 
         FIG.  1    is a block diagram of a system for storing an object on one or more pages, according to some embodiments. 
         FIG.  2    is a process for storing various objects on one or more pages, according to some embodiments. 
         FIG.  3    is a data block stored on a page, according to some embodiments. 
         FIG.  4    is a flowchart illustrating a process for storing an object on one or more pages, according to some embodiments. 
         FIG.  5    is a flowchart illustrating a process for loading an object on one or more pages, according to some embodiments. 
         FIG.  6    is an example computer system useful for implementing various embodiments. 
     
    
    
     In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears. 
     DETAILED DESCRIPTION 
     Provided herein are system, apparatus, device, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for storing an object on one or more pages of a persistent storage medium of a database. 
     In some embodiments, when storing an object in an on-disk store of a database, a database can identify the first available page of a chain of pages having unused space. The database can then determine if the size of the object exceeds the unused space of the specific memory page. If not, the database can generate (e.g., write) a single data block comprising the bytes of the object and store the data block corresponding to the object on the particular page. However, the database can also determine that the size of the object is larger than the unused space of the first available memory page. For example, in some embodiments, the first available memory page can be storing another object&#39;s data block. Further, in some embodiments, although the first available memory page cannot be storing another object&#39;s data block, the first available memory page can still nonetheless not be large enough to store the object. 
     Accordingly, when the size of the object exceeds the first available page, the database can generate multiple data blocks having one or more bytes of the object and save the data blocks on one or more pages in a columnar format. For example, in some embodiments, the database can generate a first data block to occupy the available (e.g., remaining) space available on the first available page. And, the database can create additional data blocks to occupy up to the capacity of subsequent pages following the first available page. Thus, the database can generate a second and third data block comprising one or more data bytes so long as the second and third data blocks do not comprise more data bytes than provided by the first and second available pages, respectively. In turn, in some embodiments, data blocks—comprising the same or different number of bytes and corresponding to different objects—can be stored on the same page. Along these lines, in some embodiments, a particular object can comprise multiple data blocks—including the same or different numbers of bytes—stored on separate pages. 
     Moreover, in storing data blocks on one or more pages, the database can load the pages into an in-memory store and write the data blocks onto the pages. The database can also record a location of the object&#39;s first data block on the first available page. The location can specify a particular page and an offset on the page from which the object&#39;s first data block begins. The database can then create a logical pointer for the first data block&#39;s location in the on-disk store. The logical pointer can include the location and/or the total number of bytes of the object. The database can then send the logical pointer to the user for loading the object. The logical pointer can then be used as a key to access the object. 
     Accordingly, when requesting the loading of the first object, the user can send the logical pointer to the database. The database can then utilize the logical pointer to locate the first data block of the object and determine whether the object is saved on one or multiple pages. If the object is saved on one page, the database can load the page into the in-memory store. The database can then return a pointer to a location in the in-memory store and a page handle for ensuring that the page is not removed from (e.g., flushed out of) the in-memory store. However, if the object is saved on multiple pages, the database can load the data blocks into a buffer of the in-memory store. database This allows the user to access data relating to the object. By operating in such a fashion, database  102  is able to provide a lower cost of ownership for data objects, as well as provide a smaller footprint for them. 
       FIG.  1    a system  100  for storing an object on one or more pages. System  100  can include database  102  and/or client devices  104 A-C. Database  102  can be in communication with client devices  104 A-C and can receive a request to store various objects. The objects can be of any size and/or shape. In some embodiments, the objects can include any type of data, such as geometric data (e.g., a polygon). Along these lines, the objects can be of fixed and/or variable sizes. For example, in some embodiments, the objects can be very large (e.g., 800,000 bytes). In some embodiments, the objects can be small (e.g., 100,000 bytes). 
     Database  102  can include caller  106 , application program interface (API)  108 , save API  110 , load API  112 , in-memory store  114 , and/or on-disk store  116 . In-memory store  114  can include a buffer  110  for receiving data of objects. On-disk store  118  can comprise one or more pages  120 A-C for storing objects. Although on-disk store  118  is illustrated, database  102  may include any type of persistent storage medium, such as a solid-state device and a non-volatile memory device. Pages  120 A-C can be a column database of a fixed-length contiguous block of memory (e.g., virtual memory). Pages  120 A-C can be of the same or different size. For example, in some embodiments, pages  120 A-C can each be 256K bytes. Pages  120 A-C can also be different sizes (e.g., 64K bytes, 128K bytes, and 256K bytes, respectively). 
     Caller  106  can manage data received and returned from database  102 . Accordingly, caller  106  can be in communication with user API  108 , save API  110  and/or load API  112  to store and/or retrieve objects to and/or from on-disk store  118 , as will be described in more detail below. Database  102 &#39;s user API  108  can receive requests to save objects from user devices  104 A-C. In some embodiments, user API  108  can also provide user devices  104 A-C with a single page storage option or a multi-page storage option. Upon the selection of the single page storage option, caller  106  can attempt to save the object on a single page  120 A. In some embodiments, page  120 A can contain data blocks of other objects and contain sufficient storage capacity to store the object. In some embodiments, page  120 A can not contain data blocks of any other objects and contain sufficient storage capacity to store the object. In some embodiments, although sufficient memory remains on a particular page  120 A to store the object (e.g., when another object&#39;s block is stored on page  120 A), caller  106  can store the object on a subsequent page  120 B. This can be done upon the user&#39;s request. 
     Further, in some embodiments, although the user selected the single page storage option, caller  106  can determine that the object cannot be saved on a single page  120 A and store the object on multiple pages  120 A-C using save API  110 . Along these lines, in some embodiments, although the object can be stored on a single page  120 A, the object can be stored on multiple pages  120 A-C. Thus, database  102 &#39;s ability and/or inability to save the object on a single page  120 A can be unknown to the user. 
     Further, in some embodiments, user API  108  can provide user devices  104 A-C with a single page storage option or a multi-page storage option. Thus, database  102  stores the object as a single data block on page  120 A if possible (e.g., when the object is less than or equal to page  120 A&#39;s capacity). Otherwise, database  102  stores the object on multiple pages  120 A-C. In doing so, as will be discussed in more detail below, database  102  can segment the object into multiple data blocks. Accordingly, in some embodiments, users can be unaware of the object being stored on a single page  120 A or multiple pages  120 A-C. In turn, users can also be unaware of whether the object is stored using a single data blocks or multiple data blocks. 
     Database  102 &#39;s caller  106  can store objects on on-disk store  118 &#39;s pages  120 A-C in a columnar format.  FIG.  2    illustrates an example process for storing various objects (not illustrated) on pages  202 A-D. The objects can be represented by index vectors  200 A-C. In some embodiments, the objects can be of different sizes, and thus the corresponding index vectors  200 A-C can be of different sizes. In some embodiments, objects—and corresponding index vectors  200 A-C—can be chosen intentionally to store these data structures in contiguous memory. 
     Save API  110  (of  FIG.  1   ) can analyze the chain of pages  202 A-D. Database  102  can then identify the first page  202 A having unutilized memory. In some embodiments, page  202 A of a chain of pages  202 A-D such that page  202 A is followed by page  202 B followed by page  202 C followed by page  202 D. Save API  110  can determine whether an object corresponding to a particular index vector  200 A can be saved on a single page  202 A. If not possible, caller  106  (of  FIG.  1   ) can then store the object on multiple pages  202 A-D. Save API  110  can then create data blocks  204 A-E of a particular size depending on the amount of data of index vectors  200 A-D and the size of the page  202 A-D. Accordingly, data blocks cannot be larger than pages  202 A-D. 
     For example, as illustrated, save API  110  (of  FIG.  1   ) can determine that the data of index vector  200 A can be stored entirely on page  202 A. Thus, save API  110  (of  FIG.  1   ) can store a single data block  204 A representing index vector  200 A—on page  202 A. Data block  204 A can fully utilize page  202 A&#39;s storage capacity. Thereafter, save API  110  can determine that the data of index vector  200 B exceeds page  202 B&#39;s storage capacity, which follows page  202 A. In doing so, save API  110  can determine that data of index vector  200 B requires utilizing all of page  202 B and at least a portion of page  202 C. Therefore, save API  110  can create multiple data blocks  204 B and  204 C representing data of index vector  200 B. As illustrated, data block  204 B can represent a larger portion of index vector  200 B&#39;s data then data block  204 C. Accordingly, data blocks  204 B and  204 C can be of different sizes and represent the same index vector  200 B. Save API  110  can then store data blocks  204 B and  204 C on different pages  202 B and  202 C, respectively. Data block  204 B can utilize the entire page  202 B&#39;s capacity. Data block  204 C can utilize a portion of pages  202 C&#39;s capacity. 
     Further, save API  110  (of  FIG.  1   ) can determine that the data of index vector  200 C can be entirely stored on page  202 C, which, as described above, also stores data block  204 C. Accordingly, save API  102  can create data block  204 D representing index vector  200 C. Save API  110  can then store data block  204 D on page  202 C. Data block  204 D can utilize at least a portion of pages  202 C&#39;s capacity. Accordingly, data blocks  204 C and  204 D—representing index vectors  200 C and  200 D, respectively—utilize all or a portion of page  202 C&#39;s capacity. 
     In some embodiments, as discussed above, save API  110  (of  FIG.  1   ) can receive a user&#39;s request that the object—corresponding to data of index vector  200 C—be stored on a separate page  202 D. Accordingly, although storage space remains on page  202 C, save API  110  can store data block  204 D on page  202 D. Thus, in some embodiments, like page  202 C, page  202 D can also have unutilized storage space. 
     As described above, in some embodiments, pages  202 A and  202 B can be fully utilized and store a single data block  204 A-B. In some embodiments, page  204 C can be partially utilized and store multiple data blocks  204 C and  204 D. Further, in some embodiments, page  202 D can be partially utilized and store a single data block  204 D. Thus, pages  202 A-D can store one or multiple data blocks  204 A-D and correspond to the same or different index vectors. 
     Accordingly, save API  110  (of  FIG.  1   ) can load the appropriate pages  202 A-C into in-memory store  118 . Save API  110  can then store data blocks  204 A-C on pages  202 A-C at their appropriate locations. After doing so, save API  110  can send the pages  202 A-C back in on-disk store  116 . 
     Additionally, save API  110  (of  FIG.  1   ) can record a location of the object&#39;s first data block on pages  202 A-D. As described above, save API  110  can store data blocks  204 A-D on pages  202 A-D in a columnar format. As also described above, pages  202 A-D can be of a particular size (e.g., 256K bytes). Further, objects can be of various sizes and thus comprise different amounts of bytes. In turn, data blocks  204 A-D can be of various sizes and therefore include varying amounts of bytes. Thus, save API  114  can record the location of the first block of a particular object relative to a byte on pages  202 A-D. For example, since data block  204 A and  204 B are the first data blocks on pages  202 A and  202 B, their location can be page  202 A, byte 0, and page  202 B, byte 0, respectively. And since data block  204 D follows data block  204 C on page  202 C, data block  204 D&#39;s location can be page  202 C, byte 120K (or some other nonzero number). 
     Along these lines, save API  110  (of  FIG.  1   ) can align data blocks  204 A-D on pages  202 A-D. In doing so, in some embodiments, save API  110  can offset each data block  204 A-D by a nonzero number of bytes (e.g., 8 bytes, 16 bytes, 32 bytes). Thus, save API  110  can save data blocks  204  that are not the first data block on pages  202 A-D at a byte divisible by the nonzero number of bytes (e.g., 16). For example, if data block  204 C ends on page  202 C&#39;s byte 120, data block  204  can store data block  204 D at pages  202 C&#39;s byte 128—which is the first byte after byte 120 divisible by 16. This can allow the data blocks to be loaded faster without increasing the object&#39;s memory footprint. 
       FIG.  3    illustrates an example of data block  300  created by save API  110  (of  FIG.  1   ). Block  300  includes header  302  and payload  304 . Header  302  can include metadata unique to block  300  and optionally, metadata provided by a user. Metadata unique to the block  300  can include metadata flags, for example stating that block  300  is a first or last block relating to a particular object. Metadata unique to the user can be a particular size and/or type of an object stored in payload  304 . Further, payload  304  can include data of the actual object (e.g., index vectors  200 A-C of  FIG.  1   ). 
     Referring to  FIG.  1   , in storing the object on pages  120 A-C, save API  112  can create a logical pointer  122 A-C relating to the location of the object. In some embodiments, logical pointer  122 A-C can include a location of the object&#39;s first data block and/or a number of bytes of the object. The location can specify a particular page  118 A and an offset on the page  118 A from which the object&#39;s first data block begins. Database  102  can then send logical pointer  122 A-C to the user. Logical pointer  122 A-C can then be used as a key to access the object. 
     Accordingly, users can request access to an object using logical pointer  122 A-C. In some embodiments, users may not have personally stored the object on on-disk store  118  (e.g., pages  120 A-C). In some embodiments, users can be unaware of whether the object was stored on one or multiple pages  120 A-C. In some embodiments, upon receipt of the request, database  102 &#39;s user API  108  can provide users a page-map-mode option, a full copy mode option, and/or a convenience mode option. User API  108  can then forward the request to load API  112 . In some embodiments, upon receipt of the request, and without input from a user, load API  112  can determine whether to utilize a page map mode or a full copy mode based on whether the object is stored on a single page  120 A-C or multiple pages  120 A-C. 
     The page map mode can be available for objects stored on a single page  120 A-C. Database  102  can then retrieve data from on-disk store  116  and store it in in-memory store  114 . For example, in some embodiments, database  102  can retrieve an appropriate pages  202 A-C comprising a single data block  204 A-C (of  FIG.  2   ) pertaining to the object and store the appropriate page  202 A-C in in-memory store  114 . Database  102  can send pointer  124 A-C and handle  126 A-C to maintain the user. Pointer  124 A-C can specify a location of the appropriate page  202 A-C in-memory store  114 . Handle  126 A-C can permit a user to ensure that data relating to the object (e.g., an appropriate page  204 A-C) is not removed from in-memory store  114  while it is being utilized. 
     Further, the full copy mode can be available for objects stored on multiple pages  120 A-C. As described above, objects stored on multiple pages  120 A-C comprise multiple data blocks. Thus, in the full copy mode, database  102  can retrieve data from data blocks from each page  120 A-C iteratively and store them in buffer  110 . In doing so, buffer  110  can contain data of all or part of a particular page  120 A-C at a particular time before database  102  flushes buffer  110  for storing data of another object. 
     The convenience mode can be available for users who are unaware of the object being stored on a single or multiple pages  120 A-C. Accordingly, database  102  can determine the object being stored on a single or multiple pages  120 A-C and operate according to the page map mode or the full copy mode based on this determination. 
     Additionally, after retrieving data blocks of objects from on-disk store  116  and storing the data blocks in in-memory store  114 , database  102  can permit a user to rewrite new and/or different data onto the object&#39;s data blocks  202 A-D so long as the new and/or different data does not exceed the size of the preexisting data stored on data blocks  202 A-D. For example, in some embodiments, the user can provide different metadata in a header of the data block of the object. In some embodiments, the user can also have new and/or different data relating to a different object be written onto the data blocks of the object. Along these lines, in some embodiments, where new and/or different data corresponding to a new object is provided onto existing blocks, some data blocks and/or portions of data blocks cannot be utilized. 
       FIG.  4    is a flowchart for method  400  for saving an object on one or more pages, according to some embodiments.  FIG.  5    is a flowchart for method  500  for loading an object from one or more pages, according to some embodiments. Methods  400  and  500  can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions executing on a processing device), or a combination thereof. It is to be appreciated that not all steps can be needed to perform the disclosure provided herein. Further, some of the steps can be performed simultaneously or in a different order than shown in  FIGS.  3  and  4   , as will be understood by a person of ordinary skill in the art. 
     Referring to  FIG.  4   , method  400  shall be described with reference to  FIGS.  1  and  2   . However, method  400  is not limited to those example embodiments. 
     At  402 , database  102  receives an object from a user. The object can be of a particular size and include a predefined number of bytes (e.g., 250 bytes, 400 bytes, or 1K bytes). For example, in some embodiments, the object can comprise two bytes—i.e., a first byte and a second byte. 
     At  404 , database  102  determines that page  202 A-B has sufficient unused space for storing the first byte and/or the second byte. Database  102  can first determine that page  202 A-B is the first available page in a chain of pages that has unused storage. Database  102  can thereafter determine if the unused storage is sufficient for storing one or both of the first byte and second byte. Accordingly, in some embodiments, database  102  can determine that page  202 A-B has sufficient unused space for storing the entire object—i.e., the first byte and the second byte. In some embodiments, database  102  can determine that page  202 A-B has sufficient unused space for storing the first byte (i.e., not the second byte). 
     At  406 , database  102  creates a first data block  204 A-C and/or a second data block  204 A-C comprise the first byte and/or the second byte of the object. Thus, in embodiments where first page  202 A does have sufficient unused space for storing the entire object, database  102  may create a single data block  204 A. Thus, data block  202 A may store all of the object&#39;s bytes. In some embodiments where first page  202 B does not have sufficient unused space to store the entire object&#39;s bytes, database  102  may create multiple data blocks  204 B and  204 C. Data block  204 B may include a number of object&#39;s bytes equal to the remaining unused portion on page  202 B. Data block  204 C may include the remaining number of object&#39;s bytes so long as the remaining number does not exceed the next page  202 C&#39;s capacity. 
     At  408 , database  102  stores the first data block and/or the second data block of the object on a first page or a second page. 
     At  410 , database  102  determines the location of the object&#39;s first data block  204 A-C stored on the first page  202 A-C. The location can be a page number and an offset of the first data block on the pace. Accordingly, the offset can be the first byte on the page for which the first data block starts. 
     At  412 , database  102  sends a logical pointer corresponding to the location of the object&#39;s first data block for loading the first object to the user. Thus, the user can use the logical pointer to access the object at a later time. 
     Referring to  FIG.  5   , method  500  shall be described with reference to  FIGS.  1  and  2   . However, method  500  is not limited to those example embodiments. 
     At  502 , database  102  receives a request to load an object stored on a first and/or second page  202 A-D. As described above, in some embodiments, an object may be stored on a single page  202 A. In some embodiments, an object may be stored on multiple pages  202 A-D. Accordingly, in some embodiments, a user may be unaware of the object being stored on a single page  202 A or multiple pages  202 A-D. 
     At  504 , database  102  identifies a location of the first data block of an object. As stated above, the request can include a pointer  122 A-C corresponding to a location of the object&#39;s first block  202 A-D in on-disk store  116 . As such, the location can be a page number and an offset of the first data block on the page. And, the offset can be the first byte on the page for which the first data block starts. 
     At  506 , database  102  determines that the object is located on a first and/or second page  202 A-D. As described above, with respect to  502 , the object can be stored entirely on a single page  202 A or on multiple pages  202 A-D. 
     At  508 , database  102  stores a first data block and/or a second data block on in-memory store  114  or in buffer  110 . In some embodiments, where the object is stored on a single page  202 A, database  102  retrieve the page  202 A from on-disk store  116  and stores the page in in-memory store  115 . Database can then send pointer  124 A-C and handle  126 A-C to the user. Pointer  124 A-C can provide a location in in-memory store  114  relating to the first objection. Handle  126  can ensure the is not flushed from in-memory store out during a period of time (e.g., while the user accesses or utilizes the object). In some embodiments, where the object is stored across multiple pages  202 A-D, each data block  204 A-D is copied and stored in buffer  110 . Database  102  then provides users access to data stored on in buffer  110 . 
     Various embodiments can be implemented, for example, using one or more well-known computer systems, such as computer system  600  of  FIG.  6   . One or more computer systems  600  can be used, for example, to implement any of the embodiments discussed herein, as well as combinations and sub-combinations thereof. 
     Computer system  600  can include one or more processors (also called central processing units, or CPUs), such as a processor  604 . Processor  604  can be connected to a communication infrastructure or bus  606 . 
     Computer system  600  can also include user input/output device(s)  603 , such as monitors, keyboards, pointing devices, etc., which can communicate with communication infrastructure  606  through user input/output interface(s)  602 . 
     One or more processors  604  can be a graphics processing unit (GPU). In an embodiment, a GPU can be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU can have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc. 
     Computer system  600  can also include a main or primary memory  608 , such as random access memory (RAM). Main memory  608  can include one or more levels of cache. Main memory  608  can have stored therein control logic (i.e., computer software) and/or data. 
     Computer system  600  can also include one or more secondary storage devices or memory  610 . Secondary memory  610  can include, for example, a hard disk drive  612  and/or a removable storage device or drive  614 . Removable storage drive  614  can be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive. 
     Removable storage drive  614  can interact with a removable storage unit  618 . Removable storage unit  618  can include a computer-usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit  618  can be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Removable storage drive  614  can read from and/or write to removable storage unit  618 . 
     Secondary memory  610  can include other means, devices, components, instrumentalities, or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system  600 . Such means, devices, components, instrumentalities, or other approaches can include, for example, a removable storage unit  622  and an interface  620 . Examples of the removable storage unit  622  and the interface  620  can include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface. 
     Computer system  600  can further include a communication or network interface  624 . Communication interface  624  can enable computer system  600  to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number  628 ). For example, communication interface  624  can allow computer system  600  to communicate with external or remote devices  628  over communications path  626 , which can be wired and/or wireless (or a combination thereof), and which can include any combination of LANs, WANs, the Internet, etc. Control logic and/or data can be transmitted to and from computer system  600  via communication path  626 . 
     Computer system  600  can also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smartphone, smartwatch or other wearables, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof. 
     Computer system  600  can be a client or database, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms. 
     Any applicable data structures, file formats, and schemas in computer system  600  can be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats, or schemas can be used, either exclusively or in combination with known or open standards. 
     In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon can also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system  600 , main memory  608 , secondary memory  610 , and removable storage units  618  and  622 , as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system  600 ), can cause such data processing devices to operate as described herein. 
     Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use embodiments of this disclosure using data processing devices, computer systems and/or computer architectures other than that shown in  FIG.  6   . In particular, embodiments can operate with software, hardware, and/or operating system implementations other than those described herein. 
     It is to be appreciated that the Detailed Description section, and not any other section, is intended to be used to interpret the claims. Other sections can set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit this disclosure or the appended claims in any way. 
     While this disclosure describes exemplary embodiments for exemplary fields and applications, it should be understood that the disclosure is not limited thereto. Other embodiments and modifications thereto are possible and are within the scope and spirit of this disclosure. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein. 
     Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments can perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein. 
     References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described can include a particular feature, structure, or characteristic, but every embodiment can not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein. Additionally, some embodiments can be described using the expression “coupled” and “connected” along with their derivatives. These terms are not necessarily intended as synonyms for each other. For example, some embodiments can be described using the terms “connected” and/or “coupled” to indicate that two or more elements are in direct physical or electrical contact with each other. The term “coupled,” however, can also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other. 
     The breadth and scope of this disclosure should not be limited by any of the above-described exemplary embodiments but should be defined only in accordance with the following claims and their equivalents.