We consider the use of a cluster system for Application Service Provider (ASP). In the ASP context, hosted applications and databases can be update-intensive and must remain autonomous. In this paper, we propose a new solution for parallel processing with autonomous databases, using a replicated database organization. The main idea is to allow the system administrator to control the tradeoff between database consistency and application performance. Application requirements are captured through execution rules stored in a shared directory. They are used (at run time) to allocate cluster nodes to user requests in a way that optimizes load balancing while satisfying application consistency requirements. We also propose a new preventive replication method and a transaction load balancing architecture which can trade-off consistency for performance using execution rules. Finally, we discuss the on-going implementation at LIP6 using a Linux cluster running Oracle 8i.

Abstract. We consider the use of a database cluster for Application Service Provider (ASP). In the ASP context, applications and databases can be update-intensive and must remain autonomous. In this paper, we describe the Leganet system which performs freshness-aware transaction routing in a database cluster. We use multi-master replication and relaxed replica freshness to increase load balancing. Our transaction routing takes into account freshness requirements of queries at the relation level and uses a cost function that takes into account the cluster load and the cost to refresh replicas to the required level. We implemented the Leganet prototype on a 11-node Linux cluster running Oracle8i. Using experimentation and emulation up to 128 nodes, our validation based on the TPC-C benchmark demonstrates the performance benefits of our approach.

Abstract. Clusters of PC servers make new businesses like Application Service Provider (ASP) economically viable. In the ASP context, hosted applications and databases can be update-intensive and must remain autonomous so they can be subject to definition changes to accommodate customer requirements. In this paper, we propose a new solution for load balancing of autonomous applications and databases. Our solution is similar to Distributed Shared Memory in that it provides a shared address space to applications with distributed and replicated databases. The main idea is to allow the system administrator to control the tradeoff between consistency and performance when placing applications and databases onto cluster nodes. Application requirements are captured through rules stored in a shared catalog. They are used (at run time) to allocate cluster nodes to user requests in a way that optimizes load balancing. They are also used with the database logs to detect and repair inconsistency problems. 1.

The Polar project has the aim of designing a parallel, ODMG compatible object database server. This paper describes the server requirements and investigates issues in designing a system to achieve them. We believe that it is important to build on experience gained in the design and usage of parallel relational database systems over the last ten years, as much is also relevant to parallel object database systems. Therefore we present an overview of the design of parallel relational database servers and investigate how their design choices could be adopted for a parallel object database server. We conclude that while there are many similarities in the requirements and design options for these two types of parallel database servers, there are a number of significant differences, particularly in the areas of object access and method execution.

Abstract. While cluster computing is well established, it is not clear how to coordinate clusters consisting of many database components in order to process high workloads. In this paper, we focus on Online Analytical Processing (OLAP) queries, i.e., relatively complex queries whose evaluation tends to be time-consuming, and we report on some observations and preliminary results of our PowerDB project in this context. We investigate how many cluster nodes should be used to evaluate an OLAP query in parallel. Moreover, we provide a classification of OLAP queries, which is used to decide, whether and how a query should be parallelized. We run extensive experiments to evaluate these query classes in quantitative terms. Our results are an important step towards a two-phase query optimizer. In the first phase, the coordination infrastructure decomposes a query into subqueries and ships them to appropriate cluster nodes. In the second phase, each cluster node optimizes and evaluates its subquery locally. 1

Query optimizers are error prone, due to both their nature and the increased search space that modern query processing requires them to manage. This paper introduces the Sybase Plan (AP) language, a novel technology that puts together a set of proven techniques to palliate optimizer mistaken decisions. The AP language is a 2-way user-optimizer communication mechanism based on a physical level relational algebra. AP expressions are used both by the optimizer to describe the plan that it selected and by the user to direct the optimizer choices. APs are not textually part of the query. They are persistent objects stored in the system catalogs. APs yield important performance gains by eliminating all optimizer errors. 1.

Abstract not found

Linda is a coordination language capable of solving issues in distributed computing environments that relate to process synchronization, communication and creation. The expressiveness of Linda in distributed systems is such that researchers are proposing novel applications using Linda as a primary means of coordination. The examples range from peer-to-peer to groupware computing, from simple chat applications to control systems. Surprisingly, Linda has not been used in the field of distributed databases, although Linda can be helpful in solving coordination issues in a distributed database system. In this paper, we look at a possibility of using Linda in the context of distributed databases.

Abstract—We present Quiver, a system that coordinates service proxies placed at the “edge ” of the Internet to serve distributed clients accessing a service involving mutable objects. Quiver enables these proxies to perform consistent accesses to shared objects by migrating the objects to proxies performing operations on those objects. These migrations dramatically improve performance when operations involving an object exhibit geographic locality, since migrating this object into the vicinity of proxies hosting these operations will benefit all such operations. Other workloads benefit from Quiver, dispersing the computation load across the proxies and saving the costs of sending operation parameters over the wide area when these are large. Quiver also supports optimizations for single-object reads that do not involve migrating the object. We detail the protocols for implementing object operations and for accommodating the addition, involuntary disconnection, and voluntary departure of proxies. We also evaluate Quiver through experiments on PlanetLab. Finally, we discuss the use of Quiver to build an e-commerce application and a distributed network traffic modeling service. Index Terms—Edge services, migration, serializability. Ç

We consider the use of a database cluster with lazy replication. In this context, controlling the quality of replicated data based on users' requirements is important to improve performance. However, existing approaches are limited to a particular aspect of data quality. In this paper, we propose a general model of data quality which makes the di#erence between "freshness" and "validity" of data. Data quality is expressed through divergence measures from the data with perfect quality. Users can thus specify the minimum level of quality for their queries. This information can be exploited to optimize query load balancing. We implemented our approach in our Refresco prototype. The results show that freshness control can help increase query throughput significantly. They also show significant improvement when freshness requirements are specified at the relation level rather than at the database level.