US20160364471A1 - Design and implementation of clustered in-memory database - Google Patents

Design and implementation of clustered in-memory database Download PDF

Info

Publication number
US20160364471A1
US20160364471A1 US15/243,450 US201615243450A US2016364471A1 US 20160364471 A1 US20160364471 A1 US 20160364471A1 US 201615243450 A US201615243450 A US 201615243450A US 2016364471 A1 US2016364471 A1 US 2016364471A1
Authority
US
United States
Prior art keywords
node
search
records
partition
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US15/243,450
Inventor
Scott Lightner
Franz Weckesser
Telford Berkey
Joseph Becknell
Bryan Zimmerman
Mats Persson
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qbase LLC
Original Assignee
Qbase LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qbase LLC filed Critical Qbase LLC
Priority to US15/243,450 priority Critical patent/US20160364471A1/en
Publication of US20160364471A1 publication Critical patent/US20160364471A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28Databases characterised by their database models, e.g. relational or object models
    • G06F16/284Relational databases
    • G06F16/285Clustering or classification
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/235Update request formulation
    • G06F17/30598
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/16File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164File meta data generation
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24Querying
    • G06F16/245Query processing
    • G06F16/2458Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471Distributed queries
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278Data partitioning, e.g. horizontal or vertical partitioning
    • G06F17/30091
    • G06F17/3012

