Changefeeds lie at the heart of RethinkDB’s real-time functionality.
They allow clients to receive changes on a table, a single document, or even the results from a specific query as they happen.
You can directly tell it to shard/replicate and how many shards/replicas depending on the amount of nodes. Each node doesn't need anything except one other node's ip/port in the cluster to join and maybe the auth.
RethinkDB's ReQL is a very powerful functional query language. The functional aspects of ReQL and the straightforward implementation of the Node driver for Rethinkdb make it a natural fit for Javascript developers. You no longer have to type some obscure syntax in quotes (aka SQL), your queries are just "natural" Javascript functions in the same way you would use lodash to handle your collections.
RethinkDB has administration tools in both CLI and GUI (web app). You can view whats going on right away by going to localhost:8080. The data explorer allows you to run queries on the db.
Unlike a lot of other databases where if the master is down the system is down, this one if the master is down someone else is made master so much more peer to peer.
Redis can be used as an event hub instead of a storage database. This is done in tandem with another database used for storage.
This is helpful because it helps with separating the logic of storing data according to different events.
Redis is an in-memory database suitable for cache in order to increase the speed and availability of an application.
It can be used alongside another (classical) database which does not run in memory which can be used to store permanent data.
Usually the way Redis works is this: the client sends a request to the server and waits for a response which is returned from the server once the request is executed. This can obviously bring performance issues when trying to issue multiple commands though.
Redis mitigates this through a technique called pipelining. The way this works is: you send commands to the server in sequence and the Redis client then receives the combined responses in a single block once the pipeline is closed.
The content is deployed immediately through the Firebase CLI. Once it's uploaded, the content is served immediately. If you have made a mistake, you don't need to re-upload a new version, through the Admin dashboard you can easily rollback to a previous version.
Google acquired Firebase in Oct. 2014. This gives Firebase a degree of trustworthiness in their service and future support since they are backed by such a large company.
MongoDB queries can be very fast because the data is usually all in one place and can easily be retrieved in a single lookup. But this is true only when the data is truly a document. When it's trying to emulate a relational model it starts to become really slow because it may have to perform many independent queries to retrieve a single document.
MongoDB has powerful sharding and scaling capabilities for when the data stored in the database gets so large that a single machine may not be able to store all of it. Sharding solves this problem through horizontal scaling. Mongo gives developers the ability to easily and painlessly add or remove as many machines as needed.