Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale

#1

Post by DivineTraube » Sun, Oct 15, 2017, 8:02 PM UTC

Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale
m.youtube.com

Re: Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale

#2

Post by code-is-code » Sun, Oct 15, 2017, 9:59 PM UTC

Meteor has the op-log-driver which calculates query-result for changes instead of running the wohle query again. Same comes with rxdb where it's called query-change-detection.

Re: Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale

#3

Post by btown » Mon, Oct 16, 2017, 4:35 AM UTC

Written format: https://medium.baqend.com/real-time-databases-explained-why-...

And the paper for their more scalable alternative: https://www.cl.cam.ac.uk/~mks40/pubs/vldb_2017.pdf

The devil will absolutely be in the details, but the speaker/author identifies a real pain point that bolting on a replication-log tailing system to provide realtime capabilities results in numerous write bottlenecks unless the system is architected from scratch to avoid them.

Re: Real-Time Databases Explained: Why Meteor, Rethink, Parse and Firebase Don't Scale

#4

Post by wolle » Mon, Oct 16, 2017, 5:37 AM UTC

code-is-code wrote: post #2

Meteor has the op-log-driver which calculates query-result for changes instead of running the wohle query again. Same comes with rxdb where it's called query-change-detection.

That's true, but monitoring the stream of change events in a single machine (be it server or client) makes this machine your bottleneck for overall system throughput.