Definitions

  • the present disclosure relates in general to databases, and more specifically to in-memory databases.
  • a database is an organized collection of information stored as “records” having “fields” of information (e.g., a restaurant database may have a record for each restaurant in a region, where each record contains fields describing characteristics of the restaurant, such as name, address, type of cuisine, and the like).
  • databases In operation, a database management system frequently needs to retrieve data from or persist data to storage devices such as disks. Unfortunately, access to such storage devices can be somewhat slow.
  • databases typically employ a “cache” or “buffer cache” which is a section of relatively faster memory (e.g., random access memory (RAM)) allocated to store recently used data objects.
  • Memory is typically provided on semiconductor or other electrical storage media and is coupled to a CPU (central processing unit) via a fast data bus which enables data maintained in memory to be accessed more rapidly than data stored on disks.
  • a system architecture hosting an in-memory database which may include any suitable combination of computing devices and software modules for storing, manipulating, and retrieving data records of the in-memory database that is hosted within the distributed computing architecture of the system.
  • Software modules executed by computing hardware of the system may include a system interface, a search manager, an analytics agent, a search conductor, a partitioner, collections of data, a supervisor, a dependency manager; any suitable combination of these software modules may be found in the system architecture hosting the in-memory database.
  • Nodes executing software modules may compress data stored in the records to make in-memory storage, queries, and retrieval feasible for massive data sets. Compression and decompression may be performed at nearly any level of the database (e.g., database level, collection level, record level, field level).
  • Nodes executing software modules may provide support for storing complex data structures, such as JavaScript Object Notation (JSON) in the distributed in-memory database.
  • JSON JavaScript Object Notation
  • Embodiments of an in-memory database system may be fault-tolerant due to the distributed architecture of system components and the various hardware and software modules of the system that are capable of monitoring and restoring faulty services. Fault-tolerance may include system component redundancy, and automated recovery procedures for system components, among other techniques.
  • the in memory database may effectively and efficiently query data by scoring data using scoring methods. Search results may be ranked according to the scoring methods used to score the data, thereby allowing users and/or nodes executing queries to utilize data in ways that are more tailored and contextually relevant from one query to the next. Nodes executing analytics agents may perform various advanced analytics on records stored in the in-memory database image of data. In some cases, analytics may be performed on the records retrieved with a set of search query results by search conductors.
  • a computing system hosting an in-memory database comprising: a partitioner node comprising a processor configured to, in response to receiving a collection of one or more records of a database, determine whether to compress the collection based on a machine-readable schema file associated with the collection, logically partition the collection into one or more partitions according to the schema file, and distribute the one or more partitions to one or more storage nodes according to the schema file; a storage node comprising non-transitory machine-readable main memory storing a partition received from the partitioner associated with the storage node; a search manager node comprising a processor receiving a search query from a client device of the system, and transmitting the search queries as search conductor queries to one or more search conductors in response to receive the search query from the client device, wherein the search query is a machine-readable computer file containing parameters associated with one or more records satisfying the search query; a search conductor node associated with one or more partitioners and comprising a processor configured to, in response to receiving a collection of
  • a computer implemented method comprises receiving, by a search manager computer of a system hosting an in-memory database, binary data representing a search query containing parameters querying the database, wherein the system comprises one or more storage nodes comprising main memory storing one or more collections of the database, wherein each collection contains one or more records, transmitting, by the computer, the search query to one or more search conductor nodes according to the search query, wherein the search query indicates a set of one or more collections to be queried; transmitting, by the computer, to one or more analytics agent nodes a set of search results based on the search query responsive to receiving from the one or more search conductors the set of search results containing one or more records satisfying the search query, wherein each respective record of the set of search results is associated with a score based on a scoring algorithm in the search query; and responsive to the computer receiving a computer file containing a set of one or more data linkages from the one or more analytics agent nodes: updating, by the computer, the one or more records of the set
  • a computer-implemented method comprises receiving, by a computer, one or more collections from a search conductor according to a schema file, wherein each of the collections comprises a set of one or more records having one or more fields; partitioning, by the computer, each collection according to the schema; compressing, by the computer, the records in the partition according to the schema; and distributing, by the computer, each of the partitions to one or more associated search conductors to include each of the partitions in each collection corresponding to the partitioner associated with the search conductor.
  • FIG. 1 shows an in-memory database architecture according to an exemplary embodiment.
  • FIG. 2 shows a node configuration according to an exemplary embodiment.
  • FIG. 3 is a flow chart for setting up a node according to an exemplary embodiment.
  • FIG. 4 is a flow chart depicting module set up in a node according to an exemplary embodiment.
  • FIG. 5 is a flow chart describing the function of a search manager according to an exemplary embodiment.
  • FIG. 6 is a flow chart describing the function of a search conductor according to an exemplary embodiment.
  • FIG. 7 is a flow chart describing the function of a partitioner according to an exemplary embodiment.
  • FIG. 8 is a flow chart describing a process of setting up a partition in a search conductor according to an exemplary embodiment.
  • FIG. 9A shows a collection, its updated version, and their associated partitions according to an exemplary embodiment.
  • FIG. 9B shows a first and second search node including a first collection connected to a search manager according to an exemplary embodiment.
  • FIG. 9C shows a first search node including a first collection disconnected from a search manager and a second search node including a first collection connected to a search manager according to an exemplary embodiment.
  • FIG. 9D shows a first search node loading an updated collection, and a second search node connected to a search manager according to an exemplary embodiment.
  • FIG. 9E shows a first search node including an updated collection connected to a search manager, and a second search node including a first collection disconnected from a search manager according to an exemplary embodiment.
  • FIG. 9F shows a second search node loading an updated collection, and a first search node connected to a search manager according to an exemplary embodiment.
  • FIG. 9G shows a first and second search node including an updated collection connected to a search manager according to an exemplary embodiment.
  • FIG. 10 shows a cluster of search nodes including partitions for two collections according to an exemplary embodiment.
  • 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.
  • Selection refers to a discrete set of records.
  • Record refers to one or more pieces of information that may be handled as a unit.
  • Field refers to one data element within a record.
  • Partition refers to an arbitrarily delimited portion of records of a collection.
  • Scheme refers to data describing one or more characteristics of one or more records.
  • Search Manager refers to a module configured to at least receive one or more queries and return one or more search results.
  • Analytics Agent refers to a module configured to at least receive one or more records, process said one or more records, and return the resulting one or more processed records.
  • Search Conductor refers to a module configured to at least run one or more queries on a partition and return the search results to one or more search managers.
  • 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.
  • Supervisor refers to a module configured to at least communicate with one or more components of a system and determine one or more statuses.
  • Heartbeat refers to a signal communicating at least one or more statuses to one or more supervisors.
  • Partitioner refers to a module configured to at least divide one or more collections into one or more partitions.
  • 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.
  • 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.
  • Query refers to a request to retrieve information from one or more suitable partitions or databases.
  • Memory refers to any hardware component suitable for storing information and retrieving said information at a sufficiently high speed.
  • “Fragment” refers to separating records into smaller records until a desired level of granularity is achieved.
  • Exemplary embodiments describe an in-memory database including one or more clusters and one or more modules, where suitable modules may include one or more of a search manager, an analytics agent, a node manager, a search conductor, a supervisor, a dependency manager, and/or a partitioner.
  • An in-memory database is a database storing data in records controlled by a database management system (DBMS) configured to store data records in a device's main memory, as opposed to conventional databases and DBMS modules that store data in “disk” memory.
  • DBMS database management system
  • Conventional disk storage requires processors (CPUs) to execute read and write commands to a device's hard disk, thus requiring CPUs to execute instructions to locate (i.e., seek) and retrieve the memory location for the data, before performing some type of operation with the data at that memory location.
  • In-memory database systems access data that is placed into main memory, and then addressed accordingly, thereby mitigating the number of instructions performed by the CPUs and eliminating the seek time associated with CPUs seeking data on hard disk.
  • In-memory databases may be implemented in a distributed computing architecture, which may be a computing system comprising one or more nodes configured to aggregate the nodes' respective resources (e.g., memory, disks, processors).
  • a computing system hosting an in-memory database may distribute and store data records of the database among one or more nodes.
  • these nodes are formed into “clusters” of nodes.
  • these clusters of nodes store portions, or “collections,” of database information.
  • a system interface may feed one or more search queries to one or more search managers.
  • the search managers may be linked to one or more analytics agents that perform certain analytic techniques depending upon the embodiment and return the results to a search manager.
  • the search managers may be linked to one or more search conductors.
  • the search conductors may service search queries and database updates to one or more data partitions.
  • one or more nodes comprising a partitioner store one or more partitions of one or more database collections.
  • a partition of a collection stores one or more records of the collection that have been partitioned into the particular partition.
  • the one or more nodes storing each of the partitions of a collection are storing records of the in-memory database.
  • An in-memory database may be an organized collection of information stored as “records” having “fields” of information.
  • a restaurant database may have a record for each restaurant in a region, and each record contains a different field for describing each of the characteristics of the restaurant, such as name, address, type of cuisine, and the like.
  • An embodiment of an in-memory database may use clusters of one or more nodes to store and access data; larger amounts of data may require larger amounts of non-transitory, machine-readable storage space. Compression reduces the amount of storage space required to host the information.
  • one or more collections may be described using any suitable schema that defines the compression technique used for one or more fields of the one or more records of the one or more collections.
  • one or more fields may be compressed by a partitioner using one or more techniques suitable for compressing the type of data stored in a field.
  • the type of data stored in a field may be compressed after fragmentation in which records in a collection are separated into smaller records until a desired data granularity is achieved.
  • fragmented record indices may be used to identify which record the fields were fragmented from to ensure the system remains aware that the records originate from the same original record of the collection.
  • Fragmented records may be compressed further by according to one or more fragmenting algorithms.
  • one or more collections may be indexed and/or compressed by one or more partitioner modules, which may be associated with one or more search conductor modules of an in-memory database system.
  • one or more compression techniques facilitate data compression while allowing data to be decompressed and/or accessed at any level of the in-memory database, including the field level, the record level, or the collection level.
  • FIG. 1 shows system architecture 100 having system interface 102 , first search manager 110 , nth search manager 112 , first analytics agent 120 , nth analytics agent 122 , first search conductor 130 , nth search conductor 132 , partition data 140 , partitioner 150 , first collection 160 , nth collection 162 , supervisor 170 , and dependency manager 180 .
  • system interface 102 may feed one or more queries generated outside system architecture 100 to one or more search managers 110 , 112 in a first cluster including at least one node including a first search manager 110 and up to n nodes including an nth search manager 112 .
  • the one or more search managers 110 , 112 in said first cluster may be linked to one or more analytics agents 120 , 122 in a second cluster including at least a first analytics agent 120 and up to nth analytics agent 122 .
  • Search managers 110 , 112 in the first cluster may be linked to one or more search conductors 130 , 132 in a third cluster.
  • the third cluster may include at least a first search conductor 130 and up to an nth search conductor 132 .
  • Each search node i.e., node executing search manager 110 , 112
  • Partition data 140 may include one or more partitions (i.e., arbitrarily delimited portions of records partitioned from a discrete set of records) generated by a node executing one or more partitioners 150 , which may be a module configured to at least divide one or more collections into one or more partitions.
  • partitioners 150 may be a module configured to at least divide one or more collections into one or more partitions.
  • Each of the partitions may correspond to at least a first collection 160 and up to nth collection 162 .
  • the collections 160 , 162 may additionally be described by one or more schemata files, which may define the data in the collections 160 , 162 .
  • the one or more schemata may include information about the name of the fields in records of the partitions, whether said fields are indexed, what compression method was used, and what scoring algorithm is the default for the fields, amongst others.
  • the schemata may be used by partitioners 150 when partitioning the first collection 160 and up to nth collection 162 , and may be additionally be used by the first search manager 110 and up nth search manager 112 when executing one or more queries on the collections.
  • One or more nodes may execute a supervisor 170 software module that receives a heartbeat signal transmitted from other nodes of the system 100 .
  • a supervisor 170 may be configured to receive data from nodes of the system 100 that execute one or more dependency manager 180 software modules.
  • a dependency manager 180 node may store, update, and reference dependency trees associated with one or more modules, partitions, or suitable combinations thereof, which may indicate configuration dependencies for nodes, modules, and partitions, based on relative relationships.
  • a supervisor 170 may additionally be linked to other nodes in the system 100 executing one or more other supervisors 170 . In some cases, links to additional supervisors 170 may cross between clusters of the system architecture 100 .
  • Nodes executing an analytics agent 120 , 122 may execute one or more suitable analytics modules, which conform to a specified application programming interface (API) that facilitates interoperability and data transfer between the components of the system (e.g., software modules, nodes).
  • Analytics agents 120 , 122 may be configured to process aggregated query results returned from search conductors 130 , 132 .
  • a search manager 110 may receive a search query and then generate search conductor queries, which the search manager 110 issues to one or more search conductors 130 , 132 . After the search conductors 130 , 132 execute their respectively assigned search conductor queries, the search manager 110 will receive a set of aggregated query results from the one or more search conductors 130 , 132 . The search manager 110 may forward these search query results to an analytics agent 120 for further processing, if further processing is required by the parameters of the search query.
  • API application programming interface
  • the search manager 110 may transmit a database schema file and/or one or more analytical parameters to the analytics agents 120 , 122 .
  • the search query may request particular analytics algorithms to be performed, which the search manager 110 may use to identify which analytics agent 120 should receive aggregated search results.
  • one or more of the sets of aggregated results may be transmitted to the analytics agents 120 , 122 in the form of compressed records, which contain data compressed according to a compression algorithm.
  • data of the records may be compressed at the fields of the records; and in some cases, full records may be compressed.
  • Nodes executing analytics agents 120 , 122 having various analytics modules may include: disambiguation modules, linking modules, and link on-the-fly modules, among other suitable modules and algorithms.
  • linking modules and link-on-the-fly modules may identify, generate, and/or store metadata that links data previously stored in records of the database.
  • Suitable modules may include any software implementation of analytical methods for processing any kind of data.
  • particular analytics modules or analytics agents 120 , 122 may be accessible only to predetermined instances, clusters, partitions, or/or instantiated objects of an in-memory database.
  • an application programming interface may be used to create a plurality of analytics modules, and the disclosed system architecture may allow the addition of multiple customized analytics modules executed by analytics agents of the system, which may be added to the system architecture, without interrupting operation or services, which may support dynamic processing of constant streams of data.
  • API application programming interface
  • Newly created analytics modules may be easily plugged into the database using simple module set up processes and may enable the application in real time to apply one or more analytical methods to aggregated results lists, without having to change how the data is managed, prepared and stored.
  • Separate APIs may be constructed to support models which score records against queries, typically a search conductor function, or to perform closure or other aggregate analytical function on a record set, typically an analytics agent task.
  • FIG. 2 is a diagram showing a configuration of a node 200 , according to an exemplary embodiment.
  • the node 200 in FIG. 2 may comprise a processor executing a node manager 202 software module and any number of additional software modules 210 , 212 , which may include a first software module 210 and up to nth module 212 .
  • the node 200 may be communicatively coupled over a data network to a second node executing a supervisor module, or supervisor node.
  • a node manager 202 be installed and executed by the node 200 may also configured to communicate with the supervisor node, and may also be configured to monitor a software modules 210 , 212 installed on the node, including a first module 210 , up to nth module 212 .
  • Node manager 202 may execute any suitable commands received from the supervisor, and may additionally report on the status of one or more of the node 200 , node manager 202 , and from the first module 210 to the nth module 212 .
  • the first module 210 may be linked to the one or more supervisors and may be linked to one or more other modules in the node, where other modules in the node may be of a type differing from that of first module 210 or may share a type with first module 210 . Additionally, first module 210 may be linked with one or more other modules, nodes, or clusters in the system.
  • FIG. 3 is a flowchart depicting node set-up 300 having steps 302 , 304 , and 306 .
  • an operating system (OS) suitable for use on a node is loaded to the node.
  • the OS may be loaded automatically by the node's manufacturer. In one or more other embodiments, the OS may be loaded on the node by one or more operators.
  • a node manager suitable for use with the OS loaded on the node is installed manually by one or more operators, where the installation may determine which one or more desired modules additional to node manager will be installed on the node.
  • the node manager sends a heartbeat to a supervisor, where said heartbeat may include information sufficient for the supervisor to determine that the node is ready to receive instructions to install one or more modules.
  • FIG. 4 is a flow chart depicting module set-up 400 having steps 402 , 404 , 406 , 408 , 410 , 412 , and 414 .
  • the supervisor determines one or more modules are to be installed on one or more nodes, based on the needs of the data collections defined for the system.
  • a supervisor then sends the installation preparation instruction to one or more node managers on said one or more nodes.
  • the supervisor may track the data collections (including data shards, or portions of data) and the configuration settings associated with the respective collections.
  • the supervisor may also be aware of all available nodes and their resources (as reported by Node Managers).
  • the supervisor may map (i.e., correlate) the system needs to available node resources to determine which data shards or portions, and which system services or resources, should be running on each respective node.
  • the supervisor may then sends deploy/install requests, including any dependencies defined, to the appropriate Node Managers to instruct the node managers to execute the installation on the client-side.
  • the node manager allocates the node's resources, such as computer memory, disk storage and/or a portion of CPU capacity, for running the one or more desired modules.
  • the allocation of resources may expire after a period of time should the supervisor discontinue the process.
  • Non-limiting examples of resources can include computer memory, disk storage and/or a portion of CPU capacity.
  • the resources required may be determined using the data and/or the services that the supervisor is assigning to a given node. Details of required resources may be specified in the package that defines the software and data dependencies, which is stored in the dependency manager.
  • step 406 the supervisor sends a request to a dependency manager for one or more configuration packages associated with the one or more modules to be installed on the node.
  • the supervisor may then send the configuration package to the node manager to be deployed, installed and started.
  • the configuration package which includes all data, software and metadata dependencies, is defined by a system administrator and stored in the dependency manager.
  • the node manager reads any software and data required to run the one or more modules from a suitable server.
  • Suitable software and data may include software, data and metadata suitable for indexing, compressing, decompressing, scoring, slicing, joining, or otherwise processing one or more records, as well as software and data suitable for communicating, coordinating, monitoring, or otherwise interacting with one or more other components in a system.
  • step 412 the node manager installs the required software fetched in step 410 .
  • step 414 the node manager executes the software installed in step 412 .
  • FIG. 5 is a flow chart depicting Query Processing 500 , having steps 502 , 504 , 508 , 510 , 512 , 514 , 518 , and 520 , and having checks 506 and 516 .
  • database queries generated by an external source are received by one or more search managers.
  • the queries may comprise binary data representing any suitable software source code, which may contain a user's submitted or a program's automatically-generated search parameters.
  • the source code language used for search queries may be a data serialization language capable of handling complex data structures, such as objects or classes. Data serialization languages may be used for converting complex data objects or structures to a sequence of digital bits, and may provide a data of complex objects in a format that may be managed by most any devices.
  • the queries may be represented in a markup language, such as XML and HTML, which may be validated or otherwise understood according to a schema file (e.g., XSD).
  • queries may be represented as, or otherwise communicate, a complex data structure, such as JSON, which may be validated or otherwise understood according to a schema file.
  • Queries may contain instructions suitable to search the database for desired records satisfying parameters of the query; and in some embodiments the suitable instructions may include a list of one or more collections to search.
  • the queries received from the external source may be parsed using according to the associated query language (e.g., SQL) by the one or more search managers, thereby generating a machine-readable query to be executed by the appropriate nodes (e.g., search conductor, analytics agent).
  • the appropriate nodes e.g., search conductor, analytics agent.
  • schema files associated with the software language of the queries may be provided with the query, generated by code generating the query, an accepted standard, or native to the search managers.
  • the schema files may instruct the search managers on parsing the search queries appropriately.
  • search queries are prepared using one or more markup languages (e.g., XML) or include a data structure (e.g., JSON), then a schema file, such as an XSD-based schema file, may be associated with the search query code or the data structure to identify and/or validate data within each of the markup tags of the XML code or the JSON code.
  • markup languages e.g., XML
  • JSON data structure
  • a schema file such as an XSD-based schema file, may be associated with the search query code or the data structure to identify and/or validate data within each of the markup tags of the XML code or the JSON code.
  • a search manager may determine, based on the user-provided or application-generated query, whether processing one or more fields of database and/or the queries should be performed.
  • field processing may include: address standardization, determining proximity boundaries, and synonym interpretation, among others.
  • automated or manual processes of the system may determine and identify whether any other processes associated with the search process 500 will require the use of the information included in the fields of the queries.
  • the one or more search managers may automatically determine and identify which of the one or more fields of a query may undergo a desired processing.
  • step 508 after the system determines that field processing for the one or more fields is desired in check 506 , the search managers may apply one or more suitable field processing techniques to the desired fields accordingly.
  • search managers may construct search conductor queries that are associated with the search queries.
  • the search conductor queries may be constructed so as to be processed by the various nodes of the system (e.g., search managers, search conductors, storage nodes) according to any suitable search query execution plan, such as a stack-based search. It should be appreciated that the search queries may be encoded using any suitable binary format or other machine-readable compact format.
  • the one or more search managers send the one or more search conductor queries to one or more search conductors.
  • the search managers may automatically determine which search conductors should receive search conductor queries and then transmit the search conductor queries to an identified subset of search conductors.
  • search conductors may be pre-associated with certain collections of data; and search queries received from the system interface may specify collections to be queried. As such, the search managers transmit search conductor queries to the search conductors associated with the collections specified in the one or more search queries.
  • search conductors return search results to the corresponding search managers.
  • the search results may be returned synchronously; and in some embodiments, the search results may be returned asynchronously.
  • Synchronously may refer to embodiments in which the search manager may block results or halt operations, while waiting for search conductor results from a particular search conductor.
  • Asynchronously may refer to embodiments in which the search manager can receive results from many search conductors at the same time, i.e., in a parallel manor, without blocking other results or halting other operations.
  • the search managers may collate the results received from the respective search conductors, based on record scores returned from the search conductors, into one or more results lists.
  • a search manager may determine whether additional analytics processing of the search results compiled by the search managers should be performed, based on an indication in the search query. In some cases, the indication may be included in the search query by the user. In some embodiments, the system determines if the analytics processing is desired using information included in the search query. In some embodiments, the one or more search managers may automatically determine fields should undergo a desired analytics processing. Search queries may be constructed in a software programming language capable of conveying instructions along with other data related to the search query (e.g., strings, objects).
  • Some programming languages may use metadata tags embedded into the code to identify various types of data, such as a field indicating a Boolean value whether analytics should be performed or a more complex user-defined field indicating a specific analytics module to be executed and/or the analytics agent node hosting the specific analytics module.
  • Some programming languages such as javascript or PHP, may reference stored computer files containing code that identifies whether analytics should be performed, which may be a more complex user-defined field indicating the specific analytics module to be executed and/or the analytics agent node hosting the specific analytics module.
  • one or more analytics agents apply one or more suitable processing techniques to the one or more results lists.
  • suitable techniques may include rolling up several records into a more complete record, performing one or more analytics on the results, and/or determining information about relationships between records, amongst others.
  • the analytics agent may then return one or more processed results lists to the one or more search managers.
  • the one or more search managers may decompress the one or more results lists and return them to the system that initiated the query.
  • FIG. 6 is a flow diagram depicting search conductor function 600 , having steps 602 , 604 , 608 , 610 , and 612 as well as check 606 .
  • a search manager sends a query to one or more search conductors.
  • step 604 a search conductor executes the query against its loaded partition, generating a candidate result set.
  • step 604 may include one or more index searches.
  • the search conductor may use information in one or more schemata to execute the query.
  • the search conductor determines, based on the specified query, whether scoring has been requested in the search conductor query. Scoring may be indicated in the search query received by the search manager.
  • the search conductor scores the candidate result set in step 608 .
  • a default score threshold may be defined in the schema, or may be included in the search conductor query sent by the search manager in step 602 .
  • an initial scoring may be done by the search conductor at the field level with field specific scoring algorithms, of which there may be defaults which may be overridden by one or more other scoring algorithms. Scoring algorithms may be defined or otherwise identified in the search query and/or the search conductor query, and my be performed by the search conductor accordingly.
  • the search conductor may give the record a composite score based on those individual field scores.
  • one or more aggregate scoring methods may be applied by the search conductor, which can compute scores by aggregating one or more field scores or other aggregated scores.
  • step 610 the search conductor then uses the scores to sort any remaining records in the candidate result set.
  • the search conductor returns the candidate result set to the search manager, where the number of results returned may be limited to a size requested in the query sent by the search manager in step 602 .
  • data may be added to one or more suitable in-memory databases.
  • data may be loaded in bulk using one or more partitioners.
  • FIG. 7 is a flow diagram depicting collection partitioning 700 , having steps 702 , 704 , 706 , 710 , and 712 , as well as perform check 708 .
  • one or more collections are fed into one or more partitioners.
  • the collections are fed in conjunction with one or more schemas so that the one or more partitioners can understand how to manipulate the records in the one or more collections.
  • step 704 the records in the one or more collections are fragmented.
  • the system checks the schema for the given data collection and determines whether any fields in the partitions are to be indexed by the partitioner.
  • An index may be any suitable example of a field-index, used in any known database, such as a date index or a fuzzy index (e.g., phonetic).
  • step 710 if the system determined in check 708 that the partitioner is to index any fields in the partitions, the partitioner indexes the partitions based on the index definition in the schema.
  • check 712 the system checks the schema for the given data collection and determines whether the partitions are to be compressed by the partitioner.
  • step 714 if the system determined in check 712 that the partitioner is to compress the partitions, the partitioner compressed the fields and records using the compression methods specified in the schema, which can be any technique suitable for compressing the partitions sufficiently while additionally allowing decompression at the field level.
  • step 716 the system stores the partitions suitable for distributing the partitions to one or more search conductors.
  • Collection partitioning 700 may create an initial load, reload or replacement of a large data collection.
  • the partitioner may assign unique record IDs to each record in a collection and may assign a version number to the partitioned collection, and may additionally associate the required collection schema with that partition set version for use by one or more SMs and one or more SCs.
  • new records may be added to a collection through one or more suitable interfaces, including a suitable query interface.
  • the query interface may support returning result sets via queries, but may also support returning the collection schema associated with a collection version.
  • the search interface may allow one or more users to use that collection schema to add new records to the collection by submitting them through the search interface into the search manager.
  • the search manager may then distribute the new record to an appropriate search conductor for addition to the collection.
  • the search manager may ensure eventual-consistency across multiple copies of a given partition and may guarantee data durability to non-volatile storage to ensure data is available after a system failure.
  • records may be deleted in a similar manner.
  • the result set from a query may include an opaque, unique ID for each record. This unique ID may encode the necessary information to uniquely identify a specific record in a given version of a collection and may include one or more of the collection name, the partition set version, and the unique record ID, amongst others.
  • the query interface may accept requests to delete a record corresponding to the unique record ID. This record may not be physically deleted immediately, and may be marked for deletion and may no longer be included in future answer sets.
  • a new collection schema or a delete request may be submitted to the query interface to create a new collection or remove an existing collection, respectively.
  • a new collection created this way may start out empty, where records can be added using any suitable mechanism, including the mechanism described above.
  • FIG. 8 is a flow chart depicting partition loading 800 , having steps 802 , 804 , 806 , 808 , 812 , 814 , 816 , 818 and 820 , as well as perform check 810 .
  • a supervisor determines one or more partitions are to be loaded into one or more search conductors.
  • step 804 the supervisor sends a configuration request to a dependency manager, and the dependency manager returns one or more configuration packages associated with the one or more partitions to be loaded on the one or more search conductors.
  • the supervisor determines which search conductors the partitions are to be loaded on. In one or more embodiments, the supervisor determines which one or more search conductors will be used so as to provide a desired failover ability. In one or more other embodiments, the supervisor determines which one or more search conductors will be used so as to better level out the work load perceived by one or more clusters.
  • the supervisor sends a command to one or more node managers associated with the nodes including the one or more search conductors.
  • the command informs the one or more node managers to await further instructions from the supervisor for loading the partition onto the one or more search conductors.
  • the command may include the one or more configuration packages associated with the one or more partitions to be loaded into the one or more search conductors.
  • the command may include instructions to prepare said one or more search conductors for loading a new partition into memory.
  • step 810 the one or more node managers allocate any node resources required for loading the partition.
  • the one or more node managers determine if one or more software or data updates are required to load the one or more partitions.
  • step 814 if the one or more node managers determined one or more software or data updates are required, the one or more node managers then retrieve said one or more software or data updates from one or more nodes suitable for storing and distributing said one or more software updates. The one or more node managers then proceed to install the one or more retrieved software or data updates.
  • the one or more node managers retrieve the one or more partitions from one or more nodes suitable for storing and distributing one or more partitions.
  • the retrieved partitions have previously been indexed and stored and once retrieved are loaded into memory associated with the one or more search conductors.
  • the retrieved partitions have not been indexed or compressed previous to being retrieved, and are indexed or compressed by the one or more search conductors prior to being loaded into memory associated with the one or more search conductors.
  • step 818 the one or more search conductors send heartbeats to the supervisor and the supervisor determines the one or more search conductors are ready for use in the system.
  • step 820 the supervisor informs one or more search managers the one or more search conductors are ready to receive search requests.
  • FIG. 9A shows collection 902 and an update of collection 902 denoted collection' 910 .
  • Collection 902 may be divided into at least a first partition 904 and up to nth partition 906
  • collection' 910 may be divided into at least a first partition' 912 and up to nth partition' 914 .
  • FIG. 9B shows first search node 920 having a first set of first partition 904 and up to nth partition 906 and second search node 930 having a second set of first partition 904 and up to nth partition 906 , where both first search node 920 and second search node 930 may be connected to at least one search manager 940 . Additionally, first search node 920 , second search node 930 and search manager 940 may be connected to one or more supervisors 950 .
  • FIG. 9C shows first search node 920 having been disconnected from search manager 940 as a result of a command from supervisor 950 , while second search node 930 still maintains a connection. In one or more embodiments, this may allow search manager 940 to run searches for records in collection 902 as first search node 920 is being upgraded.
  • FIG. 9D shows first search node 920 being updated to include collection' 910 .
  • FIG. 9E shows first search node 920 having first partition' 912 and up to nth partition' 914 connected to search manager 940 as a result of a command from supervisor 950 .
  • supervisor 950 then sends a command to disconnect second search node 930 from search manager 940 .
  • this may allow search manager 940 to run searches for records in collection' 910 .
  • FIG. 9F shows second search node 930 being updated to include collection' 910 .
  • FIG. 9G shows first search node 920 having a first set of first partition' 912 and up to nth partition' 914 and second search node 930 having a second set of first partition' 912 and up to nth partition' 914 connected to search manager 940 , where the connection between second search node 930 and search manager 940 may have been re-established as a result of a command from supervisor 950 .
  • This may allow search manager 940 to run searches for records in collection' 910 in either first search node 920 or second search node 930 .
  • FIG. 10 shows search node cluster 1000 , having first search node 1002 , second search node 1004 , third search node 1006 , fourth search node 1008 , first partition 1010 , second partition 1012 , third partition 1014 , and fourth partition 1016 for a first collection, and a first partition 1020 , second partition 1022 , third partition 1024 , and fourth partition 1026 for a second collection.
  • Search node cluster 1000 may be arranged to as to provide a desired level of partition redundancy, where one or more search nodes may be added or removed from the system accordingly. Additionally, the partitions included in the one or more search nodes may vary with time, and may be loaded or unloaded by the search node's node manager following a process similar to partition loading 800 . When updating or otherwise changing the partitions in search node cluster 1000 , a method similar to that described in FIGS. 9A, 9B, 9C, 9D, 9E, 9F , and 9 G may be used.
  • Example #1 is an in-memory database system including a search manager, an analytics agent, node managers on each node, eight search nodes each having two search conductors, a supervisor, a backup supervisor, a dependency manager, a backup dependency manager, and a partitioner on a node able to store and distribute partitions (where the node includes information for two collections split into four partitions each, collection 1 and collection 2 ).
  • the search manager sends a query to all the search conductors having the partitioner associated with collection 1 .
  • the search conductors work asynchronously to search and score each compressed record, make a list of compressed results having a score above the threshold defined in the query, sort the list of results and return the list of compressed records to the search manager.
  • the search conductors decompress only the fields that are to be scored.
  • the search manager receives and aggregates the list of results from each search conductor, compiles the query result, and sends it to analytics agent for further processing.
  • the analytics agent combines records it determines are sufficiently related, and returns the processed list of results to the search manager. The search manager then returns the final results through the system interface.
  • Example #2 is an in-memory database that can perform semantic queries and return linked data results on data that is not explicitly linked in the database.
  • Data or record linking is just one example of an aggregate analytical function that may be implemented in an Analytics Agent.
  • This example is an in-memory database with an analytics agent capable of discovering data linkages in unlinked data and performing semantic queries and returning semantic results.
  • Unlinked data is data from disparate data sources that has no explicit key or other explicit link to data from other data sources.
  • a pluggable analytics module could be developed and deployed in an Analytics Agent to discover/find data linkages across disparate data sources, based on the data content itself.
  • semantic search query When a semantic search query is executed, all relevant records are retrieved via search conductors, using non-exclusionary searches, and sent to an analytics agent where record linkages are discovered, based on the specific implementation of the analytics agent module, and confidence scores assigned.
  • These dynamically linked records can be represented using semantic markup such as RDF/XML or other semantic data representation and returned to the user. This approach to semantic search allows unlinked data to be linked in different ways for different queries using the same unlinked data.
  • Example #3 is an in-memory database that can perform graph queries and return linked data results on data that is not explicitly linked or represented in graph form in the database.
  • This example is an in-memory database with an analytics agent capable of discovering data linkages in unlinked data and performing graph queries and returning graph query results.
  • a graph search query is executed, all relevant records are retrieved via search conductors, using non-exclusionary searches, and sent to an analytics agent where record linkages are discovered and confidence scores assigned.
  • These dynamically linked records can be represented in graph form such as an RDF Graph, Property Graph or other graph data representation and returned to the user. This approach to graph search allows unlinked data to be linked in different ways for different queries using the same unlinked data.
  • 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 functions 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.
  • 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 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.
  • 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.

