Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Five sharding data models and which is right? P...

Five sharding data models and which is right? PGDay Nordic

Craig Kerstiens

March 14, 2018
Tweet

More Decks by Craig Kerstiens

Other Decks in Technology

Transcript

  1. What is sharding Practice of separating a large database into

    smaller, faster, more easily managed parts called data shards. Source: the internet
  2. A table A schema A PG database A node An

    instance A PG cluster Is it a shard? NO YES
  3. Hash - The steps 1. Hash your id 2. Define

    a shard range x shards, and each contain some range of hash values. Route all inserts/updates/deletes to the shard 3. Profit
  4. More details • Hash based on some id • Postgres

    internal hash can work fine, or so can your own • Define your number of shards up front, make this larger than you expect to grow to in terms of nodes • (2 is bad) • (2 million is also bad) • Factors of 2 are nice, but not actually required
  5. Create range of hash values • hash 1 = 46154

    • hash 2 = 27193 • Shard 13 = ranges 26624 to 28672
  6. Range - The steps 1. Ensure you’ve created your new

    destination for your range 2. Route your range to the right bucket 3. Profit
  7. Shard by Geography • Is there a clear line I

    can draw for a geographical boundary • Good examples: income by state, healthcare, etc. • Bad examples: • Text messages: 256 sends to 510, both want a copy of this data…
  8. Will geography sharding work for you? • Do you join

    across geographies? • Does data easily cross boundaries? • Is data queries across boundaries or a different access frequently?
  9. More specifics • Granular vs. broad • State vs. zip

    code • (California and texas are bad) • Zip codes might work, but does that work for your app?
  10. Common use cases • If your go to market is

    geography focused • Instacart/Shipt • Uber/Lyft
  11. Real world application • Range sharding makes moving things around

    harder here • Combining the geography and giving each and id, then hashing (but using smaller set of shards) can give better balance to your data
  12. Sharding by tenant • Is each customer’s data their own?

    • What’s your data’s distribution? • (If one tenant/customer is 50% of your data tenant sharding won’t help) • If it’s 10% of your data you may be okay
  13. Guidelines for multi-tenant sharding • Put your tenant_id on every

    table that’s relevant • Yes, denormalize • Ensure primary keys and foreign keys are composite ones (with tenant_id) • Enforce your tenant_id is on all queries so things are appropriately scoped
  14. Salesforce schema CREATE TABLE leads ( id serial primary key,

    first_name text, last_name text, email text ); CREATE TABLE accounts ( id serial primary key, name text, state varchar(2), size int ); CREATE TABLE opportunity ( id serial primary key, name text, amount int );
  15. Salesforce schema - with orgs CREATE TABLE leads ( id

    serial primary key, first_name text, last_name text, email text, org_id int ); CREATE TABLE accounts ( id serial primary key, name text, state varchar(2), size int org_id int ); CREATE TABLE opportunity ( id serial primary key, name text, amount int org_id int );
  16. Salesforce schema - with orgs CREATE TABLE leads ( id

    serial primary key, first_name text, last_name text, email text, org_id int ); CREATE TABLE accounts ( id serial primary key, name text, state varchar(2), size int org_id int ); CREATE TABLE opportunity ( id serial primary key, name text, amount int org_id int );
  17. Salesforce schema - with keys CREATE TABLE leads ( id

    serial, first_name text, last_name text, email text, org_id int, primary key (org_id, id) ); CREATE TABLE accounts ( id serial, name text, state varchar(2), size int, org_id int, primary key (org_id, id) ); CREATE TABLE opportunity ( id serial, name text, amount int,
  18. Salesforce schema - with keys CREATE TABLE leads ( id

    serial, first_name text, last_name text, email text, org_id int, primary key (org_id, id) ); CREATE TABLE accounts ( id serial, name text, state varchar(2), size int, org_id int, primary key (org_id, id) ); CREATE TABLE opportunity ( id serial, name text, amount int,
  19. Warnings about multi-tenant implementations • Danger ahead if using schemas

    on older PG versions • Have to reinvent the wheel for even the basics • Schema migrations • Connection limits • Think twice before using a schema or database per tenant
  20. Entity id • What’s an entity id? • Something granular

    • Want to join where you can though • Optimizing for parallelism and less for data in memory
  21. Examples tell it best • Web analytics • Shard by

    visitor_id • Shard both sessions and views • Key is to co-locate things you’ll join on
  22. Map reduce examples • Count (*) • SUM of 32

    smaller count (*) • Average • SUM of 32 smaller SUM(foo) / SUM of 32 smaller count(*) • Median • uh….
  23. But I like medians and more • Count distinct •

    HyperLogLog • Ordered list approximation • Top-n • Median • T-digest or HDR
  24. But what about sharding? • Within a graph model you’re

    going to duplicate your data • Shard based on both: • The objects themselves • The objects subscribed to other objects
  25. Time series • Range partitioning • 2016 in a bucket,

    2017 in a bucket • 2016-01-01 in a bucket, 2016-01-02 in a bucket… • Key steps • Determine your ranges • Make sure you setup enough in advance, or automate creating new ones • Delete
  26. Sensor data CREATE TABLE measurement ( city_id int not null,

    logdate date not null, peaktemp int, unitsales int );
  27. Sensor data - initial partition CREATE TABLE measurement ( city_id

    int not null, logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate);
  28. Sensor data - initial partition CREATE TABLE measurement ( city_id

    int not null, logdate date not null, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate);
  29. Sensor data - setting up partitions CREATE TABLE measurement_y2017m10 PARTITION

    OF measurement FOR VALUES FROM ('2017-10-01') TO ('2017-10-31'); CREATE TABLE measurement_y2017m11 PARTITION OF measurement FOR VALUES FROM ('2017-11-01') TO ('2017-11-30');
  30. Sensor data - indexing CREATE TABLE measurement_y2017m10 PARTITION OF measurement

    FOR VALUES FROM ('2017-10-01') TO ('2017-10-31'); CREATE TABLE measurement_y2017m11 PARTITION OF measurement FOR VALUES FROM ('2017-11-01') TO ('2017-11-30'); CREATE INDEX ON measurement_y2017m10 (logdate); CREATE INDEX ON measurement_y2017m11 (logdate);
  31. Sensor data - inserting CREATE TRIGGER insert_measurement_trigger BEFORE INSERT ON

    measurement FOR EACH ROW EXECUTE PROCEDURE measurement_insert_trigger();
  32. Sensor data - inserting CREATE OR REPLACE FUNCTION measurement_insert_trigger() RETURNS

    TRIGGER AS $$ BEGIN IF ( NEW.logdate >= DATE '2017-02-01' AND NEW.logdate < DATE '2017-03-01' ) THEN INSERT INTO measurement_y2017m02 VALUES (NEW.*); ELSIF ( NEW.logdate >= DATE '2017-03-01' AND NEW.logdate < DATE '2017-04-01' ) THEN INSERT INTO measurement_y2017m03 VALUES (NEW.*); ... ELSIF ( NEW.logdate >= DATE '2018-01-01' AND NEW.logdate < DATE '2018-02-01' ) THEN INSERT INTO measurement_y2018m01 VALUES (NEW.*); ELSE RAISE EXCEPTION 'Date out of range. Fix the measurement_insert_trigger() function!'; END IF; RETURN NULL; END; $$ LANGUAGE plpgsql;
  33. Recap • Not sharding is always easier than sharding •

    Identify your sharding approach/key early, denormalize it even when you’re small • Don’t force it into one model. No model is perfect, but disqualify where you can • Sharding used to be much more painful, it’s not quite a party yet, but it’s