380 Chapter 13 Replica Management in Grids 4. If the originator site decides to commit the transaction, it updates the TS.SID (at metadata service). The TS is increased to a new maximum, and SID points to the originator. The local timestamp of the site is also increased to match the TS of the Grid middleware. 5. Other replica sites in the partition (participants) also follow the same proce- dure if they decide to commit, i.e., the SID is set to the respective participant and the local timestamp is set to match the new TS at middleware. But the SID points to the originator and the local timestamp is not increased for any site that decides to locally abort the write transaction. 6. The number and detail of sites participating in the contingency update pro- cess are updated in the log. This is an important step, because the number of sites being updated does not form a quorum. Thus, after the partitioning has been repaired, the log is used to propagate updates to additional sites that will form a quorum. Once the quorum has been formed, normal GRAP operation can resume. Figure 13.6 is explained as follows. The quorum is collected for the data item to be written (line 1). If the network is not partitioned and the collected quorum (Q a ) is less than the required write quorum (Q w ) (line 2), the transaction is aborted. But if the collected quorum is less than the required write quorum and the network is partitioned (line 3), then the protocol works under the contingency quorum, that is, the actual collected quorum. The maximum local timestamp at the partition where the transaction is submitted and the maximum timestamp at the Grid (for the respective replica) are obtained. If both the maximum values do not match, then the transaction is aborted (line 4). This implies that the partition does not have the latest replica. If both timestamps match (line 5) but the originator decides to abort (line 6), then the global transaction will abort. If the originator decides to commit (line 7), then the transaction can continue the execution. For each site in the originator’s partition (line 8), the middleware’s timestamp is increased to a new maximum. The new site ID (SID) for the originator is set to point toward itself (line 9), which reflects that the originator decided to commit, and contains the latest replica. The local timestamp of the originator is also increased to a new maximum to match the Grid middleware’s timestamp. Since the site is working under a contingency quorum, the site ID is added in the log. If the participant site decides to commit (line 10), then the SID pointer is set to point toward itself, because that participant will also have the latest copy of the replica and the local timestamp of the participant is set to match with the origina- tor’s maximum value. The site ID of the participant is also added to the log. But if the participant decides to abort its cohort (line 11), then the SID pointer points to the originator and the local timestamp is unchanged. This ensures that the partic- ipant points to the latest replica of the data item. Since the participant decided to abort, it is not necessary to add the site ID to the log file. The contingency GRAP helps in executing transactions even in the case of mul- tiple partitioning. The partition that has the latest copy of the replica can continue. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 13.4 Handling Multiple Partitioning 381 It acts as a combination of quorum consensus protocol and primary copy protocol. The difference is that it updates all sites in the partition, not only a single site. Grid middleware’s metadata service helps to find the most up-to-date copy of the replica. 13.4.2 Comparison of Replica Management Protocols Based on the update mechanism, replication synchronization protocols can broadly be classified into two categories: (i) synchronous, also known as eager replication, and (ii) asynchronous, also known as lazy replication. Synchronous replication updates all replicas of the data object as a single transaction. An asynchronous replication protocol updates only one replica of the data, and the changes are prop- agated to other replicas later (lazily). Synchronous protocols ensure strict consistency among replicated data, but a disadvantage is that they are slow and computationally expensive, as many mes- sages are to be sent in the network. The response time of asynchronous replication protocols is less, compared with synchronous protocols, as they update the data only at one site. Asynchronous protocols do not guarantee strict consistency of data at distributed replica sites. The choice of a synchronous or an asynchronous replica protocol is a trade-off between strict consistency and the response time of the application. On the one hand, some applications need high precision and demand strict consistency (engi- neering applications, earth simulator, etc.); on the other hand, some applications can relax the consistency requirements. GRAP meets strict consistency require- ments. A major requirement of replica control protocols is that the transactions should be able to execute even if some of the replicated data sites are unavailable. In the presence of failure, synchronous protocols cannot execute the update transac- tions. Because of the distributed nature of the Grid, the failure probability is higher compared with centralized systems. Synchronous replication is best implemented in small local area networks with short latencies. In synchronous replication, the deadlock increases as the third power of the number of sites in the network and the fifth power of the transaction size. Thus the performance of a synchronous protocol is unacceptable in a Grid environment, and asynchronous protocols are unsuit- able for our purpose, as they do not ensure strict consistency of data. Hence, the quorum-based protocols are most suited for Grid database requirements. However, the quorum-based majority consensus protocol can handle only simple network partitioning. The contingency GRAP protocol can sustain multiple partitioning. Table 13.1 compares the characteristics of various replica management protocols with GRAP and contingency GRAP. The ROWA and ROWA-A protocols cannot handle network partitioning. The ROWA protocol cannot sustain any site failure. ROWA-A can sustain site fail- ure by writing only on available copies, but if the sites are operational and they cannot communicate because of network partitioning, the database may become inconsistent. The inconsistencies may be addressed by using manual or automatic Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 382 Chapter 13 Replica Management in Grids Table 13.1 Comparison of various replica control protocols Behavior Minimum Number of Simple Multiple Sites Having Site Required Site Required Network Network latest to Read a to Write a Protocol Partitioning Partitioning Replica Data Item Data Item ROWA No No All replicas Any replica All replicas ROWA-A No No Number of available sites Any replica Available replicas Primary Copy Only if primary site is in the partition Only if primary site is in the partition 1(primary site) 1(primary site) 1(primary site) Majority consensus Only if quorum can be obtained No Size of write quorum Size of read quorum Size of write quorum GRAP Only if quorum can be obtained No Size of write quorum Size of read quorum Size of write quorum Contingency GRAP Operates same as GRAP in simple partition- ing Yes Under normal operation and simple partition- ing:Size of write quorum Under normal operation and simple partition- ing:Sizeof read quorum Under normal operation and simple partition- ing:Sizeof write quorum Under multiple partition- ing:Less than write quorum Under multiple partition- ing:Less than read quorum, if the partition contains the latest replica Under multiple partition- ing:Less than write quorum Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 13.4 Handling Multiple Partitioning 383 reconciliation processes. Primary site protocols can handle network partitioning only if the partition contains the primary site. In Table 13.1, the properties of GRAP look very similar to those of the majority consensus protocol. But the main difference between the two is that the majority consensus protocol can lead to an inconsistent database state because of the auton- omy of Grid database sites, while GRAP is designed to support autonomous sites. Contingency GRAP can handle multiple network partitioning. While the network is partitioned (multiple), contingency GRAP updates fewer sites, required by the quorum, and keeps a record. Read operations can be performed at all partitions having the latest replica copy of the data (verified by the middleware). 13.4.3 Correctness of Contingency GRAP The following lemmas are used to prove the correctness of contingency GRAP, on the same grounds as GRAP. Lemma 13.3: Two write operations are ordered in the presence of multiple parti- tioning. Proof: In the presence of multiple partitioning, there will never be a majority consensus. Consider two transactions, T i and T j , executing in two different parti- tions P 1 and P 2 , respectively. The following cases are possible: (i) P 1 and P 2 do not have a copy of the latest replica: Step 2 of contingency GRAP for write transaction takes care of this case. T i and T j have to either abort their respective transactions or wait until the partitioning has been repaired. (ii) P 1 has the latest replica: Step 2 of contingency GRAP for write transaction will abort its transaction T j . Step 4 will ensure that the metadata service’s timestamp is updated to reflect the latest write transaction T i of P 1 .Step 3 and step 6 ensure the updating of the log of sites where T i ’s effects are reflected. This is an important step since, because of multiple partitioning, the write quorum could not be updated. (iii) P 1 and P 2 both have a copy of the latest replica: Assume that both T i and T j send a request to check the latest copy of the replica. Both partitions initially may get the impression that they have the latest replica. But steps 3, 4, and 6 of the algorithm prevent the occurrence of such a situation by updating the log. Also, the first transaction to update the data item will increase the times- tamp at the metadata service, and thus any later transaction that reads the timestamp from the metadata service has to abort the transaction (because it could not find any matching local timestamp), although it had the impression of latest copy at the first instance. Cases ii and iii write replicas of the data item even if the quorum could not be obtained, which can lead to inconsistency. But the metadata service’s timestamp Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 384 Chapter 13 Replica Management in Grids and log entry only allows transactions to proceed in one partition, thereby prevent- ing the inconsistency. After the partitioning has been recovered, the log file is used to propagate values of the latest replicas to more sites to at least form the quorum (steps 3 and (6) of contingency GRAP). Thus data consistency is maintained of replicas in the presence of multiple partitioning. Lemma 13.4: Any transaction will always read the latest copy of the replica. Proof: Although because of failure of sites a read quorum cannot be obtained, the latest copy of the replica can be located with the help of the metadata service’s timestamp. If the latest replica is in the partition, then the transaction reads the replica; otherwise, it has to either abort the transaction or wait until the partition has been repaired. Thus any transaction will always read the latest replica of the data (steps 3 and 4 of contingency GRAP for read transaction). Theorem 13.2: Contingency GRAP produces 1SR schedules. Proof: On similar grounds as theorem 13.1, lemma 13.3 and lemma 13.4 ensure one-copy view of the replicated database. Contingency GRAP can be combined (like GRAP) with GCC concurrency control protocol to ensure 1SR schedules. 13.5 SUMMARY To increase system availability and performance, data is replicated at different sites in physically distributed data intensive applications. Traditional distributed databases are synchronized and tightly coupled in nature. Although various replica synchronization protocols for distributed databases, such as ROWA, ROWA-available, primary copy, etc., are available, because of the autonomy of the sites, it is not possible to implement traditional replica synchronization protocols in the Grid environment. In this chapter, a quorum-based replica management protocol (GRAP) is intro- duced, which can handle the autonomy of sites in the Grid environment. It makes use of the metadata service of Grid middleware and a pointer that points to the site containing the latest replica of the data item. Considering the distributed nature of applications and the flexible behavior of quorums, quorum-based protocols in GRAP are suitable. Quorum-based protocols have the drawback that they cannot obtain the quorum in case of multiple partitioning. A contingency quorum and log file are used to extend GRAP, in order to handle multiple network partitioning, so that the partition containing the latest replica of the data can continue its opera- tion. Once multiple partitioning has been repaired and normal quorum obtained, the normal GRAP operation resumes. Replica control protocols studied for the Grid environment either are high-level services or are intended to relax the consistency requirement. But high-precision applications cannot afford to relax data consistency. Thus in this chapter the main Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 13.7 Exercises 385 focus is on a lower level protocol that does not compromise data consistency at replicated sites. This chapter may be summarized as follows: ž A replica synchronization protocol for an autonomous Grid environment is introduced. Because of the autonomy of sites, participants can reverse the global decision due to local conflicts. GRAP protocol ensures that a transac- tion reads the latest version of the data item. ž Contingency GRAP protocol is used to sustain multiple network partition- ing. When considering the global nature of Grids, it is important to address multiple network partitioning issues. ž The correctness of GRAP and contingency GRAP are demonstrated to ensure that 1SR schedule is maintained. 13.6 BIBLIOGRAPHICAL NOTES In recent years, there have been emerging conferences in the Grid areas, such as GCC, CCGrid, etc, that publish numerous papers on data replication in the Grid environment. In the GCC conference series, You et al. (2006) described a utility-based replication strategy in data grid. On the other hand, Rahman et al. (2005) introduced a multiobjective model through the use of p-median and p-center models to address the replica placement problem, and Park et al. (2003) proposed a dynamic replication that reduced data access time by avoiding network congestions in a data grid network achieved through a network-level locality In the CCGrid conference series, Liu and Wu (2006) studied replica placement in data grid systems by proposing algorithms for selecting optimal locations for placing the replicas. Carman et al. (2002) used an economic model for data replica- tion. An early work on data replication using the Globus Data Grid architecture was presented by Vazhkudai et al. (2001), who designed and implemented a high-level replica selection services. Other parallel/distributed and high-performance computing conferences, such as HiPC, Euro-Par, HPDC,andICPADS, have also attracted grid researchers to publish data replication research. Chakrabarti et al. (HiPC 2004) presented an inte- gration of scheduling and replication in data grids, and Tang et al. (Euro-Par 2005) combined job scheduling heuristics with data replication in the grid. Consistency in data replication has also been the focus of Dullman et al. (HPDC 2001), whereas Lin et al. (ICPADS 2006) studied the minimum number of replicas to ensure the locality requirements. 13.7 EXERCISES 13.1. Explain why data replication in the Grid is more common than in any other database systems (e.g., parallel databases, distributed databases, and multidatabase systems). 13.2. Discuss why replication may be a problem in the Grid. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 386 Chapter 13 Replica Management in Grids 13.3. Describe the main features of the Grid replica access protocol. 13.4. Illustrate how the Grid replica access protocol may solve the replication problem in the Grid. 13.5. What is a 1SR (1-copy serializable) schedule? Discuss Theorem 13.1, which states that GRAP produce 1SR. 13.6. What is contingency quorum? 13.7. Describe the difference between eager replication and lazy replication. 13.8. Outline the primary difference between GRAP and contigency GRAP. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Chapter 14 Grid Atomic Commitment in Replicated Data An atomic commitment protocol and a replica management protocol were explained in Chapters 12 and 13. Atomic commitment protocols are used to ensure the all-or-nothing property of a transaction that is executing in a distributed environment. A global transaction has multiple cohorts executing at different physically distributed data sites. If one site aborts its cohort (subtransaction), then all other sites must also abort their subtransactions to enforce the all-or-nothing property. Thus the computing resources at all other sites where the subtransactions decided to commit are wasted. Multiple copies of data are stored at multiple sites in a replicated database to increase system availability and performance. The database can operate even though some of the sites have failed, thereby increasing the availability of the system, and a transaction is more likely to find the data it needs close to the transaction’s home site, thereby increasing overall performance of the system. The number of aborts can be high in the Grid environment while maintaining the atomicity of global transactions. In this chapter, replicas available at different sites are used to maintain atomicity. The protocol will help to reduce the number of aborts of global transactions and will reduce wastage of computing resources. Section 14.1 presents the motivation for using replication in the ACPs. Section 14.2 describes a modified version of the Grid-ACP. The modified Grid-ACP uses replica- tion at multiple levels to reduce the number of aborts in Grid databases. Section 14.3 discusses how the ACID properties of a transaction are affected in a replicated Grid environment. High-Performance Parallel Database Processing and Grid Databases, by David Taniar, Clement Leung, Wenny Rahayu, and Sushant Goel Copyright  2008 John Wiley & Sons, Inc. 387 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 388 Chapter 14 Grid Atomic Commitment in Replicated Data 14.1 MOTIVATION Transactions executing in the Grid architecture are long-running transactions. Thus aborting the whole global transaction, even if a single subtransaction aborts, will result in high computational loss. On the other hand, if the global transaction does not abort on abortion of any subtransaction, then it violates the atomicity property of the transaction. Therefore, the two are contradictory requirements. As discussed in Chapter 12, any site that might have decided to commit its cohort of the global transaction and is in “sleep” state, should execute the compen- sating transaction if any of the subtransactions of the global transaction decides to abort. Effectively, the computational job done by the participants is lost. Consider- ing the large volume of work done in Grid databases, this is undesirable. 14.1.1 Architectural Reasons The following points constitute the major motivation, from an architectural per- spective, for using replication to reduce the number of aborts in the Grid database: (1) The Grid database handles comparatively larger volumes of data than tradi- tional distributed databases. The nature of the transactions is long-running, and hence aborts are very expensive in the Grid environment. Therefore, the number of aborts in the Grid database needs to be reduced. (2) Replication increases the availability of data, e.g., if a site with a replica is unavailable, then the transaction is redirected to another replica, thereby increasing availability. Replica control protocols do not explore replicated data once the transaction has submitted its subtransactions to local sites and these are already executing; e.g., if a subtransaction fails during the execu- tion, then the whole transaction aborts. This chapter explores the possibility of using replication to reduce aborts, after any subtransaction has aborted but while the global transaction is still active. Thus, if a subtransaction decides to abort, it looks for another replica of the data instead of aborting the entire global transaction. (3) Replication of data is provided in Grid databases naturally for fast and easy access of data, close to the transaction’s originator site. Thus it will incur fewer overheads. 14.1.2 Motivating Example A scenario of a normal operation of an atomic commitment protocol, which does not make use of replicated data, is demonstrated below. Scenario: Figure 14.1 shows the functioning of an atomic commit protocol (e.g., Grid-ACP). Assume a data item D is replicated at five sites DB 1 ; DB 2 ;:::DB 5 . To satisfy the threshold conditions, the read quorum (Q R ) and write quorum (Q W ) Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 14.1 Motivation 389 GRID MIDDLEWARE DB 1 DB 2 DB 3 DB 4 DB 5 Global Transaction (GT 1 ) Read Quorum Q R = 3 Write Quorum Q W = 3 Status of Replicated sites at Time = 0, (transaction submission) Y XYYY Status of Replicated sites at Time = 1, (transaction termination) YX Y XY Decision at local sites SAS Global decision is to abort since site-4 is either down or decided to abort its cohort of GT 1 Legend: X: Site not ready to execute transaction A: Local decision is abort Y: Site ready to execute the transaction S: Local decision was commit, hence site is in sleep stateY: Replica Site chosen for execution Global decision AAA Figure 14.1 An ACP’s operation without using replication are equal to 3. Hence, any transaction must access three sites in order to read or write the data item. In Figure 14.1, X denotes that the site is unable to fulfil the request at that time (i.e., either the site is down or the subtransaction’s decision was to abort) and Y denotes that the database is ready to serve the request. Say that at time T D 0, GT 1 is submitted at database site DB 1 . GT 1 intends to write data item D.Let us assume that all sites are active and working except DB 2 . Q W can be obtained from any three sites; let the chosen sites be DB 1 , DB 4 and DB 5 (bold letters at time D 0). After execution, say at time T D 1, DB 1 and DB 5 decide to commit their respective subtransactions but DB 4 decides to abort its part of subtransaction because of some local dependencies (remember this is possible because of auton- omy restriction among sites); to maintain atomicity of the global transaction, DB 1 and DB 5 must also abort their subtransactions. Thus the computing done at site 1 and site 5 is wasted. Furthermore, execution of the compensating transaction will consume more computing resources. From Figure 14.1, it is clear that at time T D 1, when DB 4 decides to abort and consequently the global transaction also decides to abort, the quorum was still available in terms of DB 1 , DB 3 and DB 5 . But the transaction did not check the quorum at a later stage, and the global transaction was aborted. Thus the abor- tion of transaction wastes computing resources, which could have been avoided by exploring quorums at multiple levels. Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... 15.4, and CUME DIST queries are covered in Section 15.5 This High-Performance Parallel Database Processing and Grid Databases, by David Taniar, Clement Leung, Wenny Rahayu, and Sushant Goel Copyright  2008 John Wiley & Sons, Inc 401 402 Chapter 15 Parallel Online Analytic Processing (OLAP) and Business Intelligence is followed by the parallelization of NTILE and histogram queries in Section 15.6, and. .. data intensity and the need for flexible query processing, parallelism in OLAP is particularly beneficial Section 15.1 examines the parallel multidimensional analysis framework, and then we shall study how SQL queries for OLAP may be efficiently optimized and parallelized In Section 15.2, we examine ROLLUP queries, while CUBE queries are examined in Section 15.3 The parallelization of Top-N and ranking queries... system (e.g., Grid database) is more complicated than in traditional transaction systems Traditional transaction systems (including central and distributed databases) execute a database transaction in a single (and central) DBMS A middleware-based transaction system spans several sites in the Grid database The middleware transaction system has to satisfy some message passing, locking, restart, and fault... columns in Fig 15.2 are allocated to two separate processors) and perform similar processing Let N be the number of processors, if N ½ max.m; n/ then, adopting either row parallelism or column parallelism will make little difference to parallel processing efficiency Assuming that row parallelism is adopted, the processing time will be the time for processing n numbers (all m rows are processed concurrently,... the time for aggregating all the m partial sums Thus the total processing time is that required for adding together n C m values Denoting by T r / the total processing time for processing r values, this processing time may be written as T n C m/ On the other hand, if column parallelism is adopted, the processing time will be the time for processing m numbers (all n columns are processed concurrently)... the grid are generally long-running transactions What is the impact of long-running transactions on the atomic commitment in the Grid? 14.3 Discuss the four properties of ACP 14.4 Describe why the Grid atomic commitment protocol (Grid- ACP) needs to be modified to accommodate replicated data in the Grid 14.5 Discuss why execution autonomy and site heterogeneity make atomicity of transactions in the grid. .. properties in the Grid Part V Other Data-Intensive Applications Chapter 15 Parallel Online Analytic Processing (OLAP) and Business Intelligence The efficient and accurate management of data is not sufficient to enhance the performance of an organization Data has to be to enhanced and harnessed so that profitable knowledge can be derived from it Business Intelligence (BI) is concerned with transforming and enhancing... PROPERTIES IN REPLICATED ENVIRONMENT On the one hand, data replication can increase the performance and availability of the system, while on the other hand, if not designed properly, a replicated system can produce worse performance and availability If the update must be applied and synchronized to all replicas, then it may lead to worse performance And if all replicas are to be operational in order... subtransaction and hence are in the sleep state Unlike the normal Grid- ACP, the modified Grid- ACP does not decide to abort the global transaction at this stage Traditional ACPs, including Grid- ACP, exploit only level-1 operations (of Fig 14.2) during the commit process The Grid middleware is aware of other replica locations of the data item D With the help of the replica location service of Grid middleware,... been mentioned in the Bibliographical Notes section at the end of Chapter 13 This covers the work that has 398 Chapter 14 Grid Atomic Commitment in Replicated Data been published in the Grid- related and parallel/ distributed conferences, including GCC, CCGrid, HiPC, Euro-Par, HPDC, and ICPADS Specific work on atomic commitment has generally been included in the work on transaction management, including . replicated Grid environment. High-Performance Parallel Database Processing and Grid Databases, by David Taniar, Clement Leung, Wenny Rahayu, and Sushant. replication in the Grid is more common than in any other database systems (e.g., parallel databases, distributed databases, and multidatabase systems). 13.2.