DEPENDENCY MANAGER FOR DATABASES
The present disclosure relates to in-memory databases or search engines using a dependency manager or configuration manager for maintaining configuration in the database system. The system may include a supervisor that may request and receive data from dependency manager, where the supervisor may be linked to other components in the system. The dependency manager may be used as a container for data metadata, and software components, which may be used in the system configuration. The configuration may be developed through a dependency system, where the dependency manager may keep an entire dependency tree for all software and data in the system. Similarly, dependency manager may create a deployable package to guarantee deployment integrity and to ensure a successful execution of any suitable software and data in the system.
This patent application is a continuation of U.S. Non-Provisional application Ser. No. 14/558,009, filed on Dec. 2, 2014, which claims a benefit of priority to U.S. Provisional Application 61/910,860, filed on Dec. 2, 2013, which are hereby fully incorporated by reference in their entirety.
This application is related to U.S. patent application Ser. No. 14/557,794, entitled “Method for Disambiguating Features in Unstructured Text,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/558,300, entitled “Event Detection Through Text Analysis Using Trained Event Template Models,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/557,807, entitled “Method for Facet Searching and Search Suggestions,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/558,254, entitled “Design and Implementation of Clustered In-Memory Database,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/557,827, entitled “Real-Time Distributed In Memory Search Architecture,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/557,951, entitled “Fault Tolerant Architecture for Distributed Computing Systems,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/558,055, entitled “Pluggable Architecture for Embedding Analytics in Clustered In-Memory Databases,” filed Dec. 2, 2014; U.S. patent application Ser. No. 14/558,101, entitled “Non-Exclusionary Search Within In-Memory Databases,” filed Dec. 2, 2014; and U.S. patent application Ser. No. 14/557,900, entitled “Data record compression with progressive and/or selective decompression,” filed Dec. 2, 2014; each of which are incorporated herein by reference in their entirety.
TECHNICAL FIELDThe present disclosure relates in general to databases, and more particularly, to a dependency manager that may be used for in-memory databases.
BACKGROUNDPackage management systems may be designed to save organizations time and money through remote administration and software distribution technology that may eliminate the need for manual installation and updates for any suitable component, such as, software, operating system component, application program, support library, application data, general documentation, and other data, from a system or process. One conventional approach in the art related to package management system may be the Red Hat package manager (RPM). Package managers may present a uniform way to install and/or update software programs and associated components.
To install a set of software or data packages, a package manager may order the packages and its dependent packages in topological order onto a graph. Subsequently, the package manager may collect the packages at the bottom of the graph and install these packages first. Finally, the package manager may move up the graph and install the next set of packages.
However, the conventional approach in the art related to database management systems refers that some package managers may only keep the software configuration in the system, but may not support metadata or primary data collection dependencies. In a database, particularly an in-memory database or other distributed storage architectures, deployment focuses as much on data as software, and therefore maintaining dependency trees required for data deployment are essential.
Conventional technologies may automate deployment, installation, and configuration of software components and associated dependencies, across a cluster of one or more computers in a convectional distributed computing architectures. What is needed is a solution to automate the deployment, installation, and configuration of data, metadata and software of a primary datastore of a distributed database, in a distributed computing architecture, such as in-memory databases and other distributed data platforms. Moreover, because conventional solutions focus on deploying a static set of services and data, conventional systems lack the ability to detect service or data failures and then automatically recover from those failures by moving a package of data, metadata and software to other available nodes in the distributed system.
For the aforementioned reasons, there is a need for an improved package management application to guarantee/keep a successful execution of the system configuration and dependencies into a data management system.
SUMMARYDisclosed herein are systems and methods for handling dependencies during the process of installing, upgrading, and configuring different software, data or metadata packages for any suitable database or search engine. The systems and methods may automate processes for deploying, installing, and configuring various data, metadata, and software stored in a primary datastore of the distributed-computing system, such as a distributed system hosting an in-memory database, or other types of distributed data platforms. Exemplary embodiments may describe systems and methods in which a dependency manager (configuration management) may be linked directly to a supervisor (systems management), where supervisor may maintain the system in a fully functional manner, and may accept configuration requests to make changes in the system.
In one embodiment, a computer-implemented method comprises transmitting, by a computer of a distributed computing system, a request for a machine-readable deployable-package file associated with a target node of the system to a dependency manager node comprising a non-transitory machine-readable storage medium storing one or more deployable package files associated respectively with one or more nodes of the system according to dependency tree; transmitting, by the computer, the deployable package file to the target node in response to receiving the deployable package file from the dependency node, wherein the deployable package file associated with the target node contains a set of one or more dependency files based on the dependency tree; and instructing, by the computer, the target node to install the set of dependencies in the deployable package onto the target node.
In another embodiment, a computer-implemented method comprises determining, by a computer, a set of one or more dependency files to be installed onto a target node using a dependency tree associated with the target node responsive to receiving a request to configure the target node from a supervisor node; fetching, by the computer, each of the dependency files of the set of one or more dependency files from at least one dataframe comprising non-transitory machine-readable storage medium storing one or more dependency files; generating, by the computer, a deployable package file comprising the set of one or more dependency files; and transmitting, by the computer, the deployable package file to the supervisor node.
In another embodiment, a database management system comprises one or more nodes comprising a non-transitory machine-readable storage memory storing one or more dependency files, and a processor monitoring a status of the one or more dependency files, wherein each respective dependency file is a component of the node having a comparative relationship with a corresponding component installed on a second node; one or more supervisor nodes comprising a processor monitoring a status for each of the one or more nodes and configured to transmit a deployable package comprising a set of dependencies files to each of the nodes based on the status of each respective node; and one or more dependency manager nodes comprising a non-transitory machine-readable storage medium storing one or more dependency tree files associated with the one or more nodes, and a processor configured to compile a deployable package file in accordance with a dependency tree associated with a node, wherein the deployable package file comprises a set of one or more dependencies files stored on at least one data frame, and wherein the dependency manager node determines a dependency to include in the deployable package based on a dependency tree associated with a node targeted to receive the deployable package.
Numerous other aspects, features of the present disclosure may be made apparent from the following detailed description. Additional features and advantages of an embodiment will be set forth in the description which follows, and in part will be apparent from the description. The objectives and other advantages of the invention will be realized and attained by the structure particularly pointed out in the exemplary embodiments in the written description and claims hereof as well as the appended drawings.
The present disclosure can be better understood by referring to the following figures. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the disclosure. In the figures, reference numerals designate corresponding parts throughout the different views.
As used here, the following terms may have the following definitions:
“Dependency Tree” refers to a type of data structure, which may show the relationship of partitions, modules, files, or data, among others.
“Deployable Package” refers to a set of information, which may be used in the configuration of modules, partitions, files, or data, among others.
“Node” refers to a computer hardware configuration suitable for running one or more modules.
“Cluster” refers to a set of one or more nodes.
“Module” refers to a computer software component suitable for carrying out one or more defined tasks.
“Partition” refers to an arbitrarily delimited portion of records of a collection.
“Collection” refers to a discrete set of records.
“Record” refers to one or more pieces of information that may be handled as a unit.
“Node Manager” refers to a module configured to at least perform one or more commands on a node and communicate with one or more supervisors.
“Heartbeat” refers to a signal communicating at least one or more statuses to one or more supervisors.
“Supervisor” refers to a configuration/monitoring module that may create and execute plans for change in response to changes one or more statuses or to external requests for change.
“Database” refers to any system including any combination of clusters and modules suitable for storing one or more collections and suitable to process one or more queries.
“Dependency Manager” refers to a module configured to at least include one or more dependency trees associated with one or more modules, partitions, or suitable combinations, in a system; to at least receive a request for information relating to any one or more suitable portions of said one or more dependency trees; and to at least return one or more configurations derived from said portions.
DETAILED DESCRIPTIONThe present disclosure is here described in detail with reference to embodiments illustrated in the drawings, which form a part here. Other embodiments may be used and/or other changes may be made without departing from the spirit or scope of the present disclosure. The illustrative embodiments described in the detailed description are not meant to be limiting of the subject matter presented here.
Conventional solutions focus on deploying a fairly static set of services, and so conventional solutions typically lack the functionality required to detect failures of system components and then automatically recover by moving a package of data, metadata, and/or software, to other available nodes in the distributed system.
According to one embodiment, a dependency manager may be used as a container for the maintenance or configuration of any suitable software or data component in the system. Those configurations may be driven by new data, metadata or software updates in a release process.
In another embodiment, dependency manager may include a dependency tree for releasing a releasable file, such as releases of data, metadata, or software, or any other component of the system, to the system. The releasable file may require a configuration for dependencies that may be directly linked or wrapped around another component that is being configured, and so additional components or configuration may be required. Similarly, the dependency manager may keep a system-level dependency tree for all of the software and data components released into the system.
In a further embodiment, if any suitable software or data component is released in a dependency tree, dependency manager may create a deployable package to guarantee deployment integrity. That is, the deployment integrity may ensure a successful execution of any suitable software or data component, providing a desired result.
Reference will now be made to the exemplary embodiments illustrated in the drawings, and specific language will be used here to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Alterations and further modifications of the inventive features illustrated here, and additional applications of the principles of the inventions as illustrated here, which would occur to one skilled in the relevant art and having possession of this disclosure, are to be considered within the scope of the invention.
According to one embodiment, the dependency manager 104 may be used as a non-transitory machine-readable storage medium containing the maintenance or configuration of any suitable software or data component in the system. Those configurations may be driven by new data, metadata or software updates in a release process.
The dependency manager 104 may play a role in configurations required by some processes in the system. That is, dependency manager 104 may be directly connected with supervisor 102 in order to provide the suitable dependencies, otherwise referred to as “packages,” “configurations,” “components,” and/or “files,” for the partitions, which may be used to update any suitable collection. Furthermore, supervisor 102 may be linked to one or more dependency managers 104 and may additionally be linked to one or more other supervisors 102, where additional supervisors 102 may be linked to other components in the system.
According to another embodiment, the configuration process or maintenance process may include the information regarding what dependencies a module may have and needs to be deployed along with the module. The required files may be fetched from a separate non-transitory machine-readable storage, or “data frame.” In some embodiments, this data frame may be external from the system architecture; for example, in the case of third-party vendor providing software updates. The dependencies in a suitable deployable package may include different types of files, data, or software that are directly linked or wrapped around the module or the partition that is being configured. The configuration process may include different steps step 202, 204, 206, 208, 210, and 212. The configuration process 200 may begin in response to requests requiring the system to install or update, data or software components.
In a first step 202, processors of the system may automatically detect a situation that may trigger the configuration process 200 sequence/steps.
In some embodiments, in step 202, a node of the system executing a supervisor module may poll components of the system, such as node manager software modules, responsible for reporting a health update, or “status,” to the supervisor. In such embodiments, the supervisor may automatically detect failures throughout the system based on a lack of a heartbeat (HB) signal the supervisor expects to receive from any system module, as defined by the system configuration. The supervisor may then trigger configuration process 200, among other remedial processes, in response to detecting the missing HB signal.
In some embodiments, in step 202, a node of the system executing a supervisor module may trigger configuration process 200 when the supervisor receives an external request for one or more changes in the system configuration, such as updates to a component or migration to new node hardware.
In step 204, the supervisor may send a request to the dependency manager to retrieve one or more deployment packages associated with one or more modules that are to be installed on the node. A deployment package defines each of the files and/or other materials required to satisfy the node configuration according to the dependency manager. The deployable package may contain all required dependencies, including source and destination information necessary for proper deployment and may contain module properties needed to configure or start the module. A particular dependency may have its own dependencies, also defined in the dependency manager, and therefore may be referred to as a dependency tree.
In step 206, the supervisor may transmit instructions to the dependency manager to fetch the required deployment packages from a data frame storing the deployment package. The data frame may be any non-transitory machine-readable storage media, which may be located on any suitable computing device communicatively coupled to a node executing the dependency manager. In some cases, when a deployment package is generated, the deployment package contains all dependencies for the module being transmitted, as well as the source and destination information needed to properly deploy the deployment package. The deployment package may also include one or more module properties needed to configure or start the deployment package. Deployment packages may be generated through automated or manual processes. In manual example, a system administrator may identify and/or create a deployment package with the requisite files and data. In an automated example, the supervisor or dependency manager may automatically identify and/or generate the deployment package using the automatically identified files, which is usually accomplished through a test script generated by the dependency manager, thereby yielding installation speeds and distribution rates higher than could be done by a human.
In step 208, after the dependency manager receives the deployment packages from the data frame, the dependency manager may transmit the deployable package to the node executing the supervisor that requested the deployment packages.
In step 210, the supervisor may send the deployable package to the node manager of the node requiring the configuration.
In step 212, the node manager may copy files, install, and/or execute the deployable package received from the supervisor, thereby implementing the requisite maintenance, update, or configuration for the system.
A dependency tree 310 may include different types of files that may be directly linked or wrapped around a module or partition such that a dependency may be the degree to which each member of a partition relies on each one of the other members in the partition. For instance, dependency tree 310 may include partition 1, which may depend on phonetic 1.0 and compression 1.0; subsequently, phonetic 1.0 may depend on software libraries (such as, processing DLL 1.0 and Input DLL 1.0), and compression 1.0 may depend on data-table 1.0 and so on.
The dependency manager 302 may store a dependency tree 310 associated with any releasable file of the system. In a further embodiment, if any suitable software or data component is released to components indicated within the dependency tree 310, the dependency manager 302 may create a deployable package from one or more files stored on a data frame.
Supervisor 304 may be linked to one or more dependency managers 302 including one or more dependency trees 310 for one or more modules, partitions, or suitable combinations thereof. Supervisor 304 may additionally be linked to one or more supervisor 304, where additional supervisors 304 may be linked to other components in the system.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the steps in the foregoing embodiments may be performed in any order. Words such as “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Although process flow diagrams may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.
The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description herein.
When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.
The supervisor maintains the definition and configuration of all data collections in the system, which may include settings per collection that indicate how many redundant copies of each partition are desired, how many times to try to restart failed components before moving them to another node, etc. The supervisor also maintains a list of available nodes and their resources, as provided by the node managers. From that information, the supervisor computes a desired system state by mapping the needed system modules to available nodes, while still complying with configuration settings. Fault handling 400 begins with supervisor detecting a module failure 402, where one or more supervisors may detect failures of one or more modules by comparing the actual system state to a desired system state. In one or more embodiments, supervisors may detect failure when one or more heartbeats from node managers or system modules are no longer detected. In one or more other embodiments, heartbeats from one or more modules may include status information about one or more other modules that may be interpreted by the one or more supervisors.
A supervisor may store definitions of data collections and the configurations settings associated with the data collections. The supervisor may also store information about available system resources, as reported by node managers. The configuration information may include settings per collection that indicate how many redundant copies of each respective partition are desired, how many times to try to restart failed components before moving them to another node, among other. From all this information, the supervisor derives a ‘desired’ system state that maps the needed system modules to available nodes, while still complying with configuration settings. All this information is represented as JSON objects which may be stored as JSON files on disk, or in a predefined data collection within the IMDB.
The supervisor may then detect if the associated node manager is functioning 404.
If the node manager associated with the one or more failed modules is functioning as desired or according to a status quo configuration, then supervisor may send one or more commands to the node manager instructing the node manager to attempt to restart the one or more failed modules, in a step 406.
The supervisor may then check if module is restored 408, and if so the process may proceed to end 410. In some implementations, the first action of any module is to report a status via heartbeats to one or more available supervisors. If it is determined that module function is not restored, as indicated by heartbeats, the supervisor may determine if the restart threshold has been reached 412. The threshold number of attempts is a configuration setting per collection, which may be set by the system administrator and stored with the supervisor. The supervisor determines that a module has failed and should be restarted or moved to another node. The supervisor sends commands to the node manager. If the number of attempts has not been reached, the node manager attempts to restart module 406.
If the threshold has been reached, the supervisor determines the next suitable node to place the module 414 and the supervisor requests the node manager on the new node to stage all module dependencies and start the current module 416.
The supervisor may then check if module is restored 418, and if so the process may proceed to end 410. If the module is not restored, the system may check if the restart threshold for the new node has been reached 420. If the threshold has not been reached, the supervisor requests the node manager on the new node to stage and start the current module 416.
Otherwise, the supervisor may check if the global node retry threshold has been reached 422. This value is also defined by a system administrator and may be stored with the supervisor in a script, or as JSON or similar data structure object. If the threshold has not been reached, the supervisor determines the next suitable node to place the module 414 and attempts to restart the node on the new node. If the global threshold has been reached, the system may then raise an alarm indicating module failure 424.
If the supervisor detects that the associated node manager is not functioning based on the corresponding heartbeats, as indicated by a lack of heartbeats or heartbeats from the node manager indicating a failed state, the supervisor selects a module associated with the node with a failed node manager 426. Then, the supervisor determines the next suitable node to place the module 428. Afterwards, the supervisor requests the node manager on the new node to stage and start the current module 430.
The supervisor may then check if module is restored 432. If the module is not restored, supervisor checks if the restart threshold for the new node has been reached 434. If the threshold has not been reached, the supervisor requests the node manager on the new node to stage and start the current module 430.
If the threshold has been reached, the supervisor then checks if the global node retry threshold has been reached 436. If the threshold has not been reached, the supervisor determines the next suitable node to place the module 428 and attempts to restart the node on the new node. If the global threshold has been reached, the system may then raise an alarm indicating module failure 438.
Otherwise, if the module is restored, the supervisor then checks if there are more modules to be migrated off the failed node 440. If a node has failed, the supervisor is configured to migrate all of the services that had been running on the failed node 440, as defined in the desired state. The supervisor will calculate a new desired state without the failed node 440 and will need to migrate services accordingly. In some implementations, the supervisor may select a module associated with the node having a failed node manager 426 and the node manager attempts to stage and start the module.
If the supervisor determines no more modules are to be migrated, the process may end 410.
In one or more embodiments, a node may fail and a supervisor may determine, based on information from node manager heartbeats, that no nodes have available resources. In some implementations, the node managers report their available resources in each corresponding heartbeat. The supervisor may then attempt to make resources available in other nodes in the system while maintaining a desired redundancy. In one or more embodiments, resources may be made available by unloading a module or partition. The supervisor may then load the desired module or partition on the available resources.
Example #1 illustrates what happens if a single module fails due to some resource no longer available on the node but the node itself is not otherwise adversely affected.
In this case, when the module fails the heartbeat connections to the supervisor are dropped, thereby alerting the supervisor to the module failure. The supervisor will attempt to reconnect to the module to check if the failure was just a connection issue or a module failure. In some embodiments, failure to reconnect is assumed to be a module failure.
The supervisor will first request the associated node manager to restart the module in place. Starting the module in place does not incur the cost of re-staging the module and any corresponding software or data, so can be accomplished more quickly than staging and starting on another node. However, in this example the problem is due to some resource unavailability on the specified node, thus the restart will also fail.
After making a predetermined number of attempts to restart the module in place, the supervisor will look for another suitable node to start the module on. The supervisor will contact a dependency manager to acquire the correct package required to deploy the failed module. The supervisor will then pass that package on to the node manager for the newly selected node to stage and run the module. The module finds the required resources on the new node and creates a heartbeat connection to the supervisor indicating it is running properly. The supervisor marks the functionality as restored and the event is over.
Example #2 illustrates a total node fail such as a failed power supply. In this case the node manager and all modules on the server drop their heartbeat connections to the supervisor. The supervisor recognizes this as a complete node failure and marks that node as failed and unavailable. The supervisor then walks through the list of modules that were allocated to that node. For each module in that list the supervisor will look for another suitable node to start the module on. The supervisor will contact a dependency manager to acquire the correct package required to deploy the current module. The supervisor will then pass that package on to the node manager for the newly selected node to stage and run the module. The module executes and creates a heartbeat connection to the supervisor indicating it is running properly. The supervisor marks the functionality as restored for that module. This continues until all modules have been reallocated to new nodes and the event is over.
Claims
1. A method comprising:
- sending, by a first node, a first instruction to a second node, wherein the first instruction instructs the second node to retrieve a package file locally and then to send the package file to the first node upon retrieval, wherein the package file is associated with a third node based on a dependency tree before the second node receives the first instruction, wherein the package file contains a set of dependency files based on the dependency tree, wherein the first node, the second node, and the third node define a cluster hosting an in-memory database;
- in response to receiving the package file from the second node based on the first instruction, sending, by the first node, the package file and a second instruction to the third node, wherein the second instruction instructs the third node to install the set of dependency files from the package file locally.
2. The method of claim 1, wherein the first node sends the first instruction to the second node in response to the first node detecting a dependency failure on the third node based on the first node interpreting a heartbeat signal received from the third node.
3. The method of claim 2, further comprising:
- determining, by the first node, if the third node installed the set of dependency files from the package file successfully.
4. The method of claim 1, wherein the dependency tree is based on at least one of a partition, a module, a file, or a record, wherein the in-memory database comprises at least one of the partition, the module, the file, or the record.
5. The method of claim 1, wherein the second node fetches a dependency from a data frame and then compiles the package file.
6. The method of claim 1, wherein each of the dependency files is determined by the second node via the dependency tree associated with the third node.
7. The method of claim 6, wherein each of the dependency files is based on a comparative relationship of that dependency file with a corresponding dependency file installed on a subset of nodes in the cluster.
8. The method of claim 1, further comprising:
- receiving, by the first node, a third instruction from a server external to the cluster, wherein the server is associated with at least one of the dependency files installed on the third node based on the second instruction, wherein the third instruction instructs the third node to perform an update to the package file on the third node such that the at least one of the dependency files is updated via the server.
9. A system comprising:
- a first node;
- a second node; and
- a third node, wherein the first node, the second node, and the third node define a cluster hosting an in-memory database, wherein the first node is programmed to: send a first instruction to the second node, wherein the first instruction instructs the second node to retrieve a package file locally and then to send the package file to the first node upon retrieval, wherein the package file is associated with the third node based on a dependency tree before the second node receives the first instruction, wherein the package file contains a set of dependency files based on the dependency tree; send the package file and a second instruction to the third node in response to receiving the package file from the second node based on the first instruction, wherein the second instruction instructs the third node to install the set of dependency files from the package file locally.
10. The system of claim 9, wherein the first node is programmed to send the first instruction to the second node in response to the first node detecting a dependency failure on the third node based on the first node interpreting a heartbeat signal received from the third node.
11. The system of claim 10, wherein the first node is programmed to:
- determine if the third node locally installed the set of dependency files from the package file successfully.
12. The system of claim 9, wherein the dependency tree is based on at least one of a partition, a module, a file, or a record, wherein the in-memory database comprises at least one of the partition, the module, the file, or the record.
13. The system of claim 9, wherein the second node fetches a dependency from a data frame and then compiles the package file.
14. The system of claim 9, wherein each of the dependency files is determined by the second node via the dependency tree associated with the third node.
15. The system of claim 14, wherein each of the dependency files is based on a comparative relationship of that dependency file with a corresponding dependency file installed on a subset of nodes in the cluster.
16. The system of claim 15, wherein the first node is programmed to:
- receive a third instruction from a server external to the cluster, wherein the server is associated with at least one of the dependency files installed on the third node based on the second instruction, wherein the third instruction instructs the third node to perform an update to the package file on the third node such that the at least one of the dependency files is updated via the server.
Type: Application
Filed: Feb 17, 2016
Publication Date: Jun 9, 2016
Inventors: Scott LIGHTNER (Leesburg, VA), Franz WECKESSER (Spring Valley, OH)
Application Number: 15/045,919
