How we spent $30k in Firebase in less than 72 hours

Re:How we spent $30k in Firebase in less than 72 hours by paradite on Wednesday August 01, 2018 @10:00PM (#17668724)

So it's a classic N+1 query?

[ Parent | on HN ]

Re:How we spent $30k in Firebase in less than 72 hours by alexpi on Thursday August 02, 2018 @04:56AM (#17670120)

It's more like (in good old RDBMS world) 'SELECT * FROM payments' and calculate sum on client vs 'SELECT SUM(amount) FROM payments WHERE some_id = ?'

though they already had this sum precalculated

[ Parent | on HN ]

Re:How we spent $30k in Firebase in less than 72 hours by jasonkester on Thursday August 02, 2018 @10:14AM (#17671513)

That would be more forgivable. This is:

  SELECT * FROM payments where paymentID = 1
  SELECT * FROM payments where paymentID = 2
  SELECT * FROM payments where paymentID = 3
  ...
  SELECT * FROM payments where paymentID = 14986

Each of those in its own API request over the wire, then sum them on the client.

[ Parent | on HN ]

Re:How we spent $30k in Firebase in less than 72 hours by bsaul on Thursday August 02, 2018 @04:32AM (#17670043)

Not really. N+1 is about « to many » relationships. You would need at least 2 collections to run into that problem.

In sql equivalent, what happened would be more like doing a full table scan on each query instead of using an index ( and not even that, because pre-computing a total isn’t really like an index)

This kind of « account balance » problems are typical of the problems where transactions are really useful. But also historically the kind of problem where nosql techs do a poor job ( they’re more built with « eventual consistency » in mind than atomic or transactional behaviors)

[ Parent | on HN ]