US8239535B2 - Network architecture with load balancing, fault tolerance and distributed querying - Google Patents

Network architecture with load balancing, fault tolerance and distributed querying Download PDF

Info

Publication number
US8239535B2
US8239535B2 US11/313,589 US31358905A US8239535B2 US 8239535 B2 US8239535 B2 US 8239535B2 US 31358905 A US31358905 A US 31358905A US 8239535 B2 US8239535 B2 US 8239535B2
Authority
US
United States
Prior art keywords
data
end server
retrieved
identified
visitor
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.)
Active, expires
Application number
US11/313,589
Other versions
US20060274761A1 (en
Inventor
Christopher Reid Error
Michael Paul Bailey
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.)
Adobe Inc
Original Assignee
Adobe Systems Inc
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 Adobe Systems Inc filed Critical Adobe Systems Inc
Priority to US11/313,589 priority Critical patent/US8239535B2/en
Assigned to OMNITURE, INC. reassignment OMNITURE, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: BAILEY, MICHAEL PAUL, ERROR, CHRISTOPHER R.
Publication of US20060274761A1 publication Critical patent/US20060274761A1/en
Assigned to WELLS FARGO FOOTHILL, LLC, AS AGENT reassignment WELLS FARGO FOOTHILL, LLC, AS AGENT SECURITY AGREEMENT Assignors: OMNITURE, INC.
Assigned to OMNITURE, INC. reassignment OMNITURE, INC. RELEASE BY SECURED PARTY (SEE DOCUMENT FOR DETAILS). Assignors: WELLS FARGO FOOTHILL, LLC
Assigned to ADOBE SYSTEMS INCORPORATED reassignment ADOBE SYSTEMS INCORPORATED ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: OMNITURE, INC.
Application granted granted Critical
Publication of US8239535B2 publication Critical patent/US8239535B2/en
Assigned to ADOBE INC. reassignment ADOBE INC. CHANGE OF NAME (SEE DOCUMENT FOR DETAILS). Assignors: ADOBE SYSTEMS INCORPORATED
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/06Generation of reports
    • H04L43/065Generation of reports related to network devices
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1012Server selection for load balancing based on compliance of requirements or conditions with available server resources
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1034Reaction to server failures by a load balancer

