Scaling PostreSQL with Stado

  • 4,227 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
4,227
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
55
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Scaling PostgreSQL with Stado
  • 2. Who Am I?• Jim Mlodgenski – Founder of Cirrus Technologies – Former Chief Architect of EnterpriseDB – Co-organizer of NYCPUG
  • 3. Agenda• What is Stado?• Architecture• Query Flow• Scaling• Limitations
  • 4. What is Stado?• Continuation of GridSQL• “Shared-Nothing”, distributed data architecture. – Leverage the power of multiple commodity servers while appearing as a single database to the application• Essentially... Open Source Greenplum, Netezza or Teradata
  • 5. Stado Details• Designed for Parallel Querying• Not just “Read-Only”, can execute UPDATE, DELETE• Data Loader for parallel loading• Standard connectivity via PostgreSQL compatible connectors: JDBC, ODBC, ADO.NET, libpq (psql)
  • 6. What Stado is not?• A replication solution like Slony or Bucardo• A high availability solution like Synchronous Replication in PostgreSQL 9.1• A scalable transactional solution like PostgresXC• An elastic, eventually consistent NoSQL database
  • 7. Architecture• Loosely coupled, shared- nothing architecture• Data repositories – Metadata database – Stado database• Stado processes – Central coordinator – Agents
  • 8. Configuration• Can be configured for multiple logical “nodes” per physical server – Take advantage of multi-core processors• Tables may be either replicated or partitioned• Replicated tables for static lookup data or dimensions – Partitioned tables for large fact tables
  • 9. Partitioning• Tables may simultaneously use Stado Partitioning with Constraint Exclusion Partitioning – Large queries scan a much smaller subset of data by using subtables – Since each subtable is also partitioned across nodes, they are scanned in parallel – Queries execute much faster
  • 10. Creating Tables• Tables can be partitioned or replicatedCREATE TABLE STATE_CODES ( STATE_CD varchar(2) PRIMARY KEY, USPS_CD varchar(2), NAME varchar(100), GNISIS varchar(8)) REPLICATED;
  • 11. Creating TablesCREATE TABLE roads ( gid integer NOT NULL, statefp character varying(2), countyfp character varying(3), linearid character varying(22), fullname character varying(100), rttyp character varying(1), mtfcc character varying(5), the_geom geometry)PARTITIONING KEY gid ON ALL;
  • 12. Query Optimization• Cost Based Optimizer – Takes into account Row Shipping (expensive)• Looks for joins with replicated tables – Can be done locally – Looks for joins between tables on partitioned columns
  • 13. Two Phase Aggregation• SUM – SUM(stat1) – SUM2(SUM(stat1)• AVG – SUM(stat1) / COUNT(stat1) – SUM2 (SUM(stat1)) / SUM2 (COUNT(stat1))
  • 14. Query 1SELECT sum(st_length_spheroid(the_geom, SPHEROID["GRS_1980",6378137,298.257222101]))/1609.344 as interstate_miles FROM roads WHERE rttyp = I; interstate_miles ------------------ 84588.5425986619 (1 row)
  • 15. Query 1 :Results 120 100Nodes Actual (sec) 80 1 101.2080566 Time (seconds) 4 25.6410708 60 Linear Actual 8 14.3321144 40 12 5.4738612 16 4.8214672 20 0 1 4 8 12 16 Nodes
  • 16. Query 2SELECT s.name as state, c.name as county, a.population, b.road_length, a.population/b.road_length as person_per_km FROM (SELECT state_cd, county_cd, sum(population) as population FROM census_tract GROUP BY 1, 2) a, (SELECT statefp, countyfp, sum(st_length_spheroid(the_geom,SPHEROID["GRS_1980",6378137,298.257222101]))/1000 as road_length FROM roads GROUP BY 1, 2) b, state_codes s, county_codes c WHERE a.state_cd = b.statefp AND a.county_cd = b.countyfp AND a.state_cd = c.state_cd AND a.county_cd = c.county_cd AND c.state_cd = s.state_cd ORDER BY 5 DESC LIMIT 20;
  • 17. state | county | population | road_length | person_per_km----------------------+-----------------+------------+------------------+------------------New York | New York | 1537195 | 1465.35561969273 | 1049.02521909483New York | Kings | 2465326 | 2785.37685011507 | 885.096032839562New York | Bronx | 1332650 | 1638.47925579201 | 813.345665066614New York | Queens | 2229379 | 4343.78066667893 | 513.234707521383New Jersey | Hudson | 608975 | 1474.86512729116 | 412.902162191933California | San Francisco | 776733 | 2125.05706617179 | 365.51159607175Pennsylvania | Philadelphia | 1517550 | 5067.19918355051 | 299.484970894054District of Columbia | Washington | 572059 | 2191.33029860109 | 261.055579054054New York | Richmond | 443728 | 1758.77468237864 | 252.293829588156Massachusetts | Suffolk | 689807 | 2805.37242915611 | 245.887851762877New Jersey | Essex | 793633 | 3359.22581976629 | 236.254733257324Virginia | Alexandria City | 128283 | 577.98117468444 | 221.950135434841Puerto Rico | San Juan | 434374 | 1994.26820504899 | 217.811224638829Virginia | Arlington | 189453 | 967.505165121908 | 195.816008874876New Jersey | Union | 522541 | 2827.74655887522 | 184.790605919029Maryland | Baltimore City | 651154 | 3707.01218958787 | 175.654669231717Puerto Rico | Catano | 30071 | 174.765650431886 | 172.064704509654Hawaii | Honolulu | 876156 | 5098.8482067881 | 171.834101441493Puerto Rico | Toa Baja | 94085 | 558.532996996738 | 168.450208861249Puerto Rico | Carolina | 186076 | 1122.20560229076 | 165.812752690026(20 rows)
  • 18. Query 2 :Results 4500 4000 3500Nodes Actual (sec) 3000 1 3983.1002548 Time (seconds) 2500 4 1007.1235182 Linear Actual 2000 8 563.6259202 12 365.152858 1500 16 282.7345952 1000 500 0 1 4 8 12 16 Nodes
  • 19. Scalability
  • 20. Limitations• SQL Support – Uses its own parser and optimizer so: • No Window Functions • No Stored Procedures • No Full Text Search
  • 21. Transaction Performance• Single row Insert, Update, or Delete are slow compared to a single PostgreSQL instance – The data must make an additional network trip to be committed – All partitioned rows must be hashed to be mapped to the proper node – All replicated rows must be committed to all nodes• Use “gs-loader” for bulk loading for better performance
  • 22. High Availability• No heartbeat or fail-over control in the coordinator – High Availability for each PostgreSQL node must be configured separately – Streaming replication can be ideal for this• Getting a consistent backup of the entire Stado database is difficult – Must ensure there are no transaction are occurring – Backup each node separately
  • 23. Adding Nodes• Requires Downtime – Data must be manually reloaded to partition the data to the new node• With planning, the process can be fast with no mapping of data – Run multiple PostgreSQL instances on each physical server and move the PostgreSQL instances to new hardware as needed
  • 24. Summary• Stado can improve performance tremendously of queries• Stado can scale linearly as more nodes are added• Stado is open source so if the limitations are an issue, submit a patch
  • 25. Download Stado at:http://stado.usJim Mlodgenski Email: jim@cirrusql.com Twitter: @jim_mlodgenski NYC PostgreSQL User Group http://nycpug.org