Abstract

An in-memory database system and method for administrating a distributed in-memory database, comprising one or more nodes having modules configured to store and distribute database partitions of collections partitioned by a partitioner associated with a search conductor. Database collections are partitioned according to a schema. Partitions, collections, and records, are updated and removed when requested by a system interface, according to the schema. Supervisors determine a node status based on a heartbeat signal received from each node. Users can send queries through a system interface to search managers. Search managers apply a field processing technique, forward the search query to search conductors, and return a set of result records to the analytics agents. Analytics agents perform analytics processing on a candidate results records from a search manager. The search conductors comprising partitioners associated with a collection, search and score the records in a partition, then return a set of candidate result records after receiving a search query from a search manager.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This patent application is a continuation of U.S. patent application Ser. No. 14/558,254, entitled “Design And Implementation Of Clustered In-Memory Database,” filed on Dec. 2, 2014, which claims a benefit of priority to U.S. Patent Application 61/910,841, entitled “An Implementation of Clustered In-Memory Database,” filed on Dec. 2, 2013, each of which is hereby incorporated by reference in its 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 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,009, entitled “Dependency Manager for Databases,” 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 “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 FIELD
  • The present disclosure relates in general to databases, and more specifically to in-memory databases.
  • BACKGROUND
  • Computers are powerful tools of use in storing and providing access to vast amounts of information, while databases are a common mechanism for storing information on computer systems while providing easy access to users. Typically, a database is an organized collection of information stored as “records” having “fields” of information (e.g., a restaurant database may have a record for each restaurant in a region, where each record contains fields describing characteristics of the restaurant, such as name, address, type of cuisine, and the like).
  • In operation, a database management system frequently needs to retrieve data from or persist data to storage devices such as disks. Unfortunately, access to such storage devices can be somewhat slow. To speed up access to data, databases typically employ a “cache” or “buffer cache” which is a section of relatively faster memory (e.g., random access memory (RAM)) allocated to store recently used data objects. Memory is typically provided on semiconductor or other electrical storage media and is coupled to a CPU (central processing unit) via a fast data bus which enables data maintained in memory to be accessed more rapidly than data stored on disks.
  • One approach that may be taken when attempting to solve this problem is to store all the information in the database in memory, however as memory provided on computer systems has a limited size there are a number of obstacles that must be faced when attempting to handle databases of a larger scale.
  • As such, there is a continuing need for improved methods of storing and retrieving data at high speeds at a large scale.
  • SUMMARY
  • Disclosed herein is a system architecture hosting an in-memory database, which may include any suitable combination of computing devices and software modules for storing, manipulating, and retrieving data records of the in-memory database that is hosted within the distributed computing architecture of the system. Software modules executed by computing hardware of the system may include a system interface, a search manager, an analytics agent, a search conductor, a partitioner, collections of data, a supervisor, a dependency manager; any suitable combination of these software modules may be found in the system architecture hosting the in-memory database.
  • Nodes executing software modules may compress data stored in the records to make in-memory storage, queries, and retrieval feasible for massive data sets. Compression and decompression may be performed at nearly any level of the database (e.g., database level, collection level, record level, field level). Nodes executing software modules may provide support for storing complex data structures, such as JavaScript Object Notation (JSON) in the distributed in-memory database. Embodiments of an in-memory database system may be fault-tolerant due to the distributed architecture of system components and the various hardware and software modules of the system that are capable of monitoring and restoring faulty services. Fault-tolerance may include system component redundancy, and automated recovery procedures for system components, among other techniques. The in memory database may effectively and efficiently query data by scoring data using scoring methods. Search results may be ranked according to the scoring methods used to score the data, thereby allowing users and/or nodes executing queries to utilize data in ways that are more tailored and contextually relevant from one query to the next. Nodes executing analytics agents may perform various advanced analytics on records stored in the in-memory database image of data. In some cases, analytics may be performed on the records retrieved with a set of search query results by search conductors.
  • In one embodiment, a computing system hosting an in-memory database, the system comprising: a partitioner node comprising a processor configured to, in response to receiving a collection of one or more records of a database, determine whether to compress the collection based on a machine-readable schema file associated with the collection, logically partition the collection into one or more partitions according to the schema file, and distribute the one or more partitions to one or more storage nodes according to the schema file; a storage node comprising non-transitory machine-readable main memory storing a partition received from the partitioner associated with the storage node; a search manager node comprising a processor receiving a search query from a client device of the system, and transmitting the search queries as search conductor queries to one or more search conductors in response to receive the search query from the client device, wherein the search query is a machine-readable computer file containing parameters associated with one or more records satisfying the search query; a search conductor node associated with one or more partitioners and comprising a processor configured to, in response to receiving a search conductor query from the search manager node: query a set of one or more partitions indicated by the search conductor query, identify one or more candidate records stored in the set of queried partitions, calculate a first score for each respective candidate record using a scoring algorithm, and transmit to the search manager a set of one or more query results containing one or more candidate records satisfying a threshold value; and an analytics agent node comprising a processor configured to automatically generate a machine-readable computer file containing a set of one or more data linkages for the set of query results, responsive to identifying in the set of query results received from the search manager node a data linkage correlating two or more records, wherein the data linkage correlates data contained in a first record associated with data contained in a second record.
  • In another embodiment, a computer implemented method comprises receiving, by a search manager computer of a system hosting an in-memory database, binary data representing a search query containing parameters querying the database, wherein the system comprises one or more storage nodes comprising main memory storing one or more collections of the database, wherein each collection contains one or more records, transmitting, by the computer, the search query to one or more search conductor nodes according to the search query, wherein the search query indicates a set of one or more collections to be queried; transmitting, by the computer, to one or more analytics agent nodes a set of search results based on the search query responsive to receiving from the one or more search conductors the set of search results containing one or more records satisfying the search query, wherein each respective record of the set of search results is associated with a score based on a scoring algorithm in the search query; and responsive to the computer receiving a computer file containing a set of one or more data linkages from the one or more analytics agent nodes: updating, by the computer, the one or more records of the set of search results according to the set of one or more data linkages received from the analytics agent nodes.
  • In another embodiment, a computer-implemented method comprises receiving, by a computer, one or more collections from a search conductor according to a schema file, wherein each of the collections comprises a set of one or more records having one or more fields; partitioning, by the computer, each collection according to the schema; compressing, by the computer, the records in the partition according to the schema; and distributing, by the computer, each of the partitions to one or more associated search conductors to include each of the partitions in each collection corresponding to the partitioner associated with the search conductor.
  • 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.
  • BRIEF DESCRIPTION OF THE 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.
  • FIG. 1 shows an in-memory database architecture according to an exemplary embodiment.
  • FIG. 2 shows a node configuration according to an exemplary embodiment.
  • FIG. 3 is a flow chart for setting up a node according to an exemplary embodiment.
  • FIG. 4 is a flow chart depicting module set up in a node according to an exemplary embodiment.
  • FIG. 5 is a flow chart describing the function of a search manager according to an exemplary embodiment.
  • FIG. 6 is a flow chart describing the function of a search conductor according to an exemplary embodiment.
  • FIG. 7 is a flow chart describing the function of a partitioner according to an exemplary embodiment.
  • FIG. 8 is a flow chart describing a process of setting up a partition in a search conductor according to an exemplary embodiment.
  • FIG. 9A shows a collection, its updated version, and their associated partitions according to an exemplary embodiment.
  • FIG. 9B shows a first and second search node including a first collection connected to a search manager according to an exemplary embodiment.
  • FIG. 9C shows a first search node including a first collection disconnected from a search manager and a second search node including a first collection connected to a search manager according to an exemplary embodiment.
  • FIG. 9D shows a first search node loading an updated collection, and a second search node connected to a search manager according to an exemplary embodiment.
  • FIG. 9E shows a first search node including an updated collection connected to a search manager, and a second search node including a first collection disconnected from a search manager according to an exemplary embodiment.
  • FIG. 9F shows a second search node loading an updated collection, and a first search node connected to a search manager according to an exemplary embodiment.
  • FIG. 9G shows a first and second search node including an updated collection connected to a search manager according to an exemplary embodiment.
  • FIG. 10 shows a cluster of search nodes including partitions for two collections according to an exemplary embodiment.
  • DEFINITIONS
  • As used here, the following terms may have the following definitions:
  • “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.
  • “Collection” refers to a discrete set of records.
  • “Record” refers to one or more pieces of information that may be handled as a unit.
  • “Field” refers to one data element within a record.
  • “Partition” refers to an arbitrarily delimited portion of records of a collection.
  • “Schema” refers to data describing one or more characteristics of one or more records.
  • “Search Manager”, or “S.M.”, refers to a module configured to at least receive one or more queries and return one or more search results.
  • “Analytics Agent”, “Analytics Module”, “A.A.”, or “A.M.”, refers to a module configured to at least receive one or more records, process said one or more records, and return the resulting one or more processed records.
  • “Search Conductor”, or “S.C.”, refers to a module configured to at least run one or more queries on a partition and return the search results to one or more search managers.
  • “Node Manager”, or “N.M.”, refers to a module configured to at least perform one or more commands on a node and communicate with one or more supervisors.
  • “Supervisor” refers to a module configured to at least communicate with one or more components of a system and determine one or more statuses.
  • “Heartbeat”, or “HB”, refers to a signal communicating at least one or more statuses to one or more supervisors.
  • “Partitioner” refers to a module configured to at least divide one or more collections into one or more partitions.
  • “Dependency Manager”, or “D.M.”, 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.
  • “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.
  • “Query” refers to a request to retrieve information from one or more suitable partitions or databases.
  • “Memory” refers to any hardware component suitable for storing information and retrieving said information at a sufficiently high speed.
  • “Fragment” refers to separating records into smaller records until a desired level of granularity is achieved.
  • DETAILED DESCRIPTION
  • Reference will now be made in detail to several preferred embodiments, examples of which are illustrated in the accompanying drawings. The embodiments described herein are intended to be exemplary. One skilled in the art recognizes that numerous alternative components and embodiments may be substituted for the particular examples described herein and still fall within the scope of the invention.
  • Exemplary embodiments describe an in-memory database including one or more clusters and one or more modules, where suitable modules may include one or more of a search manager, an analytics agent, a node manager, a search conductor, a supervisor, a dependency manager, and/or a partitioner.
  • System Configuration
  • In-Memory Database Architecture
  • An in-memory database is a database storing data in records controlled by a database management system (DBMS) configured to store data records in a device's main memory, as opposed to conventional databases and DBMS modules that store data in “disk” memory. Conventional disk storage requires processors (CPUs) to execute read and write commands to a device's hard disk, thus requiring CPUs to execute instructions to locate (i.e., seek) and retrieve the memory location for the data, before performing some type of operation with the data at that memory location. In-memory database systems access data that is placed into main memory, and then addressed accordingly, thereby mitigating the number of instructions performed by the CPUs and eliminating the seek time associated with CPUs seeking data on hard disk.
  • In-memory databases may be implemented in a distributed computing architecture, which may be a computing system comprising one or more nodes configured to aggregate the nodes' respective resources (e.g., memory, disks, processors). As disclosed herein, embodiments of a computing system hosting an in-memory database may distribute and store data records of the database among one or more nodes. In some embodiments, these nodes are formed into “clusters” of nodes. In some embodiments, these clusters of nodes store portions, or “collections,” of database information.
  • In one or more embodiments, a system interface may feed one or more search queries to one or more search managers. The search managers may be linked to one or more analytics agents that perform certain analytic techniques depending upon the embodiment and return the results to a search manager. The search managers may be linked to one or more search conductors. The search conductors may service search queries and database updates to one or more data partitions. In one or more embodiments, one or more nodes comprising a partitioner store one or more partitions of one or more database collections. A partition of a collection stores one or more records of the collection that have been partitioned into the particular partition. Thus, the one or more nodes storing each of the partitions of a collection are storing records of the in-memory database.
  • Partitioner Compression
  • An in-memory database may be an organized collection of information stored as “records” having “fields” of information. For example, a restaurant database may have a record for each restaurant in a region, and each record contains a different field for describing each of the characteristics of the restaurant, such as name, address, type of cuisine, and the like.
  • An embodiment of an in-memory database may use clusters of one or more nodes to store and access data; larger amounts of data may require larger amounts of non-transitory, machine-readable storage space. Compression reduces the amount of storage space required to host the information.
  • In some embodiments, one or more collections may be described using any suitable schema that defines the compression technique used for one or more fields of the one or more records of the one or more collections. In these embodiments, one or more fields may be compressed by a partitioner using one or more techniques suitable for compressing the type of data stored in a field.
  • In some embodiments, the type of data stored in a field may be compressed after fragmentation in which records in a collection are separated into smaller records until a desired data granularity is achieved. In such embodiments, fragmented record indices may be used to identify which record the fields were fragmented from to ensure the system remains aware that the records originate from the same original record of the collection. Fragmented records may be compressed further by according to one or more fragmenting algorithms.
  • In some embodiments, one or more collections may be indexed and/or compressed by one or more partitioner modules, which may be associated with one or more search conductor modules of an in-memory database system. In some embodiments, one or more compression techniques facilitate data compression while allowing data to be decompressed and/or accessed at any level of the in-memory database, including the field level, the record level, or the collection level.
  • System Architecture
  • FIG. 1 shows system architecture 100 having system interface 102, first search manager 110, nth search manager 112, first analytics agent 120, nth analytics agent 122, first search conductor 130, nth search conductor 132, partition data 140, partitioner 150, first collection 160, nth collection 162, supervisor 170, and dependency manager 180.
  • In one or more embodiments, system interface 102 may feed one or more queries generated outside system architecture 100 to one or more search managers 110, 112 in a first cluster including at least one node including a first search manager 110 and up to n nodes including an nth search manager 112. The one or more search managers 110, 112 in said first cluster may be linked to one or more analytics agents 120, 122 in a second cluster including at least a first analytics agent 120 and up to nth analytics agent 122.
  • Search managers 110, 112 in the first cluster may be linked to one or more search conductors 130, 132 in a third cluster. The third cluster may include at least a first search conductor 130 and up to an nth search conductor 132. Each search node (i.e., node executing search manager 110, 112) may include any suitable number of search conductors 130, 132.
  • Search conductors 130, 132 in the third cluster may be linked to one or more database nodes storing partition data 140. Partition data 140 may include one or more partitions (i.e., arbitrarily delimited portions of records partitioned from a discrete set of records) generated by a node executing one or more partitioners 150, which may be a module configured to at least divide one or more collections into one or more partitions. Each of the partitions may correspond to at least a first collection 160 and up to nth collection 162. The collections 160, 162 may additionally be described by one or more schemata files, which may define the data in the collections 160, 162. The one or more schemata may include information about the name of the fields in records of the partitions, whether said fields are indexed, what compression method was used, and what scoring algorithm is the default for the fields, amongst others. The schemata may be used by partitioners 150 when partitioning the first collection 160 and up to nth collection 162, and may be additionally be used by the first search manager 110 and up nth search manager 112 when executing one or more queries on the collections.
  • One or more nodes may execute a supervisor 170 software module that receives a heartbeat signal transmitted from other nodes of the system 100. A supervisor 170 may be configured to receive data from nodes of the system 100 that execute one or more dependency manager 180 software modules. A dependency manager 180 node may store, update, and reference dependency trees associated with one or more modules, partitions, or suitable combinations thereof, which may indicate configuration dependencies for nodes, modules, and partitions, based on relative relationships. A supervisor 170 may additionally be linked to other nodes in the system 100 executing one or more other supervisors 170. In some cases, links to additional supervisors 170 may cross between clusters of the system architecture 100.
  • Nodes executing an analytics agent 120,122 may execute one or more suitable analytics modules, which conform to a specified application programming interface (API) that facilitates interoperability and data transfer between the components of the system (e.g., software modules, nodes). Analytics agents 120, 122 may be configured to process aggregated query results returned from search conductors 130, 132. For example, a search manager 110 may receive a search query and then generate search conductor queries, which the search manager 110 issues to one or more search conductors 130, 132. After the search conductors 130, 132 execute their respectively assigned search conductor queries, the search manager 110 will receive a set of aggregated query results from the one or more search conductors 130, 132. The search manager 110 may forward these search query results to an analytics agent 120 for further processing, if further processing is required by the parameters of the search query.
  • In some implementations, after a search manager 110 determines the search query has requested for an analytics agent 120 to process one or more sets of aggregated results received from the search conductors 130, 132, the search manager 110 may transmit a database schema file and/or one or more analytical parameters to the analytics agents 120, 122. In some cases, the search query may request particular analytics algorithms to be performed, which the search manager 110 may use to identify which analytics agent 120 should receive aggregated search results. In some cases, one or more of the sets of aggregated results may be transmitted to the analytics agents 120, 122 in the form of compressed records, which contain data compressed according to a compression algorithm. In some cases, data of the records may be compressed at the fields of the records; and in some cases, full records may be compressed.
  • Nodes executing analytics agents 120, 122 having various analytics modules. Non-limiting examples may include: disambiguation modules, linking modules, and link on-the-fly modules, among other suitable modules and algorithms. As detailed later, linking modules and link-on-the-fly modules may identify, generate, and/or store metadata that links data previously stored in records of the database. Suitable modules may include any software implementation of analytical methods for processing any kind of data. In some embodiments, particular analytics modules or analytics agents 120, 122 may be accessible only to predetermined instances, clusters, partitions, or/or instantiated objects of an in-memory database.
  • Analytics Modules
  • According to an embodiment, an application programming interface (API) may be used to create a plurality of analytics modules, and the disclosed system architecture may allow the addition of multiple customized analytics modules executed by analytics agents of the system, which may be added to the system architecture, without interrupting operation or services, which may support dynamic processing of constant streams of data.
  • Newly created analytics modules may be easily plugged into the database using simple module set up processes and may enable the application in real time to apply one or more analytical methods to aggregated results lists, without having to change how the data is managed, prepared and stored. Separate APIs may be constructed to support models which score records against queries, typically a search conductor function, or to perform closure or other aggregate analytical function on a record set, typically an analytics agent task.
  • FIG. 2 is a diagram showing a configuration of a node 200, according to an exemplary embodiment. The node 200 in FIG. 2 may comprise a processor executing a node manager 202 software module and any number of additional software modules 210, 212, which may include a first software module 210 and up to nth module 212.
  • According to the exemplary configuration of FIG. 2, the node 200 may be communicatively coupled over a data network to a second node executing a supervisor module, or supervisor node. A node manager 202 be installed and executed by the node 200 may also configured to communicate with the supervisor node, and may also be configured to monitor a software modules 210, 212 installed on the node, including a first module 210, up to nth module 212. Node manager 202 may execute any suitable commands received from the supervisor, and may additionally report on the status of one or more of the node 200, node manager 202, and from the first module 210 to the nth module 212. The first module 210 may be linked to the one or more supervisors and may be linked to one or more other modules in the node, where other modules in the node may be of a type differing from that of first module 210 or may share a type with first module 210. Additionally, first module 210 may be linked with one or more other modules, nodes, or clusters in the system.
  • System Operation
  • System Set-up
  • FIG. 3 is a flowchart depicting node set-up 300 having steps 302, 304, and 306.
  • In step 302, an operating system (OS) suitable for use on a node is loaded to the node. In one or more embodiments, the OS may be loaded automatically by the node's manufacturer. In one or more other embodiments, the OS may be loaded on the node by one or more operators.
  • In step 304, a node manager suitable for use with the OS loaded on the node is installed manually by one or more operators, where the installation may determine which one or more desired modules additional to node manager will be installed on the node.
  • In step 306, the node manager sends a heartbeat to a supervisor, where said heartbeat may include information sufficient for the supervisor to determine that the node is ready to receive instructions to install one or more modules.
  • FIG. 4 is a flow chart depicting module set-up 400 having steps 402, 404, 406, 408, 410, 412, and 414.
  • In step 402, the supervisor determines one or more modules are to be installed on one or more nodes, based on the needs of the data collections defined for the system. A supervisor then sends the installation preparation instruction to one or more node managers on said one or more nodes. In some embodiments, the supervisor may track the data collections (including data shards, or portions of data) and the configuration settings associated with the respective collections. The supervisor may also be aware of all available nodes and their resources (as reported by Node Managers). The supervisor may map (i.e., correlate) the system needs to available node resources to determine which data shards or portions, and which system services or resources, should be running on each respective node. The supervisor may then sends deploy/install requests, including any dependencies defined, to the appropriate Node Managers to instruct the node managers to execute the installation on the client-side.
  • In step 404, the node manager allocates the node's resources, such as computer memory, disk storage and/or a portion of CPU capacity, for running the one or more desired modules. In one or more embodiments, the allocation of resources may expire after a period of time should the supervisor discontinue the process. Non-limiting examples of resources can include computer memory, disk storage and/or a portion of CPU capacity. The resources required may be determined using the data and/or the services that the supervisor is assigning to a given node. Details of required resources may be specified in the package that defines the software and data dependencies, which is stored in the dependency manager.
  • In step 406, the supervisor sends a request to a dependency manager for one or more configuration packages associated with the one or more modules to be installed on the node.
  • In step 408, the supervisor may then send the configuration package to the node manager to be deployed, installed and started. The configuration package, which includes all data, software and metadata dependencies, is defined by a system administrator and stored in the dependency manager.
  • In step 410, the node manager reads any software and data required to run the one or more modules from a suitable server. Suitable software and data may include software, data and metadata suitable for indexing, compressing, decompressing, scoring, slicing, joining, or otherwise processing one or more records, as well as software and data suitable for communicating, coordinating, monitoring, or otherwise interacting with one or more other components in a system.
  • In step 412, the node manager installs the required software fetched in step 410.
  • In step 414, the node manager executes the software installed in step 412.
  • Query Execution
  • FIG. 5 is a flow chart depicting Query Processing 500, having steps 502, 504, 508, 510, 512, 514, 518, and 520, and having checks 506 and 516.
  • In step 502, database queries generated by an external source, such as a browser-based graphical user interface (GUI) hosted by the system or a native GUI of the client computer, are received by one or more search managers. The queries may comprise binary data representing any suitable software source code, which may contain a user's submitted or a program's automatically-generated search parameters. The source code language used for search queries may be a data serialization language capable of handling complex data structures, such as objects or classes. Data serialization languages may be used for converting complex data objects or structures to a sequence of digital bits, and may provide a data of complex objects in a format that may be managed by most any devices. In some embodiments, the queries may be represented in a markup language, such as XML and HTML, which may be validated or otherwise understood according to a schema file (e.g., XSD). In some embodiments, queries may be represented as, or otherwise communicate, a complex data structure, such as JSON, which may be validated or otherwise understood according to a schema file. Queries may contain instructions suitable to search the database for desired records satisfying parameters of the query; and in some embodiments the suitable instructions may include a list of one or more collections to search.
  • In step 504, the queries received from the external source may be parsed using according to the associated query language (e.g., SQL) by the one or more search managers, thereby generating a machine-readable query to be executed by the appropriate nodes (e.g., search conductor, analytics agent). In some cases, schema files associated with the software language of the queries may be provided with the query, generated by code generating the query, an accepted standard, or native to the search managers. The schema files may instruct the search managers on parsing the search queries appropriately. For example, if the search queries are prepared using one or more markup languages (e.g., XML) or include a data structure (e.g., JSON), then a schema file, such as an XSD-based schema file, may be associated with the search query code or the data structure to identify and/or validate data within each of the markup tags of the XML code or the JSON code.
  • In check 506, a search manager may determine, based on the user-provided or application-generated query, whether processing one or more fields of database and/or the queries should be performed. Non-limiting examples of field processing may include: address standardization, determining proximity boundaries, and synonym interpretation, among others. In some embodiments, automated or manual processes of the system may determine and identify whether any other processes associated with the search process 500 will require the use of the information included in the fields of the queries. In some embodiments, the one or more search managers may automatically determine and identify which of the one or more fields of a query may undergo a desired processing.
  • In step 508, after the system determines that field processing for the one or more fields is desired in check 506, the search managers may apply one or more suitable field processing techniques to the desired fields accordingly.
  • In step 510, search managers may construct search conductor queries that are associated with the search queries. In some embodiments, the search conductor queries may be constructed so as to be processed by the various nodes of the system (e.g., search managers, search conductors, storage nodes) according to any suitable search query execution plan, such as a stack-based search. It should be appreciated that the search queries may be encoded using any suitable binary format or other machine-readable compact format.
  • In step 512, the one or more search managers send the one or more search conductor queries to one or more search conductors. In some embodiments, the search managers may automatically determine which search conductors should receive search conductor queries and then transmit the search conductor queries to an identified subset of search conductors. In such embodiments, search conductors may be pre-associated with certain collections of data; and search queries received from the system interface may specify collections to be queried. As such, the search managers transmit search conductor queries to the search conductors associated with the collections specified in the one or more search queries.
  • In step 514, search conductors return search results to the corresponding search managers. In some embodiments, the search results may be returned synchronously; and in some embodiments, the search results may be returned asynchronously. Synchronously may refer to embodiments in which the search manager may block results or halt operations, while waiting for search conductor results from a particular search conductor. Asynchronously may refer to embodiments in which the search manager can receive results from many search conductors at the same time, i.e., in a parallel manor, without blocking other results or halting other operations. After receiving the search results from search conductors, the search managers may collate the results received from the respective search conductors, based on record scores returned from the search conductors, into one or more results lists.
  • In check 516, a search manager may determine whether additional analytics processing of the search results compiled by the search managers should be performed, based on an indication in the search query. In some cases, the indication may be included in the search query by the user. In some embodiments, the system determines if the analytics processing is desired using information included in the search query. In some embodiments, the one or more search managers may automatically determine fields should undergo a desired analytics processing. Search queries may be constructed in a software programming language capable of conveying instructions along with other data related to the search query (e.g., strings, objects). Some programming languages, such as markup languages, may use metadata tags embedded into the code to identify various types of data, such as a field indicating a Boolean value whether analytics should be performed or a more complex user-defined field indicating a specific analytics module to be executed and/or the analytics agent node hosting the specific analytics module. Some programming languages, such as javascript or PHP, may reference stored computer files containing code that identifies whether analytics should be performed, which may be a more complex user-defined field indicating the specific analytics module to be executed and/or the analytics agent node hosting the specific analytics module.
  • In step 518, if the system determines in check 516 that processing is desired, one or more analytics agents apply one or more suitable processing techniques to the one or more results lists. In one or more embodiments, suitable techniques may include rolling up several records into a more complete record, performing one or more analytics on the results, and/or determining information about relationships between records, amongst others. The analytics agent may then return one or more processed results lists to the one or more search managers.
  • In step 520, the one or more search managers may decompress the one or more results lists and return them to the system that initiated the query.
  • FIG. 6 is a flow diagram depicting search conductor function 600, having steps 602, 604, 608, 610, and 612 as well as check 606.
  • In step 602, a search manager sends a query to one or more search conductors.
  • In step 604, a search conductor executes the query against its loaded partition, generating a candidate result set. In one or more embodiments, step 604 may include one or more index searches. In one or more embodiments, the search conductor may use information in one or more schemata to execute the query.
  • In check 606, the search conductor determines, based on the specified query, whether scoring has been requested in the search conductor query. Scoring may be indicated in the search query received by the search manager.
  • If scoring is requested, the search conductor scores the candidate result set in step 608. A default score threshold may be defined in the schema, or may be included in the search conductor query sent by the search manager in step 602. In one or more embodiments, an initial scoring may be done by the search conductor at the field level with field specific scoring algorithms, of which there may be defaults which may be overridden by one or more other scoring algorithms. Scoring algorithms may be defined or otherwise identified in the search query and/or the search conductor query, and my be performed by the search conductor accordingly. The search conductor may give the record a composite score based on those individual field scores. In some embodiments, one or more aggregate scoring methods may be applied by the search conductor, which can compute scores by aggregating one or more field scores or other aggregated scores.
  • In step 610, the search conductor then uses the scores to sort any remaining records in the candidate result set.
  • In check 612, the search conductor returns the candidate result set to the search manager, where the number of results returned may be limited to a size requested in the query sent by the search manager in step 602.
  • Collection Partitioning And Partition Loading
  • In one or more embodiments, data may be added to one or more suitable in-memory databases.
  • In a first embodiment, data may be loaded in bulk using one or more partitioners.
  • FIG. 7 is a flow diagram depicting collection partitioning 700, having steps 702, 704, 706, 710, and 712, as well as perform check 708.
  • In step 702, one or more collections are fed into one or more partitioners. The collections are fed in conjunction with one or more schemas so that the one or more partitioners can understand how to manipulate the records in the one or more collections.
  • In step 704, the records in the one or more collections are fragmented.
  • In check 708, the system checks the schema for the given data collection and determines whether any fields in the partitions are to be indexed by the partitioner. An index may be any suitable example of a field-index, used in any known database, such as a date index or a fuzzy index (e.g., phonetic).
  • In step 710, if the system determined in check 708 that the partitioner is to index any fields in the partitions, the partitioner indexes the partitions based on the index definition in the schema.
  • In check 712, the system checks the schema for the given data collection and determines whether the partitions are to be compressed by the partitioner.
  • In step 714, if the system determined in check 712 that the partitioner is to compress the partitions, the partitioner compressed the fields and records using the compression methods specified in the schema, which can be any technique suitable for compressing the partitions sufficiently while additionally allowing decompression at the field level.
  • In step 716, the system stores the partitions suitable for distributing the partitions to one or more search conductors.
  • Collection partitioning 700 may create an initial load, reload or replacement of a large data collection. The partitioner may assign unique record IDs to each record in a collection and may assign a version number to the partitioned collection, and may additionally associate the required collection schema with that partition set version for use by one or more SMs and one or more SCs.
  • In a second embodiment, new records may be added to a collection through one or more suitable interfaces, including a suitable query interface. The query interface may support returning result sets via queries, but may also support returning the collection schema associated with a collection version. Additionally, the search interface may allow one or more users to use that collection schema to add new records to the collection by submitting them through the search interface into the search manager. The search manager may then distribute the new record to an appropriate search conductor for addition to the collection. In some embodiments, the search manager may ensure eventual-consistency across multiple copies of a given partition and may guarantee data durability to non-volatile storage to ensure data is available after a system failure.
  • In one or more embodiments, records may be deleted in a similar manner. The result set from a query may include an opaque, unique ID for each record. This unique ID may encode the necessary information to uniquely identify a specific record in a given version of a collection and may include one or more of the collection name, the partition set version, and the unique record ID, amongst others. With appropriate permissions, the query interface may accept requests to delete a record corresponding to the unique record ID. This record may not be physically deleted immediately, and may be marked for deletion and may no longer be included in future answer sets.
  • In one or more other embodiments, a new collection schema or a delete request may be submitted to the query interface to create a new collection or remove an existing collection, respectively. A new collection created this way may start out empty, where records can be added using any suitable mechanism, including the mechanism described above.
  • FIG. 8 is a flow chart depicting partition loading 800, having steps 802, 804, 806, 808, 812, 814, 816, 818 and 820, as well as perform check 810.
  • In step 802, a supervisor determines one or more partitions are to be loaded into one or more search conductors.
  • In step 804, the supervisor sends a configuration request to a dependency manager, and the dependency manager returns one or more configuration packages associated with the one or more partitions to be loaded on the one or more search conductors.
  • In step 806, the supervisor determines which search conductors the partitions are to be loaded on. In one or more embodiments, the supervisor determines which one or more search conductors will be used so as to provide a desired failover ability. In one or more other embodiments, the supervisor determines which one or more search conductors will be used so as to better level out the work load perceived by one or more clusters.
  • In step 808, the supervisor sends a command to one or more node managers associated with the nodes including the one or more search conductors. In one or more embodiments, the command informs the one or more node managers to await further instructions from the supervisor for loading the partition onto the one or more search conductors. In another embodiment, the command may include the one or more configuration packages associated with the one or more partitions to be loaded into the one or more search conductors. In one or more other embodiments, the command may include instructions to prepare said one or more search conductors for loading a new partition into memory.
  • In step 810, the one or more node managers allocate any node resources required for loading the partition.
  • In check 812, the one or more node managers determine if one or more software or data updates are required to load the one or more partitions.
  • In step 814, if the one or more node managers determined one or more software or data updates are required, the one or more node managers then retrieve said one or more software or data updates from one or more nodes suitable for storing and distributing said one or more software updates. The one or more node managers then proceed to install the one or more retrieved software or data updates.
  • In step 816, the one or more node managers retrieve the one or more partitions from one or more nodes suitable for storing and distributing one or more partitions. In one or more embodiments, the retrieved partitions have previously been indexed and stored and once retrieved are loaded into memory associated with the one or more search conductors. In another embodiment, the retrieved partitions have not been indexed or compressed previous to being retrieved, and are indexed or compressed by the one or more search conductors prior to being loaded into memory associated with the one or more search conductors.
  • In step 818, the one or more search conductors send heartbeats to the supervisor and the supervisor determines the one or more search conductors are ready for use in the system.
  • In step 820, the supervisor informs one or more search managers the one or more search conductors are ready to receive search requests.
  • FIG. 9A shows collection 902 and an update of collection 902 denoted collection' 910. Collection 902 may be divided into at least a first partition 904 and up to nth partition 906, and collection' 910 may be divided into at least a first partition' 912 and up to nth partition' 914.
  • FIG. 9B shows first search node 920 having a first set of first partition 904 and up to nth partition 906 and second search node 930 having a second set of first partition 904 and up to nth partition 906, where both first search node 920 and second search node 930 may be connected to at least one search manager 940. Additionally, first search node 920, second search node 930 and search manager 940 may be connected to one or more supervisors 950.
  • FIG. 9C shows first search node 920 having been disconnected from search manager 940 as a result of a command from supervisor 950, while second search node 930 still maintains a connection. In one or more embodiments, this may allow search manager 940 to run searches for records in collection 902 as first search node 920 is being upgraded.
  • FIG. 9D shows first search node 920 being updated to include collection' 910.
  • FIG. 9E shows first search node 920 having first partition' 912 and up to nth partition' 914 connected to search manager 940 as a result of a command from supervisor 950. supervisor 950 then sends a command to disconnect second search node 930 from search manager 940. In one or more embodiments, this may allow search manager 940 to run searches for records in collection' 910.
  • FIG. 9F shows second search node 930 being updated to include collection' 910.
  • FIG. 9G shows first search node 920 having a first set of first partition' 912 and up to nth partition' 914 and second search node 930 having a second set of first partition' 912 and up to nth partition' 914 connected to search manager 940, where the connection between second search node 930 and search manager 940 may have been re-established as a result of a command from supervisor 950. This may allow search manager 940 to run searches for records in collection' 910 in either first search node 920 or second search node 930.
  • FIG. 10 shows search node cluster 1000, having first search node 1002, second search node 1004, third search node 1006, fourth search node 1008, first partition 1010, second partition 1012, third partition 1014, and fourth partition 1016 for a first collection, and a first partition 1020, second partition 1022, third partition 1024, and fourth partition 1026 for a second collection.
  • Search node cluster 1000 may be arranged to as to provide a desired level of partition redundancy, where one or more search nodes may be added or removed from the system accordingly. Additionally, the partitions included in the one or more search nodes may vary with time, and may be loaded or unloaded by the search node's node manager following a process similar to partition loading 800. When updating or otherwise changing the partitions in search node cluster 1000, a method similar to that described in FIGS. 9A, 9B, 9C, 9D, 9E, 9F, and 9G may be used.
  • Example #1 is an in-memory database system including a search manager, an analytics agent, node managers on each node, eight search nodes each having two search conductors, a supervisor, a backup supervisor, a dependency manager, a backup dependency manager, and a partitioner on a node able to store and distribute partitions (where the node includes information for two collections split into four partitions each, collection 1 and collection 2). When a search query for records in collection 1 is received by the database, the search manager sends a query to all the search conductors having the partitioner associated with collection 1. The search conductors work asynchronously to search and score each compressed record, make a list of compressed results having a score above the threshold defined in the query, sort the list of results and return the list of compressed records to the search manager. In this example, the search conductors decompress only the fields that are to be scored. The search manager receives and aggregates the list of results from each search conductor, compiles the query result, and sends it to analytics agent for further processing. The analytics agent combines records it determines are sufficiently related, and returns the processed list of results to the search manager. The search manager then returns the final results through the system interface.
  • Example #2 is an in-memory database that can perform semantic queries and return linked data results on data that is not explicitly linked in the database. Data or record linking is just one example of an aggregate analytical function that may be implemented in an Analytics Agent. This example is an in-memory database with an analytics agent capable of discovering data linkages in unlinked data and performing semantic queries and returning semantic results. Unlinked data is data from disparate data sources that has no explicit key or other explicit link to data from other data sources. In this example, a pluggable analytics module could be developed and deployed in an Analytics Agent to discover/find data linkages across disparate data sources, based on the data content itself. When a semantic search query is executed, all relevant records are retrieved via search conductors, using non-exclusionary searches, and sent to an analytics agent where record linkages are discovered, based on the specific implementation of the analytics agent module, and confidence scores assigned. These dynamically linked records can be represented using semantic markup such as RDF/XML or other semantic data representation and returned to the user. This approach to semantic search allows unlinked data to be linked in different ways for different queries using the same unlinked data.
  • Example #3 is an in-memory database that can perform graph queries and return linked data results on data that is not explicitly linked or represented in graph form in the database. This example is an in-memory database with an analytics agent capable of discovering data linkages in unlinked data and performing graph queries and returning graph query results. When a graph search query is executed, all relevant records are retrieved via search conductors, using non-exclusionary searches, and sent to an analytics agent where record linkages are discovered and confidence scores assigned. These dynamically linked records can be represented in graph form such as an RDF Graph, Property Graph or other graph data representation and returned to the user. This approach to graph search allows unlinked data to be linked in different ways for different queries using the same unlinked data.
  • 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.

