Saltar al contenido principal
CargarIdioma (ES)Atención al cliente
EmpresarialesMóvilRedes socialesMarketingTecnologíaArte y fotografíaEmpleoDiseñoEducaciónPresentaciones y charlas públicasGobierno y org. sin ánimo de lucroAtención sanitariaInternetDerechoLiderazgo y gestiónMotorIngenieríaSoftwareReclutamiento y RR. HH.Venta al por menorVentasServiciosCienciasPYMES y liderazgoAlimentaciónMedio ambienteEconomía y finanzasDatos y análisisRelaciones con inversoresDeportesMeditaciónNoticias y políticaViajesDesarrollo personalSector inmobiliarioEntretenimiento y humorSalud y medicinaDispositivos y hardwareEstilo de vida
ScyllaDB, profile picture
Subido porScyllaDB
PPTX, PDF11 vistas

Optimizing Write-Intensive Database Workloads Masterclass: Why Scaling Writes is So Hard

Everything hurts more at scale. We begin by looking at the specific factors that make write-heavy workloads challenging to scale and discussing the related tradeoffs you need to negotiate. - Write challenges commonly faced in different use cases: IoT, gaming, ad tech, financial - How database internals and configuration options impact write performance - Models for predicting your breaking point

Tecnología◦
Temas relacionados:
NoSQL Database Insights•
Descargar para leer sin conexión
Optimizing write intensive DB workloads WELCOME MASTERCLASS
Optimizing Write-Intensive Database Workloads 2 AGENDA TIME 8:30am PT WELCOME + EVENT PREVIEW 8:35am PT SESSION 1: Why is Scaling Writes so Hard? | FELIPE MENDES 9:05am PT SESSION 2: Optimizing Write Performance | GUILHERME NOGUEIRA 9:35am PT SESSION 3: Troubleshooting Write-Path Bottlenecks | FELIPE & GUILHERME 10:05am PT WRAP-UP + HOW TO WIN
Optimizing Write-Intensive Database Workloads 3 All content is here on the STAGE LOUNGE is open now Need help? Visit RECEPTION
Ask the best 5 questions in chat and win a copy of Database Performance at Scale
All Things Performance A ScyllaDB Community Virtual Event | OCTOBER 21 + 22, 2026 Register now at p99conf.io
Pass the exam and win a certificate and swag pack!
Why Scaling Writes is so Hard? MASTERCLASS Felipe Cardeneti Mendes
Optimizing Write-Intensive Database Workloads Reads!
Optimizing Write-Intensive Database Workloads Persisting Data Every write is a contract between durability, consistency and latency. Typical write-scaling challenges involve: ■ Contention (locks, pages, log tail, index structures, etc) ■ Replication (write amplification) ■ Coordination (network amplification, distributed consensus) ■ Costs (pay-per-operation models, single-writer topologies) 9
Optimizing Write-Intensive Database Workloads Postgres Write Path *PRIMARY/UNIQUE Key assumed 10 INSERT UPDATE │ │ ▼ ▼ Check unique index* Locate row │ (index scan or seq scan) │ │ ▼ ▼ Find heap page Read heap page / free space / existing tuple │ │ ▼ ▼ Create new tuple Mark old tuple version │ │ │ ▼ │ Create new tuple version │ │ ▼ ▼ Update indexes Update indexes │ (unless HOT) │ │ └─────────────────┬─────────────────┘ ▼ WAL write/flush │ ▼ COMMIT returns │ ▼ ─────── later ─────── │ ▼ Dirty pages written
Optimizing Write-Intensive Database Workloads LSM's Write Path 11 WRITE │ ▼ Append to WAL │ ▼ Insert into memtable │ ▼ Return │ ▼ ─────── later ─────── │ ▼ Flush to disk │ ▼ ───── background ──── │ ▼ Compaction
Optimizing Write-Intensive Database Workloads Storage Engine The database storage engine directly impact the cost of a write 12 LSM Tree ■ Appends B-Tree ■ In-place RMW
Optimizing Write-Intensive Database Workloads Replication Strategies 13 Single leader Designing Data Intensive Applications. Kleppmann, Martin. Chapter 5 – Replication, p.153 Designing Data Intensive Applications. Kleppmann, Martin. Chapter 5 – Replication, p.169 Designing Data Intensive Applications. Kleppmann, Martin. Chapter 5 – Replication, p.180 Multi leader Leaderless
Optimizing Write-Intensive Database Workloads Coordination – Distributed Consensus 14 R1 Propose a value / Check condition Accept new value R2 R3 Learn decision Prune Decision made o k ! o k ! o k ! o k o k ! ok! Client reply Client request SERIAL LOCAL SERIAL ANY, ONE, QUORUM ■ Paxos ■ Raft
Optimizing Write-Intensive Database Workloads Coordination – Last Write Wins (Dynamo W+R>N) 15 ■ Leaderless Quorum Designing Data Intensive Applications – Martin Kleppmann
Optimizing Write-Intensive Database Workloads LWW Conflict Resolution (ScyllaDB Example) 16 Compare write timestamps │ ┌──────────────┴──────────────┐ ▼ ▼ timestamps differ timestamps equal │ │ ▼ ▼ Highest timestamp Tie-break wins │ ▼ Is either cell dead? │ ▼ dead cell wins ── both cells alive ── │ ▼ Does either cell have an expiration (TTL)? │ ▼ cell with expiry wins ── both alive ── │ ▼ lexicographically higher value wins ScyllaDB Conflict Resolution Algorithm
Optimizing Write-Intensive Database Workloads pending view writes Materialized Views, Indexes and other animals ■ Coordinator sends writes to RF replicas, waits for CL (eg QUORUM) of those writes to complete. ■ Each replica asynchronously updates its paired view ■ These updates could involve lots of read activity! ■ With V views, we amplify writes by 2*V ■ If write fan-in is faster than view updates can complete, the number of queued view updates can grow unbounded ■ How to prevent view backlog from growing endlessly? 17
Optimizing Write-Intensive Database Workloads Flow Control pending base writes pending view writes ■ Delay each client write by an extra delay ■ Higher delay: slows client, view-update backlog declines ■ Lower delay: speeds-up client, view-update backlog increases ■ Goal: a dynamic controller, changing the delay as backlog changes ■ delay = α * backlog 18 ScyllaDB Flow Control: As Fast as Possible, But Not Faster
Optimizing Write-Intensive Database Workloads Vector Indexes easily contend resources 19
Optimizing Write-Intensive Database Workloads Ingestion vs Inference (incl. Recall Drop) 20
Which is why separation of concerns is good
Optimizing Write-Intensive Database Workloads Global Scale Trade-offs 22 ■ Don'ts: ○ Block on remote region ack ○ Replicate unnecessary data ○ Route queries to remote ○ Replicate yourself ■ Do's: ○ Bring data closer to users ○ Let the DB handle it ○ Use LOCAL_* consistency ○ Beware of conflict resolution App App App App App App Active/Active, replicated, auto-sharded
Optimizing Write-Intensive Database Workloads Write-Intensive Use Cases 23
Optimizing Write-Intensive Database Workloads Commonly Seen 24 ■ 📟 Internet of Things ■ Often time-series workloads ■ Small (but frequent!) append-only writes ■ Rate determined by number of ingestion endpoints ■ 📶 Logging and Monitoring ■ Similar to IOT, but… ■ Doesn't have a fixed ingestion rate ■ Prone to hotspots ■ 🎮 Online Gaming ■ Real-time user interactions (state, actions, messaging) ■ Often spiky ■ Very latency dependant ■ 🚚 E-commerce & Retail ■ Update-heavy and Batch-y ■ Inventory updates, reviews, order status & placement ■ Shopping carts inherently require a read-before- write ■ 🔔 Ad Tech and Real-time Bidding ■ Bid Processing (Impressions, Auction outcomes) ■ User Interaction (Clicks, Conversions, Fraud Detection) ■ Audience Segmentation ■ 📈 Real-time Stock exchange ■ High-frequency trading (HFT) ■ Stock prices updates ■ Order matching
Optimizing Write-Intensive Database Workloads Zillow – Real-time Property Updates Consuming records from different data producers: Out of Order Writes + Why not SQL? Locking. + Can't simply insert everything: Data bloat, higher costs + Solution: INSERT … USING TIMESTAMP ? “No one will even notice that we’re processing the entirety of Zillow’s property and listings data in order to correct some data issue or change a business rule. The beauty of that is we can process the entirety of the data at Zillow that we care about in less than a business day and, again, no performance hit to real-time data.” – Dan Podhola, Principal Software Engineer Zillow: Optimistic Concurrency with Write-Time Tim estamps 25
Optimizing Write-Intensive Database Workloads Unleashing the Power of Data wit h Scylla "We were looking for something really specific.A highly scalable, and highly performant NoSQL database. The answer was simple, ScyllaDB is a better fit for our use case." João Pedro Voltani – Head of Engineering 26
Optimizing Write-Intensive Database Workloads Fanatics – Retail Operations Use cases: + Order capture + Product Catalog + Shopping Carts + Promotions, … “During a recent peak minute, we saw nearly 280,000 IOPs for a solid minute. With a 3-node ScyllaDB cluster, we registered zero timeouts. Because of this we had happier customers and application teams.” – Niraj Kothari, Director of Platforms Engineering Read the Case St 27
Optimizing Write-Intensive Database Workloads Application Best Practices 28
Optimizing Write-Intensive Database Workloads Food For Thought ■ In an app, users must register with a valid email ● 1:1 id:email relationship ● Every email is unique ■ Prevent: ● Concurrent sign ups for same e-mail ● Later updates to the same e-mail ■ How?
Optimizing Write-Intensive Database Workloads ■ Far too complex? ● Requires handling state ● Worker fails, transaction succeeds, now what? ■ Way too many round trips ● Added latency! Option 1: Let the database handle it! Client App uid email N X email uid X N 1. INSERT INTO … IF NOT EXISTS 2. Update mapping
Optimizing Write-Intensive Database Workloads Option 2: Handle in App … with a Mutex? ■ Works, BUT… ● Waiters wait ● Observe added latency! :-( ■ But prime example on coalescing ;-) ● In which case, eliminates latency! Worker A Worker B Worker C Requests foo@bar bar@foo jon@doe var locks sync.Map func getLock(email string) *sync.Mutex { l, _ := locks.LoadOrStore(email, &sync.Mutex{}) return l.(*sync.Mutex) } func processEmail(email string, uuid string) { m := getLock(email) m.Lock() defer m.Unlock() // Critical section } BEGIN BATCH INSERT INTO ids (X, N) INSERT INTO emails (N, X) APPLY
Optimizing Write-Intensive Database Workloads Option 3: Handle in App, Fail-fast ■ Little sense to Mutex on such a thing ● First one arriving is the winner anyway ■ Fail-fast, allow the client to retry ● Careful with concurrency ■ Simpler, faster and lock-free! Worker A Worker B Worker C Requests foo@bar bar@foo jon@doe var inflight sync.Map func processEmail(email string, uuid string) { _, n := inflight.LoadOrStore(email, struct{}{}) if n { return false } defer n.Delete(email) // Critical section } BEGIN BATCH INSERT INTO ids (X, N) INSERT INTO emails (N, X) APPLY
Optimizing Write-Intensive Database Workloads Why ScyllaDB for <add use case>? 33 ■ Performance-first distributed architecture ■ Highly concurrent, lock-free, multi-writer design ■ Just in time elastic scaling App App App App App App Active/Active, replicated, auto-sharded
Optimizing Write-Intensive Database Workloads Keep in touch! Felipe Mendes Technical Director ScyllaDB felipe@scylladb.com Find me on LinkedIn!
Optimizing Write-Intensive Database Workloads 35 EXAM TIME bit.ly/3SMfL1Y
Optimizing Write-Intensive Database Workloads Key Point 36
Optimizing Write-Intensive Database Workloads Slide Title Top Gradient 2 Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Morbi ultrices sed nulla non pellentesque. Ut ac tortor facilisis neque ultricies egestas quis tempus erat. Aenean a finibus leo, sit amet congue nibh. 37
Optimizing Write-Intensive Database Workloads Slide Title Lorem ipsum dolor sit amet, consectetur adipiscing elit. Praesent consectetur ipsum eu mauris finibus gravida. In lacinia volutpat lectus sed sollicitudin. ■ Morbi pellentesque purus quam, vel feugiat ipsum pharetra eu. Fusce viverra nibh sed egestas faucibus. ■ Nunc bibendum eget metus eget gravida. ■ Cras ultrices tortor mauris, nec porta sapien placerat ut. 38
Optimizing Write-Intensive Database Workloads All Blank Slide Title Goes Here 39
Optimizing Write-Intensive Database Workloads Table Example Column 1 Column 2 Column 3 Requests/Minute 12M 500K AVG Latency 4 ms 8 ms Max Latency 8 ms 35 ms 40
Optimizing Write-Intensive Database Workloads 41
42 Submit an accepted review of ScyllaDB on G2 and win a $50 gift card!* *While supplies last. Earn $50!