1. WDAS Workshop, Lausanne, Jul. 9th1 Implementing SD-SQL Server: a Scalable Distributed Database System Soror SAHRI Witold LITWIN Soror.sahri@dauphine.frSoror.sahri@dauphine.fr Witold.litwin@dauphine.frWitold.litwin@dauphine.fr CERIA Laboratory

2. WDAS Workshop, Lausanne, Jul. 9th2 Overview Objective SDDS & DBS Principles The Gross Architecture of SD-SQL Server Server Side Client Side Experimental Performance Analysis Conclusion & Future Work

3. WDAS Workshop, Lausanne, Jul. 9th3 Objective Most of DBSs have parallel versions SQL Server, Oracle, DB2 DBSs do not provide dynamically scalable tables. Manual reorganizing if a table scale-up. Add a layer on DBSs’ Architecture

4. WDAS Workshop, Lausanne, Jul. 9th4 Objective Use the SDDS theory. Use the Distributed Partitioned Views of DBSs. Result We call the result SD-DBS Architecture Our prototype is SD-SQL Server.

5. WDAS Workshop, Lausanne, Jul. 9th5 SDDS Principles Scalable partitioning using splits of overloaded servers. Clients have private images of data partitioning.

6. WDAS Workshop, Lausanne, Jul. 9th6 Distributed & Partitioned Views Distributed & Partitioned Views allow the data in a large table to be split into smaller member tables in distributed servers. The data is partitioned between the member tables based on ranges of data values. Horizontal partitioning. The data ranges for each member table are defined in a CHECK constraint specified on the partitioning key. A view that uses UNION ALL to combine selects of all the member tables into a single result set is then defined.

7. WDAS Workshop, Lausanne, Jul. 9th7 SD-SQL Server Marriage of SDDS & DBS principles. Application to SQL Server 2000 DBS. Scalable dataTables SDDS SQL Server 2000 Images Partitioned & distributed views SD-SQL Server Scalable tables Scalable Distributed Views

8. WDAS Workshop, Lausanne, Jul. 9th8 Gross Architecture SD-DBS SDDS layer SD-DBS Application SQL Server Di …... SQL Server D2 SQL Server D1 SQL Server layer

9. WDAS Workshop, Lausanne, Jul. 9th9 SDDS Layer The SDDS Layer is composed of: Server Side: manages the scalable tables, and the split mechanism. Client Side: manages the scalable distributed views.

10. WDAS Workshop, Lausanne, Jul. 9th10 Segment SDDS Layer Scalable Distributed View …… Client Side …… Segments of a Scalable Table Segment Server Side DB3DB2DB1

11. WDAS Workshop, Lausanne, Jul. 9th11 Server Side: Scalable Tables The creation of a scalable table is similar to that of any table. With the usual CREATE TABLE statement. Each scalable table has a CHECK CONSTRAINT. Use of additional clauses related to scalable tables and store them in meta-tables: The limit size is stored in the SD-SIZE meta-table. The available servers are stored in the SD-SITE meta-table. The actual partitioning is stored in SD-C and SD-RP meta-tables.

12. WDAS Workshop, Lausanne, Jul. 9th12 Server Side: Scalable Tables Example: The creation of the scalable table Customer calls the stored procedure CREATE_SCALABLE_TABLE: EXEC CREATE_SCALABLE_TABLE ‘CREATE TABLE Customer (Customerid numeric PRIMARY KEY)’, 100 A trigger will be created on the Customer table. It launches the split when Customer exceeds its maximal size.

13. WDAS Workshop, Lausanne, Jul. 9th13 Server Side: Split Mechanism ……… Split Customer SD_CSD_RP SD_SITESD_SIZE Server1.DB_1 Meta-tables Server2.DB_1 SD_CSD_RP SD_SITESD_SIZE Meta-tables Customer

14. WDAS Workshop, Lausanne, Jul. 9th14 Server Side: Split Mechanism Customer SD_CSD_RP Split Server1.DB_1 Server2.DB_1 Meta-tables Server1.DB_1 Server2.DB_1 Server1.DB_1 Customer SD_CSD_RP Meta-tables Server1.DB_1

15. WDAS Workshop, Lausanne, Jul. 9th15 Client Side Scalable & distributed view definition is located at each SD-SQL Server client using the scalable table. Clients can have different SD views of the same scalable table. Not include all the existing segments. A client meta-table C-Image contains the number of segments of each SD view on each client.

