vFabric SQLFire for high performance data

1,151 views

Published on

Learn how to manage high performance data using VMware vFabric SQLFire

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,151
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
63
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Original design rooted in good principles of data independence, durability and consistency of data Designers naturally focused on disk IO performance and maintaining strict data consistency through many locking/latching techniques Buffer management is all about using memory for caching contiguous disk blocks
  • Driven by the desire to scale, be HA and offer lower latencies ... clusters of commodity servers .... ... focus shifts to distributing data and clustering ... shared nothing including the disk ... avoid disk seeks as much as possible .. ... memory is cheap and reliable ... Pool memory across cluster and use highly optimized concurrent data structures ... partitioning with consistent hashing ... dynamically increase cluster capacity ... Move and parallelize behavior to data (MR) ... High availability within cluster and across data centers
  • Entity groups defined in SQLFire using “colocation” clause Entity group guaranteed to be collocated in presence of failures or rebalance Now, complex queries can be executed without requiring excessive distributed data access
  • vFabric SQLFire for high performance data

    1. 1. Managing High Performance Data with vFabric SQLFire
    2. 2. Agenda <ul><li>Various NoSQL attributes and why SQL </li></ul><ul><li>SQLFire features + Demo </li></ul><ul><li>Scalability patterns </li></ul><ul><ul><li>Hash partitioning </li></ul></ul><ul><ul><li>Entity groups and collocation </li></ul></ul><ul><ul><li>Scaling behavior using “data aware stored procedures” </li></ul></ul><ul><li>Consistency model </li></ul><ul><ul><li>How we do distributed transactions </li></ul></ul><ul><li>Shared nothing persistence </li></ul>
    3. 3. We Challenge the traditional RDBMS design NOT SQL <ul><li>Too much I/O </li></ul><ul><li>Design roots don ’t necessarily apply today </li></ul><ul><ul><li>Too much focus on ACID </li></ul></ul><ul><ul><li>Disk synchronization bottlenecks </li></ul></ul>Confidential First write to LOG Second write to Data files Buffers primarily tuned for IO
    4. 4. Confidential Common themes in next-gen DB architectures NoSQL, Data Grids, Data Fabrics, NewSQL “ Shared nothing” commodity clusters focus shifts to memory, distributing data and clustering Scale by partitioning the data and move behavior to data nodes HA within cluster and across data centers Add capacity to scale dynamically
    5. 5. What is different ? <ul><li>Several data models </li></ul><ul><ul><li>Key-value </li></ul></ul><ul><ul><li>Column family (inspired by Google BigTable) </li></ul></ul><ul><ul><li>Document </li></ul></ul><ul><ul><li>Graph </li></ul></ul><ul><li>Most focus on making model less rigid than SQL </li></ul><ul><li>Consistency model is not ACID </li></ul>Low scale High scale Very high scale STRICT – Full ACID (RDB) Tunable Consistency Eventual
    6. 6. What is our take with SQLFire?
    7. 7. So, what is vFabric SQLFire? <ul><li>Distributed, Main memory oriented SQL Data management platform </li></ul><ul><li>NoSQL characteristics of scalability, performance, availability but retains support for distributed transactions, SQL querying </li></ul><ul><li>It is also designed so you can use it as a operational layer in front of your legacy databases through a caching framework </li></ul>
    8. 8. Show me a picture
    9. 9. Comparing with NoSQL, Object Data Grids <ul><li>The Good </li></ul><ul><ul><li>Little vendor specific </li></ul></ul><ul><ul><ul><li>Use SQL for Application DML, Queries </li></ul></ul></ul><ul><ul><ul><li>Vendor specific stuff in DDL </li></ul></ul></ul><ul><ul><li>Better Query engine </li></ul></ul><ul><ul><ul><li>Cost based optimizer, skip-list indexing, parallel queries </li></ul></ul></ul><ul><ul><li>No deserialization headaches </li></ul></ul><ul><ul><li>Maintain referential integrity </li></ul></ul><ul><ul><li>Easier to integrate with existing relational DBs and other products </li></ul></ul><ul><ul><ul><li>Plug-n-play is a myth </li></ul></ul></ul>
    10. 10. Comparing with NoSQL, Object Data Grids <ul><li>Not So Good </li></ul><ul><ul><li>Not as efficient for simple key access </li></ul></ul><ul><ul><li>You can only manage scalar types </li></ul></ul><ul><ul><ul><li>Nested graphs is painful </li></ul></ul></ul><ul><ul><li>Complex data relationships that could be represented as a single object and fetched using a key now may require a join </li></ul></ul><ul><ul><ul><li>Join processing is computationally expensive </li></ul></ul></ul><ul><ul><li>OR mapping can add latency </li></ul></ul>
    11. 11. Features in 1.0 <ul><li>Partitioning and Replication </li></ul><ul><li>Multiple Topologies </li></ul><ul><ul><li>Peer-2-peer, client-server, WAN </li></ul></ul><ul><li>Events framework </li></ul><ul><ul><li>Listeners, triggers, Asynchronous write behind </li></ul></ul><ul><li>Queries </li></ul><ul><ul><li>Distributed, optimized for main memory </li></ul></ul><ul><li>Procedures and Functions </li></ul><ul><ul><li>Standard Java stored proc and parallel “data aware” </li></ul></ul><ul><li>Caching </li></ul><ul><ul><li>Loader, writers, Eviction, Overflow and Expiration </li></ul></ul><ul><li>Command line tool </li></ul><ul><li>Manageability, Security </li></ul>
    12. 12. Flexible Deployment Topologies Confidential Java Application cluster can host an embedded clustered database by just changing the URL jdbc:sqlfire:;mcast-port=33666;host-data=true
    13. 13. Flexible Deployment Topologies Confidential
    14. 14. Partitioning & Replication
    15. 15. Explore features through example Assume, thousands of flight rows, millions of flightavailability records
    16. 16. Creating Tables Table CREATE TABLE AIRLINES ( AIRLINE CHAR(2) NOT NULL PRIMARY KEY, AIRLINE_FULL VARCHAR(24), BASIC_RATE DOUBLE PRECISION, DISTANCE_DISCOUNT DOUBLE PRECISION,…. ); SQLF SQLF SQLF
    17. 17. Replicated Tables CREATE TABLE AIRLINES ( AIRLINE CHAR(2) NOT NULL PRIMARY KEY, AIRLINE_FULL VARCHAR(24), BASIC_RATE DOUBLE PRECISION, DISTANCE_DISCOUNT DOUBLE PRECISION,…. ) REPLICATE ; Replicated Table Replicated Table Replicated Table SQLF SQLF SQLF
    18. 18. Partitioned Tables CREATE TABLE FLIGHTS ( FLIGHT_ID CHAR(6) NOT NULL , SEGMENT_NUMBER INTEGER NOT NULL , ORIG_AIRPORT CHAR(3), DEST_AIRPORT CHAR(3) DEPART_TIME TIME, FLIGHT_MILES INTEGER NOT NULL ) PARTITION BY COLUMN( FLIGHT_ID ); Table Partitioned Table Partitioned Table Partitioned Table Replicated Table Replicated Table Replicated Table SQLF SQLF SQLF
    19. 19. Partition Redundancy CREATE TABLE FLIGHTS ( FLIGHT_ID CHAR(6) NOT NULL , SEGMENT_NUMBER INTEGER NOT NULL , ORIG_AIRPORT CHAR(3), DEST_AIRPORT CHAR(3) DEPART_TIME TIME, FLIGHT_MILES INTEGER NOT NULL) PARTITION BY COLUMN (FLIGHT_ID) REDUNDANCY 1 ; Table Partitioned Table Redundant Partition Partitioned Table Redundant Partition Partitioned Table Redundant Partition Replicated Table Replicated Table Replicated Table SQLF SQLF SQLF
    20. 20. Partition Colocation CREATE TABLE FLIGHTAVAILABILITY ( FLIGHT_ID CHAR(6) NOT NULL , SEGMENT_NUMBER INTEGER NOT NULL , FLIGHT_DATE DATE NOT NULL , ECONOMY_SEATS_TAKEN INTEGER DEFAULT 0, …) PARTITION BY COLUMN (FLIGHT_ID) COLOCATE WITH (FLIGHTS) ; Table Partitioned Table Redundant Partition Partitioned Table Redundant Partition Partitioned Table Redundant Partition Replicated Table Replicated Table Replicated Table SQLF SQLF SQLF Colocated Partition Colocated Partition Colocated Partition Redundant Partition Redundant Partition Redundant Partition
    21. 21. Persistent Tables CREATE TABLE FLIGHTAVAILABILITY ( FLIGHT_ID CHAR(6) NOT NULL , SEGMENT_NUMBER INTEGER NOT NULL , FLIGHT_DATE DATE NOT NULL , ECONOMY_SEATS_TAKEN INTEGER DEFAULT 0, …) PARTITION BY COLUMN (FLIGHT_ID) COLOCATE WITH (FLIGHTS) PERSISTENT persistentStore ASYNCHRONOUS ; Table Partitioned Table Redundant Partition Partitioned Table Redundant Partition Partitioned Table Redundant Partition Replicated Table Replicated Table Replicated Table SQLF SQLF SQLF Colocated Partition Colocated Partition Colocated Partition Redundant Partition Redundant Partition Redundant Partition sqlf backup /export/fileServerDirectory/sqlfireBackupLocation Data dictionary is always persisted in each server
    22. 22. Demo default partitioned tables, colocation, persistent tables
    23. 23. Scaling data with Partitioned tables
    24. 24. Hash partitioning for linear scaling Key Hashing provides single hop access to its partition But, what if the access is not based on the key … say, joins are involved
    25. 25. Hash partitioning only goes so far <ul><li>Consider this query : </li></ul><ul><li>Select * from flights, flightAvailability </li></ul><ul><li>where <equijoin flights with flightAvailability> </li></ul><ul><li>and flightId ='xxx'; </li></ul><ul><li>If both tables are hash partitioned the join logic will need execution on all nodes where flightavailability data is stored </li></ul><ul><li>Distributed joins are expensive and inhibit scaling </li></ul><ul><ul><li>joins across distributed nodes could involve distributed locks and potentially a lot of intermediate data transfer across nodes </li></ul></ul>EquiJOIN of rows across multiple nodes is not supported in SQLFire 1.0
    26. 26. Partition aware DB design <ul><ul><li>Designer thinks about how data maps to partitions </li></ul></ul><ul><ul><li>The main idea is to: </li></ul></ul><ul><ul><li>minimize excessive data distribution by keeping the most frequently accessed and joined data collocated on partitions </li></ul></ul><ul><ul><li>Read Pat Helland ’s “Life beyond Distributed Transactions” and the Google MegaStore paper </li></ul></ul>
    27. 27. Partition aware DB design <ul><ul><li>Turns out OLTP systems lend themselves well to this need </li></ul></ul><ul><ul><ul><li>Typically it is the number of entities that grows over time and not the size of the entity. </li></ul></ul></ul><ul><ul><ul><ul><li>Customer count perpetually grows, not the size of the customer info </li></ul></ul></ul></ul><ul><ul><ul><li>Most often access is very restricted and based on select entities </li></ul></ul></ul><ul><ul><ul><ul><li>given a FlightID, fetch flightAvailability records </li></ul></ul></ul></ul><ul><ul><ul><ul><li>given a customerID, add/remove orders, shipment records </li></ul></ul></ul></ul><ul><ul><li>Identify partition key for “Entity Group” </li></ul></ul><ul><ul><ul><li>&quot;entity groups&quot;: set of entities across several related tables that can all share a single identifier </li></ul></ul></ul><ul><ul><ul><ul><li>flightID is shared between the parent and child tables </li></ul></ul></ul></ul><ul><ul><ul><ul><li>CustomerID shared between customer, order and shipment tables </li></ul></ul></ul></ul>
    28. 28. Partition aware DB design Entity Groups Table FlightAvailability partitioned by FlightID colocated with Flights FlightID is the entity group Key
    29. 29. Partition Aware DB design <ul><li>STAR schema design is the norm in OLTP design </li></ul><ul><li>Fact tables (fast changing) are natural partitioning candidates </li></ul><ul><ul><li>Partition by: FlightID … Availability, history rows colocated with Flights </li></ul></ul><ul><li>Dimension tables are natural replicated table candidates </li></ul><ul><ul><li>Replicate Airlines, Countries, Cities on all nodes </li></ul></ul><ul><li>Dealing with Joins involving M-M relationships </li></ul><ul><ul><li>Can the one side of the M-M become a replicated table? </li></ul></ul><ul><ul><li>If not, run the Join logic in a parallel stored procedure to minimize distribution </li></ul></ul><ul><ul><li>Else, split the query into multiple queries in application </li></ul></ul>
    30. 30. Scaling Application logic with Parallel “Data Aware procedures”
    31. 31. Procedures Java Stored Procedures may be created according to the SQL Standard SQLFabric also supports the JDBC type Types.JAVA_OBJECT. A parameter of type JAVA_OBJECT supports an arbitrary Serializable Java object. In this case, the procedure will be executed on the server to which a client is connected (or locally for Peer Clients) CREATE PROCEDURE getOverBookedFlights (IN argument OBJECT, OUT result OBJECT) LANGUAGE JAVA PARAMETER STYLE JAVA READS SQL DATA DYNAMIC RESULT SETS 1 EXTERNAL NAME com.acme.OverBookedFLights;
    32. 32. Data Aware Procedures Parallelize procedure and prune to nodes with required data Extend the procedure call with the following syntax: Hint the data the procedure depends on CALL getOverBookedFlights( <bind arguments> ON TABLE FLIGHTAVAILABILITY WHERE FLIGHTID = <SomeFLIGHTID> ; If table is partitioned by columns in the where clause the procedure execution is pruned to nodes with the data (node with <someFLIGHTID> in this case) CALL [PROCEDURE] procedure_name ( [ expression [, expression ]* ] ) [ WITH RESULT PROCESSOR processor_name ] [ { ON TABLE table_name [ WHERE whereClause ] } | { ON {ALL | SERVER GROUPS (server_group_name [, server_group_name ]*) }} ] Fabric Server 2 Fabric Server 1 Client
    33. 33. Parallelize procedure then aggregate (reduce) Fabric Server 2 Fabric Server 1 Client Fabric Server 3 CALL SQLF.CreateResultProcessor( processor_name, processor_class_name); register a Java Result Processor (optional in some cases) : CALL [PROCEDURE] procedure_name ( [ expression [, expression ]* ] ) [ WITH RESULT PROCESSOR processor_name ] [ { ON TABLE table_name [ WHERE whereClause ] } | { ON {ALL | SERVER GROUPS (server_group_name [, server_group_name ]*) }} ]
    34. 34. Consistency model
    35. 35. Consistency Model without Transactions <ul><ul><li>Replication within cluster is always eager and synchronous </li></ul></ul><ul><ul><li>Row updates are always atomic; No need to use transactions </li></ul></ul><ul><ul><li>FIFO consistency: writes performed by a single thread are seen by all other processes in the order in which they were issued </li></ul></ul><ul><ul><li>Consistency in Partitioned tables </li></ul></ul><ul><ul><ul><li>a partitioned table row owned by one member at a point in time </li></ul></ul></ul><ul><ul><ul><li>all updates are serialized to replicas through owner </li></ul></ul></ul><ul><ul><ul><li>&quot;Total ordering&quot; at a row level: atomic and isolated </li></ul></ul></ul><ul><ul><li>Membership changes and consistency – need another hour  </li></ul></ul><ul><ul><li>Pessimistic concurrency support using ‘Select for update’ </li></ul></ul><ul><ul><li>Support for referential integrity </li></ul></ul>
    36. 36. Distributed Transactions <ul><ul><li>Full support for distributed transactions (Single phase commit) </li></ul></ul><ul><ul><li>Highly scalable without any centralized coordinator or lock manager </li></ul></ul><ul><ul><li>We make some important assumptions </li></ul></ul><ul><ul><ul><li>Most OLTP transactions are small in duration and size </li></ul></ul></ul><ul><ul><ul><li>W-W conflicts are very rare in practice </li></ul></ul></ul><ul><ul><li>How does it work? </li></ul></ul><ul><ul><ul><li>Each data node has a sub-coordinator to track TX state </li></ul></ul></ul><ul><ul><ul><li>Eagerly acquire local “write” locks on each replica </li></ul></ul></ul><ul><ul><ul><ul><li>Object owned by a single primary at a point in time </li></ul></ul></ul></ul><ul><ul><ul><li>Fail fast if lock cannot be obtained </li></ul></ul></ul><ul><ul><li>Atomic and works with the cluster Failure detection system </li></ul></ul><ul><ul><li>Isolated until commit </li></ul></ul><ul><ul><ul><li>Only support local isolation during commit </li></ul></ul></ul>
    37. 37. Scaling disk access with shared nothing disk files and a “journaling” store design
    38. 38. Disk persistence in SQLF <ul><li>Parallel log structured storage </li></ul><ul><li>Each partition writes in parallel </li></ul><ul><li>Backups write to disk also </li></ul><ul><ul><li>Increase reliability against h/w loss </li></ul></ul><ul><li>Don ’t seek to disk </li></ul><ul><li>Don ’t flush all the way to disk </li></ul><ul><ul><li>Use OS scheduler to time write </li></ul></ul><ul><li>Do this on primary + secondary </li></ul><ul><li>Realize very high throughput </li></ul>
    39. 39. Performance benchmark
    40. 40. How does it perform? Scale? <ul><li>Scale from 2 to 10 servers (one per host) </li></ul><ul><li>Scale from 200 to 1200 simulated clients (10 hosts) </li></ul><ul><li>Single partitioned table: int PK, 40 fields (20 ints, 20 strings) </li></ul>
    41. 41. How does it perform? Scale? <ul><li>CPU% remained low per server – about 30% indicating many more clients could be handled </li></ul>
    42. 42. Is latency low with scale? <ul><li>Latency decreases with server capacity </li></ul><ul><li>50-70% take < 1 millisecond </li></ul><ul><li>About 90% take less than 2 milliseconds </li></ul>
    43. 43. Q & A <ul><li>VMWare vFabric SQLFire BETA available now </li></ul><ul><li>Checkout http://communities.vmware.com/community/vmtn/appplatform/vfabric_sqlfire </li></ul>
    44. 44. Built using GemFire object data fabric + Derby

    ×