Claims (20)

What is claimed is:
1. A system comprising:
a first node storing a plurality of records of an in-memory database;
a second node receiving a search query from a client;
a third node receiving the search query from the second node, querying the records based on the search query, identifying a record from the records, determining a score for the record, and sending a search result to the second node, wherein the search result links to the record based on the score satisfying a threshold value; and
a fourth node receiving the search result from the second node, generating a file containing a content derived from the search result, wherein each of the first node, the third node, and the fourth node is a distinct node.
2. The system of claim 1, wherein the second node is distinct from the first node, the third node, and the fourth node.
3. The system of claim 1, wherein the fourth node identifies a data linkage in the search result, wherein the record is a first record containing a first content, wherein the records comprise a second record containing the second content, wherein the data linkage correlates the first content and the second content.
4. The system of claim 1, further comprising:
a fifth node receiving a heartbeat signal from at least one of the first node, the second node, the third node, or the fourth node, wherein the heartbeat signal comprises a node status, wherein the fifth node supervises the at least one of the first node, the second node, the third node, or the fourth node.
5. The system of claim 4, wherein the fifth node sends a configuration file to at least one of the first node, the second node, the third node, or the fourth node based on the sixth node determining the configuration to be misconfigured.
6. The system of claim 4, further comprising:
a sixth node monitoring a status based on the heartbeat signal received via the fifth node, wherein the status is of a configuration at least one of the first node, the second node, the third node, or the fourth node.
7. The system of claim 6, wherein the status is monitored via a tree stored at least one of local or remote from the sixth node.
8. The system of claim 7, wherein the fifth node is distinct from the sixth node.
9. The system of claim 1, further comprising:
a fifth node partitioning a collection of the records into a partition according to the schema file and sending the partition to the first node according to the schema file such that the first node stores the records in a fragmented manner according to the schema file, wherein the partition contains the records.
10. The system of claim 1, further comprising:
a fifth node partitioning a collection of the records into a partition according to a schema file and sending the partition to the first node according to the schema file, wherein the partition contains the records.
11. A method comprising:
storing, by a first node, a plurality of records of an in-memory database;
receiving, by a second node, a search query from a client;
in response to receiving, by a third node, the search query from the second node, querying, by the third node, the records based on the search query, identifying, by the third node, a record from the records, determining, by the third node, a score for the record, and sending, by the third node, a search result to the second node, wherein the search result links to the record based on the score satisfying a threshold value; and
in response to receiving, by a fourth node, the search result from the second node, generating, by the fourth node, a file containing a content derived from the search result, wherein each of the first node, the third node, and the fourth node is a distinct node.
12. The method of claim 11, wherein the second node is distinct from the first node, the third node, and the fourth node.
13. The method of claim 11, wherein the fourth node identifies a data linkage in the search result, wherein the record is a first record containing a first content, wherein the records comprise a second record containing the second content, wherein the data linkage correlates the first content and the second content.
14. The method of claim 11, further comprising:
receiving, by a fifth node, a heartbeat signal from at least one of the first node, the second node, the third node, or the fourth node, wherein the heartbeat signal comprises a node status, wherein the fifth node supervises the at least one of the first node, the second node, the third node, or the fourth node.
15. The method of claim 14, wherein the fifth node sends a configuration file to at least one of the first node, the second node, the third node, or the fourth node based on the sixth node determining the configuration to be misconfigured.
16. The method of claim 14, further comprising:
monitoring, by a sixth node, a status based on the heartbeat signal received via the fifth node, wherein the status is of a configuration at least one of the first node, the second node, the third node, or the fourth node.
17. The method of claim 16, wherein the status is monitored via a tree stored at least one of local or remote from the sixth node.
18. The method of claim 17, wherein the fifth node is distinct from the sixth node.
19. The method of claim 11, further comprising:
partitioning, by a fifth node, a collection of the records into a partition according to the schema file; and
sending, by the fifth node, the partition to the first node according to the schema file such that the first node stores the records in a fragmented manner according to the schema file, wherein the partition contains the records.
20. The method of claim 11, further comprising:
partitioning, by a fifth node, a collection of the records into a partition according to a schema file; and
sending, by the fifth node, the partition to the first node according to the schema file, wherein the partition contains the records.
US15/243,450 2013-12-02 2016-08-22 Design and implementation of clustered in-memory database Abandoned US20160364471A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US15/243,450 US20160364471A1 (en) 2013-12-02 2016-08-22 Design and implementation of clustered in-memory database

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201361910841P 2013-12-02 2013-12-02
US14/558,254 US9430547B2 (en) 2013-12-02 2014-12-02 Implementation of clustered in-memory database
US15/243,450 US20160364471A1 (en) 2013-12-02 2016-08-22 Design and implementation of clustered in-memory database

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US14/558,254 Continuation US9430547B2 (en) 2013-12-02 2014-12-02 Implementation of clustered in-memory database

