Counting is hard (at scale)

Russell Brown @russelldb

Big data - More machines

•Availability

•Fault tolerance

•Low latency

Distributed = CAP

!!!<-­‐  Consistent  -­‐-­‐-­‐-­‐-­‐-­‐  Available  -­‐>  !!Atomic  -­‐  Identity  -­‐  idempotent  -­‐  ec  -­‐  Probalistic  

Counting waits; Waiting counts

Joseph M. Hellerstein -“The Declarative Imperative”

•Consensus/coordination (count)

•Count all records (wait)

•Non-monotonicity means synchronisation (+/- on a counter?)

Stop! I Can’t Count

•Atomic sequences

•Fail when unavailable

•Registering users

•Checking out

I Just Can’t Stop

•Events you have no control over

•Web hit counts

•Traffic counts

•“Likes!”

•Reduce accuracy for availability

No Means Yes, Maybe.

•Partial failures with sloppy quorum

•Re-try? D-Double count.

•Idempotency

•Space trade off

•Acks / TTL?

Probably

•Probabilistic

•Sampling

•Estimates

•Great for cardinality, poor for identity

•Great for the scalezzzz

Implementations

•Ids -> Ticket servers, RDBMS, Redis

•Atomic counts -> RDBMS / Zookeeper / App Engine

•Distributed Ids -> Snowflake / zookeeper / SQL Shards

Implementations

•EC Idempotent -> Bueller?

•EC -> Riak / Cassandra / NoSql

•Estimates -> Stats / Sampling

Take Home?

•Know what you’re counting

•Know why

•Make your trade off based on use case

•BUT think ahead (big data got that way ‘cos it grew)