Fast Replication into Vectorwise with HVR Steve Sheil

Transcription

1 Fast Replication into Vectorwise with HVR Steve Sheil

2 PaaS Platforms HVR SaaS IaaS Amazon EC2 Windows Azure Salesforce Mongo DB Q files Tera data Sharepoint files HVR hub Q Vector wise Xml Postgre SQL Other Ingres Oracle (Exadata) DB2 MS SQL 2

3 HVR Process Architecture hvr gui hvr agent log files hvr scheduler HUB repository TARGETS SOURCES DB#1 capture capture integrate integrate integrate NoSQL XML DB#3 DB#2 oracle redo logs DB#4 Web of connected co-processes from hub All logging, scheduling and configuration on hub Other nodes only; only agent listening on TCP/IP port 3

4 Replication into Vectorwise Databases typically have three speeds; top gear for bulk load to populate DB middle gear for set-wise/batch operations, e.g. batch DML, set-wise update low gear for singleton operations, e.g. insert/update one row each HVR 4.4 uses two gears HVR Refresh uses bulk load HVR Integrate (trickle) uses singleton insert/update But for OLAP the low/singleton speed often low because; Indexes don t pinpoint a row, only restrict which pages to search A column-wise DBMS keeps [small] changes separate from main table data For VW, tuning is possible Inserts slower if VW table has index But removing index to make updates go slower. Tuning: put index on update heavy tables but remove from insert heavy tables 4

5 Transactional (trickle) Replication Capture Database Changes Target Database table lookups Changes applied to target in original order Update transactions row 1 applied in commit order changes inside each transaction applied in actual order Only variation is transaction bundling, i.e. less frequent commits, so transactions are bigger=faster. 5

6 Potential Improvement 1: Batch SQL Capture Database Changes Target Database Batch consecutive changes into batch insert Can perform Update multiple row 1 inserts into a batch insert SQL statement, but... Only helps if consecutive inserts on same table are common But at customer only 3% of changes were candidates Lots of restrictions on when batch SQL allowed (depends on DBMS) Only inserts (not updates) No LOBs No SQL expressions 6

7 Potential Improvement 2: Coalescing Capture Database Changes Target Database Coalesce consecutive changes into single insert Replace Update consecutive row 1 changes to same row Update with row single 1 change 5 updates -> 1 update Insert + Update -> Insert Insert + Delete + Insert + Delete -> nothing Only helps if consecutive changes to same row But at customer only 5% of changes were candidates 7

8 How about Sorted Batches?? Capture Database Changes Target Database update from Insert select from 1. Sort [say] 10K changes by table 2. Do all updates, then inserts (for example). Benefits: lots of consecutive inserts can be batched. Consecutive updates can be done set-wise Put into staging table, the { update T from staging table where }. No because consistency breaks if same key gets deleted & [re]inserted 8

9 HVR 4.5 : Burst Integrate Capture Database Changes Target Database Insert select from 1. Sort [say] 10K changes by table and key column 2. Coalesce multiple changes to same row 3. Batch all updates, then inserts (or vise-versa). Optimal use of set-wise SQL. Optimal coalescing. Correct (but FK constraints are [temporarily] violated) 9

10 Performance test Oracle 11 VW 3.0 Simple table 16M rows Changes Simple table 16M rows Oracle v11 to Vectorwise 3.0 Simple table; 1 integer key and 2 other columns 16M rows in table Source & target on 4 CPU Linux development box Change generation, capture and integrate sequential, not parallel 10

11 Performance : results Type Number of changes SQL to Oracle HVR Capture HVR Integrate into VW Trickle Burst Updates Updates Updates Deletes Inserts Speeds (rows/sec) HVR Trickle Integrate Updates 163 Deletes 225 Inserts 168 Speeds (rows/sec) HVR 4.5 Trickle Integrate Updates Deletes Inserts HVR 4.5 Burst is about x180 faster here 11

12 Also for HVR 4.5 GA: Integrate Parallelism SOURCES DB#1 capture HUB integrate TARGETS DB#2 capture integrate integrate DB#3 Parallelism already possible with HVR 4.4 One capture job Many integrate locations all pointing at same DB Benefits of HVR 4.5 Much easier to setup (click /Parallelism and type 5 ) Automatic distribution of work across sessions Currently statistics & Excel needed of work out which tables are busiest Coordination between sessions E.g. Commits are issued simultaneously Sharding key can be table or value of key column For OLAP DBMS table sharding is best DB#4 12

13 HVR Release Dates HVR Beta released end May Delays due to bugs exposed in VW 3.0 HVR GA release in this July 13

14 Questions?? 14