16. WDAS Workshop, Lausanne, Jul. 9th16 Client Side Customer Server1.DB_1 Server2.DB_1 Customer SELECT * FROM Server1.DB_1.dbo.Customer UNION ALL SELECT * FROM Server2.DB_1.dbo.Customer SELECT * FROM Server1.DB_1.dbo.Customer Customer_View C-Image 2 Customer 1 C-Image

17. WDAS Workshop, Lausanne, Jul. 9th17 Client Side: View Adjustment Find all the scalable tables in Q Check each scalable view Pass Q to DBS for usual execution Adjust the outdate ones

18. WDAS Workshop, Lausanne, Jul. 9th18 Client Side: View Adjustment Example: Q: SELECT * FROM Server2.DB_1.dbo.Customer_view, T 1.Find the scalable tables in Q: Customer_view 2.Check the correctness of the view using the SD-RP and C-Image meta-tables. Count Customer segments in SD-RP as n. Check n and n’ the number in C-Image meta-table. 3. If n’< n then Adjust the view. 4.Execute Q.

19. WDAS Workshop, Lausanne, Jul. 9th19 Client Side: Query Processing The SQL commands used for the application are: SELECT, INSERT, UPDATE, DELETE. Each command is executed by a stored procedure. Example: EXEC SELECT_VIEW_SITE ‘select * from Customer_view’ CREATE_SCALABLE_TABLE ALTER_SCALABLE_TABLE DROP_SCALABLE_TABLE CREATE_SCALABLE_VIEW DROP_SCALABLE_VIEW

20. WDAS Workshop, Lausanne, Jul. 9th20 Experimental Performance Analysis Test environment: The hardware consisted of 1.8 GHz P4 PCs, connected through 1Gbps Ethernet. The experiments are used with the Customer table. The timing of the operations are measured using the SQL Profiler.

21. WDAS Workshop, Lausanne, Jul. 9th21 0 1000 2000 3000 100100010000 Segment Capacity Split time (ms) centralized split distributed split Experim Perf Analysis: Server Side

22. WDAS Workshop, Lausanne, Jul. 9th22 Experim Perf Analysis: Client Side Example: Let’s the Customer_view definition: CREATE VIEW Customer_view AS SELECT * FROM Server1.DB_1.dbo.Customer. On Server2.DB_1, we execute Q: INSERT INTO Customer_view VALUES (25)

23. WDAS Workshop, Lausanne, Jul. 9th23 Query execution Query execution + View 0 100100010000 Segment Capacity 50 100 150 Exécution Time (ms) View update Experim Perf Analysis: Client Side

24. WDAS Workshop, Lausanne, Jul. 9th24 Experim Perf Analysis: SkyServer Database Use of the SkyServer Database from the website: http://research.microsoft.com/~gray/SDSS Creation of PhotoObj table as a scalable table. Photoobj has 158 426 rows and 400 columns. Its size is 506 MB. Generation of two segments with the PhotoObj’ split.

25. WDAS Workshop, Lausanne, Jul. 9th25 The split time of The PhotoObj table is about 1mn. The execution time of the query 44 sec without the view update and 45 sec with the view update. select * from PhotoObj_view WHERE (status & 0x00001000 = 0) and NOT ( (status & 0x00002000>0) and (status & 0x0010 >0)) Experim Perf Analysis: SkyServer Database

26. WDAS Workshop, Lausanne, Jul. 9th26 Conclusion Scalable Tables are now Reality For SD-SQL Server at least at present. Dynamic data partitioning. Splitting time is practical Small for small segments, larger for larger segments…. Sub-linear with the segment size. Time to test a scalable view or to adjust it is negligible. The prototype is available in CERIA Lab.

27. WDAS Workshop, Lausanne, Jul. 9th27 Future work More complex SQL queries: With subqueries, views, aliases… Complete th SQL Libarary. Use of indexes to optimize the execution time of queries. More performance analysis with the SkyServer database.

28. WDAS Workshop, Lausanne, Jul. 9th28 THANKS FOR YOUR ATTENTION END Soror.sahri@dauphine.frSoror.sahri@dauphine.fr Witold.litwin@dauphine.frWitold.litwin@dauphine.fr