Definitions

  • This invention relates generally to system for responding to data queries. For example for web analytics data. More particularly, the present invention relates a system and method that reduce the time for response to multiple queries by load balancing over computing devices while also providing fault tolerance.
  • Web analytics basically refers to the analysis of data created by website usage. For instance, web analytics could be used to mine visitor traffic data. A variety of visitor traffic data is measured such as what web browser is being used, what links on a given web page were selected, whether a product was purchase, etc. There are number of web analytics tools presently available such as Site Catalyst version 11 from Omniture of Orem, Utah.
  • the present invention is a network architecture with load balancing, fault tolerance and distributed querying.
  • the system of the present invention preferably comprises a plurality of front-end servers, a plurality of back-end servers, and a database.
  • the front-end servers are coupled to a network to receive data requests from client devices.
  • the front-end servers are each coupled to the plurality of back-end servers.
  • the front-end servers handle data requests at a macro level and divide the request into sub-requests that are sent to the plurality of back-end servers.
  • the back-end servers are coupled to the database to retrieve data. Each data request is distributed across the plurality of back-end servers according to workload.
  • the front-end servers are fault tolerant in that they can respond to a request for data without all of the back-end servers being responsive or providing data.
  • the present invention also includes a plurality of methods including: a method for distributed querying, a method for loading data sets from a database, and a method for responding to a query that provides fault tolerance.
  • FIG. 1 is a block diagram of a system for operating, web analytics tools of the present invention.
  • FIG. 2 is block diagram of a preferred embodiment of a network according to the present invention.
  • FIG. 3 is graphical representation of data in a database including a data set and slices of the data set.
  • FIG. 4 is a flowchart of one embodiment of a method for accessing a web analytics system and running queries according to the present invention.
  • FIG. 5 is a flowchart of one embodiment of a method for loading a data set according to the present invention.
  • FIG. 6 is a flowchart of one embodiment of a method for responding to a query or request for data according to the present invention.
  • FIG. 7 is graphical representation of load balancing across multiple back-end servers at different points in time for multiple visitors each having a data set including multiple slices.
  • the present invention is a network architecture with load balancing, fault tolerance and distributed querying. While the present invention and its principles will now be described in the context of a network 102 used as part of a web analytics system, this is only by way of example. Those skilled in the art will recognize that the present invention may be used in any variety of general purpose databases to provide the same advantages as noted below.
  • the present invention also relates to apparatus for performing the operations herein.
  • This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer.
  • a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
  • FIG. 1 there is shown an example of an architecture for practicing the present invention according to one embodiment.
  • One skilled in the art will recognize that the invention can be practiced using other embodiments that differ from the examples shown.
  • Java client 101 runs on a personal computer for viewing and interacting with website usage reports. Client 101 sends reports to display 107 (or other output device) for output to the user.
  • Network 102 is a centralized network for handling and responding to client requests for data on website usage.
  • the user interface is implemented using a known environment such as Macromedia Flex, Java, DHTML, or any combination thereof.
  • Java client 101 sends query 103 to network 102 , specifying which reports are requested, and optionally specifying one or more filters for the reports.
  • query 103 is in XML format.
  • network 102 returns hashed data 104 that contains an encoded representation of the report data.
  • the hashed data 104 may specify, in hash coded terms, the number of visitors that were using a specific web browser and that visited the website within a specified time period. This hashed data 104 is received by client 101 .
  • Client 101 stores, in local cache 109 , a list of previously received and decoded hash codes, so that it can correctly interpret a hash code that it has encountered previously.
  • local cache 109 is cleared at the end of a session, so that only those codes previously received in the same session are stored in cache 109 .
  • local cache 109 is implemented in a more persistent or less persistent fashion, depending on user needs.
  • client 101 Upon receiving hashed data 104 , client 101 consults cache 109 ; if cache 109 contains the hash code(s) in data 104 (in other words, if client 101 has previously received data containing the same hash code), client 101 can interpret the meaning of the hash-coded data without any further communication with network 102 . If hash code(s) from data 104 is/are not present in cache 109 , client 101 sends hash query 105 to network 102 ; network 102 responds by sending hash translation 106 to client 101 . Hash translation 106 provides client 101 with the meaning of hash terms (for example, specifying that hash term #299 signifies a user using Internet Explorer 6.0). In one embodiment, client 101 stores this meaning in cache 109 for future use.
  • the present invention can employ a method for using hash values as disclosed in related U.S. patent application Ser. No. 11/313,443, filed on Dec. 20, 2005, entitled METHOD FOR COMMUNICATION BETWEEN COMPUTING DEVICES USING CODED VALUES.
  • client 101 Once client 101 has received sufficient data to generate a report, it sends report 108 to display 107 for output to the user. In one embodiment, if some hash meanings have not yet been received, client 101 still sends report 108 , and report 108 states that certain hash terms are unknown. In another embodiment, client 101 displays an error message and/or waits until more complete hash meaning data is available.
  • the user can interact with the displayed report 108 via user input device 110 such as a mouse, a keyboard, or the like.
  • user input device 110 such as a mouse, a keyboard, or the like.
  • the user can click on areas within report 108 ; when the user clicks on an area that can be interpreted as a filter, client 101 generates and sends a new query 103 containing the new report filter criteria.
  • the above process then repeats, and an updated report 108 is sent to display 107 .
  • Network 102 includes any number of front-end web servers 201 a - n that receive queries 103 , 105 from client 101 , and any number of back-end servers 202 a - n that obtain data from storage, analyze the obtained data, and send report data back to client 101 .
  • Back-end servers 202 a - n send an appropriate data set to client 101 based on the filter request. For example, if a filter request specifies that the user is only interested in visitors that used a particular web browser, back-end servers 202 a - n remove the data that does not match the specified criterion, and only forward to client 101 the data that does match.
  • back-end servers 202 a - n are applying a movable filter bar to the data set, maintaining consistency in the views into the data while changing the size of the data set according to the filter request.
  • Database 203 contains website visitation data, which in one embodiment is stored in a binary format stored in some storage medium such as a hard drive.
  • the website visitation data is broken up into files, or “bricks”, to facilitate extraction of portions of the data.
  • servers 202 a - n extract data from database 203 , they are provided with specific bricks that match the criteria.
  • back-end servers 202 a - n extract data from database 203 that contains web visitation logs and/or statistics.
  • servers 202 a - n obtain data from database 203 that represents a snapshot of website visitation over a specified time period.
  • Servers 202 a - n then store this website visitation data in temporary local storage (such as random access memory), using for example a binary format that is encoded according to a hash algorithm so as to minimize bandwidth usage.
  • this binary format is identical to the format used in database 203 , so that no file format translation need be performed when servers 202 a - n extract data from database 203 .
  • Servers 202 a - n and then apply filters as requested, and send the filtered data to client 101 .
  • the back-end servers 202 a - n perform a new data extraction from database 203 .
  • the step of data extraction may be performed using any combination of data ranges for the data in the database 203 and is not restricted to splitting the data by date range. In alternate embodiments, any other values could be used to partition the data.
  • the front-end servers 201 a - n are coupled 204 for communication with the back-end servers 202 a - n .
  • Each front-end server 201 a - n can be connected 204 to the other back-end servers 202 a - n as shown, or a variety of other network topologies may be used so long as messages can be broadcast among the front-end servers 201 a - n and the back-end servers 202 a - n.
  • FIG. 3 illustrates how and where the data is stored and processed in order to respond to requests or queries from the client 101 .
  • All the website visitation data 302 is stored in the database 203 .
  • the website visitation data 302 can be for multiple clients 101 and includes all the data about web statistics for those sites.
  • a data set 304 is extracted from all the data 302 in the database 203 for use by the client 101 .
  • the data set 304 is preferably smaller in size than all the data 302 so that it can be effectively transmitted and manipulated. In an exemplary embodiment, the data set 1 MB in size.
  • the data set 304 is advantageously created on a per client visit or client session basis.
  • the data set 304 is further divided for processing by individual backend servers 202 a - n into data slices 306 .
  • the data slices 306 are preferably each a complete uncompromised segment of the data set 304 that can be used to provide a statistically valid response to a query.
  • the division of slices 306 across backend servers 202 a - n is described in more detail below with reference to FIGS. 5 and 7 , but is particularly advantageous because it provides improved speed in responding to queries since each slice can be processed in parallel.
  • the distribution of slices over the backend servers 202 a - n provides a level of fault tolerance because if one more the backend servers 202 a - n do not provide their a response for their slice, the system, in particular the front-end servers 201 a - n are able to generated a response from those back-end servers 202 a - n that do respond and scale it so that it is representative of the entire data set as will be discussed below with reference to FIG. 6 .
  • the process begins when a visitor or client 101 logs 402 onto the system. Upon log in, each visitor is assigned 404 a visitor identification number. This visitor identification number is used to assign the visitor/client 101 to a particular one of the plurality of front-end servers 210 a - n . It does not matter which front-end server 210 a - n is assigned to the visitor/client 101 ; and the front-end servers 210 a - n are preferably assigned to accomplish load balancing of requests across the plurality of front-end servers 210 a - n .
  • the visitors with identification number 1 - 100 are assigned to front-end server 201 a
  • visitors with identification number 200 - 300 are assigned to front-end server 201 b
  • visitors with identification number 300 - 400 are assigned to front-end server 201 c
  • front-end server 201 a - n there is a variety of other ways to distribute visitors over the front-end servers 201 a - n such as every nth visitor being assigned to front-end server 201 a , every n+1 visitor assigned to front-end server 201 b , etc.
  • the step of logging in is optional and that in an alternate embodiment, a user need not log in, but rather clients 101 can just send data requests to one of the front-end servers 210 a - n ; and the front-end server 210 a - n that receives the request can respond to it.
  • step 406 based on the ID number the visitor, the corresponding front-end servers 210 a - n is notified and communication is established between that front-end server 210 a - n and the visitor. Then the assigned front-end server 210 a - n divides the request into slices and sends them to the back-end servers 202 a - n to retrieve 408 the data set 304 and load it to the back-end servers 202 a - n , as will be described in more detail below with reference to FIG. 5 .
  • One advantage of the present invention is that the data set is divided into slices and the slices are assigned to one or more back-end servers 202 a - n based on the availability of the back-end servers 202 a - n .
  • the system continues to determine 416 if the network 102 has failed (either all the front-end servers 201 a - n or not operational or all the back-end servers 202 a - n are not operational) if so the process ends. If not the process returns to step 412 to continue to process additional requests from the visitor. If the front-end server 201 determined the visitor has logged out or there are has been a predetermined amount of time of inactivity by the visitor in step 414 , the front-end server 210 will clear 418 the data set 304 for the visitor from the back-end servers 202 a - n . This is particularly advantageous because it optimizes the use of the front-end servers 201 a - n and ensures that only in-use data is loaded on the back-end servers 202 a - n.
  • the process for loading 408 the data set 304 to the back-end servers 202 a - n begins in step 502 with the front-end server 201 identifying the data set 304 corresponding to the visitor. It should be noted that the data is not associated with the visitor, but rather data that is need by a visitor remains loaded on the back-end servers 202 a - n such that if another visitor needs the data it remains loaded until a predetermined time of non-use has elapsed after which the backend servers 202 a - n are not required to keep the data loaded. Then the front-end sever 201 divides 504 the data set into a plurality of slices 306 .
  • each of the slices 306 is a complete uncompromised segment of the data set 304 that can be used to provide a statistically valid response to a query.
  • the front-end sever 201 selects 506 a slice 306 and broadcasts a request for one of the back-end severs 202 to retrieve the slice 306 .
  • This request is preferably broadcast to all available back-end servers 202 such as with a UDP broadcast message.
  • Each back-end server 202 a - n reports 508 its load and availability to the front-end server 201 .
  • the load and availability of a particular back-end server 202 a - n can be based on a variety of factor including: the number of slices already being processed, the processing power/speed of the back-end server 202 , the communication/connection speed available to the back-end server 202 , and other processing characteristics as will understood to those of ordinary skill in the art.
  • the front-end sever 201 selects 510 the back-end server 202 a - n with the lowest load and best availability and transfers control to the selected back-end server 202 . This selection is solely to achieve load balancing across the back-end servers 202 a - n .
  • the selected back-end server 202 then loads 512 the identified slice 306 from the database 203 , and sends a confirmation message back to the front-end server 201 indicating the data slice 306 has been loaded.
  • the selected back-end server 202 records 512 the percentage of the data set 304 that the slice 306 represents. Then the selected back-end server 202 transfers 516 control back to the front-end server 201 . Then the front-end server 201 determines 518 whether there are any more slices 306 of the data set 304 to be loaded to back-end server 202 a - n . If so the process returns to step 506 to repeat the process for the next data slice 306 .
  • a key advantage of the present invention is that the process for loading data slices 306 to the back-end servers 202 a - n is masterless and done in an anarchistic way. In other words, maintenance of the data is masterless.
  • one of the front-end servers 201 a - n temporarily acts as an overseer to divide the data set into slices and send a request to load the slice to which every back-end servers 202 a - n will accept the request.
  • step 506 - 516 for given slices may be done in whole or part in parallel by broadcasting such requests between the front-end server 201 and the back-end servers 202 a - n before the remaining steps 512 - 516 complete.
  • the front-end server 201 does not care which back-end server 202 a - n responds to the request to retrieve the slice 306 of the data set 304 , nor does it track which of the back-end servers 202 a - n responded and holds the data slice 306 .
  • FIG. 7 an example of the load and how it is balanced over four back-end servers 202 a - 202 d at four different times T 1 -T 4 is shown.
  • time T 0 (not shown) there are no visitors and no slices are loaded on any of the back-end servers 202 a - d .
  • a visitor, V 1 logs onto the system and its data set is loaded.
  • a time T 1 there are only three servers active, servers 202 a - c .
  • the data set 304 for the first visitor (V 1 ) has three slices (S 1 -S 3 ).
  • a first slice (V 1 S 1 ) is loaded on back-end server 202 a
  • a second slice (V 1 S 2 ) is loaded on back-end server 202 b
  • a third slice (V 1 S 3 ) is loaded on back-end server 202 c .
  • a second visitor V 2 with a data set 304 having four data slices V 1 -V 4 is loaded onto the back-end servers 203 a - c .
  • an additional server 202 d is added to the back-end, and a new visitor V 4 with a data set 304 having four slices S 1 -S 4 logs onto the system. Because the additional server 202 d is new and has a high availability, all four of the slices for visitor V 4 S 1 -V 4 S 4 are loaded on the new back end server 202 d as shown at time T 4 in FIG. 7 . Thus, those skilled in the art will understand how back-end servers 202 can easily be added when additional capacity is needed. Similarly, when a server 202 fails or need to be removed, it can respond to the front-end server 201 with no availability until there are no slices loaded on it then it may be removed. This increased the fault recovery of the system.
  • FIG. 6 one embodiment of the method for processing a query is shown.
  • the data set has already been loaded on the back-end servers 202 a - n as discussed above with reference to FIGS. 5 and 7 .
  • the process begins with a query from a visitor received 602 at the front-end server 201 .
  • the front-end server 201 assigned to communicate with the visitor according the visitor's number generates and sends 604 a broadcast query to all or a plurality of back end servers 202 .
  • the query needs to broadcast to a plurality, but preferably as many as possible of the back-end servers 202 . Then each of the back-end servers 202 receives the query or request, and determines 606 if they have the data for the query. Then in step 608 , the back-end servers 202 that have the data for the query, perform the query on their portion of the data set 304 . Each of the back-end servers 202 that have data send the result data and what percentage of the entire data set 304 they have back to the front-end server 201 .
  • the front-end server 201 determines if 100% of the data set has been returned by whatever responses it received from the back-end severs 202 . If so, the method proceeds to step 614 where it combines the result data received from each of the back-end servers 202 and sends it to the visitor, and the response to the query is complete.
  • step 612 If in step 612 , it is determined that less than 100% of the data set 304 has been returned, the method continues to step 616 where the front-end server 201 combines the result data from the back-end servers 202 . Then the percentage of data from the data set 304 is determined 618 . This can be done by summing the percentages received from each back-end server 202 for this visitor for this request from step 610 . Then the front-end server 201 multiplies 620 the data from the query by the inverse of the percentage determined in step 618 . Then the multiplied values are sent 622 to the visitor as the result data for the query or request.
  • the front-end server 201 is still able to create a response from the back-end servers 202 that do respond. This provides a significant advantage of fault tolerance in the event one of the back-end servers 202 fails or does not respond to the data request in a timely manner.
  • the rules applied can be dynamic depending on the size of the data set 304 . For example, if the data set is large, a response by 50% of the slices may be sufficient, whereas if the data set is small, a higher percentage such as 80% of the slices must be present to send valid data back to the visitor.
  • modules, routines, features, attributes, methodologies and other aspects of the present invention can be implemented as software, hardware, firmware or any combination of the three.
  • a component an example of which is a module, of the present invention is implemented as software
  • the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of ordinary skill in the art of computer programming.
  • the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the present invention, which is set forth in the following claims.

Abstract

A network architecture with load balancing, fault tolerance and distributed querying comprises a plurality of front-end servers, a plurality of back-end servers, and a database. The front-end servers are coupled to a network to receive data requests from client devices. The front-end servers are each coupled to the plurality of back-end servers. The front-end servers handle data requests at a macro level and divide the request into sub-requests that are sent to the plurality of back-end servers. The back-end servers are coupled to the database to retrieve data. Each data request is distributed across the plurality of back-end servers according to workload. The front-end servers are fault tolerant in that they can respond to a request for data without all of the back-end servers being responsive or providing data. The present invention also includes a plurality of methods including: a method for distributed querying, a method for loading data sets from a database, and a method for responding to a query that provides fault tolerance.

Description

CROSS-REFERENCES TO RELATED APPLICATIONS
The present application claims priority under 35 U.S.C. §119(e) to U.S. Provisional Patent Application No. 60/688,104, filed on Jun. 6, 2005, entitled “NETWORK ARCHITECTURE WITH LOAD BALANCING, FAULT TOLERANCE AND DISTRIBUTED QUERYING” which is incorporated by reference in its entirety.
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates generally to system for responding to data queries. For example for web analytics data. More particularly, the present invention relates a system and method that reduce the time for response to multiple queries by load balancing over computing devices while also providing fault tolerance.
2. Background of the Invention
Web analytics basically refers to the analysis of data created by website usage. For instance, web analytics could be used to mine visitor traffic data. A variety of visitor traffic data is measured such as what web browser is being used, what links on a given web page were selected, whether a product was purchase, etc. There are number of web analytics tools presently available such as Site Catalyst version 11 from Omniture of Orem, Utah.
One problem with such existing tools and systems is there ability to respond to requests for information from thousands of users requesting thousands of different data groups. There is also a need for a system that provides fault tolerance in case where a failure occurs for a portion the network or system. Finally, there is need to optimize the usage of different groups of machines by load balancing while not reducing processing speed by adding administrative over head to accomplish load balancing.
SUMMARY OF THE INVENTION
The present invention is a network architecture with load balancing, fault tolerance and distributed querying. The system of the present invention preferably comprises a plurality of front-end servers, a plurality of back-end servers, and a database. The front-end servers are coupled to a network to receive data requests from client devices. The front-end servers are each coupled to the plurality of back-end servers. The front-end servers handle data requests at a macro level and divide the request into sub-requests that are sent to the plurality of back-end servers. The back-end servers are coupled to the database to retrieve data. Each data request is distributed across the plurality of back-end servers according to workload. The front-end servers are fault tolerant in that they can respond to a request for data without all of the back-end servers being responsive or providing data. The present invention also includes a plurality of methods including: a method for distributed querying, a method for loading data sets from a database, and a method for responding to a query that provides fault tolerance.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a system for operating, web analytics tools of the present invention.
FIG. 2 is block diagram of a preferred embodiment of a network according to the present invention.
FIG. 3 is graphical representation of data in a database including a data set and slices of the data set.
FIG. 4 is a flowchart of one embodiment of a method for accessing a web analytics system and running queries according to the present invention.
FIG. 5 is a flowchart of one embodiment of a method for loading a data set according to the present invention.
FIG. 6 is a flowchart of one embodiment of a method for responding to a query or request for data according to the present invention.
FIG. 7 is graphical representation of load balancing across multiple back-end servers at different points in time for multiple visitors each having a data set including multiple slices.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
The present invention is a network architecture with load balancing, fault tolerance and distributed querying. While the present invention and its principles will now be described in the context of a network 102 used as part of a web analytics system, this is only by way of example. Those skilled in the art will recognize that the present invention may be used in any variety of general purpose databases to provide the same advantages as noted below.
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention can be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to avoid obscuring the invention.
The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus.
The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein.
Architecture
Referring now to FIG. 1, there is shown an example of an architecture for practicing the present invention according to one embodiment. One skilled in the art will recognize that the invention can be practiced using other embodiments that differ from the examples shown.
Java client 101 runs on a personal computer for viewing and interacting with website usage reports. Client 101 sends reports to display 107 (or other output device) for output to the user. Network 102 is a centralized network for handling and responding to client requests for data on website usage.
In one embodiment, the user interface is implemented using a known environment such as Macromedia Flex, Java, DHTML, or any combination thereof.
In one embodiment, the components shown in FIG. 1 operate as follows. When a report is to be displayed, Java client 101 sends query 103 to network 102, specifying which reports are requested, and optionally specifying one or more filters for the reports. In one embodiment, query 103 is in XML format.
In response to query 103, network 102 returns hashed data 104 that contains an encoded representation of the report data. For example, the hashed data 104 may specify, in hash coded terms, the number of visitors that were using a specific web browser and that visited the website within a specified time period. This hashed data 104 is received by client 101.
Client 101 stores, in local cache 109, a list of previously received and decoded hash codes, so that it can correctly interpret a hash code that it has encountered previously. In one embodiment, local cache 109 is cleared at the end of a session, so that only those codes previously received in the same session are stored in cache 109. In other embodiments, local cache 109 is implemented in a more persistent or less persistent fashion, depending on user needs.
Upon receiving hashed data 104, client 101 consults cache 109; if cache 109 contains the hash code(s) in data 104 (in other words, if client 101 has previously received data containing the same hash code), client 101 can interpret the meaning of the hash-coded data without any further communication with network 102. If hash code(s) from data 104 is/are not present in cache 109, client 101 sends hash query 105 to network 102; network 102 responds by sending hash translation 106 to client 101. Hash translation 106 provides client 101 with the meaning of hash terms (for example, specifying that hash term #299 signifies a user using Internet Explorer 6.0). In one embodiment, client 101 stores this meaning in cache 109 for future use. By way of example, the present invention can employ a method for using hash values as disclosed in related U.S. patent application Ser. No. 11/313,443, filed on Dec. 20, 2005, entitled METHOD FOR COMMUNICATION BETWEEN COMPUTING DEVICES USING CODED VALUES.
Once client 101 has received sufficient data to generate a report, it sends report 108 to display 107 for output to the user. In one embodiment, if some hash meanings have not yet been received, client 101 still sends report 108, and report 108 states that certain hash terms are unknown. In another embodiment, client 101 displays an error message and/or waits until more complete hash meaning data is available.
The user can interact with the displayed report 108 via user input device 110 such as a mouse, a keyboard, or the like. The user can click on areas within report 108; when the user clicks on an area that can be interpreted as a filter, client 101 generates and sends a new query 103 containing the new report filter criteria. The above process then repeats, and an updated report 108 is sent to display 107.
Referring now to FIG. 2, there is shown an example of an architecture for network 102 according to one embodiment. Network 102 includes any number of front-end web servers 201 a-n that receive queries 103, 105 from client 101, and any number of back-end servers 202 a-n that obtain data from storage, analyze the obtained data, and send report data back to client 101. Back-end servers 202 a-n send an appropriate data set to client 101 based on the filter request. For example, if a filter request specifies that the user is only interested in visitors that used a particular web browser, back-end servers 202 a-n remove the data that does not match the specified criterion, and only forward to client 101 the data that does match. Conceptually, back-end servers 202 a-n are applying a movable filter bar to the data set, maintaining consistency in the views into the data while changing the size of the data set according to the filter request.
Database 203 contains website visitation data, which in one embodiment is stored in a binary format stored in some storage medium such as a hard drive. In one embodiment, the website visitation data is broken up into files, or “bricks”, to facilitate extraction of portions of the data. When servers 202 a-n extract data from database 203, they are provided with specific bricks that match the criteria.
In one embodiment, when the user requests a report showing website visitation data for a specified time period, back-end servers 202 a-n extract data from database 203 that contains web visitation logs and/or statistics. In one embodiment, servers 202 a-n obtain data from database 203 that represents a snapshot of website visitation over a specified time period. Servers 202 a-n then store this website visitation data in temporary local storage (such as random access memory), using for example a binary format that is encoded according to a hash algorithm so as to minimize bandwidth usage. In one embodiment, this binary format is identical to the format used in database 203, so that no file format translation need be performed when servers 202 a-n extract data from database 203. Servers 202 a-n and then apply filters as requested, and send the filtered data to client 101.
In one embodiment, whenever the user requests a broader date range for website visitation data, the back-end servers 202 a-n perform a new data extraction from database 203. However, when the user narrows the date range from a previously specified range, no new data extraction is performed; rather back-end servers 202 a-n filter the previously extracted data according to the new filter parameters. Those skilled in the art will recognize that the step of data extraction may be performed using any combination of data ranges for the data in the database 203 and is not restricted to splitting the data by date range. In alternate embodiments, any other values could be used to partition the data.
As shown in FIG. 2, the front-end servers 201 a-n are coupled 204 for communication with the back-end servers 202 a-n. Each front-end server 201 a-n can be connected 204 to the other back-end servers 202 a-n as shown, or a variety of other network topologies may be used so long as messages can be broadcast among the front-end servers 201 a-n and the back-end servers 202 a-n.
Data Set
Referring now to FIG. 3, the storage and retrieval of data by the network 102 can best be understood. FIG. 3 illustrates how and where the data is stored and processed in order to respond to requests or queries from the client 101. All the website visitation data 302 is stored in the database 203. The website visitation data 302 can be for multiple clients 101 and includes all the data about web statistics for those sites. A data set 304 is extracted from all the data 302 in the database 203 for use by the client 101. The data set 304 is preferably smaller in size than all the data 302 so that it can be effectively transmitted and manipulated. In an exemplary embodiment, the data set 1 MB in size. The data set 304 is advantageously created on a per client visit or client session basis. The data set 304 is further divided for processing by individual backend servers 202 a-n into data slices 306. The data slices 306 are preferably each a complete uncompromised segment of the data set 304 that can be used to provide a statistically valid response to a query. The division of slices 306 across backend servers 202 a-n is described in more detail below with reference to FIGS. 5 and 7, but is particularly advantageous because it provides improved speed in responding to queries since each slice can be processed in parallel. Moreover, the distribution of slices over the backend servers 202 a-n provides a level of fault tolerance because if one more the backend servers 202 a-n do not provide their a response for their slice, the system, in particular the front-end servers 201 a-n are able to generated a response from those back-end servers 202 a-n that do respond and scale it so that it is representative of the entire data set as will be discussed below with reference to FIG. 6.
General Query Method
Referring now to FIG. 4, a preferred method for operation of the present invention will be described. The process begins when a visitor or client 101 logs 402 onto the system. Upon log in, each visitor is assigned 404 a visitor identification number. This visitor identification number is used to assign the visitor/client 101 to a particular one of the plurality of front-end servers 210 a-n. It does not matter which front-end server 210 a-n is assigned to the visitor/client 101; and the front-end servers 210 a-n are preferably assigned to accomplish load balancing of requests across the plurality of front-end servers 210 a-n. For example, in one embodiment, the visitors with identification number 1-100 are assigned to front-end server 201 a, visitors with identification number 200-300 are assigned to front-end server 201 b, visitors with identification number 300-400 are assigned to front-end server 201 c, etc. Those skilled in the art will recognize that there is a variety of other ways to distribute visitors over the front-end servers 201 a-n such as every nth visitor being assigned to front-end server 201 a, every n+1 visitor assigned to front-end server 201 b, etc. This is assignment is particularly advantageous because is provides load balancing across the front-end servers 210 a-n, and also fault recovery in the event a front-end server 210 a-n fails, its visitors end their connection, but upon re-login will be assigned to one of the remaining operational front-end servers 210 a-n. Those skilled in the art will also understand that the step of logging in is optional and that in an alternate embodiment, a user need not log in, but rather clients 101 can just send data requests to one of the front-end servers 210 a-n; and the front-end server 210 a-n that receives the request can respond to it.
In step 406, based on the ID number the visitor, the corresponding front-end servers 210 a-n is notified and communication is established between that front-end server 210 a-n and the visitor. Then the assigned front-end server 210 a-n divides the request into slices and sends them to the back-end servers 202 a-n to retrieve 408 the data set 304 and load it to the back-end servers 202 a-n, as will be described in more detail below with reference to FIG. 5. One advantage of the present invention is that the data set is divided into slices and the slices are assigned to one or more back-end servers 202 a-n based on the availability of the back-end servers 202 a-n. Once the data set 304 has been loaded to the back-end servers 202 a-n, they notify 410 the front-end server 201. The visitor can now run 412 queries on the data set 304, as will be described in more detail below with reference to FIG. 6. Once a query has been run, the front-end server 201 communicating with the visitor determines 414 if the visitor has logged out or there are has been a predetermined amount of time of inactivity by the visitor. If not, the system continues to determine 416 if the network 102 has failed (either all the front-end servers 201 a-n or not operational or all the back-end servers 202 a-n are not operational) if so the process ends. If not the process returns to step 412 to continue to process additional requests from the visitor. If the front-end server 201 determined the visitor has logged out or there are has been a predetermined amount of time of inactivity by the visitor in step 414, the front-end server 210 will clear 418 the data set 304 for the visitor from the back-end servers 202 a-n. This is particularly advantageous because it optimizes the use of the front-end servers 201 a-n and ensures that only in-use data is loaded on the back-end servers 202 a-n.
Load Balancing
Referring now to FIG. 5, the process for loading 408 the data set 304 to the back-end servers 202 a-n is shown. The process begins in step 502 with the front-end server 201 identifying the data set 304 corresponding to the visitor. It should be noted that the data is not associated with the visitor, but rather data that is need by a visitor remains loaded on the back-end servers 202 a-n such that if another visitor needs the data it remains loaded until a predetermined time of non-use has elapsed after which the backend servers 202 a-n are not required to keep the data loaded. Then the front-end sever 201 divides 504 the data set into a plurality of slices 306. As has been noted above, each of the slices 306 is a complete uncompromised segment of the data set 304 that can be used to provide a statistically valid response to a query. Then the front-end sever 201 selects 506 a slice 306 and broadcasts a request for one of the back-end severs 202 to retrieve the slice 306. This request is preferably broadcast to all available back-end servers 202 such as with a UDP broadcast message. Each back-end server 202 a -n reports 508 its load and availability to the front-end server 201. The load and availability of a particular back-end server 202 a-n can be based on a variety of factor including: the number of slices already being processed, the processing power/speed of the back-end server 202, the communication/connection speed available to the back-end server 202, and other processing characteristics as will understood to those of ordinary skill in the art. Next, the front-end sever 201 selects 510 the back-end server 202 a-n with the lowest load and best availability and transfers control to the selected back-end server 202. This selection is solely to achieve load balancing across the back-end servers 202 a-n. The selected back-end server 202 then loads 512 the identified slice 306 from the database 203, and sends a confirmation message back to the front-end server 201 indicating the data slice 306 has been loaded. The selected back-end server 202 records 512 the percentage of the data set 304 that the slice 306 represents. Then the selected back-end server 202 transfers 516 control back to the front-end server 201. Then the front-end server 201 determines 518 whether there are any more slices 306 of the data set 304 to be loaded to back-end server 202 a-n. If so the process returns to step 506 to repeat the process for the next data slice 306.
It should be recognized that a key advantage of the present invention is that the process for loading data slices 306 to the back-end servers 202 a-n is masterless and done in an anarchistic way. In other words, maintenance of the data is masterless. During loading of the data, one of the front-end servers 201 a-n temporarily acts as an overseer to divide the data set into slices and send a request to load the slice to which every back-end servers 202 a-n will accept the request. However, once the data set has been divided into slices and a back-end server 202 a-n has agreed to load the slice, the front-end server 201 a-n acting as the overseer, does nothing further to confirm the data is loaded or make sure the back-end server 202 a-n load or maintain the data. The process of performing step 506-516 for given slices may be done in whole or part in parallel by broadcasting such requests between the front-end server 201 and the back-end servers 202 a-n before the remaining steps 512-516 complete. In other words, the front-end server 201 does not care which back-end server 202 a-n responds to the request to retrieve the slice 306 of the data set 304, nor does it track which of the back-end servers 202 a-n responded and holds the data slice 306.
Referring now also to FIG. 7, an example of the load and how it is balanced over four back-end servers 202 a-202 d at four different times T1-T4 is shown. At time T0 (not shown) there are no visitors and no slices are loaded on any of the back-end servers 202 a-d. Between time T0 and T1, a visitor, V1 logs onto the system and its data set is loaded. A time T1, there are only three servers active, servers 202 a-c. The data set 304 for the first visitor (V1) has three slices (S1-S3). As the requests are sent to the back-end servers 202 a-c, different servers respond with their availability and the slices are assigned to the sever with the best availability; for example a first slice (V1S1) is loaded on back-end server 202 a, a second slice (V1S2) is loaded on back-end server 202 b, and a third slice (V1S3) is loaded on back-end server 202 c. Between time T1 and time T2, a second visitor V2 with a data set 304 having four data slices V1-V4 is loaded onto the back-end servers 203 a-c. As the requests are sent to the back-end servers 202 a-c, different servers respond; and a first and four slices (V2S1, V2VS4) are loaded on back-end server 202 a, a second slice (V2S2) is loaded on back-end server 202 b, and a third slice (V2S3) is loaded on back-end server 202 c. Between time T2 and time T3, a third visitor V3 with a data set 304 having three data slices V1-V3 is loaded onto the back-end servers 203 a-c. As the requests are sent to the back-end servers 202 a-c, different servers respond; and a first slice (V3S1) is loaded on back-end server 202 c, a second and third slice (V3S2, V3S3) are loaded on back-end server 202 b, and no slices for the third visitor V3 are loaded on back-end server 202 a. From the above transitions, it can be seen how the system automatically balances the load over the three back-end servers 202 a-c based on their availability. Another key feature of the present invention in the ability to add additional back end servers 202 a-d. Between time T3 and T4, an additional server 202 d is added to the back-end, and a new visitor V4 with a data set 304 having four slices S1-S4 logs onto the system. Because the additional server 202 d is new and has a high availability, all four of the slices for visitor V4S1-V4S4 are loaded on the new back end server 202 d as shown at time T4 in FIG. 7. Thus, those skilled in the art will understand how back-end servers 202 can easily be added when additional capacity is needed. Similarly, when a server 202 fails or need to be removed, it can respond to the front-end server 201 with no availability until there are no slices loaded on it then it may be removed. This increased the fault recovery of the system.
Distributed Query
Referring now to FIG. 6, one embodiment of the method for processing a query is shown. Before the process begins, the data set has already been loaded on the back-end servers 202 a-n as discussed above with reference to FIGS. 5 and 7. As shown in FIG. 6, the process begins with a query from a visitor received 602 at the front-end server 201. Then the front-end server 201 assigned to communicate with the visitor according the visitor's number generates and sends 604 a broadcast query to all or a plurality of back end servers 202. Since the front-end server 201 does not know which of the back-end servers 202 store the data set 304 for this visitor, the query needs to broadcast to a plurality, but preferably as many as possible of the back-end servers 202. Then each of the back-end servers 202 receives the query or request, and determines 606 if they have the data for the query. Then in step 608, the back-end servers 202 that have the data for the query, perform the query on their portion of the data set 304. Each of the back-end servers 202 that have data send the result data and what percentage of the entire data set 304 they have back to the front-end server 201. Next, the front-end server 201 determines if 100% of the data set has been returned by whatever responses it received from the back-end severs 202. If so, the method proceeds to step 614 where it combines the result data received from each of the back-end servers 202 and sends it to the visitor, and the response to the query is complete.
If in step 612, it is determined that less than 100% of the data set 304 has been returned, the method continues to step 616 where the front-end server 201 combines the result data from the back-end servers 202. Then the percentage of data from the data set 304 is determined 618. This can be done by summing the percentages received from each back-end server 202 for this visitor for this request from step 610. Then the front-end server 201 multiplies 620 the data from the query by the inverse of the percentage determined in step 618. Then the multiplied values are sent 622 to the visitor as the result data for the query or request. This is particularly advantageous because if for any reason some of the back-end servers 202 are unable to respond to the query or request, the front-end server 201 is still able to create a response from the back-end servers 202 that do respond. This provides a significant advantage of fault tolerance in the event one of the back-end servers 202 fails or does not respond to the data request in a timely manner. Those skilled in the art will recognize that there may be a variety of additional rules applied to steps 616-622 in determining what data to send back to the visitor, whether there is enough data for a statistically valid response, etc. Moreover, the rules applied can be dynamic depending on the size of the data set 304. For example, if the data set is large, a response by 50% of the slices may be sufficient, whereas if the data set is small, a higher percentage such as 80% of the slices must be present to send valid data back to the visitor.
The foregoing description of the embodiments of the present invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of the present invention be limited not by this detailed description, but rather by the claims of this application. As will be understood by those familiar with the art, the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. Likewise, the particular naming and division of the modules, routines, features, attributes, methodologies and other aspects are not mandatory or significant, and the mechanisms that implement the present invention or its features may have different names, divisions and/or formats. Furthermore, as will be apparent to one of ordinary skill in the relevant art, the modules, routines, features, attributes, methodologies and other aspects of the present invention can be implemented as software, hardware, firmware or any combination of the three. Of course, wherever a component, an example of which is a module, of the present invention is implemented as software, the component can be implemented as a standalone program, as part of a larger program, as a plurality of separate programs, as a statically or dynamically linked library, as a kernel loadable module, as a device driver, and/or in every and any other way known now or in the future to those of ordinary skill in the art of computer programming. Additionally, the present invention is in no way limited to implementation in any specific programming language, or for any specific operating system or environment. Accordingly, the disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the present invention, which is set forth in the following claims.

Claims (26)

1. A system for responding to requests for data from a client device, the system comprising: a front-end server configured to: receive a request for data from a client; identify a data set to be retrieved, wherein the identified data set comprises stored data that corresponds to the requested data; identify a plurality of slices of data to be retrieved, wherein each identified slice of data to be retrieved comprises a complete uncompromised segment of the identified data set that can be used to provide a statistically valid response to the request for data such that the front-end server is capable of generating a statistically valid response to the request upon receiving data corresponding to less than all of the plurality of slices of data identified; generate a plurality of sub-requests, wherein each of the plurality of sub-requests corresponds to an identified slice of data to be retrieved; communicate the plurality of sub-requests to one or more of a plurality of back-end servers; receive data corresponding to less than all of the plurality of slices of data identified; and generate, in response to receiving data corresponding to less than all of the plurality of slices of data identified, a statistically valid response to the request for data, wherein to generate the statistically valid response, the front-end server is further configured to scale the data received to account for data that is not received; wherein each respective back-end server is configured to: receive one or more of the plurality of sub-requests from the first front-end server; load, from a database, a portion of the stored data corresponding to the identified slice of data to be retrieved that corresponds to the one or more sub-requests received at the respective back-end server; and transmit, to the front-end server, data corresponding to the identified slice of data loaded from the database; and wherein the database comprises the stored data, wherein the database is configured to communicate, to each respective back-end server, a portion of the stored data corresponding to the identified slice of data to be retrieved that corresponds to the one or more sub-requests received at the respective back-end server.
2. The system of claim 1, wherein the system further comprises a second front-end server configured to: receive a request for data from a client; identify a data set to be retrieved, wherein the identified data set comprises stored data that corresponds to the requested data; identify a plurality of slices of data to be retrieved, wherein each identified slice of data to be retrieved is a complete uncompromised segment of the identified data set to be retrieved; generate a plurality of sub-requests, wherein each of the plurality of sub-requests corresponds to an identified slice of data to be retrieved; and communicate the plurality of sub-requests to one or more of the plurality of back-end servers.
3. The system of claim 1, wherein the back-end servers filter the data in response to a filter request and based on criterion provided by the front-end servers.
4. The system of claim 1, wherein the stored data comprises website visitation data stored in a binary format.
5. The system of claim 4, wherein a binary format used to send the data to the client is encoded according to a hash algorithm so as to minimize bandwidth usage, the binary format is identical to the format used in database so that no file format translation need be performed when back-end servers extract data from the database.
6. The system of claim 1, wherein the back-end servers store and process the portion of the stored data received from the database.
7. The system of claim 1, wherein sub-request are distributed to one or more of the plurality of the back-end servers according to the load and availability of each of the plurality of the back-end servers.
8. The system of claim 1, wherein to generate the statistically valid response, the front-end server is further configured to determine statistical validity for the response depending on a size of the data set request for data comprises scaling the data received to account for data that is not received.
9. The system of claim 1, wherein to communicate the plurality of sub-requests to one or more of a plurality of back-end servers, the front-end server is further configured to: communicate, to a first of the back-end servers, a first of the plurality of sub-requests corresponding to a first identified slice of data to be retrieved; and communicate, to a second of the back-end servers, a second of the plurality of sub-requests corresponding to a second identified slice of data to be retrieved, wherein to receive the data corresponding to less than all of the plurality of slices of data identified, the front-end server is further configured to: receive, from at least the first back-end server, a response comprising data corresponding to the first sub-request and the first identified slice of data to be retrieved; and fail to receive, from at least the second back-end server, a response comprising data corresponding to the second sub-request and the second identified slice of data to be retrieved, and wherein to generate the statistically valid response to, the front-end server is further configured to: scale the data of responses received to generate a statistically valid response based at least on the received response comprising data corresponding to the first sub-request and the first identified slice of data to be retrieved.
10. A method for accessing a web analytics system and responding to a query, the method comprising the steps of: assigning a visitor to one of a plurality of front-end servers; receiving a query for data from the visitor; identifying a data set to be retrieved, wherein the identified data set comprises stored data that corresponds to the queried data; identifying a plurality of slices of data to be retrieved, wherein each identified slice of data to be retrieved is a complete uncompromised segment of the identified data set that can be used to provide a statistically valid response to the query for data such that the front-end server is capable of generating a statistically valid response to the query upon receiving data corresponding to less than all of the plurality of slices of data identified; generating a plurality of sub-requests, wherein each of the plurality of sub-requests corresponds to an identified slice of data to be retrieved; communicating the plurality of sub-requests to one or more of a plurality of back-end servers; wherein each respective back-end server is configured to: receive one or more of the plurality of sub-requests from the first front-end server; retrieve, from a database, a portion of the stored data corresponding to the identified slice of data to be retrieved that corresponds to the one or more sub-requests received at the respective back-end server; and notify the front-end server that the portion of the stored data is loaded into the respective back-end server; receiving, from the plurality of back-end servers, data corresponding to less than all of the plurality of slices of data identified; generating, in response to receiving data corresponding to less than all of the plurality of slices of data identified, a statistically valid response to the request for data, wherein said generating the statistically valid response comprises scaling the data received to account for data that is not received; and sending the statistically valid response as the response to the query.
11. The method of claim 10, wherein the step of assigning the visitor to one of the plurality of front-end servers is performed to load balance a plurality of visitors among the plurality of front-end servers.
12. The method of claim 10, wherein assigning the visitor to one of the plurality of front-end servers comprises the steps of: receiving the query from the visitor; assigning the visitor a visitor identification number; and assigning the visitor to one of a plurality of front-end servers based on the visitor identification number assigned to the visitor.
13. The method of claim 12, wherein the step of assigning the visitor to one of a plurality of front-end servers assigns the visitor to a first front-end server if the visitor identification number is in a first group, and assigns the visitor to a second front-end server if the visitor identification number is from a second group.
14. A method for loading a data set from a database to a plurality of back-end servers, the method comprising the steps of: identifying a data set to be retrieved corresponding to a visitor; identifying a plurality of slices of data to be retrieved, wherein each identified slice of data to be retrieved is a complete uncompromised segment of the identified data set that can be used to provide a statistically valid response to a request for data such that a front-end server receiving data is capable of generating a statistically valid response to the request upon receiving data corresponding to less than all of the plurality of slices of data identified, and wherein a determination of statistical validity for the response depends on a size of the data set; generating a request for a selected slice of the plurality of slices of data to be retrieved; determining which of the plurality of back-end servers has the lowest load based on the load and availability for the plurality of back-end servers; selecting a back-end sever determined to have the lowest load; and sending the request to the selected back-end server.
15. The method of claim 14, wherein the step of sending the request to the selected back-end sever is performed by broadcasting a UDP broadcast message to available backend servers.
16. The method of claim 14, wherein determining which of the plurality of back-end servers has the lowest load based on the load and availability of the back-end server is a based on a factor from the group of: a number of slices already being processed, a processing power/speed of the back-end server, a communication/connection speed available to the back-end server, and other processing characteristics.
17. The method of claim 14 wherein the step of selecting the back-end server selects the back-end server with the best availability.
18. The method of claim 14 further comprises the steps of sending a confirmation message indicating the data slice has been loaded into the back end server.
19. The method of claim 14, further comprising:
transmitting a confirmation message from the selected back-end server, the confirmation message indicating a visitor identification, number for the slice and percentage of the data set that the slice represents.
20. The method of claim 14 wherein some of steps are performed by a frontend server and wherein the process for loading data slices is masterless and is done in an anarchistic way.
21. A method for responding to a query for data from a client, the method comprising the steps of: receiving at a front-end server a query from a visitor, the visitor corresponding to a data set; identifying a data set to be retrieved, wherein the identified data set comprises stored data that corresponds to the data set corresponding to the visitor; identifying a plurality of slices of data to be retrieved, wherein each identified slice of data to be retrieved is a complete uncompromised segment of the identified data set to be retrieved that can be used to provide a statistically valid response to the request for data such that the front-end server is capable of generating a statistically valid response to the request upon receiving data corresponding to less than all of the plurality of slices of data identified, and wherein a determination of statistical validity for the response depends on a size of the data set; generating by the front-end server a broadcast request for at least one of the plurality of slices of data to be retrieved, the broadcast request being sent to a plurality of back-end servers including at least a first back-end server, the broadcast request including a visitor identification number assigned to the visitor; where at least one of the back-end severs is configured to: receive the broadcast request; determine whether the back-end server holds at least one of the plurality of slices of data to be retrieved; perform, responsive to determining that the back-end server holds a slice of data to be retrieved, at least a portion of the query on the back-end server to generate result data including the data to be retrieved held by the back-end server; and send the result data in association with the visitor identification number to the front-end server.
22. The method of claim 21 wherein the broadcast request is sent to as many as possible of plurality of the back-end servers.
23. The method of claim 21 wherein the step of sending result data includes sending a percentage of the data set that the result data represents.
24. The method of claim 23 further comprising the steps of: determining that the entire data set has been received by the front-end server; upon determining that the entire data set has been received by the front end server: combining responses from the plurality of back-end servers; and sending the combined response to the client.
25. The method of claim 23 further comprising the steps of: determining that less than the entire data set has been received by the front-end server; upon determining that less than the entire data set has been received by the front end server: combining responses from the plurality of back-end servers; determining the percentage of the data set received, multiplying the data from the request by the inverse of the determined percentage; and sending the multiplied data to the client.
26. The method of claim 23 further comprising the steps of comparing the determined percentage of the data set received to a threshold, and sending a message indicating there is not enough data for a statistically valid response to the visitor if the determined percentage is less than the threshold.
US11/313,589 2005-06-06 2005-12-20 Network architecture with load balancing, fault tolerance and distributed querying Active 2029-11-04 US8239535B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/313,589 US8239535B2 (en) 2005-06-06 2005-12-20 Network architecture with load balancing, fault tolerance and distributed querying

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US68810405P 2005-06-06 2005-06-06
US11/313,589 US8239535B2 (en) 2005-06-06 2005-12-20 Network architecture with load balancing, fault tolerance and distributed querying

Publications (2)

Publication Number Publication Date
US20060274761A1 US20060274761A1 (en) 2006-12-07
US8239535B2 true US8239535B2 (en) 2012-08-07

Family

ID=37494032

Family Applications (1)

Application Number Title Priority Date Filing Date
US11/313,589 Active 2029-11-04 US8239535B2 (en) 2005-06-06 2005-12-20 Network architecture with load balancing, fault tolerance and distributed querying

Country Status (1)

Country Link
US (1) US8239535B2 (en)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100217796A1 (en) * 2007-10-09 2010-08-26 Cleversafe, Inc. Integrated client for use with a dispersed data storage network
US20120226702A1 (en) * 2009-09-23 2012-09-06 Zte Corporation Data Query System and Constructing Method Thereof and Corresponding Data Query Method
US20120246263A1 (en) * 2011-03-25 2012-09-27 Fujitsu Limited Data transfer apparatus, data transfer method, and information processing apparatus
US9069774B1 (en) * 2008-11-04 2015-06-30 Infoblox Inc. Graphical visualization and management of networks
US9098565B1 (en) * 2009-10-08 2015-08-04 Cellco Partnership In-house elegant JDBC connection pooling solution for message broker

Families Citing this family (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7724657B2 (en) 2004-07-23 2010-05-25 Citrix Systems, Inc. Systems and methods for communicating a lossy protocol via a lossless protocol
KR20070037649A (en) 2004-07-23 2007-04-05 사이트릭스 시스템스, 인크. A method and systems for routing packets from a gateway to an endpoint
US7810089B2 (en) 2004-12-30 2010-10-05 Citrix Systems, Inc. Systems and methods for automatic installation and execution of a client-side acceleration program
US8954595B2 (en) 2004-12-30 2015-02-10 Citrix Systems, Inc. Systems and methods for providing client-side accelerated access to remote applications via TCP buffering
US8255456B2 (en) 2005-12-30 2012-08-28 Citrix Systems, Inc. System and method for performing flash caching of dynamically generated objects in a data communication network
US8239535B2 (en) * 2005-06-06 2012-08-07 Adobe Systems Incorporated Network architecture with load balancing, fault tolerance and distributed querying
WO2007075846A2 (en) * 2005-12-19 2007-07-05 Propero Ltd. Method and system for providing virtualized application workspaces
US8024651B1 (en) 2007-01-30 2011-09-20 Adobe Systems Incorporated Data visualization using tables integrated with hierarchical pie charts
US20080209435A1 (en) * 2007-02-23 2008-08-28 Microsoft Corporation Scalable workflow management system
US8201016B2 (en) * 2007-06-28 2012-06-12 Alcatel Lucent Heartbeat distribution that facilitates recovery in the event of a server failure during a user dialog
US8843630B1 (en) * 2008-08-27 2014-09-23 Amazon Technologies, Inc. Decentralized request routing
US8495176B2 (en) * 2010-08-18 2013-07-23 International Business Machines Corporation Tiered XML services in a content management system
EP2659395A2 (en) 2010-12-28 2013-11-06 Citrix Systems, Inc. Systems and methods for database proxy request switching
US9589029B2 (en) * 2010-12-28 2017-03-07 Citrix Systems, Inc. Systems and methods for database proxy request switching
US9176829B2 (en) * 2011-07-01 2015-11-03 Microsoft Technology Licensing, Llc Managing recovery virtual machines in clustered environment
US9197710B1 (en) 2011-07-20 2015-11-24 Google Inc. Temporal based data string intern pools
US8606907B1 (en) 2011-07-20 2013-12-10 Google Inc. Multi-tiered system for receiving and reporting web site traffic data
US8560685B1 (en) * 2011-07-20 2013-10-15 Google Inc. Probabilistic data storage owner election and replication protocol
US20150363800A1 (en) * 2014-03-27 2015-12-17 Google Inc. Merchant performance evaluation in a computer networked environment
US10832229B2 (en) 2015-12-03 2020-11-10 Mastercard International Incorporated Translating data signals between a frontend interface and a backend server
CN107545015B (en) * 2016-06-29 2020-12-04 华为技术有限公司 Processing method and processing device for query fault
CN110943993A (en) * 2019-12-02 2020-03-31 北京锐安科技有限公司 Method and device for requesting preposition, computer equipment and storage medium
CN114048020B (en) * 2021-09-22 2022-04-26 北京中科金马科技股份有限公司 Guest room management system based on big data
CN114938377A (en) * 2022-04-20 2022-08-23 京东科技信息技术有限公司 Back-end server management method and device, readable medium and electronic equipment

Citations (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6160819A (en) * 1998-02-19 2000-12-12 Gte Internetworking Incorporated Method and apparatus for multiplexing bytes over parallel communications links using data slices
US6285997B1 (en) 1998-11-16 2001-09-04 International Business Machines Corporation Query optimization with deferred update and autonomous sources
US20010049671A1 (en) * 2000-06-05 2001-12-06 Joerg Werner B. e-Stract: a process for knowledge-based retrieval of electronic information
US20020059170A1 (en) * 2000-04-17 2002-05-16 Mark Vange Load balancing between multiple web servers
US20020133400A1 (en) * 2001-03-13 2002-09-19 Boomerangmarketing.Com Incorporated Systems and methods for internet reward service
US6470333B1 (en) * 1998-07-24 2002-10-22 Jarg Corporation Knowledge extraction system and method
US20020194051A1 (en) * 2001-05-31 2002-12-19 Hall Stephen A. Data distribution method and sytem
US20030028640A1 (en) * 2001-07-30 2003-02-06 Vishal Malik Peer-to-peer distributed mechanism
US20030046339A1 (en) * 2001-09-05 2003-03-06 Ip Johnny Chong Ching System and method for determining location and status of computer system server
US20030120660A1 (en) * 2001-12-07 2003-06-26 Maritzen L. Michael Consumer-centric context-aware switching model
US20030154442A1 (en) * 2002-02-13 2003-08-14 Karen Papierniak Visualization tool for web analytics
US20040030739A1 (en) * 2002-08-06 2004-02-12 Homayoun Yousefi'zadeh Database remote replication for multi-tier computer systems by homayoun yousefi'zadeh
US20040059746A1 (en) * 2002-06-28 2004-03-25 Brett Error Capturing and presenting site visitation path data
US20040093425A1 (en) * 2002-11-07 2004-05-13 Thomas David Andrew Method and system for managing fragmented information packets in a computer network
US20040135805A1 (en) * 2003-01-10 2004-07-15 Gottsacker Neal F. Document composition system and method
US20040162822A1 (en) * 2003-02-13 2004-08-19 Khachatur Papanyan Method and apparatus for converting in-line database queries to stored procedures
US20040174397A1 (en) * 2003-03-05 2004-09-09 Paul Cereghini Integration of visualizations, reports, and data
US20040193656A1 (en) * 2003-03-28 2004-09-30 Pizzo Michael J. Systems and methods for caching and invalidating database results and derived objects
US6823391B1 (en) * 2000-10-04 2004-11-23 Microsoft Corporation Routing client requests to back-end servers
US6865605B1 (en) * 2000-10-04 2005-03-08 Microsoft Corporation System and method for transparently redirecting client requests for content using a front-end indicator to preserve the validity of local caching at the client system
US20050080913A1 (en) * 2003-10-09 2005-04-14 Thomas David Andrew Method and system for querying information from a switch by a server in a computer network
US20050080858A1 (en) * 2003-10-10 2005-04-14 Microsoft Corporation System and method for searching a peer-to-peer network
US6898633B1 (en) * 2000-10-04 2005-05-24 Microsoft Corporation Selecting a server to service client requests
US20050114480A1 (en) * 2003-11-24 2005-05-26 Sundaresan Ramamoorthy Dynamically balancing load for servers
US20050125807A1 (en) * 2003-12-03 2005-06-09 Network Intelligence Corporation Network event capture and retention system
US20050182838A1 (en) * 2000-11-10 2005-08-18 Galactic Computing Corporation Bvi/Ibc Method and system for providing dynamic hosted service management across disparate accounts/sites
US20050228855A1 (en) * 2004-03-16 2005-10-13 Masahiro Kawato Acquisition system for distributed computing resources
US20050270299A1 (en) * 2004-03-23 2005-12-08 Rasmussen Jens E Generating and serving tiles in a digital mapping system
US6983338B2 (en) * 2003-04-01 2006-01-03 Dell Products L.P. Coupling device for connectors wherein coupling device comprises multiplexer unit for selectiving first mode for SATA channel and second mode that establishes loop back function
US20060020691A1 (en) * 2004-07-20 2006-01-26 Hewlett-Packard Development Company, L.P. Load balancing based on front-end utilization
US20060080388A1 (en) * 2001-06-20 2006-04-13 Ludmila Cherkasova System and method for workload-aware request distribution in cluster-based network servers
US20060101142A1 (en) * 2004-11-05 2006-05-11 Jean-Philippe Vasseur Technique for selecting a path computation element
US20060155805A1 (en) * 1999-09-01 2006-07-13 Netkingcall, Co., Ltd. Scalable server architecture based on asymmetric 3-way TCP
US20060161554A1 (en) * 2001-03-14 2006-07-20 Microsoft Corporation Schema-Based Services For Identity-Based Data Access
US20060224744A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Sending inter-server notifications using an out-of-band communications protocol
US20060271935A1 (en) * 2005-05-31 2006-11-30 Microsoft Corporation Assignment of clients to tasks in a distributed system
US20060274761A1 (en) * 2005-06-06 2006-12-07 Error Christopher R Network architecture with load balancing, fault tolerance and distributed querying
US20060274763A1 (en) * 2005-06-03 2006-12-07 Error Christopher R Variable sampling rates for website visitation analysis
US7149222B2 (en) * 1999-12-21 2006-12-12 Converged Access, Inc. Integrated access point network device
US7161487B1 (en) * 2003-06-20 2007-01-09 Globeranger Corporation System, method, and logic for processing raw data comprising tag identifiers
US7209148B2 (en) * 2004-03-23 2007-04-24 Google Inc. Generating, storing, and displaying graphics using sub-pixel bitmaps
US20070226320A1 (en) * 2003-10-31 2007-09-27 Yuval Hager Device, System and Method for Storage and Access of Computer Files
US20080022136A1 (en) * 2005-02-18 2008-01-24 Protegrity Corporation Encryption load balancing and distributed policy enforcement
US7337351B2 (en) * 2002-09-18 2008-02-26 Netezza Corporation Disk mirror architecture for database appliance with locally balanced regeneration
US7349960B1 (en) * 2000-05-20 2008-03-25 Ciena Corporation Throttling distributed statistical data retrieval in a network device
US7350229B1 (en) * 2001-03-07 2008-03-25 Netegrity, Inc. Authentication and authorization mapping for a computer network
US7376665B2 (en) * 2003-11-06 2008-05-20 At&T Delaware Intellectual Property, Inc. Systems, methods and computer program products for automating retrieval of data from a DB2 database
US20080133623A1 (en) * 2000-09-08 2008-06-05 Masashi Tsuchida Method and system for managing multiple database storage units
US20080170579A1 (en) * 2003-10-22 2008-07-17 International Business Machines Corporation Methods, apparatus and computer programs for managing performance and resource utilization within cluster-based systems
US20080201357A1 (en) * 2003-06-27 2008-08-21 Omniture, Inc. Page Grouping for Site Traffic Analysis Reports
US7486678B1 (en) * 2002-07-03 2009-02-03 Greenfield Networks Multi-slice network processor
US7525963B2 (en) * 2003-04-24 2009-04-28 Microsoft Corporation Bridging subnet broadcasts across subnet boundaries
US7925665B2 (en) * 2004-03-08 2011-04-12 Siebel Systems, Inc. Using query persistence for efficient subquery evaluation in federated databases

Patent Citations (58)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6160819A (en) * 1998-02-19 2000-12-12 Gte Internetworking Incorporated Method and apparatus for multiplexing bytes over parallel communications links using data slices
US6470333B1 (en) * 1998-07-24 2002-10-22 Jarg Corporation Knowledge extraction system and method
US6285997B1 (en) 1998-11-16 2001-09-04 International Business Machines Corporation Query optimization with deferred update and autonomous sources
US20060155805A1 (en) * 1999-09-01 2006-07-13 Netkingcall, Co., Ltd. Scalable server architecture based on asymmetric 3-way TCP
US7149222B2 (en) * 1999-12-21 2006-12-12 Converged Access, Inc. Integrated access point network device
US20020059170A1 (en) * 2000-04-17 2002-05-16 Mark Vange Load balancing between multiple web servers
US7349960B1 (en) * 2000-05-20 2008-03-25 Ciena Corporation Throttling distributed statistical data retrieval in a network device
US20010049671A1 (en) * 2000-06-05 2001-12-06 Joerg Werner B. e-Stract: a process for knowledge-based retrieval of electronic information
US20080133623A1 (en) * 2000-09-08 2008-06-05 Masashi Tsuchida Method and system for managing multiple database storage units
US6823391B1 (en) * 2000-10-04 2004-11-23 Microsoft Corporation Routing client requests to back-end servers
US6865605B1 (en) * 2000-10-04 2005-03-08 Microsoft Corporation System and method for transparently redirecting client requests for content using a front-end indicator to preserve the validity of local caching at the client system
US6898633B1 (en) * 2000-10-04 2005-05-24 Microsoft Corporation Selecting a server to service client requests
US20050182838A1 (en) * 2000-11-10 2005-08-18 Galactic Computing Corporation Bvi/Ibc Method and system for providing dynamic hosted service management across disparate accounts/sites
US7350229B1 (en) * 2001-03-07 2008-03-25 Netegrity, Inc. Authentication and authorization mapping for a computer network
US20020133400A1 (en) * 2001-03-13 2002-09-19 Boomerangmarketing.Com Incorporated Systems and methods for internet reward service
US20060161554A1 (en) * 2001-03-14 2006-07-20 Microsoft Corporation Schema-Based Services For Identity-Based Data Access
US20020194051A1 (en) * 2001-05-31 2002-12-19 Hall Stephen A. Data distribution method and sytem
US20090083130A1 (en) * 2001-05-31 2009-03-26 Landmark Nv-S Ventures Group, Inc. Data Distribution Method and System
US20060080388A1 (en) * 2001-06-20 2006-04-13 Ludmila Cherkasova System and method for workload-aware request distribution in cluster-based network servers
US20030028640A1 (en) * 2001-07-30 2003-02-06 Vishal Malik Peer-to-peer distributed mechanism
US20030046339A1 (en) * 2001-09-05 2003-03-06 Ip Johnny Chong Ching System and method for determining location and status of computer system server
US20030120660A1 (en) * 2001-12-07 2003-06-26 Maritzen L. Michael Consumer-centric context-aware switching model
US20030154442A1 (en) * 2002-02-13 2003-08-14 Karen Papierniak Visualization tool for web analytics
US20040059746A1 (en) * 2002-06-28 2004-03-25 Brett Error Capturing and presenting site visitation path data
US7486678B1 (en) * 2002-07-03 2009-02-03 Greenfield Networks Multi-slice network processor
US7370064B2 (en) * 2002-08-06 2008-05-06 Yousefi Zadeh Homayoun Database remote replication for back-end tier of multi-tier computer systems
US20040030739A1 (en) * 2002-08-06 2004-02-12 Homayoun Yousefi'zadeh Database remote replication for multi-tier computer systems by homayoun yousefi'zadeh
US7337351B2 (en) * 2002-09-18 2008-02-26 Netezza Corporation Disk mirror architecture for database appliance with locally balanced regeneration
US20040093425A1 (en) * 2002-11-07 2004-05-13 Thomas David Andrew Method and system for managing fragmented information packets in a computer network
US20040135805A1 (en) * 2003-01-10 2004-07-15 Gottsacker Neal F. Document composition system and method
US20040162822A1 (en) * 2003-02-13 2004-08-19 Khachatur Papanyan Method and apparatus for converting in-line database queries to stored procedures
US20040174397A1 (en) * 2003-03-05 2004-09-09 Paul Cereghini Integration of visualizations, reports, and data
US20040193656A1 (en) * 2003-03-28 2004-09-30 Pizzo Michael J. Systems and methods for caching and invalidating database results and derived objects
US6983338B2 (en) * 2003-04-01 2006-01-03 Dell Products L.P. Coupling device for connectors wherein coupling device comprises multiplexer unit for selectiving first mode for SATA channel and second mode that establishes loop back function
US7525963B2 (en) * 2003-04-24 2009-04-28 Microsoft Corporation Bridging subnet broadcasts across subnet boundaries
US7161487B1 (en) * 2003-06-20 2007-01-09 Globeranger Corporation System, method, and logic for processing raw data comprising tag identifiers
US20080201357A1 (en) * 2003-06-27 2008-08-21 Omniture, Inc. Page Grouping for Site Traffic Analysis Reports
US20090037579A1 (en) * 2003-06-27 2009-02-05 Omniture, Inc. Page Grouping For Site Traffic Analysis Reports
US20050080913A1 (en) * 2003-10-09 2005-04-14 Thomas David Andrew Method and system for querying information from a switch by a server in a computer network
US20050080858A1 (en) * 2003-10-10 2005-04-14 Microsoft Corporation System and method for searching a peer-to-peer network
US20080170579A1 (en) * 2003-10-22 2008-07-17 International Business Machines Corporation Methods, apparatus and computer programs for managing performance and resource utilization within cluster-based systems
US20070226320A1 (en) * 2003-10-31 2007-09-27 Yuval Hager Device, System and Method for Storage and Access of Computer Files
US20080222195A1 (en) * 2003-11-06 2008-09-11 At & T Delaware Intellectual Property, Inc. Systems, methods and computer program products for automating retrieval of data from a db2 database
US7376665B2 (en) * 2003-11-06 2008-05-20 At&T Delaware Intellectual Property, Inc. Systems, methods and computer program products for automating retrieval of data from a DB2 database
US20050114480A1 (en) * 2003-11-24 2005-05-26 Sundaresan Ramamoorthy Dynamically balancing load for servers
US20050125807A1 (en) * 2003-12-03 2005-06-09 Network Intelligence Corporation Network event capture and retention system
US7925665B2 (en) * 2004-03-08 2011-04-12 Siebel Systems, Inc. Using query persistence for efficient subquery evaluation in federated databases
US20050228855A1 (en) * 2004-03-16 2005-10-13 Masahiro Kawato Acquisition system for distributed computing resources
US20050270299A1 (en) * 2004-03-23 2005-12-08 Rasmussen Jens E Generating and serving tiles in a digital mapping system
US20070182751A1 (en) * 2004-03-23 2007-08-09 Rasmussen Jens E Generating, Storing, and Displaying Graphics Using Sub-Pixel Bitmaps
US7209148B2 (en) * 2004-03-23 2007-04-24 Google Inc. Generating, storing, and displaying graphics using sub-pixel bitmaps
US20060020691A1 (en) * 2004-07-20 2006-01-26 Hewlett-Packard Development Company, L.P. Load balancing based on front-end utilization
US20060101142A1 (en) * 2004-11-05 2006-05-11 Jean-Philippe Vasseur Technique for selecting a path computation element
US20080022136A1 (en) * 2005-02-18 2008-01-24 Protegrity Corporation Encryption load balancing and distributed policy enforcement
US20060224744A1 (en) * 2005-03-30 2006-10-05 Microsoft Corporation Sending inter-server notifications using an out-of-band communications protocol
US20060271935A1 (en) * 2005-05-31 2006-11-30 Microsoft Corporation Assignment of clients to tasks in a distributed system
US20060274763A1 (en) * 2005-06-03 2006-12-07 Error Christopher R Variable sampling rates for website visitation analysis
US20060274761A1 (en) * 2005-06-06 2006-12-07 Error Christopher R Network architecture with load balancing, fault tolerance and distributed querying

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100217796A1 (en) * 2007-10-09 2010-08-26 Cleversafe, Inc. Integrated client for use with a dispersed data storage network
US8965956B2 (en) * 2007-10-09 2015-02-24 Cleversafe, Inc. Integrated client for use with a dispersed data storage network
US20150172386A1 (en) * 2007-10-09 2015-06-18 Cleversafe, Inc. Integrated client for use with a dispersed data storage network
US10270855B2 (en) * 2007-10-09 2019-04-23 International Business Machines Corporation Integrated client for use with a dispersed data storage network
US9069774B1 (en) * 2008-11-04 2015-06-30 Infoblox Inc. Graphical visualization and management of networks
US20120226702A1 (en) * 2009-09-23 2012-09-06 Zte Corporation Data Query System and Constructing Method Thereof and Corresponding Data Query Method
US8909666B2 (en) * 2009-09-23 2014-12-09 Zte Corporation Data query system and constructing method thereof and corresponding data query method
US9098565B1 (en) * 2009-10-08 2015-08-04 Cellco Partnership In-house elegant JDBC connection pooling solution for message broker
US20120246263A1 (en) * 2011-03-25 2012-09-27 Fujitsu Limited Data transfer apparatus, data transfer method, and information processing apparatus

Also Published As

Publication number Publication date
US20060274761A1 (en) 2006-12-07

Similar Documents

Publication Publication Date Title
US8239535B2 (en) Network architecture with load balancing, fault tolerance and distributed querying
US7523454B2 (en) Apparatus and method for routing a transaction to a partitioned server
US8352434B2 (en) Performing scheduled backups of a backup node associated with a plurality of agent nodes
CN1091277C (en) Load balancing across the processes of a server computer
JP5230421B2 (en) Extensive user clustering based on set similarity
KR100511687B1 (en) The intelligent Traffic Managemet system for among the networks and method thereof
CN111756841B (en) Service implementation method, device, equipment and storage medium based on micro service cluster
CN109710615B (en) Database access management method, system, electronic device and storage medium
US20050138151A1 (en) System and method for providing integrated impact analysis data
CN102208991A (en) Blog processing method, device and system
CN1955932A (en) Method and apparatus for performance and policy analysis in distributed computing systems
CN113094136A (en) Page display control method and device, storage medium and electronic equipment
CN107924345B (en) Data store for aggregated measurements of metrics
CN101330431B (en) Method and system for storing instant information
CN111400350B (en) Configuration data reading method, system, electronic device and storage medium
CN101505305A (en) Method and apparatus for binding domain name and specific service
CN113177179B (en) Data request connection management method, device, equipment and storage medium
US20030160609A9 (en) Method and facility for storing and indexing web browsing data
CN102150397B (en) Method for responding to request relative to hose name and method for entrusting multiple host names in shared entrusted environments
US7822748B2 (en) Method and system for delivering information with caching based on interest and significance
CN113986876A (en) Method and device for developing data query management and electronic equipment
CN113360558A (en) Data processing method, data processing device, electronic device, and storage medium
US7062426B1 (en) Method for calculating memory requirements for thin client sizing tool
US20130326006A1 (en) Managing large data sets through page based information tracking in multi-master environments
CN112732999B (en) Static disaster recovery method, system, electronic equipment and storage medium

Legal Events

Date Code Title Description
AS Assignment

Owner name: OMNITURE, INC., UTAH

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ERROR, CHRISTOPHER R.;BAILEY, MICHAEL PAUL;REEL/FRAME:017403/0376

Effective date: 20051121

AS Assignment

Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT, CALIFORNIA

Free format text: SECURITY AGREEMENT;ASSIGNOR:OMNITURE, INC.;REEL/FRAME:022078/0141

Effective date: 20081224

AS Assignment

Owner name: OMNITURE, INC., UTAH

Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO FOOTHILL, LLC;REEL/FRAME:023525/0335

Effective date: 20091023

AS Assignment

Owner name: ADOBE SYSTEMS INCORPORATED, CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OMNITURE, INC.;REEL/FRAME:023538/0077

Effective date: 20091112

Owner name: ADOBE SYSTEMS INCORPORATED,CALIFORNIA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:OMNITURE, INC.;REEL/FRAME:023538/0077

Effective date: 20091112

STCF Information on status: patent grant

Free format text: PATENTED CASE

CC Certificate of correction
FPAY Fee payment

Year of fee payment: 4

AS Assignment

Owner name: ADOBE INC., CALIFORNIA

Free format text: CHANGE OF NAME;ASSIGNOR:ADOBE SYSTEMS INCORPORATED;REEL/FRAME:048867/0882

Effective date: 20181008

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8