Publications (1)

Publication Number Publication Date
US20160364471A1 true US20160364471A1 (en) 2016-12-15

Family

ID=53265491

Family Applications (2)

Application Number Title Priority Date Filing Date
US14/558,254 Active US9430547B2 (en) 2013-12-02 2014-12-02 Implementation of clustered in-memory database
US15/243,450 Abandoned US20160364471A1 (en) 2013-12-02 2016-08-22 Design and implementation of clustered in-memory database

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US14/558,254 Active US9430547B2 (en) 2013-12-02 2014-12-02 Implementation of clustered in-memory database

Country Status (7)

Country Link
US (2) US9430547B2 (en)
EP (1) EP3077927A4 (en)
JP (1) JP2017504874A (en)
KR (1) KR20160124743A (en)
CN (1) CN106462575A (en)
CA (1) CA2932402C (en)
WO (1) WO2015084760A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106909467A (en) * 2017-02-28 2017-06-30 郑州云海信息技术有限公司 A kind of distributed transaction processing method based on micro services framework
CN108804446A (en) * 2017-04-28 2018-11-13 西安科技大市场创新云服务股份有限公司 A kind of data retrieval method and system

Families Citing this family (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9547701B2 (en) 2013-12-02 2017-01-17 Qbase, LLC Method of discovering and exploring feature knowledge
US9201744B2 (en) 2013-12-02 2015-12-01 Qbase, LLC Fault tolerant architecture for distributed computing systems
KR20160124743A (en) 2013-12-02 2016-10-28 큐베이스 엘엘씨 Design and implementation of clustered in-memory database
US9025892B1 (en) 2013-12-02 2015-05-05 Qbase, LLC Data record compression with progressive and/or selective decomposition
US9659108B2 (en) 2013-12-02 2017-05-23 Qbase, LLC Pluggable architecture for embedding analytics in clustered in-memory databases
US9424294B2 (en) 2013-12-02 2016-08-23 Qbase, LLC Method for facet searching and search suggestions
US9355152B2 (en) 2013-12-02 2016-05-31 Qbase, LLC Non-exclusionary search within in-memory databases
US9348573B2 (en) * 2013-12-02 2016-05-24 Qbase, LLC Installation and fault handling in a distributed system utilizing supervisor and dependency manager nodes
US20160191665A1 (en) * 2014-12-31 2016-06-30 Samsung Electronics Co., Ltd. Computing system with distributed compute-enabled storage group and method of operation thereof
EP3091449B1 (en) * 2015-05-04 2018-07-25 Deloitte Consulting GmbH Operating a database system
US10120938B2 (en) * 2015-08-01 2018-11-06 MapScallion LLC Systems and methods for automating the transmission of partitionable search results from a search engine
US10268710B2 (en) * 2015-10-07 2019-04-23 Oracle International Corporation Relational database organization for sharding
CN106250443A (en) * 2016-07-27 2016-12-21 福建富士通信息软件有限公司 The method and system of data base's complex text inquiry are solved based on internal memory full-text search
CN106776848B (en) * 2016-11-04 2020-04-17 广州市诚毅科技软件开发有限公司 Database query method and device
CN106777225B (en) * 2016-12-26 2021-04-06 腾讯科技(深圳)有限公司 Data migration method and system
US10685019B2 (en) * 2017-04-14 2020-06-16 Salesforce.Com, Inc. Secure query interface
CN109299100B (en) * 2018-10-12 2019-08-30 第四范式(北京)技术有限公司 Managing internal memory data and the method and system for safeguarding data in memory
US11544239B2 (en) 2018-11-13 2023-01-03 Thoughtspot, Inc. Low-latency database analysis using external data sources
US11416477B2 (en) * 2018-11-14 2022-08-16 Thoughtspot, Inc. Systems and methods for database analysis
EP3899749A1 (en) * 2018-12-21 2021-10-27 Telefonaktiebolaget LM Ericsson (publ) Performing operations based on distributedly stored data
CN109977119A (en) * 2019-03-25 2019-07-05 浙江大学 Data classification and storage method for bioelectronics mixing man-made organ system
US11210018B2 (en) * 2019-05-20 2021-12-28 Honeywell International Inc. Holistic linking of data across data sources
US11106698B2 (en) * 2019-06-11 2021-08-31 Sap Se Multi-master with ownership transfer
US11586620B2 (en) 2019-07-29 2023-02-21 Thoughtspot, Inc. Object scriptability
US11194773B2 (en) 2019-09-12 2021-12-07 Oracle International Corporation Integration of existing databases into a sharding environment
CN111090687B (en) * 2019-12-24 2023-03-10 腾讯科技(深圳)有限公司 Data processing method, device and system and computer readable storage medium
US11379495B2 (en) 2020-05-20 2022-07-05 Thoughtspot, Inc. Search guidance
CN112486992B (en) * 2020-11-30 2023-11-21 深圳供电局有限公司 Data storage method and system
CN112380275B (en) * 2021-01-15 2021-07-23 北京金山云网络技术有限公司 Data query method and device and electronic equipment
US11580111B2 (en) 2021-04-06 2023-02-14 Thoughtspot, Inc. Distributed pseudo-random subset generation
CN113411237B (en) * 2021-08-18 2021-11-30 成都丰硕智能数字科技有限公司 Method, storage medium and system for detecting terminal state with low delay

Family Cites Families (113)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6128660A (en) 1996-03-21 2000-10-03 Hearme Network match maker
US6178529B1 (en) 1997-11-03 2001-01-23 Microsoft Corporation Method and system for resource monitoring of disparate resources in a server cluster
JP4183311B2 (en) 1997-12-22 2008-11-19 株式会社リコー Document annotation method, annotation device, and recording medium
US6353926B1 (en) 1998-07-15 2002-03-05 Microsoft Corporation Software update notification
US6266781B1 (en) 1998-07-20 2001-07-24 Academia Sinica Method and apparatus for providing failure detection and recovery with predetermined replication style for distributed applications in a network
US6338092B1 (en) 1998-09-24 2002-01-08 International Business Machines Corporation Method, system and computer program for replicating data in a distributed computed environment
US6959300B1 (en) * 1998-12-10 2005-10-25 At&T Corp. Data compression method and apparatus
US7099898B1 (en) 1999-08-12 2006-08-29 International Business Machines Corporation Data access system
US6738759B1 (en) 2000-07-07 2004-05-18 Infoglide Corporation, Inc. System and method for performing similarity searching using pointer optimization
US8692695B2 (en) 2000-10-03 2014-04-08 Realtime Data, Llc Methods for encoding and decoding data
US6832373B2 (en) 2000-11-17 2004-12-14 Bitfone Corporation System and method for updating and distributing information
US6691109B2 (en) * 2001-03-22 2004-02-10 Turbo Worx, Inc. Method and apparatus for high-performance sequence comparison
GB2374687A (en) 2001-04-19 2002-10-23 Ibm Managing configuration changes in a data processing system
US7082478B2 (en) 2001-05-02 2006-07-25 Microsoft Corporation Logical semantic compression
US6961723B2 (en) 2001-05-04 2005-11-01 Sun Microsystems, Inc. System and method for determining relevancy of query responses in a distributed network search mechanism
US20030028869A1 (en) 2001-08-02 2003-02-06 Drake Daniel R. Method and computer program product for integrating non-redistributable software applications in a customer driven installable package
US6954456B2 (en) 2001-12-14 2005-10-11 At & T Corp. Method for content-aware redirection and content renaming
US6829606B2 (en) 2002-02-14 2004-12-07 Infoglide Software Corporation Similarity search engine for use with relational databases
US7421478B1 (en) 2002-03-07 2008-09-02 Cisco Technology, Inc. Method and apparatus for exchanging heartbeat messages and configuration information between nodes operating in a master-slave configuration
US6817558B1 (en) 2002-04-23 2004-11-16 Uop Llc Parallel sizing, dosing and transfer assembly and method of use
US8015143B2 (en) 2002-05-22 2011-09-06 Estes Timothy W Knowledge discovery agent system and method
US20040010502A1 (en) 2002-07-12 2004-01-15 Bomfim Joanes Depaula In-memory database for high performance, parallel transaction processing
US7570262B2 (en) 2002-08-08 2009-08-04 Reuters Limited Method and system for displaying time-series data and correlated events derived from text mining
US7249312B2 (en) 2002-09-11 2007-07-24 Intelligent Results Attribute scoring for unstructured content
US7058846B1 (en) 2002-10-17 2006-06-06 Veritas Operating Corporation Cluster failover for storage management services
CA2425045C (en) * 2003-04-08 2013-01-15 Ibm Canada Limited - Ibm Canada Limitee Method and system for executing a database query
US20040205064A1 (en) 2003-04-11 2004-10-14 Nianjun Zhou Adaptive search employing entropy based quantitative information measurement
US7543174B1 (en) 2003-09-24 2009-06-02 Symantec Operating Corporation Providing high availability for an application by rapidly provisioning a node and failing over to the node
US9009153B2 (en) 2004-03-31 2015-04-14 Google Inc. Systems and methods for identifying a named entity
US7818615B2 (en) 2004-09-16 2010-10-19 Invensys Systems, Inc. Runtime failure management of redundantly deployed hosts of a supervisory process control data acquisition facility
US7403945B2 (en) 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US20060179026A1 (en) 2005-02-04 2006-08-10 Bechtel Michael E Knowledge discovery tool extraction and integration
US20060294071A1 (en) 2005-06-28 2006-12-28 Microsoft Corporation Facet extraction and user feedback for ranking improvement and personalization
US7630977B2 (en) 2005-06-29 2009-12-08 Xerox Corporation Categorization including dependencies between different category systems
US8386463B2 (en) * 2005-07-14 2013-02-26 International Business Machines Corporation Method and apparatus for dynamically associating different query execution strategies with selective portions of a database table
US7681075B2 (en) 2006-05-02 2010-03-16 Open Invention Network Llc Method and system for providing high availability to distributed computer applications
US20070073708A1 (en) 2005-09-28 2007-03-29 Smith Adam D Generation of topical subjects from alert search terms
US7447940B2 (en) 2005-11-15 2008-11-04 Bea Systems, Inc. System and method for providing singleton services in a cluster
US8341622B1 (en) 2005-12-15 2012-12-25 Crimson Corporation Systems and methods for efficiently using network bandwidth to deploy dependencies of a software package
US7899871B1 (en) 2006-01-23 2011-03-01 Clearwell Systems, Inc. Methods and systems for e-mail topic classification
US7519613B2 (en) 2006-02-28 2009-04-14 International Business Machines Corporation Method and system for generating threads of documents
US8726267B2 (en) 2006-03-24 2014-05-13 Red Hat, Inc. Sharing software certification and process metadata
US8892509B2 (en) * 2006-03-28 2014-11-18 Oracle America, Inc. Systems and methods for a distributed in-memory database
US8190742B2 (en) 2006-04-25 2012-05-29 Hewlett-Packard Development Company, L.P. Distributed differential store with non-distributed objects and compression-enhancing data-object routing
US20070282959A1 (en) 2006-06-02 2007-12-06 Stern Donald S Message push with pull of information to a communications computing device
US8615800B2 (en) 2006-07-10 2013-12-24 Websense, Inc. System and method for analyzing web content
US7624118B2 (en) * 2006-07-26 2009-11-24 Microsoft Corporation Data processing over very large databases
US8122026B1 (en) 2006-10-20 2012-02-21 Google Inc. Finding and disambiguating references to entities on web pages
US7853611B2 (en) 2007-02-26 2010-12-14 International Business Machines Corporation System and method for deriving a hierarchical event based database having action triggers based on inferred probabilities
US9535911B2 (en) 2007-06-29 2017-01-03 Pulsepoint, Inc. Processing a content item with regard to an event
US8332258B1 (en) 2007-08-03 2012-12-11 At&T Mobility Ii Llc Business to business dynamic pricing system
US20090043792A1 (en) * 2007-08-07 2009-02-12 Eric Lawrence Barsness Partial Compression of a Database Table Based on Historical Information
US8442969B2 (en) 2007-08-14 2013-05-14 John Nicholas Gross Location based news and search engine
GB2453174B (en) 2007-09-28 2011-12-07 Advanced Risc Mach Ltd Techniques for generating a trace stream for a data processing apparatus
KR100898339B1 (en) 2007-10-05 2009-05-20 한국전자통신연구원 Autonomous fault processing system in home network environments and operation method thereof
US8594996B2 (en) 2007-10-17 2013-11-26 Evri Inc. NLP-based entity recognition and disambiguation
US8396838B2 (en) 2007-10-17 2013-03-12 Commvault Systems, Inc. Legal compliance, electronic discovery and electronic document handling of online and offline copies of data
US8375073B1 (en) 2007-11-12 2013-02-12 Google Inc. Identification and ranking of news stories of interest
US8294763B2 (en) 2007-12-14 2012-10-23 Sri International Method for building and extracting entity networks from video
US20090216734A1 (en) 2008-02-21 2009-08-27 Microsoft Corporation Search based on document associations
US8326847B2 (en) 2008-03-22 2012-12-04 International Business Machines Corporation Graph search system and method for querying loosely integrated data
WO2009117835A1 (en) 2008-03-27 2009-10-01 Hotgrinds Canada Search system and method for serendipitous discoveries with faceted full-text classification
US8712926B2 (en) 2008-05-23 2014-04-29 International Business Machines Corporation Using rule induction to identify emerging trends in unstructured text streams
US8358308B2 (en) * 2008-06-27 2013-01-22 Microsoft Corporation Using visual techniques to manipulate data
CA2686796C (en) 2008-12-03 2017-05-16 Trend Micro Incorporated Method and system for real time classification of events in computer integrity system
US8874576B2 (en) 2009-02-27 2014-10-28 Microsoft Corporation Reporting including filling data gaps and handling uncategorized data
US20100235311A1 (en) 2009-03-13 2010-09-16 Microsoft Corporation Question and answer search
US8213725B2 (en) 2009-03-20 2012-07-03 Eastman Kodak Company Semantic event detection using cross-domain knowledge
US8161048B2 (en) 2009-04-24 2012-04-17 At&T Intellectual Property I, L.P. Database analysis using clusters
US8055933B2 (en) 2009-07-21 2011-11-08 International Business Machines Corporation Dynamic updating of failover policies for increased application availability
US9165034B2 (en) 2009-10-15 2015-10-20 Hewlett-Packard Development Company, L.P. Heterogeneous data source management
US8645372B2 (en) 2009-10-30 2014-02-04 Evri, Inc. Keyword-based search engine results using enhanced query strategies
US20110125764A1 (en) 2009-11-26 2011-05-26 International Business Machines Corporation Method and system for improved query expansion in faceted search
JP5576384B2 (en) 2010-01-29 2014-08-20 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ Data processing device
US9710556B2 (en) 2010-03-01 2017-07-18 Vcvc Iii Llc Content recommendation based on collections of entities
US8595234B2 (en) 2010-05-17 2013-11-26 Wal-Mart Stores, Inc. Processing data feeds
US9189357B2 (en) 2010-05-25 2015-11-17 Red Hat, Inc. Generating machine state verification using number of installed package objects
US8429256B2 (en) 2010-05-28 2013-04-23 Red Hat, Inc. Systems and methods for generating cached representations of host package inventories in remote package repositories
US8345998B2 (en) 2010-08-10 2013-01-01 Xerox Corporation Compression scheme selection based on image data type and user selections
US8321443B2 (en) * 2010-09-07 2012-11-27 International Business Machines Corporation Proxying open database connectivity (ODBC) calls
US20120102121A1 (en) 2010-10-25 2012-04-26 Yahoo! Inc. System and method for providing topic cluster based updates
US8423522B2 (en) 2011-01-04 2013-04-16 International Business Machines Corporation Query-aware compression of join results
KR101502896B1 (en) * 2011-02-14 2015-03-24 주식회사 케이티 Distributed memory cluster control apparatus and method using map reduce
US20120246154A1 (en) 2011-03-23 2012-09-27 International Business Machines Corporation Aggregating search results based on associating data instances with knowledge base entities
KR20120134916A (en) 2011-06-03 2012-12-12 삼성전자주식회사 Storage device and data processing device for storage device
US20120310934A1 (en) * 2011-06-03 2012-12-06 Thomas Peh Historic View on Column Tables Using a History Table
US9104979B2 (en) 2011-06-16 2015-08-11 Microsoft Technology Licensing, Llc Entity recognition using probabilities for out-of-collection data
WO2013003770A2 (en) 2011-06-30 2013-01-03 Openwave Mobility Inc. Database compression system and method
US9032387B1 (en) 2011-10-04 2015-05-12 Amazon Technologies, Inc. Software distribution framework
US9026480B2 (en) 2011-12-21 2015-05-05 Telenav, Inc. Navigation system with point of interest classification mechanism and method of operation thereof
US9037579B2 (en) 2011-12-27 2015-05-19 Business Objects Software Ltd. Generating dynamic hierarchical facets from business intelligence artifacts
US10908792B2 (en) 2012-04-04 2021-02-02 Recorded Future, Inc. Interactive event-based information system
US20130290232A1 (en) 2012-04-30 2013-10-31 Mikalai Tsytsarau Identifying news events that cause a shift in sentiment
US10162766B2 (en) * 2012-04-30 2018-12-25 Sap Se Deleting records in a multi-level storage architecture without record locks
US8948789B2 (en) 2012-05-08 2015-02-03 Qualcomm Incorporated Inferring a context from crowd-sourced activity data
US9275135B2 (en) 2012-05-29 2016-03-01 International Business Machines Corporation Annotating entities using cross-document signals
US20130325660A1 (en) 2012-05-30 2013-12-05 Auto 100 Media, Inc. Systems and methods for ranking entities based on aggregated web-based content
US9053420B2 (en) 2012-09-25 2015-06-09 Reunify Llc Methods and systems for scalable group detection from multiple data streams
US9703833B2 (en) 2012-11-30 2017-07-11 Sap Se Unification of search and analytics
US9542652B2 (en) 2013-02-28 2017-01-10 Microsoft Technology Licensing, Llc Posterior probability pursuit for entity disambiguation
US20140255003A1 (en) 2013-03-05 2014-09-11 Google Inc. Surfacing information about items mentioned or presented in a film in association with viewing the film
US9104710B2 (en) 2013-03-15 2015-08-11 Src, Inc. Method for cross-domain feature correlation
US8977600B2 (en) * 2013-05-24 2015-03-10 Software AG USA Inc. System and method for continuous analytics run against a combination of static and real-time data
US9087005B2 (en) 2013-05-31 2015-07-21 International Business Machines Corporation Increasing resiliency of a distributed computing system through lifeboat monitoring
US9734221B2 (en) * 2013-09-12 2017-08-15 Sap Se In memory database warehouse
CN106164890A (en) 2013-12-02 2016-11-23 丘贝斯有限责任公司 For the method eliminating the ambiguity of the feature in non-structured text
US9355152B2 (en) 2013-12-02 2016-05-31 Qbase, LLC Non-exclusionary search within in-memory databases
US9223875B2 (en) 2013-12-02 2015-12-29 Qbase, LLC Real-time distributed in memory search architecture
US9025892B1 (en) 2013-12-02 2015-05-05 Qbase, LLC Data record compression with progressive and/or selective decomposition
US9659108B2 (en) * 2013-12-02 2017-05-23 Qbase, LLC Pluggable architecture for embedding analytics in clustered in-memory databases
US9424294B2 (en) 2013-12-02 2016-08-23 Qbase, LLC Method for facet searching and search suggestions
US9201744B2 (en) 2013-12-02 2015-12-01 Qbase, LLC Fault tolerant architecture for distributed computing systems
KR20160124743A (en) 2013-12-02 2016-10-28 큐베이스 엘엘씨 Design and implementation of clustered in-memory database

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106909467A (en) * 2017-02-28 2017-06-30 郑州云海信息技术有限公司 A kind of distributed transaction processing method based on micro services framework
CN108804446A (en) * 2017-04-28 2018-11-13 西安科技大市场创新云服务股份有限公司 A kind of data retrieval method and system

Also Published As

Publication number Publication date
CA2932402C (en) 2018-07-31
EP3077927A4 (en) 2017-07-12
US20150154200A1 (en) 2015-06-04
WO2015084760A1 (en) 2015-06-11
CN106462575A (en) 2017-02-22
EP3077927A1 (en) 2016-10-12
KR20160124743A (en) 2016-10-28
JP2017504874A (en) 2017-02-09
US9430547B2 (en) 2016-08-30
CA2932402A1 (en) 2015-06-11

Similar Documents

Publication Publication Date Title
US9430547B2 (en) Implementation of clustered in-memory database
US9785521B2 (en) Fault tolerant architecture for distributed computing systems
CN108351900B (en) Relational database organization for sharding
US9223875B2 (en) Real-time distributed in memory search architecture
CA2932403A1 (en) Systems and methods for hosting an in-memory database
US9830342B2 (en) Optimizing database deduplication
US20170220647A1 (en) Pluggable architecture for embedding analytics in clustered in-memory databases
US10877810B2 (en) Object storage system with metadata operation priority processing
US20180165469A1 (en) Access operation request management
US11636124B1 (en) Integrating query optimization with machine learning model prediction
US11113265B2 (en) Information processing apparatus and information processing system
US11657069B1 (en) Dynamic compilation of machine learning models based on hardware configurations
US11907197B2 (en) Volume placement failure isolation and reporting
US11671494B2 (en) Volume placement based on resource usage
US20240119037A1 (en) Techniques for adaptive independent compression of key and non-key portions of database rows in index organized tables (iots)
US20240126750A1 (en) Accelerating query execution by optimizing data transfer between storage nodes and database nodes

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION