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

Can Postgres scale like DynamoDB?

Can Postgres scale like DynamoDB?

DynamoDB is one of the most praised and reputed services from Amazon Web Services. While offering a very simple model to the users, and with some notable limitations, it can scale almost endlessly. It is reported to have achieved 80M transactions per second, when servicing Amazon Retail platform on Black Friday 2020.

Key to DynamoDB’s scalability is a shared-nothing, scale-out and multi-tenant architecture. Postgres doesn’t have a native sharding capability, but would it be needed to offer similar performance and scalability characteristics to those of DynamoDB? How could it be done?

This talk is about DynamoDB’s architecture, similarities and differences with Postgres, and understand how Postgres may scale in a similar way.

OnGres

May 20, 2021
Tweet

More Decks by OnGres

Other Decks in Technology

Transcript

  1. ` whoami ` Álvaro Hernández aht.es @ahachete • Founder &

    CEO, OnGres • 20+ years Postgres user and DBA • Mostly doing R&D to create new, innovative software on Postgres • Frequent speaker at Postgres, database conferences • Principal Architect of StackGres, ToroDB • Founder and President of the NPO Fundación PostgreSQL • AWS Data Hero
  2. A high-traffic Postgres example GitLab.com spikes to >300K Postgres tx/s

    on a single cluster: https://about.gitlab.com/blog/2020/09/11/gitlab-pg-upgrade/
  3. What is DynamoDB • A scale-out, NoSQL database • Key-Value:

    ◦ Key: a simple or composite PK ◦ Value: a JSON blob • Consistent performance at any scale: single-digit ms queries • Severless • Pay-per-use ◦ WCUs, RCUs ◦ Storage, data transfer
  4. What makes DynamoDB so successful • Yeah, that it’s serverless.

    • Yeah, that it scales without limits. • But in reality, what makes DynamoDB unique is: Consistent and low latency at any scale. Below 10ms
  5. What makes DynamoDB so special • Yeah, that it’s serverless.

    • Yeah, that it scales without limits. • But in reality, what makes DynamoDB unique is: Consistent and low latency at any scale. Below 10ms • What, 10ms???? My Postgres answers queries in less than 1ms!
  6. What makes DynamoDB so special • Yeah, that it’s serverless.

    • Yeah, that it scales without limits. • But in reality, what makes DynamoDB unique is: Consistent and low latency at any scale. Below 10ms • What, 10ms???? My Postgres answers queries in less than 1ms! • At any scale? • Consistently? What are your p99 response times?
  7. DynamoDB (relevant) Operations • Single-value, single-partition operations: ◦ PutItem, DeleteItem,

    GetItem, UpdateItem ◦ Compute hash of partition key, go to shard, operate on value • Multiple-value, single-partition operations: ◦ Query. Reads values with the same hash, sorted by sort key • Multiple-value, multiple-partition operations: ◦ Scan ◦ Supports (server assisted) parallelism • Multiple-value operations: max 1MB results, provides pagination mechanisms, filtering (still consumes RCUs!)
  8. DynamoDB (missing?) Operations • No joins • No aggregations •

    No advanced queries (windows, subqueries…) Why?? By design. To keep latency single-digit ms.
  9. Citus limitations for DynamoDB scale • Single controller ◦ Controller

    has a bit of state (metadata + local tables) ◦ It’s possible to have multiple (with replication among them), but is not mainstream ◦ Don’t use local tables • Main reason: processing time in the controller is not guaranteed to scale like DynamoDB. Complex queries and scatter-gather communication with shards are an anti-pattern in DynamoDB model.
  10. postgres_fdw limitations for DynamoDB scale • postgres_fdw limitations ◦ Doesn’t

    push down all the clauses ◦ When talking to multiple shards, it works serially ◦ Requires connection pooling • Main reason: processing time in the controller is not guaranteed to scale like DynamoDB. Complex queries and scatter-gather communication with shards are an anti-pattern in DynamoDB model.
  11. Application-based sharding • Noted that the main reason for not

    achieving DynamoDB scale with either Citus or postgres_fdw is essentially the same? • Processing time in the coordinator and complexity of allowed operations violate DynamoDB’s main promise: single-digit ms response times. • What’s the alternative then? • Application-based sharding. • Involving the client or application in the sharding process, sending the queries directly to the appropriate shard. • Except for scan, all operations are single-shard (single partition)
  12. Possible table structure Table "public.pglikedy_simple" ┌─────────┬────────┬───────────┬──────────┬─────────┐ │ Column │ Type

    │ Collation │ Nullable │ Default │ ├─────────┼────────┼───────────┼──────────┼─────────┤ │ hash │ bigint │ │ not null │ │ │ content │ jsonb │ │ not null │ │ └─────────┴────────┴───────────┴──────────┴─────────┘ Indexes: "pglikedy_simple_hash_key" UNIQUE CONSTRAINT, btree (hash) "pglikedy_simple_pk" UNIQUE, btree ((content -> 'partitionKey'::text)) Table "public.pglikedy_composite" ┌─────────┬────────┬───────────┬──────────┬─────────┐ │ Column │ Type │ Collation │ Nullable │ Default │ ├─────────┼────────┼───────────┼──────────┼─────────┤ │ hash │ bigint │ │ not null │ │ │ content │ jsonb │ │ not null │ │ └─────────┴────────┴───────────┴──────────┴─────────┘ Indexes: "pglikedy_composite_pk" UNIQUE, btree ((content -> 'partitionKey'::text), (content -> 'sortKey'::text))
  13. Would it scale like DynamoDB? • Scaling is essentially linear

    with the number of shards (partitions) • Almost all (permitted) operations are single-partition, and the issuer knows which partition to be directed to: hash(primaryKey) -> partition • Scan is essentially a composition of Query commands, potentially out-of-order. • Architecture is complex, needing request routers, metadata servers for partition -> server placement, re-sharding… • But would allow, theoretically, Postgres to scale like DynamoDB!