Skip to Navigation
In this video, RavenDB CEO Oren Eini shows you how to get 1,000 writes and 13,000 reads per second on a $35 Raspberry Pi by easily setting up our RavenDB NoSQL Document Database on a server that fits in the palm of your hand.
Featuring:
1,000 writes and 13,000 reads per second on a Raspberry Pi $35 server that fits in the palm of your hand.
In this video, we set up security pretty quickly and work on a Python console. On the Python console app, we will create functions where you are pulling data, querying data, updating data, and indexing data on your Raspberry Pi device.
Even for a simple query like this, our NoSQL Document Database automatically sets up an index to make sure traversing your data involves as little latency as possible. Especially for a Raspberry Pi where memory and compute power can be a little tight, RavenDB sets up data worm holes to get your information quickly.
You can see that there were some changes made to the data. So we want to see if there is an audit history for the documents that were changed. For a document that has been updated, there is a flag for revisions, so we know which documents have a revision history of every revision. For all updated documents, we can call them, see every revision performed on the document, and even drill down into each version of the document and see what changed in the revision.
Yes, there are errors in coding this simple application, the assumption is that errors must be handled as much as prevented. RavenDB helps you scale development hurdles by making error explanations very clear so you can troubleshoot easy, determine the issue, and decide quickly how to fix it.
What if you want to have more than one instance of your database running? You can set up an additional instance on the cloud and run the nodes in tandem with one another.
Here, we set up an instance of the same database on AWS. Then we start to replicate the data from the Raspberry Pi instance to the cloud database.
Once a secure links is set up, an ETL process replicates from the Raspberry Pi to the cloud. This creates a situation where your on-premise database is instantly replicated to the cloud.
The limits of this system is that data flows in one direction, from your Raspberry Pi instance to your cloud. What if you wanted data to go in both directions?
You can use another task in RavenDB called pull replication where data will move from the cloud instance to your Raspberry Pi database. This makes networking between the cloud and your Pi a lot easier, saving you lots of steps, time, and complexity without sacrificing security.
One Document database connected to one replicated cloud instance makes a nice database system, but what happens when you have a chain of stores and need something more sophisticated? What if you have 5 bakeries in 5 locations throughout the city with all of them feeding data into their own Raspberry Pi server?
If all of the bakeries worked the same, with the same data going back and forth, there isn’t much more to do but to set up more nodes of the same database and bind them to different URL’s.
But what happens when each bakery has its own unique operations, and generates data that is different from every other location? What if one bakery sold only cookies, another cakes, and another offered everything vegan?
We can set up a data subscription, or a persistent query as an ongoing task to alert us if something is vegan or not, and it can be included in the products offered by the vegan branch. In this instance, we tell RavenDB to analyze every new product for the inclusion of “cheese”. If an item doesn’t have cheese, let it be updated to the vegan document for “menu”. If it does have cheese, do not replicate to the vegan menu. This will happen for every update. A product can have updated ingredients to include cheese, or have cheese replaced with, say, soy, in which the subscription will indicate whether or not the new type of product should be in the vegan menu document, or, a new product all together can be made and the data subscription will decide if it goes to the vegan menu or not.
Because you have ETL replication that replicates from your Raspberry Pi to your cloud, a data subscription will update the documents you want to update in the Raspberry Pi, and the relevant documents that are tied to a data subscription. Since RavenDB also gives you pull replication, you can also make changes in your cloud instance and it will be replicated to the Raspberry Pi instance where documents that are affected by the data subscription will also be impacted. This means you can make changes on either instance of your database and both locations, the Raspberry Pi and the cloud will instantly update to reflect the most current state of your data.
This gives you enormous flexibility in determining and evolving your application architecture.
