-
Notifications
You must be signed in to change notification settings - Fork 0
Performance
I'm not a database expert nor do I think that mqttDB as of today is good at scaling. mqttDB handles memory quite inefficient, the whole database is kept in memory in the core and all the worker processes.
mqttDB wasn't designed for storing gigabytes of data, millions of frequently changing documents or thousands of views. The concept was made with a couple of dozen views and a few thousand rarely changing documents of small size in mind. You should find out for yourself if it can deliver sufficient performance for your use case.
Due to the fact that mqttDB publishes all documents and views as retained MQTT messages, you have to be aware that this might - depending on the amount/size of documents/views and the subscription count - put significant load on your MQTT broker and raise it's memory consumption.
Furthermore you should take care that your database clients only subscribe the topics they really need, it should be well considered if it's really needed to subscribe to db/doc/#
. A better approach could possibly be to create views that contains the ids of needed documents for a specific client, let the client first subscribe to that view and then subscribe only to the documents that are specified by the view.
TL;DR mqttDB can under circumstances put significant load on your MQTT broker and has a memory consumption that is a multiple of the database size.
mqttDB copyright (c) 2017 Sebastian Raff. MIT License